Subject: [CDNi] Status of Adaptive Streaming and CDNI draft

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Wed, 23 May 2012 11:36:57 +0000

Hi all,

Next Tuesday we have a planned interim meeting for discussing the combination between HTTP Adaptive Streaming and CDNI. One  of the expected inputs for this meeting is a follow-up draft to draft-brandenburg-cdni-has-00.

We are currently working hard at finishing this draft, but as you might have seen, we have not yet uploaded a new version. Currently we are at a stage where we have a first complete internal draft ready. However, Francois and I have agreed that we rather spend some more time on it so that it fully covers all the areas of the CDNI-HAS combination than upload an incomplete version right now. We are currently planning to upload the draft this Friday (25th of May) at the latest. I hope this gives you all enough time to read the draft before the meeting on Tuesday.

Sorry for the delay.

Ray

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Fri, 25 May 2012 14:18:36 +0000

Hi all,

I've just uploaded a new version of draft-brandenburg-cdni-has.

You can find the document at: http://www.ietf.org/id/draft-brandenburg-cdni-has-01.txt

The draft is meant as an input document for the virtual meeting on Thursday to discuss the impact of HTTP Adaptive Streaming on the CDNI Interfaces. In the draft a number of alternative solutions are presented for each area where the use of HAS might touch with the CDNI Interfaces (e.g. content acquisition, content purge, request routing, logging and URL signing).

I'm looking forward to your comments.

Have a nice weekend!

Ray van Brandenburg

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brandenburg, R. (Ray) van
Sent: woensdag 23 mei 2012 13:37
To: [email-masked]
Subject: [CDNi] Status of Adaptive Streaming and CDNI draft

Hi all,

Sorry for the delay.

Ray

---

From: Kevin J Ma <[email-masked]>
Date: Sat, 26 May 2012 19:37:06 -0400

Hi Ray,

  I read through the updated draft and had a number of comments ahead of
  the meeting.

  First, a general comment about manifest files.  The document seems
  to assume that manifest files will be distributed through the CDN.
  There are many services where this is not the case, often to prevent
  modification.  There is a large focus in the document on how to modify
  manifest files, in some cases where the manifest file itself is not
  necessarily relevant.  I believe there are ways to optimize HAS
  delivery without modifying manifest files, and in imo, manifest
 manipulation falls under content adaptation which the wg declared to
  be out of scope for the initial phase?

  With respect section 2.2, I believe I commented on this in the
  initial draft, but I still feel that the relative vs absolute URL
  discussion is rather misleading.  It seems to imply that:
    a) the HOST portion of a relative URL cannot point to a RR, that
    b) a RR must be accessed through some web service like API, and that
    c) absolute URLs can only point to specific surrogates.
  While these are all valid examples of how to use URLs, they do not
  seem to be typical cases.  For us, a typical service has a DNS
  address which points to a base directory in one or more CDNs.  The
  relative path from that base directory is the same in all CDNs.  The
  hostname does not point to any one surrogate, and each CDN is still
  able to redirect requests as it sees fit.

  With respect to sections 3.1 and 3.2, while I agree that content
  storage and acquisition optimization is important, and that there
  should be metadata which can describe the format of the content, I
  do think the CDN needs to be fully HAS aware, nor do I think that
  the CDN necessarily needs access to the manifest file.  I also do
  not see a "significant" impact to the MI.  The metadata interface
  will have the ability to define metadata that applies to a set of
  content assets, per the META-10 requirement.  Ultimately, the CDN
  needs to be able to respond to content requests from the client,
  even if that client got a manifest file directly from the content
  provider (not from the CDN) and is expecting the content to be in
  the format that was provided to the CDN by the content provider.
  How it got the content and how it stores it is out of scope?

  With respect to section 3.3, I think that a third case is missing,
 where the content provider does not provide the manifest file to the
  CDN (which can be a fairly common case).

  With respect to sections 3.3.2 and 3.3.3, would not DNS-based
  redirection solve the issue by simply directing manifest/chunk
  requests to the dCDN, rather than doing a manifest rewrite for every
  request (especially in the case of live streaming where the manifest
  might be changing on every chunk)?  Also, presumably, the RR would
  only rewrite URLs which were within its own domain (i.e., not
  blackholing ad insertion segments, etc.)?

  With respect to section 3.5, the time component of URL signing is
  not mentioned until section 3.5.3.  Expiration of URL tokens, in
  general, is an issue with HAS.  Robust key management is an arguably
  more reliable approach to content access protection, though that
  would seem to be fairly well out of scope for CDNI.  The proposed
  solution in section 3.5.3, seems to be managing session state?
  Depending on the complexity of the cookie, this could be troublesome
  if there is a failover and session state is not properly synchronized?
  And in the case of live streaming, the manifest is going to be
  requested every time?  How is the state managed in that case?  Is
  the cookie less susceptible to replay attacks than the URL token?
  Will the cookie work across all CDNs?  Moving on to section 3.5.4
  is even more concerning.  What if the content is already encrypted?
  How is authentication being handled on the key server?  Who is
  responsible for auditing the security of the solution?  Is this
  intended to provide DRM?  work with existing DRM?  circumvent
  existing DRM?  Does it only use the DRM/encryption support of the
  delivery protocol?  or is the client expected to implement an
  alternate protocol?  And how is this synchronized across CDNs?
  More generally, are we attempting to define security protocols for
  content delivery?  If so, I would like to see a more formal
 definition of what those requirements are?

  With respect to section 3.6.2, it seems that we just want to be able
 to purge a set of content assets.  Would a URI prefix not be sufficient?

thanx.

--  Kevin J. Ma

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brandenburg, R. (Ray) van
Sent: Friday, May 25, 2012 10:19 AM
To: [email-masked]
Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft

Hi all,

Have a nice weekend!

Ray van Brandenburg

Hi all,

Sorry for the delay.

Ray

---

From: Stef van der Ziel <[email-masked]>
Date: Sun, 27 May 2012 15:03:49 +0200

Hi Kevin,

Actually, many CDNs prefer to serve out both the segments and the manifest files.
Sure, dumb caching/DNS based CDNs can be used to deliver segments and they wouldn't care about segments. They will just pump out the delivered objects. But intelligent CDNs that are actually usable for commercial/secure and manageable HAS, need the manifests.

IMHO the role of a manifest file should not be confused with the role of a referrer file. 
A manifest is to represent the entire content, not just to the client but in the entire chain of encoding, protection, CDN and clients. 
A referrer file is the proper way to point to the (logical) content from any remote location.

We hardly ever see manifest files to be distributed outside of the CDN in reality. It is not a fairly common scenario and should not be. In more automated environments, it can actually be the CDN that creates the manifest.

The assumption that manifest files should or can be distributed offline or outside the CDN is mostly wrong. The assumption that you can point from a manifest to a CDN for the segments won't work since a proper CDN would (should) block direct access to segments to prevent deep linking. But we understand why people make these assumptions, we've heard other statements from HAS enthusiasts that don't make sense in the real world.

Serving out the manifests alongside the segments from the same CDN account is done for multiple reasons, which do not at all adapt the content:

- Logical asset recognition (parsing the manifests so the CDN understands that the segments are part of a logical entity)
- Logical asset management (processing, copying, managing manifests and subsequent segments as if they are one asset)
- Logical asset reporting (reporting manifests and subsequent segments via web interfaces and APIs as if they are one asset)
- Request routing control (CDNs only produce URLs for manifest files and will not accept requests for segments to prevent unnecessary request routing overload by having to request route every individual segment request)
- Access control (CDNs will not allow direct access to segments but only via the manifest file to prevent deep-linking, you don't want any third party to publish a manifest file on an unlicensed portal and then point users to the segments on the CDN without any access control)
- Session control (http streaming is stateless and that is quite dramatic for CDNs because you lose control over the session and over session logging)

There are additional reasons for CDNs to be able to adapt the manifest files but do so without changing the actual content:
- For instance, they could dynamically insert base URLs to point users to a group of servers to improve the availability.
- Or they could dynamically insert tokens into the manifest to control access to segments.
- Or they could dynamically insert session keys to be able to track a unique user session over multiple federated CDNs.
- Or they could dynamically remove higher or lower bit rates to better control the actual QoE on a per request basis.

Concluding: 
To a CDN, the segments aren't actually that interesting. They are just pieces of useless raw data that needs to be protected, managed and served. 
For a CDN, the manifest represents the content and is a critical component so they need to be able to parse, alter and serve them. 

I think the above by itself describes some interesting challenges. Just one example: how are CDNs going to guarantee anti-deeplinking to segments in a federated constellation where multiple nodes of multiple CDNs and request routers need to be aware of each others sessions and tokens, etc? 

My 2 cents.

Kind regards, Stef van der Ziel

-- 
Owner Jet-Stream | StreamZilla
GMT+1 Office: +31 50 5261820 | Mobile: +31 6 23406348
www.jet-stream.com | www.streamzillacdn.com
this communication is confidential

On 27 mei 2012, at 01:37, Kevin J Ma wrote:

> I’ve just uploaded a new version of draft-brandenburg-cdni-has.
>  
> I’m looking forward to your comments.
>  
> Have a nice weekend!
>  
> Ray van Brandenburg
>  
>  
>  
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Kevin J Ma <[email-masked]>
Date: Sun, 27 May 2012 12:00:34 -0400

Hi Stef,

  I was not arguing that a CDN would not prefer to have the manifest.
  I was more arguing that content providers may not trust CDNs with
  the manifest generation/modification.  Securing content, preventing
  unauthorized access, and preventing piracy requires much more than
  simple auth tokens.  DRM is explicitly listed as out-of-scope in
  the charter, so as I said, if the intent is to define a security
  protocol, then I would like to see more requirements.  If, however,
  I have misunderstood, and section 3.5.4 is describing an existing
  feature that is widely supported across CDNs today, that just needs
  CDNI support, then I suppose that would be different.

  As for asset management, I agree the CDN needs to know what files go
  together, but I do not agree that a CDN should be allowed to modify
  a manifest file any way it wants, or generate any manifest it wants
  and present that to the end user.  Manifest files may contain other
 information besides segment file locations, e.g., DRM info, targeted
  ad insertions, subscription-based customizations, etc., which the
  content provider may not trust the CDN with.  I would like to know
  where the boundaries are of what the CDN may modify?  Much of this
  requires subscriber-awareness.  How subscriber-aware are we assuming
 the CDN to be?  One might argue that the CDN should perform all these
 functions and be a one-stop intelligent content delivery shop, but
 that seems improbable in the short-run?

  Perhaps a more general question: Are we talking about making CDNs
  HAS aware, or making CDNI HAS aware?  It feels more like the former,
  with the latter being an after-thought, and it is not clear to me
  how the former fits into the charter?  Going straight from the uCDN
  routing every segment, to the uCDN supporting modification of a half
  dozen manifest formats feels disingenuous.  Is there no BCP for how
  to configure DNS-RR to take the load off the uCDN RR, or a simple
  set of metadata to describe the source content structure which can
  facilitate more efficient content acquisition?

thanx.

--  Kevin J. Ma

From: Stef van der Ziel [mailto:[email-masked]]
Sent: Sunday, May 27, 2012 9:03 AM
To: Kevin J Ma
Cc: Brandenburg, R. (Ray) van; [email-masked]
Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft

Hi Kevin,

Concluding:

My 2 cents.

--
Owner Jet-Stream | StreamZilla
GMT+1 Office: +31 50 5261820 | Mobile: +31 6 23406348
www.jet-stream.com<http://www.jet-stream.com> | www.streamzillacdn.com<http://www.streamzillacdn.com>
this communication is confidential

Hi Ray,

thanx.

--  Kevin J. Ma

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Brandenburg, R. (Ray) van
Sent: Friday, May 25, 2012 10:19 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft

Hi all,

Have a nice weekend!

Ray van Brandenburg

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Brandenburg, R. (Ray) van
Sent: woensdag 23 mei 2012 13:37
To: [email-masked]<mailto:[email-masked]>
Subject: [CDNi] Status of Adaptive Streaming and CDNI draft

Hi all,

Sorry for the delay.

Ray

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer
_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Mon, 28 May 2012 09:17:09 +0000

Hi all,

Kevin, if you want the ability to prevent CDNs from modifying the manifest in some cases, wouldn't we be able to achieve this by adding a simple 'do not change manifest'-boolean to the metadate interface? I think that solves your concern and still leaves CDNs that do want to optimize their delivery with the option of doing so.

Ray

On 27 mei 2012, at 18:00, "Kevin J Ma" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Stef,

thanx.

--  Kevin J. Ma

From: Stef van der Ziel [mailto:[email-masked]]
Sent: Sunday, May 27, 2012 9:03 AM
To: Kevin J Ma
Cc: Brandenburg, R. (Ray) van; [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft

Hi Kevin,

Concluding:

My 2 cents.

Hi Ray,

thanx.

--  Kevin J. Ma

Hi all,

Have a nice weekend!

Ray van Brandenburg

Hi all,

Sorry for the delay.

Ray

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Mon, 28 May 2012 09:37:49 +0000

Hi Kevin,

Thanks for your review. See my comments inline.

On 27 mei 2012, at 01:37, "Kevin J Ma" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ray,

Sure, in some cases the CDN might not deliver the manifest, however in some other cases it will. I think ruling out the latter is not what we want right?

In my opinion, considering manifest manipulation to be content adaptation is stretching the definition of content adaption a little bit. I think Stef already presented enough examples of why a CDN might want to modify the manifest file in a way that is not related to content adaptation at all.

 As I said in my other mail: wouldn't a simple  'do not change manifest'-boolean in the metadate interface solve your concerns in the cases where a Content Provider does not want the manifest to be modified?

I'm not sure I understand you. The idea behind a Relative URL is that it doesn't have a HOST portion.

The example presented is meant as just that, an example. The important part here is in the HOST portion pointing to a RR function. However, if you find this example to be confusing, I can change it.

Absolute URLs without Redirection point to surrogates, Absolute URLs with Redirection explicitely do not.

I agree that this is how some CDNs might do it.  But I'm not sure how this affects 2.2. Section 2.2 is meant as a general overview into the different methods with which chunks might be addressed in a manifest file. Some CDNs might use one option, some CDNs might use another.

If you want, I can add this case.

I think we both agree that the CDNI interfaces should support both HTTP based and DNS based redirection, right? So even if DNS based redirection would solve some issues regarding manifest files, we still need an HTTP based solution.

I will defer this discussion to other.

thanx.

--  Kevin J. Ma

Hi all,

Have a nice weekend!

Ray van Brandenburg

Hi all,

Sorry for the delay.

Ray

---

From: Kevin J Ma <[email-masked]>
Date: Mon, 28 May 2012 10:49:34 -0400

Hi Ray,

  I was also wondering what the optimization options are if the manifest is not
  provided to the CDN for delivery.  Or would there also need be some kind of
 "only use this manifest for optimizing, but do not provide this manifest to
 clients'-boolean?

  Theres also still a question in my mind of how this applies to live content?

thanx.

--  Kevin J. Ma

From: Brandenburg, R. (Ray) van [mailto:[email-masked]]
Sent: Monday, May 28, 2012 5:17 AM
To: Kevin J Ma
Cc: Stef van der Ziel; [email-masked]
Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft

Hi all,

Ray

thanx.

--  Kevin J. Ma

Hi Kevin,

Concluding:

My 2 cents.

Hi Ray,

thanx.

--  Kevin J. Ma

Hi all,

Have a nice weekend!

Ray van Brandenburg

Hi all,

Sorry for the delay.

Ray

---

From: Kevin J Ma <[email-masked]>
Date: Mon, 28 May 2012 12:09:57 -0400

Hi Ray,

> Sure, in some cases the CDN might not deliver the manifest, however in some other cases it will. I think ruling out the latter is not what we want right?

I was more concerned that we may have tried to rule out the former.
If we agree that there is a valid case where the CDN does not deliver
the manifest, I think that it should be covered.

> In my opinion, considering manifest manipulation to be content adaptation is stretching the definition of content adaption a little bit.  I think Stef already presented enough examples of why a CDN…

I think it's a slippery slope.  Forbidding changes to data is pretty
clear cut.  When you start making exceptions, it raises concerns?
What is it going to break?  Who might stretch the boundaries of what
would be reasonable to modify?  How does it fit into the different
distribution paradigms?

There's no question that a CDN might want to modify a manifest.  The
question is should the CDN be allowed to, and if it is, what are the
limits to what it is allowed to modify?  There must be defined limits.

>  might be changing on every chunk)?
>

Certainly, I agree that both DNS and HTTP redirects should be
supported.  I was trying to understand if there was "significant
signalling overhead" in both cases?  or if there are other factors
involved, e.g., the redirection method.  It might be helpful to expand
the discussion of advantages and disadvantages for the different cases?

> I'm not sure I understand you. The idea behind a Relative URL is that it doesn't have a HOST portion.

The manifest has a host from which it was retrieved.  In your example,
that host is a surrogate:

  http://surrogate.server.cdn.example.com/content_1/manifest.xml

but that could have been a RR, that uses either DNS or HTTP redirects:

  http://rr.cdn.example.com/content_1/manifest.xml

and that the relative paths could have been appended to the RR host,
(as would be the case with HLS):

  http://rr.cdn.example.com/content_1/segments/segment1_1.ts

I agree with the brittleness comments in section 3.3.1.  Perhaps some
text to that affect in section 2 would clarify it for the linear reader?

though, the RR is going to need to be aware of the idiosyncrasies of
each protocol and support all those brittle clients?

> The example presented is meant as just that, an example. The important part here is in the HOST portion pointing to a RR function. However, if you find this example to be confusing, I can change it.

It was not clear to me if the path was significant.  Perhaps a second
example with just the host name difference would clarify that?

  http://rr.cdn.example.com/content_1/segments/segment1_1.ts

thanx.

--  Kevin J. Ma

From: Brandenburg, R. (Ray) van [mailto:[email-masked]]
Sent: Monday, May 28, 2012 5:38 AM
To: Kevin J Ma
Cc: [email-masked]; Stef van der Ziel
Subject: Re: Status of Adaptive Streaming and CDNI draft

Hi Kevin,

thanx.

--  Kevin J. Ma

Hi all,

Have a nice weekend!

Ray van Brandenburg

Hi all,

Sorry for the delay.

Ray

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 28 May 2012 20:09:50 +0100

Stef,

> Actually, many CDNs prefer to serve out both the segments and the manifest files.
<snip>
> The assumption that manifest files should or can be distributed offline or outside the CDN is mostly wrong.

I'd disagree. I've seen live deployments of both cases of distributing manifests through the CDN and out of band of the CDN so I don't think we can make an assumption either way here.

I think it would be useful for the group to consciously distinguish between "core" CDNI capabilities and "value add" CDNI capabilities, where I define "core" as being those things absolutely required for end to end content delivery etc. to work across a set of interconnected CDNs and "value add" as everything else (e.g. provides an optimisation/efficiency gain or is a "nice to have" etc.).

IMO HAS awareness, manifest awareness, manifest re-writing are all "value add" as I believe we should be able to build a working CDNI architecture that can deliver HAS at scale without requiring those things. Having them provides benefits but is not absolutely required for a scalable system.

Ben

> The assumption that you can point from a manifest to a CDN for the segments won't work since a proper CDN would (should) block direct access to segments to prevent deep linking. But we understand why people make these assumptions, we've heard other statements from HAS enthusiasts that don't make sense in the real world.
>

---

From: Stef van der Ziel <[email-masked]>
Date: Tue, 29 May 2012 08:03:46 +0200

Hi Ben,

I know many CDNs that require manifests to be distributed via their CDN. It is mandatory. So if these CDNs would ever be used in federated scenarios, then federation must support this. 

Verstuurd vanaf mijn iPad

---

From: Stef van der Ziel <[email-masked]>
Date: Tue, 29 May 2012 09:05:38 +0200

Hi Kevin,

Concluding: 

My 2 cents.

---

From: Stef van der Ziel <[email-masked]>
Date: Tue, 29 May 2012 09:06:30 +0200

Hi Kevin,

>   CDNI support, then I suppose that would be different.

In general CDNs must offer the ability to secure access to content. 
Access restriction and DRM can complement each other and don't necessarily overlap.
Many CDNs use tokens between portals and request routers and between request routers and delivery nodes to prevent unauthorized access to content.

However being a stateless and segmented technology, HAS introduces a new massive gap in the security by having manifest files in between the request router and the actual content. So it is a responsibility for the CDN to close this gap. 

I know that many platforms who call themselves CDNs are nothing more than a managed caching environment. So you can pull anything through. So coming from this angle it makes sense to assume that you can simply distribute manifests besides the CDN. I'm trying to educate here that this vision is too simple and that we foresee that content providers will demand from CDNs that their content is protected by actively managing the manifests. 

Doing nothing about manifest control, these passive CDNs have a wide open security problem. I see many possibilities for people to reconstruct manifests and abuse federated CDNs by directly pulling off objects from caches. 

If these CDNs would allow direct access to segments, that would be a blocking issue for other CDNs to actually federate with these CDNs. Because it breaks the level of security they are offering to their content publishing customers.

>  that seems improbable in the short-run?

The real problem is that manifest files are quite open, not well designed and immature so everyone in the value chain thinks they can just use and abuse the manifest file for whatever purpose they have. 

Content publishers may want to dynamically adjust the manifest files to actually change the content on a per request basis. 

At the same time CDNs must be able to adjust the manifest files to do session tracking, access protection, management, etc. Without actually changing the content by the way! 

These requirements can't be supported at the same time today. In my view the core role of a manifest is to instruct the client how to reconstruct segments into a fluent stream. However there are secondary roles which are in conflict: content adaptation (ad insertion for insance) and CDN distribution management, asset management, session management, access management.

The solution would be to wait for manifest files to become more mature. I prefer to have manifest files roles to be split into content management manifests and distribution management manifests. 

Anyway it is too easy to assume that CDNs don't change manifests so they don't need to serve out manifests. They do, so CDNi should be aware of it. It is not a matter of being an advanced feature, it is how many CDNs simply work from a core philosophy around HAS.

I'm not asking CDNi to make serving out manifests mandatory, because that would be a similar mistake the other way around, what i propose is that CDNi should be aware of which CDNs cannot control manifests, and which CDNs make manifest control mandatory.

>   facilitate more efficient content acquisition?

I think you hit a weak spot in CDNi. Some CDNs use passive DNS rr and others use active HTTP rr. Some support both. Some also use redirect instructional files which IMHO is the best technology since it is active and guarantees much higher uptime and performance. If you want I can share more details about this because it would be a great feature for CDNi.

You are right that active rr CDNs may not want to federate to DNS based CDNs because their service level would drop below the SLA they offered to their customer. And you are right that some scenarios may simply not work, for instance when a uCDN manifest based anti-deeplinking and a dCDN hasn't implemented this. Some CDNs don't care about manifests, others need them to do their job. It isn't guaranteed that CDNs are always interchangeable. 

So that is why it is so important that CDNi doesn't rule out specific technology visions, architecture designs or technology choices. It should support these different flavors and definitely not rule out specific ones. And this is a typical example of information that should be shared between CDNs via a capabilities API, so CDNs can decide if they want to federate with other CDNs that cannot support the features they require.

Best Stef

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Tue, 29 May 2012 08:00:25 +0000

Hi Kevin,

Comments inline.

Best regards,

Ray

From: Kevin J Ma [mailto:[email-masked]]
Sent: maandag 28 mei 2012 18:10
To: Brandenburg, R. (Ray) van
Cc: [email-masked]; Stef van der Ziel
Subject: RE: Status of Adaptive Streaming and CDNI draft

Hi Ray,

RvB: My goal was not to rule out anything (although I agree with Stef's comment that having the manifest file be delivered by the Content Provider does present some problems). However, in the case where the manifest file is delivered by the Content Provider, wouldn't that force the manifest file to use Absolute URLs?

RvB: In the case of section 3.3.2, it is the uCDN who modifies the manifest. I would guess that the uCDN has (should have) a pretty good idea of what he discussed with the Content Provider about the possibilities of modifying the manifest. Do you agree that we don't have a problem in that case?

As for section 3.3.3, where the dCDN does some of the manifest manipulation, I agree that we need to have some guidelines on what can en what can't be modified.

RvB: I'm not familiar enough with DNS CDNs to answer your question. If you want, maybe you can write some text that details the DNS-redirection scenario better than the current draft?

RvB: That would only be the case if the manifest were delivered by the RR function, right?

RvB: I can add this to the next version.

RvB: Yes, that's a good idea. I will add this to the next version.

thanx.

--  Kevin J. Ma

From: Brandenburg, R. (Ray) van [mailto:[email-masked]]
Sent: Monday, May 28, 2012 5:38 AM
To: Kevin J Ma
Cc: [email-masked]<mailto:[email-masked]>; Stef van der Ziel
Subject: Re: Status of Adaptive Streaming and CDNI draft

Hi Kevin,

thanx.

--  Kevin J. Ma

Hi all,

Have a nice weekend!

Ray van Brandenburg

Hi all,

Sorry for the delay.

Ray

---

From: "Theodore Zahariadis" <[email-masked]>
Date: Tue, 29 May 2012 11:08:57 +0300

Dear all,

Just some additional (simplified?) thoughts/considerations to the
discussion..

I fully agree that changing the manifest files can give some flexibility and
good (short term) results.

Yet, it is like hacking the application! Just like changing on the fly an
HTTP page that is being downloaded. 

And finally, affecting the provided service; thus it could complicate the
end-to-end business model.

I think that drastically changing the manifest files would make CDNi too
application specific (embed too much application specific intelligence),
while on the other hand be prone to updates of the  manifest files'
structure (updating the standard structure of the manifest files to support
a new video format will cause changes to CDNi!). 

With respect to the security, I guess that content chunks (or some of the
chunks) could be encrypted following the CCN approach. Thus, only the users
that have  the relevant decryption keys could actually use them.

Best regards,

Theodore

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brandenburg, R. (Ray) van
Sent: Tuesday, May 29, 2012 11:00 AM
To: Kevin J Ma
Cc: [email-masked]
Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft

Hi Kevin,

Comments inline.

Best regards,

Ray

Hi Ray,

> Sure, in some cases the CDN might not deliver the manifest, however in
some other cases it will. I think ruling out the latter is not what we want
right?

RvB: My goal was not to rule out anything (although I agree with Stef's
comment that having the manifest file be delivered by the Content Provider
does present some problems). However, in the case where the manifest file is
delivered by the Content Provider, wouldn't that force the manifest file to
use Absolute URLs? 

> In my opinion, considering manifest manipulation to be content adaptation
is stretching the definition of content adaption a little bit.  I think Stef
already presented enough examples of why a CDN might want to modify the
manifest file in a way that is not related to content adaptation at all.

distribution paradigms?

RvB: In the case of section 3.3.2, it is the uCDN who modifies the manifest.
I would guess that the uCDN has (should have) a pretty good idea of what he
discussed with the Content Provider about the possibilities of modifying the
manifest. Do you agree that we don't have a problem in that case? 

As for section 3.3.3, where the dCDN does some of the manifest manipulation,
I agree that we need to have some guidelines on what can en what can't be
modified.

> I think we both agree that the CDNI interfaces should support both HTTP
based and DNS based redirection, right? So even if DNS based redirection
would solve some issues regarding manifest files, we still need an HTTP
based solution.

RvB: I'm not familiar enough with DNS CDNs to answer your question. If you
want, maybe you can write some text that details the DNS-redirection
scenario better than the current draft?

RvB: That would only be the case if the manifest were delivered by the RR
function, right?

> The example presented is meant as just that, an example. The important
part here is in the HOST portion pointing to a RR function. However, if you
find this example to be confusing, I can change it. 

 

thanx.

--  Kevin J. Ma

Hi Kevin,

On 27 mei 2012, at 01:37, "Kevin J Ma" <[email-masked]> wrote:

Hi Ray,

  the meeting.

 

Sure, in some cases the CDN might not deliver the manifest, however in some
other cases it will. I think ruling out the latter is not what we want
right?

In my opinion, considering manifest manipulation to be content adaptation is
stretching the definition of content adaption a little bit. I think Stef
already presented enough examples of why a CDN might want to modify the
manifest file in a way that is not related to content adaptation at all.

 As I said in my other mail: wouldn't a simple  'do not change
manifest'-boolean in the metadate interface solve your concerns in the cases
where a Content Provider does not want the manifest to be modified?

I'm not sure I understand you. The idea behind a Relative URL is that it
doesn't have a HOST portion. 

The example presented is meant as just that, an example. The important part
here is in the HOST portion pointing to a RR function. However, if you find
this example to be confusing, I can change it. 

Absolute URLs without Redirection point to surrogates, Absolute URLs with
Redirection explicitely do not. 

I agree that this is how some CDNs might do it.  But I'm not sure how this
affects 2.2. Section 2.2 is meant as a general overview into the different
methods with which chunks might be addressed in a manifest file. Some CDNs
might use one option, some CDNs might use another. 

 

I think we both agree that the CDNI interfaces should support both HTTP
based and DNS based redirection, right? So even if DNS based redirection
would solve some issues regarding manifest files, we still need an HTTP
based solution.

 

thanx.

--  Kevin J. Ma

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brandenburg, R. (Ray) van
Sent: Friday, May 25, 2012 10:19 AM
To: [email-masked]
Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft

Hi all,

You can find the document at:
<http://www.ietf.org/id/draft-brandenburg-cdni-has-01.txt>
http://www.ietf.org/id/draft-brandenburg-cdni-has-01.txt

The draft is meant as an input document for the virtual meeting on Thursday
to discuss the impact of HTTP Adaptive Streaming on the CDNI Interfaces. In
the draft a number of alternative solutions are presented for each area
where the use of HAS might touch with the CDNI Interfaces (e.g. content
acquisition, content purge, request routing, logging and URL signing). 

Have a nice weekend!

Ray van Brandenburg

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brandenburg, R. (Ray) van
Sent: woensdag 23 mei 2012 13:37
To: [email-masked]
Subject: [CDNi] Status of Adaptive Streaming and CDNI draft

Hi all,

Next Tuesday we have a planned interim meeting for discussing the
combination between HTTP Adaptive Streaming and CDNI. One  of the expected
inputs for this meeting is a follow-up draft to
draft-brandenburg-cdni-has-00. 

We are currently working hard at finishing this draft, but as you might have
seen, we have not yet uploaded a new version. Currently we are at a stage
where we have a first complete internal draft ready. However, Francois and I
have agreed that we rather spend some more time on it so that it fully
covers all the areas of the CDNI-HAS combination than upload an incomplete
version right now. We are currently planning to upload the draft this Friday
(25th of May) at the latest. I hope this gives you all enough time to read
the draft before the meeting on Tuesday. 

Sorry for the delay.

Ray

This e-mail and its contents are subject to the DISCLAIMER at
http://www.tno.nl/emaildisclaimer

---

From: Scott Wainner <[email-masked]>
Date: Tue, 29 May 2012 07:52:15 -0400

On 5/29/12 3:06 AM, Stef van der Ziel wrote:
> Hi Kevin,
>
> Op 27 mei 2012 om 18:00 heeft Kevin J Ma <[email-masked] 
> <mailto:[email-masked]>> het volgende geschreven:
>
>> Hi Stef,
>>
> Many CDNs use tokens between portals and request routers and between 
> request routers and delivery nodes to prevent unauthorized access to 
> content.
>
> However being a stateless and segmented technology, HAS introduces a 
> new massive gap in the security by having manifest files in between 
> the request router and the actual content. So it is a responsibility 
> for the CDN to close this gap.
>
> I know that many platforms who call themselves CDNs are nothing more 
> than a managed caching environment. So you can pull anything through. 
> So coming from this angle it makes sense to assume that you can simply 
> distribute manifests besides the CDN. I'm trying to educate here that 
> this vision is too simple and that we foresee that content providers 
> will demand from CDNs that their content is protected by actively 
> managing the manifests.
>
> Doing nothing about manifest control, these passive CDNs have a wide 
> open security problem. I see many possibilities for people to 
> reconstruct manifests and abuse federated CDNs by directly pulling off 
> objects from caches.
>
> If these CDNs would allow direct access to segments, that would be a 
> blocking issue for other CDNs to actually federate with these CDNs. 
> Because it breaks the level of security they are offering to their 
> content publishing customers.
I think we need to address the security in several different context:

a) CSP -> uCDN RR
b) uCDN -> dCDN RR
c) dCDN RR -> dCDN Delivery Node

If I understand your 'deep-linking' comment, you're referring to 
hand-off (c) above where some external entity obtains the URL that the 
dCDN RR would have provided.  I'm thinking the CDN-I may be focused 
specifically on the hand-off (b) above.  While we define a security 
mechanism for (b), we need to understand there are various methods for 
(c) above and they should not interfere with one another.

If we break the security problem in these three transactions, we can 
still allow the dCDN to choose a method of securing the HAS transactions 
between the client and dCDN using a method that does not override the 
security method using between the uCDN and dCDN.
> The real problem is that manifest files are quite open, not well 
> designed and immature so everyone in the value chain thinks they can 
> just use and abuse the manifest file for whatever purpose they have.
>
> Content publishers may want to dynamically adjust the manifest files 
> to actually change the content on a per request basis.
>
> At the same time CDNs must be able to adjust the manifest files to do 
> session tracking, access protection, management, etc. Without actually 
> changing the content by the way!
>
> These requirements can't be supported at the same time today. In my 
> view the core role of a manifest is to instruct the client how to 
> reconstruct segments into a fluent stream. However there are secondary 
> roles which are in conflict: content adaptation (ad insertion for 
> insance) and CDN distribution management, asset management, session 
> management, access management.
>
> The solution would be to wait for manifest files to become more 
> mature. I prefer to have manifest files roles to be split into content 
> management manifests and distribution management manifests.
I like this model, but as you say, the Manifest/MPD needs a BaseURL that 
is a Relative URL such that the client will refer back to the Delivery 
Node for each segment request.
>
> Anyway it is too easy to assume that CDNs don't change manifests so 
> they don't need to serve out manifests. They do, so CDNi should be 
> aware of it. It is not a matter of being an advanced feature, it is 
> how many CDNs simply work from a core philosophy around HAS.
>
> I'm not asking CDNi to make serving out manifests mandatory, because 
> that would be a similar mistake the other way around, what i propose 
> is that CDNi should be aware of which CDNs cannot control manifests, 
> and which CDNs make manifest control mandatory.
Is this a binary option?  Manifest may be modified / may not be modified?

> I think you hit a weak spot in CDNi. Some CDNs use passive DNS rr and 
> others use active HTTP rr. Some support both. Some also use redirect 
> instructional files which IMHO is the best technology since it is 
> active and guarantees much higher uptime and performance. If you want 
> I can share more details about this because it would be a great 
> feature for CDNi.
>
> Youare right that active rr CDNs may not want to federate to DNS based 
> CDNs because their service level would drop below the SLA they offered 
> to their customer. And you are right that some scenarios may simply 
> not work, for instance when a uCDN manifest based anti-deeplinking and 
> a dCDN hasn't implemented this. Some CDNs don't care about manifests, 
> others need them to do their job. It isn't guaranteed that CDNs are 
> always interchangeable.
Sounds like a capability exchange that the dCDN must provide some means 
of manifest management in order to comply with the uCDN's SLA requirements.
>
> So that is why it is so important that CDNi doesn't rule out specific 
> technology visions, architecture designs or technology choices. It 
> should support these different flavors and definitely not rule out 
> specific ones. And this is a typical example of information that 
> should be shared between CDNs via a capabilities API, so CDNs can 
> decide if they want to federate with other CDNs that cannot support 
> the features they require.
>
> Best Stef
>
>
>> thanx.
>>
>> --  Kevin J. Ma
>>
>> *From:*Stef van der Ziel [mailto:[email-masked]]
>> *Sent:* Sunday, May 27, 2012 9:03 AM
>> *To:* Kevin J Ma
>> *Cc:* Brandenburg, R. (Ray) van; [email-masked] <mailto:[email-masked]>
>> *Subject:* Re: [CDNi] Status of Adaptive Streaming and CDNI draft
>>
>> Hi Kevin,
>>
>> Sure, dumb caching/DNS based CDNs can be used to deliver segments and 
>> they wouldn't care about segments. They will just pump out the 
>> delivered objects. But intelligent CDNs that are actually usable for 
>> commercial/secure and manageable HAS, need the manifests.
>>
>> A manifest is to represent the entire content, not just to the client 
>> but in the entire chain of encoding, protection, CDN and clients.
>>
>> We hardly ever see manifest files to be distributed outside of the 
>> CDN in reality. It is not a fairly common scenario and should not 
>> be. In more automated environments, it can actually be the CDN that 
>> creates the manifest.
>>
>> The assumption that manifest files should or can be distributed 
>> offline or outside the CDN is mostly wrong. The assumption that you 
>> can point from a manifest to a CDN for the segments won't work since 
>> a proper CDN would (should) block direct access to segments to 
>> prevent deep linking. But we understand why people make these 
>> assumptions, we've heard other statements from HAS enthusiasts that 
>> don't make sense in the real world.
>>
>> Serving out the manifests alongside the segments from the same CDN 
>> account is done for multiple reasons, which do not at all adapt the 
>> content:
>>
>> - Logical asset recognition (parsing the manifests so the CDN 
>> understands that the segments are part of a logical entity)
>>
>> - Logical asset management (processing, copying, managing manifests 
>> and subsequent segments as if they are one asset)
>>
>> - Logical asset reporting (reporting manifests and subsequent 
>> segments via web interfaces and APIs as if they are one asset)
>>
>> - Request routing control (CDNs only produce URLs for manifest files 
>> and will not accept requests for segments to prevent unnecessary 
>> request routing overload by having to request route every individual 
>> segment request)
>>
>> - Access control (CDNs will not allow direct access to segments but 
>> only via the manifest file to prevent deep-linking, you don't want 
>> any third party to publish a manifest file on an unlicensed portal 
>> and then point users to the segments on the CDN without any access 
>> control)
>>
>> - Session control (http streaming is stateless and that is quite 
>> dramatic for CDNs because you lose control over the session and over 
>> session logging)
>>
>> There are additional reasons for CDNs to be able to adapt the 
>> manifest files but do so without changing the actual content:
>>
>> - For instance, they could dynamically insert base URLs to point 
>> users to a group of servers to improve the availability.
>>
>> - Or they could dynamically insert session keys to be able to track a 
>> unique user session over multiple federated CDNs.
>>
>> - Or they could dynamically remove higher or lower bit rates to 
>> better control the actual QoE on a per request basis.
>>
>> Concluding:
>>
>> To a CDN, the segments aren't actually that interesting. They are 
>> just pieces of useless raw data that needs to be protected, managed 
>> and served.
>>
>> For a CDN, the manifest represents the content and is a critical 
>> component so they need to be able to parse, alter and serve them.
>>
>> I think the above by itself describes some interesting challenges. 
>> Just one example: how are CDNs going to guarantee anti-deeplinking to 
>> segments in a federated constellation where multiple nodes of 
>> multiple CDNs and request routers need to be aware of each others 
>> sessions and tokens, etc?
>>
>> My 2 cents.
>>
>> www.jet-stream.com <http://www.jet-stream.com> | 
>> www.streamzillacdn.com <http://www.streamzillacdn.com>
>>
>> *From:[email-masked] 
>> <mailto:[email-masked]>[mailto:[email-masked]]*On 
>> Behalf Of*Brandenburg, R. (Ray) van
>> *Sent:*Friday, May 25, 2012 10:19 AM
>> *To:[email-masked] <mailto:[email-masked]>
>> *Subject:*Re: [CDNi] Status of Adaptive Streaming and CDNI draft
>>
>> Hi all,
>>
>> You can find the document 
>> at:http://www.ietf.org/id/draft-brandenburg-cdni-has-01.txt
>>
>> The draft is meant as an input document for the virtual meeting on 
>> Thursday to discuss the impact of HTTP Adaptive Streaming on the CDNI 
>> Interfaces. In the draft a number of alternative solutions are 
>> presented for each area where the use of HAS might touch with the 
>> CDNI Interfaces (e.g. content acquisition, content purge, request 
>> routing, logging and URL signing).
>>
>> *From:[email-masked] 
>> <mailto:[email-masked]>[mailto:[email-masked]]*On 
>> Behalf Of*Brandenburg, R. (Ray) van
>> *Sent:*woensdag 23 mei 2012 13:37
>> *To:[email-masked] <mailto:[email-masked]>
>> *Subject:*[CDNi] Status of Adaptive Streaming and CDNI draft
>>
>> Hi all,
>>
>> combination between HTTP Adaptive Streaming and CDNI. One  of the 
>> expected inputs for this meeting is a follow-up draft to 
>> We are currently working hard at finishing this draft, but as you 
>> might have seen, we have not yet uploaded a new version. Currently we 
>> are at a stage where we have a first complete internal draft ready. 
>> However, Francois and I have agreed that we rather spend some more 
>> time on it so that it fully covers all the areas of the CDNI-HAS 
>> combination than upload an incomplete version right now. We are 
>> currently planning to upload the draft this Friday (25^th of May) at 
>> the latest. I hope this gives you all enough time to read the draft 
>> before the meeting on Tuesday.
>>
>> Sorry for the delay.
>>
>> Ray
>>
>> This e-mail and its contents are subject to the DISCLAIMER 
>> athttp://www.tno.nl/emaildisclaimer
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Stef van der Ziel <[email-masked]>
Date: Tue, 29 May 2012 19:48:23 +0200

Hi Scott,

> c) dCDN RR -> dCDN Delivery Node

Actually it is:

a) CSP -> uCDN RR
b) uCDN -> dCDN RR
c) dCDN RR -> dCDN Delivery Node Manifest file
d) dCDN manifest file -> dCDN (segmented) data

BTW, in our view a higher layered entity can either be a CSP or a uCDN. They are inter-exchangable. 

> If I understand your 'deep-linking' comment, you're referring to hand-off (c) above where some external entity obtains the URL that the dCDN RR would have provided.  I'm thinking the CDN-I may be focused specifically on the hand-off (b) above.  While we define a security mechanism for (b), we need to understand there are various methods for (c) above and they should not interfere with one another.
> 
> If we break the security problem in these three transactions, we can still allow the dCDN to choose a method of securing the HAS transactions between the client and dCDN using a method that does not override the security method using between the uCDN and dCDN.

True. That is how we work today as well. The token between A and B does not affect the token between B and C etc. We are not passing along tokens, but are creating new ones in every step. Othewise you'll end up integrating and exchanging tokens between many parties and that will never work from an operational / SI point of view. 

> I like this model,

Thanks. I would highly recommended to split content management and adaption and CDN-client session management. With todays manifests that is a blurred mess, unfortunately it is with all HAS technologies including DASH. 

> but as you say, the Manifest/MPD needs a BaseURL that is a Relative URL such that the client will refer back to the Delivery Node for each segment request.  

Correct. You don't want clients to go through request routers for every segment, that is highly inefficient. 

> Is this a binary option?  Manifest may be modified / may not be modified?

Yes it is binary but in this way: CDN doesn't care about manifests / CDN requires manifests to be modified

Best Stef

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Tue, 29 May 2012 15:17:31 -0700

Hi Kevin. Thanks for your feedback. I've separated the URL Signing as a
sub-topic of HAS draft.

Comments below.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Kevin J Ma
Sent: Saturday, May 26, 2012 4:37 PM
To: Brandenburg, R. (Ray) van; [email-masked]
Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft

<snip>

  general, is an issue with HAS.  

KL> The "time period" or freshness of the signed URL is mentioned in
section 3.5. Perhaps it's a bit cursory as an example of potential
authorization parameters in the embedded URL. I can dedicate a paragraph
in this section for URL expiration. NTP can be used to sync the clocks
on the entities that sign and validate the URL. Not sure if the logging
interface requires some timestamp mediation? If so, maybe the same
technique can be applied.

  Robust key management is an arguably

  would seem to be fairly well out of scope for CDNI.  

KL> If the key management is out-of-band from the CDNI Interfaces, then
it would be out of scope.

  The proposed

 

KL> Yes, this option is for per-HAS-session. There are various schemes
to handle failover scenario, which is out of scope. 

  requested every time?  How is the state managed in that case?  

KL> For live streaming, this depends on the HAS technology. I don't
think the draft needs to get into the details of each technology. The
fundamental concept is there is a manifest file for a Content Item which
needs to be signed. And subsequent request  for related content (i.e.
chunk and sub-level manifest file) is associated with the authorization.

  Is

  Will the cookie work across all CDNs?  

KL> I can add some more info on replay protection on the cookie. Cookie
expiration time can be used. No time synchronization issue for the same
surrogate case. Failover across surrogates in same CDN requires NTP or
other clock synchronization. Cookie method is not intended to work
across CDNs since redirection should happen in this case.

  Moving on to section 3.5.4

KL> CDN is not aware and don't care if the content is encrypted. The
session-based encryption is only a technique to link to the authorized
state of the Content Item.  

  delivery protocol?  

KL> There is no intention for DRM. It is an independent matter. This is
only for encryption for the HAS session after URL of the manifest file
is validated. One way to look at sections 3.5.3 and 3.5.4 is that after
the initial URL for the Content Item is validated via URL Signing,
access to related Content Collection can use alternative methods such as
authorization token or session-based encryption during the HAS session.
The advantage is these techniques do not require URL to be rewritten
which is the method used by URL Signing. I should probably add one more
option where all content for the Content Item use URL Signing for
authorization.

or is the client expected to implement an

  alternate protocol?  

KL> It's not the intent to come up with new protocol. For example, HLS
already supports this method. The section points out various solution
options that are applicable to URL Signing. This may be applicable to
some of the HAS technology as I'm not clear if it's universally
possible.

And how is this synchronized across CDNs?

KL> See earlier comment about across CDNs. Both methods are limited to
same CDN.

KL> No, there is no attempt to define security protocols. The objective
was to identify the options that are available when URL Signing is used
for authorization of HAS content. Once the CDN is HAS-aware, then
related content can be grouped. There are several techniques used to
group the chunks and possibly sub-level manifest files for the HAS
session. There are advantages and disadvantages of each technique.

Kent

<snip>

--  Kevin J. Ma

Hi all,

The draft is meant as an input document for the virtual meeting on
Thursday to discuss the impact of HTTP Adaptive Streaming on the CDNI
Interfaces. In the draft a number of alternative solutions are presented
for each area where the use of HAS might touch with the CDNI Interfaces
(e.g. content acquisition, content purge, request routing, logging and
URL signing). 

Have a nice weekend!

Ray van Brandenburg

Hi all,

We are currently working hard at finishing this draft, but as you might
have seen, we have not yet uploaded a new version. Currently we are at a
stage where we have a first complete internal draft ready. However,
Francois and I have agreed that we rather spend some more time on it so
that it fully covers all the areas of the CDNI-HAS combination than
upload an incomplete version right now. We are currently planning to
upload the draft this Friday (25th of May) at the latest. I hope this
gives you all enough time to read the draft before the meeting on
Tuesday. 

Sorry for the delay.

Ray

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 30 May 2012 00:14:29 -0400

Hi Kent,

  With respect to token time periods, it is difficult to estimate when
  a segment is actually going to be requested.  Web pages typically
  request everything immediately, but that's not the case with HAS.
  Maybe the player gets paused and its a while between manifest request
 and segment request, or maybe seeking causes segments to be played
 out of sequence.  You often end up needing long time periods on all
 segments to prevent undue rejections, which limits the value of
  having URL tokens?

  To Scott's point, we may need to differentiate between URL tokens on
  inter-CDN acquisition vs dCDN-to-end-user tokens.  Perhaps there is
  more value for the former than the latter?

> What if the content is already encrypted?
>
> KL> CDN is not aware and don't care if the content is encrypted.

  I don't think this is true.  Depending on how the encryption is
  being implemented, the CDN has to care if the content is already
  encrypted.  You mention HLS supporting encryption.  That is true,
  but you cannot double encrypt the content?  If we are talking about
  reusing existing HAS protocol support, then I think you need to care
  what existing encryption and DRM are in use.

  Are you assuming this would only be performed on unencrypted content
  and that the CDN would have some business agreement with the CP to
  implement a DRM packaging function?  If not, I don't think we can
  assume one way or the other if the content is already encrypted.
  The manifest may not be available, and even if it is, the manifest
  may not tell you if the content is encrypted, especially if it is
  using a third party DRM.

  Were you anticipating that the encryption keys would be session
  specific?  Would they be client (subscriber) specific?  I would be
  interested in more details on the security of the key exchange?  If
  the keys are easily obtained, then there's little value in having
  segment encryption (as it pertains to authorization)?

thanx.

--  Kevin J. Ma

From: Kent Leung (kleung) [mailto:[email-masked]]
Sent: Tuesday, May 29, 2012 6:18 PM
To: Kevin J Ma; Brandenburg, R. (Ray) van; [email-masked]
Subject: URL Signing in Adaptive Streaming and CDNI draft

Hi Kevin. Thanks for your feedback. I've separated the URL Signing as a sub-topic of HAS draft.

Comments below.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin J Ma
Sent: Saturday, May 26, 2012 4:37 PM
To: Brandenburg, R. (Ray) van; [email-masked]
Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft

<snip>

KL> The "time period" or freshness of the signed URL is mentioned in section 3.5. Perhaps it's a bit cursory as an example of potential authorization parameters in the embedded URL. I can dedicate a paragraph in this section for URL expiration. NTP can be used to sync the clocks on the entities that sign and validate the URL. Not sure if the logging interface requires some timestamp mediation? If so, maybe the same technique can be applied.

KL> If the key management is out-of-band from the CDNI Interfaces, then it would be out of scope.

  The proposed

KL> Yes, this option is for per-HAS-session. There are various schemes to handle failover scenario, which is out of scope.

KL> For live streaming, this depends on the HAS technology. I don't think the draft needs to get into the details of each technology. The fundamental concept is there is a manifest file for a Content Item which needs to be signed. And subsequent request  for related content (i.e. chunk and sub-level manifest file) is associated with the authorization.

  Is

KL> I can add some more info on replay protection on the cookie. Cookie expiration time can be used. No time synchronization issue for the same surrogate case. Failover across surrogates in same CDN requires NTP or other clock synchronization. Cookie method is not intended to work across CDNs since redirection should happen in this case.

KL> CDN is not aware and don't care if the content is encrypted. The session-based encryption is only a technique to link to the authorized state of the Content Item.

KL> There is no intention for DRM. It is an independent matter. This is only for encryption for the HAS session after URL of the manifest file is validated. One way to look at sections 3.5.3 and 3.5.4 is that after the initial URL for the Content Item is validated via URL Signing, access to related Content Collection can use alternative methods such as authorization token or session-based encryption during the HAS session. The advantage is these techniques do not require URL to be rewritten which is the method used by URL Signing. I should probably add one more option where all content for the Content Item use URL Signing for authorization.

KL> It's not the intent to come up with new protocol. For example, HLS  already supports this method. The section points out various solution options that are applicable to URL Signing. This may be applicable to some of the HAS technology as I'm not clear if it's universally possible.

KL> See earlier comment about across CDNs. Both methods are limited to same CDN.

KL> No, there is no attempt to define security protocols. The objective was to identify the options that are available when URL Signing is used for authorization of HAS content. Once the CDN is HAS-aware, then related content can be grouped. There are several techniques used to group the chunks and possibly sub-level manifest files for the HAS session. There are advantages and disadvantages of each technique.

Kent

<snip>

--  Kevin J. Ma

Hi all,

Have a nice weekend!

Ray van Brandenburg

Hi all,

Sorry for the delay.

Ray

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Tue, 29 May 2012 23:31:01 -0700

Hi Kevin. Comments below.

From: Kevin J Ma [mailto:[email-masked]] 
Sent: Tuesday, May 29, 2012 9:14 PM
To: Kent Leung (kleung); Brandenburg, R. (Ray) van; [email-masked]
Subject: RE: URL Signing in Adaptive Streaming and CDNI draft

Hi Kent,

  having URL tokens?

KL> I'm not clear what you mean by "URL tokens". Are you talking about
Option 5.1 or 5.2?  If the latter, then the authorization token is for
the HAS session. This is not per chunk basis. The cookie can be
refreshed periodically during the session. So any chunk can be requested
during the HAS session as long as the cookie has not expired. This is an
issue for the former case.

KL> I agree that there is a difference between the tokens. But URL
Signing is about delivery authorization (or content access control) and
not content acquisition. The scheme used for acquisition does not have
to be the same as for delivery. We should not be figuring out how token
is used for different interfaces (e.g. between CDNs or between dCDN and
end user). Instead, we should be figuring out how to support HAS with
URL Signing. I think there are quite a few methods. Some of them may
depend on the capabilities of the HAS technology. If your point is that
this is not CDNI issue, I don't have a problem with that. CDNI does need
to be aware that URL Signing is used for delivery to end user. This
impacts some of the CDNI Interfaces. As for how URL Signing is optimized
when CDN is HAS-aware, that may not need to be defined. So using
Authorization token, session-based encryption, or some other methods
don't need to be described in detail. Maybe just the concept that the
manifest URL of the Content Item is protected by URL Signing and the
related content is associated for the HAS session is sufficient?

  using a third party DRM.

KL> Maybe I'm missing your point. Double encryption happens all the
time. For example, I have an HTTPS session to a web server over the
business IPSec VPN. In this case, the content is encrypted with DRM. The
content may be transported over VPN between CSP and uCDN or between uCDN
and dCDN. The content may be delivered from dCDN to end user with
session-based encryption.

KL> So far, we've been talking in the context of the HAS session. But
the keying method can be flexible. Anyways, I offered the Session-Based
Encryption as an option to bind the HAS session with the authorized
manifest file for dCDN that is HAS-aware. The intent was to give an
example and not get into the detailed implementation.

Maybe we should step back and look at the following to see if we are on
the right track?

1.       URL Signing is a method to authorize content delivery (or
content access control)

2.       CDNI needs URL Signing support on Request Routing (mandatory),
Metadata (mandatory), and Logging (optional) Interfaces

3.        When URL Signing is used in CDN without HAS-awareness,
everything works fine with some caveats

a.       Relative URL is signed for invariant portion of URL

b.      Request for signed URL needs to be within the expiration period
(this can be an issue)

4.       When URL Signing is used in CDN with HAS-awareness, validation
of the URL for manifest of Original Content assumes that access to the
Content Collection is authorized for the HAS session (Details of the
methods are not CDNI related)

Kent

thanx.

--  Kevin J. Ma

Comments below.

<snip>

  The proposed

 

 

  Is

  delivery protocol?  

  alternate protocol?  

Kent

<snip>

--  Kevin J. Ma

Hi all,

Have a nice weekend!

Ray van Brandenburg

Hi all,

Sorry for the delay.

Ray

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 30 May 2012 08:28:21 -0400

Hi Kent,

KL> Maybe I'm missing your point. Double encryption happens all the time. For example, I have an HTTPS session to a web server over the business IPSec VPN.

This is true, but the termination of those tunnels is in different levels.
L3 for IPSec.  L5+ for HTTPS.  L7+ for HLS.  The order is well defined.
If we are talking about using the encryption support of HLS or some other
HAS protocol, and the encryption has already taken place, the client is
not equipped to recognize that the content is encrypted multiple times.
If we are just talking about using HTTPS, then thats different, since the
transport is terminated at a lower layer than the HAS client decryption?

In another example, if the CP and the client are using a third party DRM,
layering on an additional encryption scheme which the client is forced to
recognize and deal with may not work, e.g., a CP wants to deliver HLS to
iPad, but has a corporate mandate to use Playready DRM and the segments
are encrypted with Playready.  That client is unlikedly to be able to
handle some unexpected extra HLS encryption that a CDN may have added.
In general, the order of the crypto operations is not well defined here.

> Maybe we should step back and look at the following to see if we are on the right track?
> 1.  URL Signing is a method to authorize content delivery (or content access control)
> 2.  CDNI needs URL Signing support on Request Routing (mandatory), Metadata (mandatory), and Logging (optional) Interfaces
> 3.  When URL Signing is used in CDN without HAS-awareness, everything works fine with some caveats
>   b.      Request for signed URL needs to be within the expiration period (this can be an issue)
> 4.  When URL Signing is used in CDN with HAS-awareness, validation of the URL for manifest of Original Content assumes that access to the Content Collection is authorized for the HAS session (Details of the methods are not CDNI related)

I agree with 1 and 2.  I agree with 3, but think that b is a big issue.
I have a fundamental problem with 4, however, in that: if content security
matters, I dont think manifests should be delivered through the CDN, and
without details of the exact (non-CDNI related) methods, I am unable to
assess how secure they are or what they might break in the process?

thanx.

--  Kevin J. Ma

From: Kent Leung (kleung) [mailto:[email-masked]]
Sent: Wednesday, May 30, 2012 2:31 AM
To: Kevin J Ma; Brandenburg, R. (Ray) van; [email-masked]
Subject: RE: URL Signing in Adaptive Streaming and CDNI draft

Hi Kent,

KL> I'm not clear what you mean by "URL tokens". Are you talking about Option 5.1 or 5.2?  If the latter, then the authorization token is for the HAS session. This is not per chunk basis. The cookie can be refreshed periodically during the session. So any chunk can be requested during the HAS session as long as the cookie has not expired. This is an issue for the former case.

KL> I agree that there is a difference between the tokens. But URL Signing is about delivery authorization (or content access control) and not content acquisition. The scheme used for acquisition does not have to be the same as for delivery. We should not be figuring out how token is used for different interfaces (e.g. between CDNs or between dCDN and end user). Instead, we should be figuring out how to support HAS with URL Signing. I think there are quite a few methods. Some of them may depend on the capabilities of the HAS technology. If your point is that this is not CDNI issue, I don't have a problem with that. CDNI does need to be aware that URL Signing is used for delivery to end user. This impacts some of the CDNI Interfaces. As for how URL Signing is optimized when CDN is HAS-aware, that may not need to be defined. So using Authorization token, session-based encryption, or some other methods don't need to be described in detail. Maybe just the concept that the manifest URL of the Content Item is protected by URL Signing and the related content is associated for the HAS session is sufficient?

KL> Maybe I'm missing your point. Double encryption happens all the time. For example, I have an HTTPS session to a web server over the business IPSec VPN. In this case, the content is encrypted with DRM. The content may be transported over VPN between CSP and uCDN or between uCDN and dCDN. The content may be delivered from dCDN to end user with session-based encryption.

KL> So far, we've been talking in the context of the HAS session. But the keying method can be flexible. Anyways, I offered the Session-Based Encryption as an option to bind the HAS session with the authorized manifest file for dCDN that is HAS-aware. The intent was to give an example and not get into the detailed implementation.

Maybe we should step back and look at the following to see if we are on the right track?

1.       URL Signing is a method to authorize content delivery (or content access control)

2.       CDNI needs URL Signing support on Request Routing (mandatory), Metadata (mandatory), and Logging (optional) Interfaces

3.        When URL Signing is used in CDN without HAS-awareness, everything works fine with some caveats

b.      Request for signed URL needs to be within the expiration period (this can be an issue)

4.       When URL Signing is used in CDN with HAS-awareness, validation of the URL for manifest of Original Content assumes that access to the Content Collection is authorized for the HAS session (Details of the methods are not CDNI related)

Kent

thanx.

--  Kevin J. Ma

Comments below.

<snip>

  The proposed

  Is

Kent

<snip>

--  Kevin J. Ma

Hi all,

Have a nice weekend!

Ray van Brandenburg

Hi all,

Sorry for the delay.

Ray

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Wed, 30 May 2012 11:20:34 -0700

From: Kevin J Ma [mailto:[email-masked]] 
Sent: Wednesday, May 30, 2012 5:28 AM
To: Kent Leung (kleung); Brandenburg, R. (Ray) van; [email-masked]
Subject: RE: URL Signing in Adaptive Streaming and CDNI draft

Hi Kent,

business IPSec VPN.

This is true, but the termination of those tunnels is in different
levels.

If we are talking about using the encryption support of HLS or some
other

If we are just talking about using HTTPS, then thats different, since
the

In another example, if the CP and the client are using a third party
DRM,

layering on an additional encryption scheme which the client is forced
to

KL> Agree that the order of crypto operations is needed to function
properly. Have you encountered real world problems with this scenario?

> 4.  When URL Signing is used in CDN with HAS-awareness, validation of
the URL for manifest of Original Content assumes that access to the
Content Collection is authorized for the HAS session (Details of the
methods are not CDNI related)

I have a fundamental problem with 4, however, in that: if content
security

KL> Manifest file delivered via dCDN or not is another factor. This is a
generic HAS issue. We still have to consider the case when manifest file
is from the same dCDN used for chunk delivery for URL Signing. I think
the section can describe how the requests can be associated with an HAS
session to provide the logical bundling for all the content for the
Original Content.

Kent

thanx.

--  Kevin J. Ma

Hi Kent,

  having URL tokens?

  using a third party DRM.

Kent

thanx.

--  Kevin J. Ma

Comments below.

<snip>

  The proposed

 

 

  Is

  delivery protocol?  

  alternate protocol?  

Kent

<snip>

--  Kevin J. Ma

Hi all,

Have a nice weekend!

Ray van Brandenburg

Hi all,

Sorry for the delay.

Ray

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 30 May 2012 14:38:59 -0400

Hi Kent,

KL> Agree that the order of crypto operations is needed to function properly. Have you encountered real world problems with this scenario?

The Playready-HLS scenario is real.  I have not yet had a CDN try to insert
HLS encryption over top of it, and I sincerely hope that I never do....

From: Kent Leung (kleung) [mailto:[email-masked]]
Sent: Wednesday, May 30, 2012 2:21 PM
To: Kevin J Ma; Brandenburg, R. (Ray) van; [email-masked]
Subject: RE: URL Signing in Adaptive Streaming and CDNI draft

Hi Kent,

KL> Agree that the order of crypto operations is needed to function properly. Have you encountered real world problems with this scenario?

KL> Manifest file delivered via dCDN or not is another factor. This is a generic HAS issue. We still have to consider the case when manifest file is from the same dCDN used for chunk delivery for URL Signing. I think the section can describe how the requests can be associated with an HAS session to provide the logical bundling for all the content for the Original Content.

Kent

thanx.

--  Kevin J. Ma

Hi Kent,

Kent

thanx.

--  Kevin J. Ma

Comments below.

<snip>

  The proposed

  Is

Kent

<snip>

--  Kevin J. Ma

Hi all,

Have a nice weekend!

Ray van Brandenburg

Hi all,

Sorry for the delay.

Ray

---

From: "Peterson, Larry" <[email-masked]>
Date: Wed, 30 May 2012 16:00:31 -0400

I apologize for not being able to make the call, but I can't help but wonder
why we're making this so complicated.

The whole point of HTTP-AS is to apply RESTful principles to video delivery,
to leverage the simplicity of HTTP. It seems like a mistake to assume CDNs
are purposely working against that principle, especially when doing so
complicates our ability to define a base/minimal CDNI strategy.

Larry

On May 29, 2012, at 3:06 AM, Stef van der Ziel wrote:

> <ATT00002.c>

---

From: Thomas Stockhammer <[email-masked]>
Date: Wed, 30 May 2012 22:09:00 +0200

+1

/T

>>> https://www.ietf.org/mailman/listinfo/cdni

---
Dr. Thomas Stockhammer (CEO) || [email-masked] || phone +49 89 978980 02 || cell +491725702667 || http://www.nomor-research.com
Nomor Research GmbH  -  Sitz der Gesellschaft: München - Registergericht: München, HRB 165856 – Umsatzsteuer-ID: DE238047637 - Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 31 May 2012 09:15:44 +0200

Hi Larry, Thomas,

Thanks for the useful additional input.
During the extended design team meeting, with respect to the Request Routing question, my perception is that there was a fairly clear consensus for 1) have CDNI support operation without any Manifest File manipulation, 2) possibly allow the uCDN to optionally manipulate manifest files -but that would not be specified by CDNI and would not affect the CDNI interfaces and 3) do not go down the path of specifying Manifest File manipulation by dCDN and specifying extensions to CDNI interfaces to support that.

So the solution proposed will likely not be "so complicated". But it is useful to bring up all the options, have them documented (in cdni-has), identify the pros & cons and then document the rationale for the recommendations that will be made to the group.

Cheers

Francois