Subject: [CDNi] Summary of recommendations regarding CDNI and HAS

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Wed, 25 Jul 2012 07:56:51 +0000

Hi all,

In order to spur some online discussion before the Vancouver meeting next week, I've summarized here the main recommendations from the CDNI & HTTP Adaptive Streaming work we've been doing over the past months (see http://tools.ietf.org/html/draft-brandenburg-cdni-has-03).

Content Acquisition & File Management
-       The recommendation made in the draft is to not do anything specific for HAS regarding Content Acquisition and File Management. This means that the dCDN is not explicitly made aware of any relationship between different chunks and the dCDN handles each chunk as if it were an individual and independent content item. The result is that content acquisition between uCDN and dCDN also happens on a per-chunk basis. The draft does identify some potential improvements in this area which might be taken up after a possible re-chartering of the WG once the initial CDNI specification is complete.

Request Routing & Manifest Files
-       The recommendation made in the draft regarding request routing consists of a mandatory and an optional part. The mandatory part, which each CDN should support, is to perform request routing on a per-chunk basis. This means that, depending on the type of manifest file that is used, there might be an individual inter-CDN request routing operation taking place for each individual chunk. As an optional feature, the draft describes a method wherein the uCDN rewrites the manifest file so that it points directly to the dCDN, reducing request routing overhead. Since the process of manifest file rewriting is a uCDN-internal process, this does not require standardization beyond the existing request routing interface.

Logging
-       The recommendation made in the draft regarding logging also consists of a mandatory and an optional part. As a mandatory requirement, the draft recommends that CDNs support per-chunk logging (e.g. logging each chunk request as if it were an independent content request). As an optional feature, the draft recommends to have a system where the dCDN can include a Content Collection Identifier (CCID) and/or Session Identifier as part of the logging fields, thereby providing the option for a CDN to do per-session logging of HAS content.

URL Signing
-       For CDNs that want to do URL signing, the draft recommends that CDNs support either Flexible URL Signing by the Content Provider or by the uCDN. Both scenarios result in a system where the dCDN can remain unaware of HAS, with either the Content Provider or the uCDN signing the URLs in the manifest file.

Other topics
-       Regarding Content Purge, the draft does not yet include a recommendation but describes two options for dealing with the purge of large numbers of related files from a dCDN. A recommendation for this topic will be added to the next iteration of the draft.
-       The draft recommends that the CDNI Capability Advertisement method includes some way for CDNs to indicate whether they support the HAS-specific optional features recommended in the draft (such as the ability to log CCIDs). Furthermore, the draft recommends that there is some way for dCDNs to indicate whether they require access to manifest in order to be able to perform the delivery of HAS content.

I would like to invite anyone who is interested in the topic and wishes to discuss some of these recommendations in Vancouver, to read the draft (http://tools.ietf.org/html/draft-brandenburg-cdni-has-03) before the meeting, so that we can have a fruitful discussion in Vancouver.

Best regards,

Ray

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

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 25 Jul 2012 09:24:45 +0000

Ray,
Thanks much for this great summary.

All,
two small  clarifications embedded (for those who did not follow the discussions as closely):

On 25 Jul 2012, at 09:56, Brandenburg, R. (Ray) van wrote:

Hi all,

In order to spur some online discussion before the Vancouver meeting next week, I’ve summarized here the main recommendations from the CDNI & HTTP Adaptive Streaming work we’ve been doing over the past months (see http://tools.ietf.org/html/draft-brandenburg-cdni-has-03).

  *   The recommendation made in the draft is to not do anything specific for HAS regarding Content Acquisition and File Management. This means that the dCDN is not explicitly made aware of any relationship between different chunks and the dCDN handles each chunk as if it were an individual and independent content item. The result is that content acquisition between uCDN and dCDN also happens on a per-chunk basis. The draft does identify some potential improvements in this area which might be taken up after a possible re-chartering of the WG once the initial CDNI specification is complete.

  *   The recommendation made in the draft regarding request routing consists of a mandatory and an optional part. The mandatory part, which each CDN should support, is to perform request routing on a per-chunk basis. This means that, depending on the type of manifest file that is used, there might be an individual inter-CDN request routing operation taking place for each individual chunk. As an optional feature, the draft describes a method wherein the uCDN rewrites the manifest file so that it points directly to the dCDN, reducing request routing overhead. Since the process of manifest file rewriting is a uCDN-internal process, this does not require standardization beyond the existing request routing interface.

Logging

  *   The recommendation made in the draft regarding logging also consists of a mandatory and an optional part. As a mandatory requirement, the draft recommends that CDNs support per-chunk logging (e.g. logging each chunk request as if it were an independent content request). As an optional feature, the draft recommends to have a system where the dCDN can include a Content Collection Identifier (CCID) and/or Session Identifier as part of the logging fields, thereby providing the option for a CDN to do per-session logging of HAS content.

perhaps slightly more accurately: this is to facilitate the job of a CDN that wants to extract per-content-collection or per-session information (e.g. for analytics) a-posteriori, deriving those form the per-chunk logs (but this approach does not require.assume or even define standardized per-session log formats).

URL Signing

  *   For CDNs that want to do URL signing, the draft recommends that CDNs support either Flexible URL Signing by the Content Provider or by the uCDN.

"Flexible URL signing" includes the ability to exclude from signature coverage a subset of the URI path that varies on a per-chunk-basis (e.g. the part of the URI identifying the time/byte offset).

  *   Both scenarios result in a system where the dCDN can remain unaware of HAS, with either the Content Provider or the uCDN signing the URLs in the manifest file.

Cheers

Francois

Other topics

  *   Regarding Content Purge, the draft does not yet include a recommendation but describes two options for dealing with the purge of large numbers of related files from a dCDN. A recommendation for this topic will be added to the next iteration of the draft.
  *   The draft recommends that the CDNI Capability Advertisement method includes some way for CDNs to indicate whether they support the HAS-specific optional features recommended in the draft (such as the ability to log CCIDs). Furthermore, the draft recommends that there is some way for dCDNs to indicate whether they require access to manifest in order to be able to perform the delivery of HAS content.

Best regards,

Ray

_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni

---

From: Scott Wainner <[email-masked]>
Date: Wed, 25 Jul 2012 06:42:19 -0400

Ray,

     Comments in line ...

Scott

On 7/25/12 3:56 AM, Brandenburg, R. (Ray) van wrote:
> Hi all,
> In order to spur some online discussion before the Vancouver meeting 
> next week, I've summarized here the main recommendations from the CDNI 
> & HTTP Adaptive Streaming work we've been doing over the past months 
> (see _http://tools.ietf.org/html/draft-brandenburg-cdni-has-03_).
>   * The recommendation made in the draft is to not do anything
>     specific for HAS regarding Content Acquisition and File
>     Management. This means that the dCDN is not explicitly made aware
>     of any relationship between different chunks and the dCDN handles
>     each chunk as if it were an individual and independent content
>     item. The result is that content acquisition between uCDN and dCDN
>     also happens on a per-chunk basis. The draft does identify some
>     potential improvements in this area which might be taken up after
>     a possible re-chartering of the WG once the initial CDNI
>     specification is complete.
>
>   * The recommendation made in the draft regarding request routing
>     consists of a mandatory and an optional part. The mandatory part,
>     which each CDN should support, is to perform request routing on a
>     per-chunk basis. This means that, depending on the type of
>     manifest file that is used, there might be an individual inter-CDN
>     request routing operation taking place for each individual chunk.
>     As an optional feature, the draft describes a method wherein the
>     uCDN rewrites the manifest file so that it points directly to the
>     dCDN, reducing request routing overhead. Since the process of
>     manifest file rewriting is a uCDN-internal process, this does not
>     require standardization beyond the existing request routing
>     interface.
>
> Logging
>
>   * The recommendation made in the draft regarding logging also
>     consists of a mandatory and an optional part. As a mandatory
>     requirement, the draft recommends that CDNs support per-chunk
>     logging (e.g. logging each chunk request as if it were an
>     independent content request). As an optional feature, the draft
>     recommends to have a system where the dCDN can include a Content
>     Collection Identifier (CCID) and/or Session Identifier as part of
>     the logging fields, thereby providing the option for a CDN to do
>     per-session logging of HAS content.
>
> URL Signing
>
>   * For CDNs that want to do URL signing, the draft recommends that
>     CDNs support either Flexible URL Signing by the Content Provider
>     or by the uCDN. Both scenarios result in a system where the dCDN
>     can remain unaware of HAS, with either the Content Provider or the
>     uCDN signing the URLs in the manifest file.
>
     I think we also indicated that the dCDN needed to signal that it 
supported the Flexible URL Signing so that the uCDN would know if that 
particular dCDN was a candidate or not.

     The corollary is that the uCDN needed a way to indicate to the dCDN 
which portions of the URL were included in the URL signing.

     I don't know if there was a recommendation on where and how these 
capabilities and methods were conveyed between the uCDN and dCDN.
> Other topics
>
>   * Regarding Content Purge, the draft does not yet include a
>     recommendation but describes two options for dealing with the
>     purge of large numbers of related files from a dCDN. A
>     recommendation for this topic will be added to the next iteration
>     of the draft.
>   * The draft recommends that the CDNI Capability Advertisement method
>     includes some way for CDNs to indicate whether they support the
>     HAS-specific optional features recommended in the draft (such as
>     the ability to log CCIDs). Furthermore, the draft recommends that
>     there is some way for dCDNs to indicate whether they require
>     access to manifest in order to be able to perform the delivery of
>     HAS content.
>
> I would like to invite anyone who is interested in the topic and 
> wishes to discuss some of these recommendations in Vancouver, to read 
> the draft (_http://tools.ietf.org/html/draft-brandenburg-cdni-has-03_) 
> before the meeting, so that we can have a fruitful discussion in 
> Vancouver.
> Best regards,
> Ray
>
> [email-masked]