Re: [CDNi] Two additional definitions for cdni-framework

["Deventer, M.O. (Oskar) van" <[e-mail]>]

Dear Larry and Francois,

> Yes... Generally, it would be good to do a survey of terminology 
> various docs have introduced recently, and converge on the core 
> definitions.
CDNi terminology is also under development by the ETSI CDNi activity ([e-mail]). So while we are harmonizing terminology between IETF documents, we should also consider the relevant ETSI documents.

These are the relevant ETSI document:
Use cases and requirements: http://docbox.etsi.org/MCD/Open/Latest_Drafts/cdn-i013v0011.pdf
Architecture and information flows: http://docbox.etsi.org/TISPAN/Open/NGN_LATEST_DRAFTS/RELEASE_INDEPENDENT/02086_ts182032_cdn-i_architecture_v004.pdf

Here is an initial analysis of CDNi terminology and approaches by ETSI and IETF.

-The terms "distribution" and "delivery" seem to consistent between ETSI and IETF. The first term is intra- and inter-CDN, whereas the second term is about delivery to a user agent.

-There may to be an inconsistency between the IETF and ETSI definitions of Upstream CDN and Downstream CDN. The IETF Problem Statement defines these in terms of redirection (upstream redirects to downstream). ETSI defines these in terms of distribution (upstream closer to Content Provider, downstream closer to Consumer). Especially in case of HAS content, there may be no redirection for individual chunks (segments, fragments), whereas we would still consider the chunk-delivering-CDN the "downstream CDN". Would this require a refinement of the IETF definition?

-Unlike ETSI, IETF has no terminology for segmented content yet. This is work in progress on http://tools.ietf.org/id/draft-brandenburg-cdni-has-00.txt, and we are trying to remain aligned.

-The IETF Framework document defines four interfaces (or five, if one counts the moving-of-content), whereas ETSI has only two (or three, if one counts ...). These are the ETSI ones:
   -Interconnection Control: ... is used for controlling interconnection peer and transferred over this point information related to CDN capabilities and status, including footprint exchange, capability exchange, interconnection status reporting and network usage/performance logging.
   -Request Routing and Content Control: ... is used for requesting content and to transfer content related information, including content metadata exchange, content requests and content status reporting.
The reason for having only two interfaces is that having more interfaces than needed takes unnecessary implementation complexity and additional configuration and management effort. Can you tell me why IETF CDNi has four interfaces, and why two is not enough?

-IETF has a rather loose definition of Content: "Any form of digital data [including] continuous media."
ETSI has a more strict and CDNi-functional definition of Content Item: "A uniquely addressable content element in a CDN. A content item is defined by the fact that it has its own Content Metadata associated with it. It is the object of content distribution and request routing operations in a CDN. Example of Content Items are a video file/ stream, an audio file/stream, an image file or segmented content together with an associated manifest file."
Would it make sense to add this definition of "Content Item" to the Problem Statement or Framework documents?

-ETSI distinguishes logging ("recording event ...") from reporting ("providing access to recorded events ..."). This includes the possibility that the dCDN processes the logged information, e.g. into a standardized, possibly aggregated format. IETF uses only the term logging. Does this preclude reporting processed logging information between CDNs?

Depending on the response to this analysis, I would be happy to draft some refined definitions. Thank you.

Best regards,

Oskar

ETSI rapporteur on CDNi work items

Dr. ir. M.O. (Oskar) van Deventer
TNO - Innovation for Life
Senior Scientist Media Networking
Media & Network Services
T [phone]
M [phone]
E [e-mail]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Francois Le Faucheur
Sent: Thursday, 17 May, 2012 02:16
To: Peterson, Larry
Cc: [e-mail]
Subject: Re: [CDNi] Two additional definitions for cdni-framework

Larry and all,

My understanding is that:
	* problem-statement includes a set of "core" definitions. 
	* framework will be cleaned up to refer to problem-statement for all the "core" definitions (and not redefine them)
	* framework will include the additional definitions of general interest to the working group. I believe there are a few already in framework in that category. 
	* I think we are converging that:
		* "Delivering CDN" fits in the category of additional definitions to be included in the framework
		* "Access CDN" does not fit that category and shoudl not be introduced in framework.

If folks (in particular authors of other documents) feel that they have definitions that shoudl go into framework, please indicate so on the list.

Thanks

Francois


On 9 May 2012, at 19:05, Peterson, Larry wrote:

> Yes... Generally, it would be good to do a survey of terminology 
> various docs have introduced recently, and converge on the core 
> definitions.
> 
> Larry
> 
> On May 9, 2012, at 11:47 AM, Francois Le Faucheur wrote:
> 
>> Hi Larry,
>> 
>> Can you confirm this can be done in next rev of cdni-framework?
>> 
>> Tx
>> 
>> Francois
>> 
>> 
>> On 9 May 2012, at 17:19, <[e-mail]> wrote:
>> 
>>> Hi François,
>>> 
>>> Thanks for your review. We are integrating your comments.
>>> 
>>> About your comments on Section 1.1, I definitely think the terms "Access CDN" and "Delivering CDN" are useful more broadly than just in the use cases document. Therefore, I would be in favor of moving them to the framework document as you propose.
>>> 
>>>      Access CDN:
>>>      A CDN that includes Surrogates in the same network (e.g., same Autonomous System) as the End User. An Access CDN may have specific information about
>>>      the End User and the network, for instance, End User's
>>>      profile and access capabilities.
>>> 
>>>      Delivering CDN:
>>>      The CDN that delivers the requested piece of content to
>>>      the End User. In particular, the Delivering CDN can be an
>>>      Access CDN.
>>> 
>>> 
>>> Best regards,
>>> 
>>> Gilles
>>> 
>>> 
>>> -----Message d'origine-----
>>> De : [e-mail] [mailto:[e-mail]] De la part 
>>> de Francois Le Faucheur Envoyé : mercredi 25 avril 2012 18:46 À :
>>> [e-mail]
>>> Cc : [e-mail]
>>> Objet : [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases
>>> 
>>> To use-cases authors,
>>> 
>>> Below are my shepherd review comments of cdni-uses-cases.
>>> 
>>> I think the document is in a good shape and captures well the key targeted use cases.
>>> I identified two remaining significant points to be addressed, and also have included many suggestions to improve the document.
>>> I suggest we resolve the two significant points on the list and leave it to editor/authors to decide how to dispose of the suggestions for improvement offline.
>>> 
>>> Cheers
>>> 
>>> Francois
>>> 
>>> 
>>> Significant points
>>> =============
>>> 
>>> *** section 8 security considerations I have a few specific issues 
>>> with the current text of the Security Considerations section. But I don't really see the need to have an expanded Security Considerations section in both the use-case document and the problem-statement (particularly considering that the first IESG review comments on problem-statement suggest expanding the security considerations section there), in particular because the security considerations currently brought up in use-cases are not specific to individual use cases bur rather generic to the whole CDN interconnection problem space.
>>> So my proposal would be to remove the whole discussion from use-cases (i.e. the first 4 paragraphs) and refer to the Security Considerations section of the Problem Statement e.g.. by replacing:
>>> "
>>> This document focuses on the motivational use cases for CDN Interconnection, and does not analyze these threats in detail.
>>> "
>>> with:
>>> "
>>> This document focuses on the motivational use cases for CDN Interconnection, and does not analyze the associated threats. Those are discussed in [I-D.ietf-cdni-problem-statement].
>>> "
>>> 
>>> 
>>> ***section A.1:
>>> I still have a problem with the text of that section.
>>> I thought we had converged on an agreement that the text would:
>>>     * explain that CSPs may take into account very multiple/arbitrary/specific criteria in their policy
>>>     * explain that the CDNs are only expected to enforce a few specific policy rules (e.g. geo-blocking, time window) and for enforcement of all fancy CSP policy we propose that the responsibilities be divided into (1) the CSP being responsible for the fancy policy decision and (ii) the CDN for merely enforcing the CSP decision without having to understand the policy (e.g. via URI signing).
>>> Do we not agree on that or not?
>>> 
>>> The current text says that CDN selection and surrogate selection "are influenced by these policies" (referring to the fancy CSP policies). I do not agree with that. I don;t think we want CDN Selection or Surrogate selection to be influenced by whether a movie shoudl be available 14 or 28 days after DVD release, or whether a given resolution is "too high" for a particular user or terminal.
>>> 
>>> Also, the paragraph keeps talking about "dCDN selection or Surrogate selection" may fail for some fancy policy reasons. I don't understand what it means to "fail" , but more importantly again, I don't think we want CDN request routing decisions to be factoring very fancy CSP policy rules.
>>> Do we agree or not?
>>> 
>>> The last paragraphs gives examples of the CSP objectives of supporting delivery policies in CDNs, and those are fine and can be achieved with the set of mechanisms discussed above (i.e. goeblocking + time window + URI signing).
>>> 
>>> 
>>> Suggestions for improvements
>>> =======================
>>> 
>>> ***Abstract
>>> replace "CDNI" by "CDN Interconnection".
>>> 
>>> *** section 1:
>>> expand the first instance of CDNI into "CDN Interconnection (CDNI)".
>>> 
>>> *** section 1:
>>> "Then, the document highlights the need for interoperability to 
>>> exchange and enforce content delivery policies (Section 5)."
>>> I'd suggest replacing "for interoperability to exchange" by "for interoperability to allow exchange" or by "for interoperability in order to exchange"
>>> 
>>> *** section 1.1:
>>> Do you feel that the two additional terms are really specific to the use-case document (in which case their definition should stay in this document) or are they likely useful in other documents (in which case their definition should be migrated to the framework document)?
>>> Personally, I would say that those terms might be useful in other documents/discussions (eg I am pretty sure we'd need to refer to the "Delivering CDN" in other context).
>>> 
>>> *** section 1.1:
>>> "Access CDN:
>>> A CDN that is directly connected to the End User's access."
>>> I think this definition needs to be a little more specific. "Directly connected" does not mean "L2 connectivity" (because an on-net cache maybe a few L2 hops away), nor does it mean "L3 connectivity" (because an OTT CDN cache has IP connectivity to an enduser). I think you mean something in between,  more or less that the CDN and the access are within the same IP administrative domain, or something close to that. Can you try refine that definition?
>>> 
>>> *** section 1.3:
>>> " o  improve the experience for the End User; for instance delivery has
>>>   lower latency (decreased round-trip-time between the user and the
>>>   delivery server) and better robustness,"
>>> To be more comprehensive in justifying the claims, how about:
>>> " o  improve the experience for the End User; for instance delivery has
>>>   lower latency (decreased round-trip-time and higher throughput between the user and the
>>>   delivery server) and better robustness (ability to use multiple delivery servers),"
>>> 
>>> *** section 1.3:
>>> "o  reduce the Content Service Provider's (CSP) costs, such as
>>>   datacenter capacity, space, and electricity consumption, as
>>>   popular content is delivered through the CDN rather than through
>>>   the CSP's servers."
>>> The current wording raises the question of "if it reduces the costs by reducing expenses in the CSP datacenter, why does it not correspondingly increase the cost by increasing expenses in the CDN (which the CDN provider then charges back to the CSP)?"



>>> I think the gain is in the scale and effective pooling of CDN resources across many CSPs. Could you refine the wording to explain why there is indeed a net gain?
>>> 
>>> *** section 1.3:
>>> Replace:
>>> "
>>> An example is depicted in Figure 1.  Two CDN Providers establish a CDN Interconnection.
>>> "
>>> with:
>>> "
>>> An example is depicted in Figure 1 where two CDN Providers establish a CDN Interconnection.
>>> "
>>> (this is to minimize the redundancy with the sentence coming below: 
>>> "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their
>>> CDNs.")
>>> 
>>> 
>>> *** section 1.3:
>>> replace:
>>> "
>>> "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs."
>>> with:
>>> "Independently, CDN Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs."
>>> this is to clarify that the A<->B agreement is not specific to the 
>>> 1<->A agreement
>>> 
>>> 
>>> *** section 1.3:
>>> replace:
>>> "
>>> When a User Agent requests content from CSP-1, CDN-A considers that delivery by CDN-B is appropriate "
>>> with:
>>> "
>>> When a given User Agent requests content from CSP-1, CDN-A may consider that delivery by CDN-B is appropriate "
>>> 
>>> 
>>> *** section 1.3:
>>> replace:
>>> "
>>> CDN-A has delegated the handling of requests for CSP-1's content through the CDN Interconnection agreement, thus, the content is actually delivered from CDN-B.
>>> "
>>> with:
>>> "
>>> Through the CDN Interconnection arrangements put in place between CDN-A and CDN-B (as a result of the CDN Interconnection agreement established between CDN Provider 'A' and CDN Provider 'B'), CDN-A can redirect the request to CDN-B and the content is actually delivered to the User Agent by CDN-B.
>>> "
>>> (the current wording suggests that all deliveries of CSP1 content 
>>> would be handled by CDN-B, which is typically not the case i.e. only 
>>> a subset of the requests are redirected thy CDN-A to CDN-B)
>>> 
>>> 
>>> *** section 1.3:
>>> replace:
>>> "
>>> CSP-1 benefits because it only needs to make one business agreement and one physical connection, with CDN Provider 'A'
>>> "
>>> with:
>>> "
>>> CSP-1 benefits because it only needs to make one business agreement and one technical arrangement with CDN Provider 'A'
>>> "
>>> (this is because the interfacing between CSP and uCDN comprises more than "physical connection").
>>> 
>>> 
>>> *** section 1.3:
>>> replace:
>>> "
>>> CSP-1 had also gone to the trouble of making a business agreement with CDN Provider 'B'
>>> "
>>> with:
>>> "
>>> CSP-1 had also gone to the trouble of making a business agreement and technical arrangemement with CDN Provider 'B'
>>> "
>>> 
>>> *** section 1.3:
>>> replace:
>>> "
>>> But it does not want
>>> "
>>> with:
>>> "
>>> However, CSP-2 may not want
>>> "
>>> 
>>> *** section 2.1:
>>> after
>>> "
>>> o  without incurring additional transit and other network costs that
>>>    would result from serving content from geographically or
>>>    topologically remote Surrogates.
>>> "
>>> add:
>>> "
>>> o without incurring the cost of deploying and operating Surrogates and the associated CDN infrastructure that may not be justified in the corresponding geographic region (e.g. because of relatively low delivery volume, or conversely because of the high investments that would be needed to satisfy the high volume) "
>>> 
>>> 
>>> *** section 2.2:
>>> replace:
>>> "
>>> A large CDN Provider may also operate CDNs from several subsidiaries (which may rely on different CDN technologies, see Section 4.2). In certain circumstances, the CDN Provider needs to make its CDNs interoperate to provide a consistent service to its customers on its whole footprint.
>>> "
>>> with:
>>> "
>>> A large CDN Provider may have several subsidiaries that also each operate their own CDN (which may rely on different CDN technologies, see Section 4.2). In certain circumstances, the CDN Provider needs to make these CDNs interoperate to provide a consistent service to its customers on the whole collective footprint.
>>> "
>>> 
>>> 
>>> *** section 2.3:
>>> replace:
>>> "
>>> injected into the access network
>>> "
>>> with:
>>> "
>>> injected into the ISP network
>>> "
>>> 
>>> *** section 2.3:
>>> replace:
>>> "
>>> There are mutual benefits to the Access CDN, "
>>> with:
>>> "
>>> There are mutual benefits to the ISP (acting as an Access CDN), "
>>> 
>>> 
>>> *** section 2.3:
>>> replace:
>>> "
>>> for example, QoS and reduced round trip time.
>>> "
>>> with:
>>> "
>>> for example, reduced content startup time or increased video quality and resolution of adaptive streaming content.
>>> "
>>> (I don't think RTT is very meaningful to a CSP customer)
>>> 
>>> 
>>> *** section 2.4:
>>> The nomadic user is currently defined as "moving between CDNs" which is sort of a self-serving definition to justify CDN interconnection. I think we should rather define the nomadic user as "moving between access networks" and then justify that leveraging local CDNs can bring a lot of benefits.
>>> This requires the following text edits:
>>> s/who move between CDNs/who move between access networks/ s/moving 
>>> between different CDN Providers/moving between different access 
>>> networks/
>>> 
>>> *** section 2.4:
>>> replace:
>>> "
>>> which may reside
>>> "
>>> with:
>>> "
>>> which may be located
>>> "
>>> 
>>> *** section 2.4:"
>>> I propose to remove the sentence:
>>> "
>>> The term "Nomadic" does not necessarily relate to geographic roaming.
>>> "
>>> because this point has already been fully (and better) clarified in the preceding paragraph.
>>> 
>>> 
>>> 
>>> *** section 2.4:
>>> replace:
>>> "
>>> the WiFi or mobile provider
>>> "
>>> with:
>>> "
>>> the WiFi or mobile provider (NSP B)
>>> "
>>> 
>>> 
>>> *** section 3.1:
>>> replace:
>>> "
>>> needs CDN capacities
>>> "
>>> with:
>>> "
>>> needs CDN capacity
>>> "
>>> 
>>> *** section 3.2.1:
>>> The text mentions two options (use OS, use another CDN). I think the section shoudl probably also mention the most obvious option (i.e. use other surrogates in the same CDN). Or alternatively, clarify that the considered situation is where there is a partial failure of some surrogates resulting in the remaining surrogates being fully loaded.
>>> 
>>> 
>>> *** section 3.2.1:
>>> replace:
>>> "
>>> to both distribute load between origin servers and attempt content 
>>> acquisition from alternate origin servers when acquisition failures occur.  When normal content acquisition fails, a CDN may need to try other origin server options, "
>>> with:
>>> "
>>> to both distribute load between content sources and attempt content 
>>> acquisition from alternate content sources when acquisition failures occur.  When normal content acquisition fails, a CDN may need to try other content source options, "
>>> (I believe everywhere else we use "origin server" to refer to the OS 
>>> of the CSP and "content source" as the generic term for getting 
>>> content including origin server and uCDN)
>>> 
>>> *** section 3.2.2:
>>> replace:
>>> "
>>> the selection of content acquisition sources should be considered.
>>> "
>>> with:
>>> "
>>> the selection of content acquisition sources should be considered and facilitated.
>>> "
>>> (i.e. it is not just a matter of "thinking" about it: it must be explicitly allowed or at leads made easier).
>>> 
>>> 
>>> *** section 4.1:
>>> "to serve a proportion of its traffic that requires HTTPS."
>>> can you include a reference for HTTPS?
>>> 
>>> 
>>> *** section 5:
>>> replace:
>>> "
>>> An important aspect of the above use cases "
>>> with:
>>> "
>>> An important aspect common to all the above use cases "
>>> 
>>> 
>>> *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on 
>>> line 618, but no explicit reference was found in the text I'd suggest you add an explicit reference. For example, in "1.  Introduction" you could replace:
>>> "
>>> The document can be used to guide the definition of the requirements to be supported by the various CDNI interfaces defined in [I-D.ietf-cdni-problem-statement].
>>> "
>>> by
>>> "
>>> The document can be used to guide the definition of the requirements (as documented in [I-D.ietf-cdni-requirements]) to be supported by the set of CDNI interfaces defined in [I-D.ietf-cdni-problem-statement].
>>> "
>>> (BTW, independely of the reference issue, "the set of CDNI interfaces" might read better than "the various CDNI interfaces").
>>> 
>>> 
>>> *** The document has a disclaimer for pre-RFC5378 work, but was first  submitted on or after 10 November 2008.  Does it really need the disclaimer?
>>> _______________________________________________
>>> CDNi mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/cdni
>> 
> 

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