Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 4 Aug 2011 15:22:35 +0100

Use Case authors, Colleagues,

On 28 Jul 2011, at 21:16, Francois Le Faucheur wrote:

> Kent and all,
> 
> On 28 Jul 2011, at 16:10, Kent Leung (kleung) wrote:
> 
>> Hi Francois.  Responding to comments related to the requirements draft
>> below.
>> 
>> 
>>   o  an expiration time (i.e., the time at which the content files
>>      should be expunged from all CDN storage).
>> "
>> I understand this is saying that CDNI metadata need to include this
>> expiration time (triggering cache removal) , in addition to deactivation
>> time. 
>> I don't think this is discussed in cdni-requirements yet. Can you bring
>> that up on the list with the cdni-reqts authors?
>> 
>> KL> I've seen references to content expiration time (i.e. removal) in
>> some drafts.  So it seems to be needed in the CDNI Metadata.  Noted as
>> requirement (possibly part of availability window) unless others object.
> 
> FLF as an Individual: that works for me.

I'd like to understand the underlying requirement a bit better as it's not clear to me what the expected behaviour of a surrogate would be when receiving a request for the content after the "expiration time" is reached as well as how the surrogate is supposed to treat any cached copy of the content held in either volatile or non-volatile storage.

For example, when receiving a request for content after the "expiration time" is reached, is a surrogate required to:
- No longer deliver the content, even if presented with a valid request to do?
- Consider any cached copy of the content as "stale" and revalidate the content against the Origin, delivering the content if revalidation succeeds and not delivering the content if revalidation fails.

For example, for any cached copy of the content after the "expiration time" is reach, is a surrogate required to:
- Nothing more than whatever it is supposed to do in the example above and use its normal cache expiration procedures to recovery the storage space used like it would for "stale" content that does not have an explicit expiration time? 
- Actively keep track of cached content & its associated expiration time and actively "de-link" (e.g. remove from the filesystem table) the cached copy of the content? 
- Actively keep track of cached content & its associated expiration time and actively overwrite the storage sectors containing that content in both volatile & non-volatile storage?

Thanks
Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 4 Aug 2011 15:45:11 +0100

draft-bertrand-cdni-use-cases states in section 2.4:
> "
>   The delivery of content may be further influenced by policies which
>   may include quality of service rules that specify:
>   o  the maximum resolution deliverable to specific devices,
>   o  the maximum resolution deliverable though a specific NSP, or
>   o  the maximum resolution deliverable to users based on their
>      subscription levels.
> "

On 26 Jul 2011, at 21:54, Francois Le Faucheur wrote:
> I don't think this is covered in the cdni-requirements doc. 
> It is not obvious to me that absolutely all of those ought to be in
> phase 1. The first bullet only makes sense if the solution supports
> transcoding/transrating, which I don't know if it will be supported in
> Initial scope.
> The last bullet does not make sense to me as we don;t want the CDNs to
> be aware of any user subscription levels (ie only CSP is aware of user
> subscription level).

On 28 Jul 2011, at 21:10, Kent Leung (kleung) wrote:
> KL> I'm not yet convinced that this should be part of the CDNI Metadata.
> Based on the discussion conclusion, we can track this as possible
> requirement for now.

I can understand that the stated "maximum resolution" requirements may be CSP requirements but I'm a little unclear as to how they translate to capabilities on a CDN which would typically not be aware of the resolution of the content it is delivering.

It is not clear to me how delivery to specific devices can be handled by a CDN as I'm not really sure how a CDN can identify a particular device in the general case?

Given different resolutions will map to different files (or sets of files) in a CDN is it sufficient to, for example (other methods may also be equally applicable):

  - Have delivery to specific NSPs handled by geo-blocking policies per file (or set of files)?

  - Have delivery based on subscription level handled by authentication tokens set by the CSP's "portal" (or something other than the CDN that actually understands who has what subscription?)?

Therefore meaning that specific details of the resolution of a particular file (or set of files) still remain transparent to the CDN?

Thanks
Ben

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Thu, 4 Aug 2011 12:15:36 -0700

Hi Ben.  I agree with your comments.  It seems that there are no new
requirements.

Kent

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Thursday, August 04, 2011 7:45 AM
To: Kent Leung (kleung)
Cc: Francois Le Faucheur (flefauch);
[email-masked]; [email-masked]
Subject: Maximum resolutions & CDNs

> Based on the discussion conclusion, we can track this as possible

I can understand that the stated "maximum resolution" requirements may
be CSP requirements but I'm a little unclear as to how they translate to
capabilities on a CDN which would typically not be aware of the
resolution of the content it is delivering.

It is not clear to me how delivery to specific devices can be handled by
a CDN as I'm not really sure how a CDN can identify a particular device
in the general case?

Given different resolutions will map to different files (or sets of
files) in a CDN is it sufficient to, for example (other methods may also
be equally applicable):

  - Have delivery to specific NSPs handled by geo-blocking policies per
file (or set of files)?

  - Have delivery based on subscription level handled by authentication
tokens set by the CSP's "portal" (or something other than the CDN that
actually understands who has what subscription?)?

Therefore meaning that specific details of the resolution of a
particular file (or set of files) still remain transparent to the CDN?

Thanks
Ben

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Thu, 4 Aug 2011 12:26:42 -0700

Hi Ben.  In general, I think that content that has expired should be
treated similarly as de-activated except that content is removed from
the Surrogate.  The content availability window has to work in
conjunction with cache aging function.  So there shouldn't be
requirements to the level of implementation.

As for de-linking from filesystem vs overwrite, this is the same
question for Control Interface content removal function.  I think both
operations should be consistent (i.e. explicit content removal and
content expiration).

Kent

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Thursday, August 04, 2011 7:23 AM
To: Francois Le Faucheur (flefauch)
Cc: Kent Leung (kleung); [email-masked];
[email-masked]
Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02

> FLF as an Individual: that works for me.

I'd like to understand the underlying requirement a bit better as it's
not clear to me what the expected behaviour of a surrogate would be when
receiving a request for the content after the "expiration time" is
reached as well as how the surrogate is supposed to treat any cached
copy of the content held in either volatile or non-volatile storage.

For example, when receiving a request for content after the "expiration
time" is reached, is a surrogate required to:
- No longer deliver the content, even if presented with a valid request
to do?
- Consider any cached copy of the content as "stale" and revalidate the
content against the Origin, delivering the content if revalidation
succeeds and not delivering the content if revalidation fails.

For example, for any cached copy of the content after the "expiration
time" is reach, is a surrogate required to:
- Nothing more than whatever it is supposed to do in the example above
and use its normal cache expiration procedures to recovery the storage
space used like it would for "stale" content that does not have an
explicit expiration time? 
- Actively keep track of cached content & its associated expiration time
and actively "de-link" (e.g. remove from the filesystem table) the
cached copy of the content? 
- Actively keep track of cached content & its associated expiration time
and actively overwrite the storage sectors containing that content in
both volatile & non-volatile storage?

Thanks
Ben

---

From: Kevin J Ma <[email-masked]>
Date: Thu, 4 Aug 2011 15:27:05 -0400

Hi Ben,

  As mentioned in a previous response, different encodings could certainly
  be treated as independent files.  It may be, however, that information
  about different encodings (not just resolution) may be useful to dCDNs,
  e.g., for prefetching HLS segments, or for identifying HLS segment
  bundles, but for policy enforcement, often a User-Agent header or some
  other custom header or cookie is sufficient for content selection.  It
  may be that not all CDNs support this, and this is probably outside the
  scope of CDNI, but the use case was more intended as an example of the
  need for opaque metadata, and not as a requirement of CDNI to enforce
  CSP policies.

  In the updated draft, we have moved the text and tried to make it more
  generic in terms of the need for detecting metadata feature support.

thanx.

--  Kevin J. Ma

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ben Niven-Jenkins
> Sent: Thursday, August 04, 2011 10:45 AM
> To: Kent Leung
> Cc: [email-masked]; [email-masked]
> Subject: [CDNi] Maximum resolutions & CDNs
> 
> I can understand that the stated "maximum resolution" requirements may be
> CSP requirements but I'm a little unclear as to how they translate to
> capabilities on a CDN which would typically not be aware of the resolution
> of the content it is delivering.
> 
> It is not clear to me how delivery to specific devices can be handled by a
> CDN as I'm not really sure how a CDN can identify a particular device in
> the general case?
> 
> Given different resolutions will map to different files (or sets of files)
> in a CDN is it sufficient to, for example (other methods may also be
> equally applicable):
> 
> Therefore meaning that specific details of the resolution of a particular
> file (or set of files) still remain transparent to the CDN?
> 
> Thanks
> Ben
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Kevin J Ma <[email-masked]>
Date: Thu, 4 Aug 2011 15:36:16 -0400

Hi Ben,

  I would expect that once the expiration time is reached, all copies of the
  content would be expunged from any surrogates/storage devices.

  I believe there was discussion a while back about whether to only use the
  control interface to issue purge requests, or whether to use metadata to
  set expiration dates, or to allow both?  In the event of both, I would
  think both functions should act the same, i.e., when the expiration date
  is reached, it is just like a uCDN sent a purge request.

thanx.

--  Kevin J. Ma

> Sent: Thursday, August 04, 2011 10:23 AM
> To: Francois Le Faucheur
> Cc: Kent Leung (kleung); [email-masked]; draft-bertrand-cdni-use-
> [email-masked]
> I'd like to understand the underlying requirement a bit better as it's not
> clear to me what the expected behaviour of a surrogate would be when
> receiving a request for the content after the "expiration time" is reached
> as well as how the surrogate is supposed to treat any cached copy of the
> content held in either volatile or non-volatile storage.
> 
> - Nothing more than whatever it is supposed to do in the example above and
> use its normal cache expiration procedures to recovery the storage space
> used like it would for "stale" content that does not have an explicit
> expiration time?
> and actively "de-link" (e.g. remove from the filesystem table) the cached
> copy of the content?
> and actively overwrite the storage sectors containing that content in both
> volatile & non-volatile storage?
> 
> Thanks
> Ben
>

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 4 Aug 2011 12:49:56 -0700

Hi Kevin,

I would think the data should have the expiration times for sure.

Time based content, which uses control messages to purge can have issues
which could be result of connectivity. I am not sure why there should be any
control messages for purge at all.

Thanks,
Vishwas
On Thu, Aug 4, 2011 at 12:36 PM, Kevin J Ma <[email-masked]>wrote:

> not
> reached
> to
> > do?
> and

---

From: Kevin J Ma <[email-masked]>
Date: Thu, 4 Aug 2011 17:03:12 -0400

Hi Vishwas,

  One could certainly implement an instantaneous purge by setting the
  expiration date to the current time, but I believe the one advantage
  of using the control interface was going to be some type of explicit
  acknowledgement (synchronous or asynchronous) for purge complete.
  It may be that this could be done another way as well (perhaps via
  the logging interface), but that was the distinction, as I recall.

thanx.

--  Kevin J. Ma

From: Vishwas Manral [mailto:[email-masked]]
Sent: Thursday, August 04, 2011 3:50 PM
To: Kevin J Ma
Cc: Ben Niven-Jenkins; Francois Le Faucheur; [email-masked]; [email-masked]
Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02

Hi Kevin,

Time based content, which uses control messages to purge can have issues which could be result of connectivity. I am not sure why there should be any control messages for purge at all.

Thanks,
Vishwas
On Thu, Aug 4, 2011 at 12:36 PM, Kevin J Ma <kevin.ma<http://kevin.ma>@azukisystems.com<http://azukisystems.com>> wrote:
Hi Ben,

thanx.

--  Kevin J. Ma

> From: Ben Niven-Jenkins [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: Kent Leung (kleung); [email-masked]<mailto:[email-masked]>; draft-bertrand-cdni-use-
> [email-masked]<mailto:[email-masked]>

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

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Thu, 4 Aug 2011 14:09:46 -0700

The CDNI Control Interfaces enables the removal of content
asynchronously for reasons that could be administrative, legal, etc.
which are not based on a scheduled time.  For example, a content may
have metadata to expire in one week.  But some legal ruling requires the
content to be removed from distribution & delivery before that time.
Then the CDNI Control Interface can be used to accomplish that.  The
requirement for asynchronous removal is explicit acknowledgement.

Kent

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Kevin J Ma
Sent: Thursday, August 04, 2011 2:03 PM
To: Vishwas Manral
Cc: [email-masked]; [email-masked]
Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02

Hi Vishwas,

thanx.

--  Kevin J. Ma

Cc: Ben Niven-Jenkins; Francois Le Faucheur; [email-masked];

Hi Kevin,

Time based content, which uses control messages to purge can have issues
which could be result of connectivity. I am not sure why there should be
any control messages for purge at all.

Thanks,

Vishwas

On Thu, Aug 4, 2011 at 12:36 PM, Kevin J Ma <[email-masked]>
wrote:

Hi Ben,

 I would expect that once the expiration time is reached, all copies of
the
 content would be expunged from any surrogates/storage devices.

 I believe there was discussion a while back about whether to only use
the
 control interface to issue purge requests, or whether to use metadata
to
 set expiration dates, or to allow both?  In the event of both, I would
 think both functions should act the same, i.e., when the expiration
date
 is reached, it is just like a uCDN sent a purge request.

thanx.

--  Kevin J. Ma

not
reached
> - No longer deliver the content, even if presented with a valid
request to
and
> and actively "de-link" (e.g. remove from the filesystem table) the
cached
> and actively overwrite the storage sectors containing that content in
both

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 4 Aug 2011 14:53:16 -0700

Agree with you there Kent.

But the control interface is not the default mechanism for sure, its used as
an exception.

-Vishwas
On Thu, Aug 4, 2011 at 2:09 PM, Kent Leung (kleung) <[email-masked]>wrote:

>  The CDNI Control Interfaces enables the removal of content asynchronously
> for reasons that could be administrative, legal, etc. which are not based on
> a scheduled time.  For example, a content may have metadata to expire in one
> week.  But some legal ruling requires the content to be removed from
> distribution & delivery before that time.  Then the CDNI Control Interface
> can be used to accomplish that.  The requirement for asynchronous removal is
> explicit acknowledgement.****
>
> ** **
>
> Kent****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Kevin J Ma
> *Sent:* Thursday, August 04, 2011 2:03 PM
> *To:* Vishwas Manral
> *Cc:* [email-masked]; [email-masked]
>
> *Subject:* Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02****
>
>   ** **
>
> Hi Vishwas,****
>
> ** **
>
>   One could certainly implement an instantaneous purge by setting the****
>
>   expiration date to the current time, but I believe the one advantage****
>
>   of using the control interface was going to be some type of explicit****
>
>   acknowledgement (synchronous or asynchronous) for purge complete.****
>
>   It may be that this could be done another way as well (perhaps via****
>
>   the logging interface), but that was the distinction, as I recall.****
>
> ** **
>
> thanx.****
>
> ** **
>
> --  Kevin J. Ma****
>
> ** **
>
> *From:* Vishwas Manral [mailto:[email-masked]]
> *Sent:* Thursday, August 04, 2011 3:50 PM
> *To:* Kevin J Ma
> *Cc:* Ben Niven-Jenkins; Francois Le Faucheur; [email-masked];
> *Subject:* Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02****
>
> ** **
>
> Hi Kevin,****
>
>  ****
>
> I would think the data should have the expiration times for sure. ****
>
>  ****
>
> control messages for purge at all.****
>
>  ****
>
> Thanks,****
>
> Vishwas****
>
> wrote:****
> --  Kevin J. Ma****
> > From: Ben Niven-Jenkins [mailto:[email-masked]]****
>
> > To: Francois Le Faucheur****
>
> https://www.ietf.org/mailman/listinfo/cdni****
>
> ** **
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 5 Aug 2011 00:08:50 +0100

Kent, Kevin,

>  content would be expunged from any surrogates/storage devices.

I'm starting to worry that we are creating new requirements on CDNs in general rather than reflecting existing CDN requirements into CDNI.

For example, content that expires "naturally" (e.g. due to Cache-Control headers) is not automatically "expunged" and therefore I am struggling a little to understand why content that has an associated availability window is required to be "expunged" when that availability window expires. I have not personally encountered a CSP that has such a requirement.

Ben

---

From: Kevin J Ma <[email-masked]>
Date: Thu, 4 Aug 2011 20:23:14 -0400

Hi Ben,

> I'm starting to worry that we are creating new requirements on CDNs in
> general rather than reflecting existing CDN requirements into CDNI.  

I will just reiterate that I do not necessarily see a need for an explicit
requirement, but I do think this may be a feature that interconnected CDNs
may wish to support and therefore need to be able to exchange metadata about,
and/or advertise their support for.

> I am struggling a
> little to understand why content that has an associated availability
> window is required to be "expunged" when that availability window expires.

I suppose it depends on the paranoia level of the CSP?  I have delt with CSPs
who requested content purge at a certain time, when they nolonger have the
rights to distribute it.  One consideration might be the case where a CDN does
not support availability windows, but it does support expiration/purge?

thanx.

--  Kevin J. Ma

> Sent: Thursday, August 04, 2011 7:09 PM
> To: Kent Leung (kleung); Kevin J Ma
> Cc: Francois Le Faucheur (flefauch); [email-masked]; draft-bertrand-cdni-
> [email-masked]
> I'm starting to worry that we are creating new requirements on CDNs in
> general rather than reflecting existing CDN requirements into CDNI.
> 
> For example, content that expires "naturally" (e.g. due to Cache-Control
> headers) is not automatically "expunged" and therefore I am struggling a
> little to understand why content that has an associated availability
> window is required to be "expunged" when that availability window expires.
> I have not personally encountered a CSP that has such a requirement.
> 
> Ben
> 
>

---

From: Scott Wainner <[email-masked]>
Date: Thu, 11 Aug 2011 08:53:52 -0400

Indeed there are cases where cached content needs to be purged prior to 
expiration.

For example, the quality of a transcoded asset may be unsatisfactory 
leading the CSP to issue a purge request to flush the cache prior to 
content expiration.  The assumption is made that a new media version is 
published using the previously defined metadata and we want the CDN's to 
re-populate its cache with the updated version of the media.  In lieu of 
this capability, the corrupt content may continue to be served until the 
natural expiration of the cache or availability window.

Scott

On 8/4/11 5:53 PM, Vishwas Manral wrote:
> But the control interface is not the default mechanism for sure, its 
> used as an exception.
> -Vishwas
> On Thu, Aug 4, 2011 at 2:09 PM, Kent Leung (kleung) <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     asynchronously for reasons that could be administrative, legal,
>     etc. which are not based on a scheduled time.  For example, a
>     content may have metadata to expire in one week.  But some legal
>     ruling requires the content to be removed from distribution &
>     delivery before that time.  Then the CDNI Control Interface can be
>     used to accomplish that.  The requirement for asynchronous removal
>     is explicit acknowledgement.
>
>     Kent
>
>     *From:[email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] *On
>     Behalf Of *Kevin J Ma
>     *Cc:* [email-masked] <mailto:[email-masked]>;
>     <mailto:[email-masked]>
>
>     *Subject:* Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02
>
>     Hi Vishwas,
>
>     *From:*Vishwas Manral [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Cc:* Ben Niven-Jenkins; Francois Le Faucheur; [email-masked]
>     <mailto:[email-masked]>;
>     <mailto:[email-masked]>
>     *Subject:* Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02
>
>     Hi Kevin,
>
>     Time based content, which uses control messages to purge can have
>     issues which could be result of connectivity. I am not sure why
>     there should be any control messages for purge at all.
>
>     Thanks,
>
>     Vishwas
>
>     On Thu, Aug 4, 2011 at 12:36 PM, Kevin J Ma <kevin.ma
>     <http://kevin.ma/>@azukisystems.com <http://azukisystems.com/>> wrote:
>
>     Hi Ben,
>
>     > Cc: Kent Leung (kleung); [email-masked] <mailto:[email-masked]>;
>     draft-bertrand-cdni-use-
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: <[email-masked]>
Date: Tue, 30 Aug 2011 16:11:22 +0200

Hi Kent,

Thanks for your review.

========

1.  Sect 1.1 Terminology: The following are not new terms: CDN Provider, dCDN, CDNI.  These terms should go to one document later.

We are progressing on the cleaning of this section, keeping in mind that all the definitions will be moved later to a unique draft. 

2.  "Asymmetric Distribution" term doesn't match description well, IMHO.

Maybe something like "Authorized Content Distribution"? It's probably not much better.

We have removed this definition as the text did not use it anymore

3.  Sect 1.2 Abbreviations: ISP, PC, STB, UE, VoD, WiFI are not used in document.  Maybe others too?

We have updated the list to remove the non-used acronyms. We will cleanup the list again later, as the text evolves.

4.  Consistency use of "CDN Interconnect" vs "CDN Interconnection"

Checked

5.  Make sure to use terms properly "surrogate" -> "Surrogate", "end-user" -> "End User", etc.

Done. I have lowercased all these terms (more readable, IMHO)

6.  Sect 2.4 Delivery Restrictions: Typo "geo- location-based"

Corrected 

7. The bullets for maximum resolution do not seem relevant to CDNI.

Would this be controlled by the CSP/SP that authorizes access to the content by providing the URL to this type of resolution?  The line is blurring between content delivery limitations (in non-CDNI case) and metadata relevant to CDNI.  Definitely subscription should not be a factor.  It seems to me that if the request reaches the uCDN, access to the content has already been authorized (i.e. to the End User or device).

We are working on this point and should propose a text revision to clarify these issues. 

8.  Sect 3.2.1 and 3.2.2 Failure of Content: I'm not clear if dCDN is allowed to obtain contain directly from CSP?  If so, then the CDNI model should have a Request Interface from dCDN to CSP.

I think acquisition on any origin server should be supported. We agree that the interface for the actual content acquisition is out of scope; however, the provision of the content source information is in scope.

9.  Sect 4.1 Device and Network: The example assumes that CSP licensed both high and low resolution content to CDN A, right?  Not clear how UA (mobile device) can get authorization to high resolution content?  I assume there will be some URL validation at uCDN.

We have clarified the section and are working on a text revision on "content availability", to clarify the resolution-related issues.

10.Sect 7 Security: Typo "situtations" -> "situations"

Corrected.

========

Cheers,

Gilles

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Kent Leung (kleung)
Envoyé : jeudi 28 juillet 2011 20:55
À : Francois Le Faucheur (flefauch); [email-masked]
Cc : [email-masked]
Objet : Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02

Hi.  I'll pile on my comments under the same subject line.

1. Sect 1.1 Terminology: The following are not new terms: CDN Provider, dCDN, CDNI.  These terms should go to one document later.

2. "Asymmetric Distribution" term doesn't match description well, IMHO.

Maybe something like "Authorized Content Distribution"? It's probably not much better.

3. Sect 1.2 Abbreviations: ISP, PC, STB, UE, VoD, WiFI are not used in document.  Maybe others too?

4. Consistency use of "CDN Interconnect" vs "CDN Interconnection"

5. Make sure to use terms properly "surrogate" -> "Surrogate", "end-user" -> "End User", etc.

6. Sect 2.4 Delivery Restrictions: Typo "geo- location-based"

7. The bullets for maximum resolution do not seem relevant to CDNI.

Would this be controlled by the CSP/SP that authorizes access to the content by providing the URL to this type of resolution?  The line is blurring between content delivery limitations (in non-CDNI case) and metadata relevant to CDNI.  Definitely subscription should not be a factor.  It seems to me that if the request reaches the uCDN, access to the content has already been authorized (i.e. to the End User or device).

8. Sect 3.2.1 and 3.2.2 Failure of Content: I'm not clear if dCDN is allowed to obtain contain directly from CSP?  If so, then the CDNI model should have a Request Interface from dCDN to CSP.

9. Sect 4.1 Device and Network: The example assumes that CSP licensed both high and low resolution content to CDN A, right?  Not clear how UA (mobile device) can get authorization to high resolution content?  I assume there will be some URL validation at uCDN.

10. Sect 7 Security: Typo "situtations" -> "situations"

Kent

-----Original Message-----

From: [email-masked] [mailto:[email-masked]] On Behalf Of Francois Le Faucheur (flefauch)

Sent: Tuesday, July 26, 2011 1:54 PM

To: [email-masked]

Cc: [email-masked]

Subject: [CDNi] comments on draft-bertrand-cdni-use-cases-02

Hello,

Please find my review comments below.

Cheers

Francois

*** Abstract & Introduction:

"

It provides the business motivations for CDNI Working Group, which can be used to

   validate different interconnection arrangements, and requirements of the various CDNI interfaces.

"

Now the WG is formed you may want to adjust into something like:

"

It can be used to provide guidance to the CDNI WG about the interconnection arrangements to be supported and to validate the requirements of the various CDNI interfaces."

*** Introduction:

"

This document now merges input from [I-D.watson-cdni-use-cases] and

   [I-D.ma-cdni-publisher-use-cases].

"

I suggest you remove this historical info in new revs, as the document gradually matures towards WG material.

*** Introduction:

"

There are many possible combinations for the relationships between

   the different parties (Network Service Provider (NSP), CDN Provider,

   Content Service Provider (CSP) and End User) involved in end-to-end

   content delivery.  However, in the context of interconnecting CDNs

   the key relationships are listed below.

   o  How the CSP interacts with the CDN provider, so that the CDN

      delivers content in a manner compliant with CSP's distribution

      policies.

   o  How the End User interacts with the CSP and one or more CDNs to

      request and receive content.

   o  How the different CDN providers, operating their CDNs, interact

      with one another to deliver the CSP's content to the End User

      while continuing to enforce the CSP's distribution policies.

"

I don't quite see the relevance of this text in the use-case document, or what point it is trying to bring across.

In particular, it is a little confusing sine it talks about interfaces that are out of scope for CDNI without saying so.

*** 1.1 Terminology

o I expect that terminology across problem-statement, requirements and use-case needs to be aligned and made probably moved into one document and referred by all the others. 

o "CDN Peering": I am not sure we need that term. 

o "Recursive request routing/ Recursive request routing": see discussion on the list about moving those terms in a single doc 

*** 1.3 High Level Use Cases for Multi-CDN Systems I found it a little confusing to have the word "use cases" used here in the introduction as well as later in teh individual use-cases.

How about something like "Rationale or Multi-CDN Systems"?

*** 1.3 High Level Use Cases for Multi-CDN Systems "

CSP-1 benefits because it only needs to make one business agreement

   and one physical connection, with CDN Provider A, but its End Users

   get a service quality as though it had also gone to the trouble of

   making a business agreement with CDN Provider B.

"

s/as though it had /as though CSP-1 had /

*** 1.4.  The Need for CDNI Standards

"

   Existing CDN interfaces are proprietary and an external CDN typically

   cannot use them, especially if the two CDNs rely on different

   solutions. 

"

It is difficult to use existing interfaces because they are proprietary, but also because they have often been designed as intra-CDN/intra-domain interfaces, so they don't have all the right attributes.

Also, I think by "solutions" you mean "implementations".

So perhaps:

"

   Existing CDN interfaces are proprietary and have often been design for intra-CDN/intra-domain operations. So an external CDN typically cannot use them, especially if the two CDNs rely on different implementations.

"

"

Nevertheless, [I-D.bertrand-cdni-experiments] shows that

   some level of CDN interconnection can be achieved experimentally

   without standardized interfaces between the CDNs.  The methods used

   in these experiments are hardly usable in an operational context,

   because they suffer from several limitations in terms of

   functionalities, scalability, and security level.

"

s/ The methods used/However, the methods used/

"

   The aim of the CDNI standards work is therefore to overcome such

   shortcomings; a full list of requirements is being developed in

   [I-D.lefaucheur-cdni-requirements].

"

s/the CDNI standards work/IETF CDNI WG solution/

***2.1.  Geographic Extension

"

   In this use case, the CDN Provider wants to extend the geographic

   distribution that it can offer CSPs, without

   o  compromising the quality of delivery

   o  attracting transit and other network costs by serving from

      geographically or topologically remote surrogates.

"

I think would read better as:

"

   In this use case, the CDN Provider wants to extend the geographic

   distribution that it can offer to its CSPs:

   o  without compromising the quality of delivery

   o  without incurring additional transit and other network costs that would result from serving content from

      geographically or topologically remote surrogates.

"

"

As an example, suppose a French CSP wants to distribute its TV

   programs to End Users located in various countries in Europe and

   North Africa.  It asks a French CDN Provider to deliver the content.

   The French CDN Provider's network only covers France, so it makes an

   agreement with another CDN Provider that covers North Africa.

   Overall, from the CSP's perspective the French CDN Provider provides

   a CDN service for both France and North Africa.

"

The example initially mentions a required coverage of Europe+ North Africa, but then seem to descrive a solution for a coverage of

France+North Africa.

*** 2.2.  Region to Region Interconnection I don't find the phrase "Region to Region" very distinctive versus the previous "Geographic Extension".

I think the key differences here is that the different CDNs are operated by different organization that are affiliates of the same company.

So how about "Inter-Affiliates Interconnection"?

*** 2.3.  Nomadic Users

You may want to mention that this is often loosely referred to as "TV everywhere".

"

The motivation in this case is to allow nomadic users to maintain access,

   rather than to allow all residents within a region access to the

   content.

"

s/to maintain access/to maintain access with consistent quality of experience/

You may want to expand a little on which CDNs need to be interconnected to address the use case (ie with CDN of "home NSP" interconnected to CDN of visited NSP) possibly with a picture.

*** 2.4.  Delivery Restrictions

"Hence, the exchange through the CDN interconnection of information

   for controlling the footprint of the delivery is an important use

   case.

"

To me this is not an additional use cases, this is a requirement that has to be met in the use cases described earlier. In fact, the document mixes use cases and requirements in a few places.

I would suggest that :

      * you refer to  things discussed in that section as "requirements"

      * add a statement clarifying these requirements apply to the use cases discussed in the document.

"

"

I understand this is saying that CDNI metadata need to include this expiration time (triggering cache removal) , in addition to deactivation time. 

I don't think this is discussed in cdni-requirements yet. Can you bring that up on the list with the cdni-reqts authors?

"

      subscription levels.

"

It is not obvious to me that absolutely all of those ought to be in phase 1. The first bullet only makes sense if the solution supports transcoding/transrating, which I don't know if it will be supported in Initial scope.

The last bullet does not make sense to me as we don;t want the CDNs to be aware of any user subscription levels (ie only CSP is aware of user subscription level).

*** 3.1.  Overload Handling and Dimensioning "

This brings dimensioning savings to the CDNs as they can use the resources

   of each other during their peaks of activity.

"

s/their peaks of activity./ their respective peaks of activity./

*** 3.3.  Branding Consideration

Again, this seems more of a requirement than a use case per-say. I recommend you make that clear upfront in teh section (ie this is not an extra use cases, but a requirement applying to use-cases discussed before).

Also, is there a reason this applicable to only the use cases in section

3 and not section 2?

Anotehr option may be to move 2.4 and 3.3 under a separate heading somewhere collecting key requirements applicable to the many use cases. 

*** 4.1.  Device and Network Technology Extension Again I think some of the discussion assumes that there is some conversion of quality done inside the CDNs (as opposed to different terminal requesting different URIs).

I think we need to discuss whether this is going to come in Initial Scope or not.

*** in Figure 2: 

s/CDN Provider A/CDN Provider 1/

*** co-authors. You have a long list of co-authors. As per current practice, you would want to split that into "editors" and "contributors".

CDNi mailing list

[email-masked]

CDNi mailing list

[email-masked]

---

From: <[email-masked]>
Date: Tue, 30 Aug 2011 16:11:49 +0200

Hi François,

Thanks for your review.

========

"

"

"

Done

*** Introduction:

"

"

Done

*** Introduction:

"

      policies.

"

Text removed

*** 1.1 Terminology

 

Done

"

Done

"

   solutions. 

"

So perhaps:

"

   Existing CDN interfaces are proprietary and have often been designed for intra-CDN/intra-domain operations. So an external CDN typically cannot use them, especially if the two CDNs rely on different implementations.

"

Done

"

"

Done

"

"

Done

"

"

"

"

Done

"

"

The example initially mentions a required coverage of Europe+ North Africa, but then seem to descrive a solution for a coverage of France+North Africa.

Corrected

Done

*** 2.3.  Nomadic Users

In progress.

"

   content.

"

Done

In progress.

   case.

"

I would suggest that :

"

"

"

      subscription levels.

"

We have collected the requirements-like use cases in a new section about "Content Availability", and we are working on it to take all the received comments into account.

"

Done

Also, is there a reason this applicable to only the use cases in section 3 and not section 2?

We are working to improve this section.

This section presents a quite general use case in which a CDN1 delegates requests to another CDN2 that offers any function that CDN1 is not able to provide. It does not assume that quality conversion is done in the CDN, although this one of the possible examples for this use case.

*** in Figure 2: 

We have removed this figure

We need to discuss this point with the co-authors.

========

Best regards,

Gilles

-----Message d'origine-----
De : Francois Le Faucheur [mailto:[email-masked]] 
Envoyé : mardi 26 juillet 2011 22:54
À : [email-masked]
Cc : Le Faucheur Francois; [email-masked]
Objet : comments on draft-bertrand-cdni-use-cases-02

Hello,

Cheers

Francois

"

"

"

 

*** Introduction:

"

"

 

*** Introduction:

"

      policies.

"

 

*** 1.1 Terminology

 

 

"

 

"

   solutions. 

"

So perhaps:

"

"

"

"

 

"

"

 

"

"

"

"

"

"

The example initially mentions a required coverage of Europe+ North Africa, but then seem to descrive a solution for a coverage of France+North Africa.

 

*** 2.3.  Nomadic Users

"

   content.

"

 

   case.

"

I would suggest that :

"

"

"

      subscription levels.

"

 

"

 

Also, is there a reason this applicable to only the use cases in section 3 and not section 2?

 

 

*** in Figure 2:

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 30 Aug 2011 19:41:28 +0200

Hi Gilles and co-authors,
Thanks for factoring all my earlier comments. Looking forward to the new version.
Francois