Subject: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 25 Apr 2012 18:45:38 +0200

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?

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 25 Apr 2012 18:38:57 +0100

Francois,

> 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.

Works for me. As part of reworking the Security Considerations section in the problem statement I will see what text from the use cases draft can be reused.

> Do we not agree on that or not?

I agree with what you said, i.e. CSPs handle fancy policy and then grant tokens/whatever that the dCDN can validate to ensure they are only delivering to End Users the CSP has granted access too.

CDN policies should not be CSP specific - they should just cover things like geo-blocking rules etc.

Ben

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

---

From: Kevin J Ma <[email-masked]>
Date: Thu, 26 Apr 2012 17:46:18 -0400

Hi Francois,

>       * 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).

I agree that the CDN should enforce any policy that is defined in metadata.
If a supported metadata dictates a restriction, regardless of any individual
interpretation of the semantic fanciness, the restriction should be enforced.
If a dCDN does not support a given metadata, it can express that to the uCDN,
which should influence the inter-CDN request routing.

> 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 failure could probably be a more generic delivery failure, due to
restrictions defined in the metadata, though, the framework document
shows the metadata checks as part of request routing decision making
which presumably influences dCDN/Surrogate selection?

The fanciness of the policy should not matter, as long as the
metadata which conveys the enforcement of that policy is clear and
succinct.  The inter-CDN request routing should be aware of the
capabilities of each dCDN and not delegate to dCDNs that lack support
for capabilities which are deemed mandatory.

The use cases do not dictate any specific implementations.  They do not
require request routing to implement fancy policy rules.  A valid
implementation could wrap all the fancy policy rules into a nice neat
boolean value.  An equally valid implementation could implement extra
super fancy policy rules.  The use case does not mandate one or the other.

Is the concern that specific portions are not valid, or that the descriptions
are unclear, or is the concern about an assumed implementation's fanciness?

thanx.

--  Kevin J. Ma

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francois Le Faucheur
> Sent: Wednesday, April 25, 2012 12:46 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases
>
> To use-cases authors,
>
> 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
> =============
>
> 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:
>       * 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).
> 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).
>
>
> 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:
> 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:
> 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:
> "
> (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-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'
> "
> 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:
> "
> 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:
> "
> for example, reduced content startup time or increased video quality and
> resolution of adaptive streaming content.
> "
> 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.
> 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:
> "
> (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:
> *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line 618,
> but no explicit reference was found in the text
> 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?

---

From: Kevin J Ma <[email-masked]>
Date: Thu, 26 Apr 2012 17:46:25 -0400

Hi Ben,

> I agree with what you said, i.e. CSPs handle fancy policy and then grant
> tokens/whatever that the dCDN can validate to ensure they are only
> delivering to End Users the CSP has granted access too.

I do not disagree with your statement.  I just will note that if the CSP
is nolonger in control of which dCDN the request will ultimately be delegated
to, the "whatever" has to be enforced across all dCDNs.

thanx.

--  Kevin J. Ma

> Ben Niven-Jenkins
> Sent: Wednesday, April 25, 2012 1:39 PM
> To: Francois Le Faucheur
> Cc: [email-masked]; [email-masked]
> Subject: Re: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases
>
> Francois,
>
> Works for me. As part of reworking the Security Considerations section in
> the problem statement I will see what text from the use cases draft can be
> reused.
>
> > ***section A.1:
> I agree with what you said, i.e. CSPs handle fancy policy and then grant
> tokens/whatever that the dCDN can validate to ensure they are only
> delivering to End Users the CSP has granted access too.
>
> > 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
> > (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
> > o without incurring the cost of deploying and operating Surrogates and
> the associated CDN infrastructure that may not be justified in the
> > 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:
> > "
> > *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line
> 618, but no explicit reference was found in the text
> > 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
> > "