Subject: [CDNi] comments on ietf-cdni-use-cases-00

From: Francois Le Faucheur <[email-masked]>
Date: Sun, 13 Nov 2011 04:18:18 +0800

Gilles et al,

My individual's comments on latest version of use-cases.

High level comments:

***) cost reduction/incremental revenue use cases for access network:
I believe one fairly significant use case of CDNI is where:
	* an access provider carries to its subscribers a lot of content coming from a 3rd party CSP and injected into the access network by an Authoritative CDN provider 
	* the access provider wants to 
		(i) reduce the corresponding traffic load (eg by caching instead of carrying the same content many times)
		(ii) influence/control the traffic ingestion points
		(iii) possibly derive some incremental revenue for transport of that traffic
The access provider may elect to use a CDN in his network and offer a CDNI interconnection to the authoritative CDN. This allows the access provider to perform caching in a managed way (in particular so it can influence traffic acquisition paths, so that full visibility and control is retained for the CSP, etc).
I don't think that use case is really covered. It ends up being similar to the Footprint extension usecase, but the footprint extension usecase is described more from teh uCDN viewpoint whereas here I feel it is useful to describe the use case from the dCDN/access provider viewpoint.

***) section 2, 3 and 4 are in good shape but I am still not comfortable withs section 5.
In particular, section 5 mixes  delivery policies that are indeed relevant to CDNs with "policies" that in my opinion pertain to some service layer above the CDN and are irrelevant to CDNs.
A good example of that issue would be "resolution-based constraints" of 5.1 and of course the content encoding restrictions of 5.1.3. I don't think we want the CDNs/CDNI to have to be aware about which user is allowed to access which resolution , or which encoding is deliverable to specific devices. These functional requirements can be better achieved in my opinion by the Content Portal making decision of whether a request is allowed based on any combination of any criteria and then only leave it to the CDN to validate that the requst has been authorised (eg via URI signing or token).
Alos , I find that some text is way too specific and looks like a Requirement (that shoudl be proposed to cdni-requirements) and not like usecases.

More specific comments:

*) in abstract & introduction:
"
This document outlines real world use-cases (not technical solutions) for interconnecting CDNs.
...
This document describes a number of use cases that motivate CDN Interconnection.
"
One of these two sentences seems redundant.

* ) 1.1:
"
CDN peering: A business relation between two CDN providers based on one or more CDN Interconnections.
"
This definition is not used anywhere (and "peering" brings a lot of connotations), please remove that definition.

*) 1.1
Some definitions ("aCDN", "Delivering CDN"...) seem generally useful. Can you work with the authors of problem-statement and framework to locate them in the relevant document.

*) 1.3
Figure 1:
	* shows a CSP-2 attached to CDN-B but is not discussed
	* does not show CSP-3 attached to CDN-A that is discussed in the text.
Please align figure and text.

*)1.3 paragraph above Fig 1.
"When a User Agent that is connected to CDN Provider B’s network requests Content from CSP-1, the Content is actually delivered from CDN-B"
I think this is a little too specific description in this section that is very generic. I suggest the text indicates that the request is served by CDN-B because CDN-A feels that it will be better served by CDN-B, and then only indicate that the reason to do so _may_, _for example_, be becaue B is an access network and the user is directly attached to it.

*) 3.2.1:
"
In partial failure scenarios, a CDN Provider could redirect some requests towards another CDN, which must be able to serve the redirected requests or, depending on traffic management policies, to forward these requests to the CSP’s origin server.
"
I can parse the last part of that sentence ("to forward these requests to the CSP’s origin server") in two ways:
	(a) another CDN which must be able to ...forward these requests to the CSP’s origin server
	(b) a CDN Provider could redirect some requests towards another CDN ... or forward these requests to the CSP’s origin server.
Can you change text so it is unambiguous?
If you meant (a) , that does not make sense to me.

*) section 5:
I suggest replacing title of "Policy Enforcement" by something more precise like "Enforcement of Content Delivery Policy"

*) section 5.1.3
I still believe this shoudl mostly be removed from the document.

*) section 5.2:
"
There are situations where one CDN Provider cannot or does not want to operate all the functions of a uCDN, e.g., a CDN exchange, which handles request routing (and possibly log retrieval) but delegates all content delivery to the surrogates of other dCDNs.
"
I don;t see the point of that text and how it relates to what is discussed in section 5.2.

I also have a whole series of editorial suggestions, that I'll pass offline.

Can we meet in Taipei to discuss these comments as well as how to deal with section 5?

Cheers

Francois

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 14 Nov 2011 02:21:05 +0000

> A good example of that issue would be "resolution-based constraints" of 5.1 and of course the content encoding restrictions of 5.1.3. I don't think we want the CDNs/CDNI to have to be aware about w…

+1.

The same can be said for the "temporal restrictions" which can be achieved using a combination of the content portal and CDN data plane functions (e.g. Expires/Cache-Control headers) 

Ben

---

From: ZhouZhipeng <[email-masked]>
Date: Mon, 14 Nov 2011 07:06:54 +0000

Hi Francois,
Just a high level comment on your sentence: "from the dCDN/access provider viewpoint."
I feel the CDN or CDNi is based on the viewpoint of the whole system to evaluate the benefit from implementing the caching system, not on part of the system.
E.g. it may reduce the system cost(end to end) via CDN comparing with the system without CDN.

If we consider CP as the consumer of CDNs and CDNs as the consumer of access provider, the description on "CDN to CDN" is clear to address the whole system.
Generally , CDN is a layer over access network. Hence "CDN may reduce the traffic load" is equal to "CDN may reduce the access network's load" .

Just my two cents for reference.
Zhipeng

-----Original Message-----
From: Francois Le Faucheur [mailto:[email-masked]] 
Sent: Sunday, November 13, 2011 4:18 AM
To: [email-masked]
Subject: [CDNi] comments on ietf-cdni-use-cases-00

Gilles et al,

High level comments:

More specific comments:

* ) 1.1:
"

*) 1.1

*) 1.3
Figure 1:

*)1.3 paragraph above Fig 1.
"When a User Agent that is connected to CDN Provider B's network requests Content from CSP-1, the Content is actually delivered from CDN-B"
I think this is a little too specific description in this section that is very generic. I suggest the text indicates that the request is served by CDN-B because CDN-A feels that it will be better served by CDN-B, and then only indicate that the reason to do so _may_, _for example_, be becaue B is an access network and the user is directly attached to it.

*) 3.2.1:
"
In partial failure scenarios, a CDN Provider could redirect some requests towards another CDN, which must be able to serve the redirected requests or, depending on traffic management policies, to forward these requests to the CSP's origin server.
"
I can parse the last part of that sentence ("to forward these requests to the CSP's origin server") in two ways:
	(a) another CDN which must be able to ...forward these requests to the CSP's origin server
	(b) a CDN Provider could redirect some requests towards another CDN ... or forward these requests to the CSP's origin server.
Can you change text so it is unambiguous?
If you meant (a) , that does not make sense to me.

*) section 5:

*) section 5.1.3

*) section 5.2:
"

Cheers

Francois

---

From: ZhouZhipeng <[email-masked]>
Date: Mon, 14 Nov 2011 09:06:39 +0000

Hi Ben and Francois,
Besides what I have explained for the bandwidth efficiency on this use case, I have a scenario to the portal issue : if the content has three optional formats and 3 optional stream rates, hence total 9 options, how the portal may be nice to display all these options on each content item.
Second, do we wish the normal user to be so clear on the technical details when they consume the content.

Thanks.
Zhipeng

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Monday, November 14, 2011 10:21 AM
To: Francois Le Faucheur
Cc: [email-masked]
Subject: Re: [CDNi] comments on ietf-cdni-use-cases-00

+1.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 15 Nov 2011 08:15:37 +0000

Zhipeng,

> Besides what I have explained for the bandwidth efficiency on this use case, I have a scenario to the portal issue : if the content has three optional formats and 3 optional stream rates, hence tot…

I'm not sure what the relevance of that is to CDNI. It's up to the Content Provider how they arrange their portal and how they present options to End Users.

> Second, do we wish the normal user to be so clear on the technical details when they consume the content.

Again this is nothing to do with CDNI. The content portals I use and I am aware of manage to present multiple options to their users without requiring users to understand the technical details. For example by describing/presenting different versions as HD, SD, Mobile, PC, TV etc. and in many cases only offering the options that the Content Provider wants to offer to the particular device/client the End User is using.

Ben

---

From: ZhouZhipeng <[email-masked]>
Date: Tue, 15 Nov 2011 08:48:32 +0000

Ben, Good afternoon,

1) we have discussed many times that we may reduce the bandwidth between uCDN and dCDN. 

2) Francois had said in previous email that Content Portal may help for delivering different formats while I explained that it is not just that simple even for portal issue.
  You may assign a terminal only one file format but if the CDN should serve for different types of terminals then the CDN server should hold content with different formats.

3)  In fact adaptation is not an identical issue of portal. The adaptation scenario is as below:
a. the adaptation is conducted between Server and Client automatically.
For example, once bandwidth on access network has changed during the service, the new rate stream will be delivered to the terminal without the user's operation.
b. see the scenario of multi-screen service:
The user may move among home, office, outside. Therefore he may use different terminals( TV, PC, Mobile phone) to see the same content without break(when he goes out home the content will be delivered to his smart phone) and the user would hope the operation may be as simple as possible( let the device to do the adaptation).

Above all, if the dCDN should hold multiple formats content, whether we may give a solution that only one content copy being delivered to dCDN.

Thanks.
Zhipeng

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Tuesday, November 15, 2011 4:16 PM
To: ZhouZhipeng
Cc: Francois Le Faucheur; [email-masked]
Subject: Content Portals (Re: [CDNi] comments on ietf-cdni-use-cases-00)

Zhipeng,

Ben