Subject: [CDNi] CDNI Use Cases

From: Grant Watson <[email-masked]>
Date: Sat, 8 Jan 2011 21:48:48 +0000

Ben & Francois et al,

CDN Interconnect is a very hot topic for us right now and we are very keen to support your proposal. 

We have been working on a I-D to document provider use cases, to compliment your I-D. Hopefully you will find this to be a useful exercise. 

It is not complete but I wanted to socialise it early as we are keen and open to collaborate on this I-D with other providers that have use cases to that they would like to include, or input in any other way.

http://www.ietf.org/id/draft-watson-cdni-use-cases-00.txt

Thanks

Grant Watson
[email-masked]

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 10 Jan 2011 18:43:25 +0100

Hello Grant,

I went through the Use Cases document you posted and here are my comments/suggestions.

	* I would suggest that the Use Cases I-D expands significantly more on what are the motivations/applications/services that are targeted through the CDN Interconnect solution. ie why is it exactly that you are interested in interconnecting your CDN to someone else's? To me this is the main goal of that document.
For example, I would encourage to expand on each of the points a. and b. you currently have under section 4. 
To me a. should be described as a Use Case of its own: CDN Interconnect allows a CDN operator to design its CDN to deal with reasonable peak/failure (but not absolute worst peak/failure) and use another CDN to deal with exceptional peak/failure. 
Similarly, what you describe under b. could be considered a Use Case of its own: extend footprint/coverage beyond CDN footprint without extending CDN build out.

	* I would suggest you don't expand too much on the redirection steps/variations because I expect this would be covered in other documents (kind of more related to how it works, than to the use cases).
For example, regarding the Editor's note below, I am note sure you need to describe that extra option (in that document):
" [Ed: There are a potentially couple of options, the above and the
   option to hand off to CDN-B without making a request first.  Consider
   describing that as an option also?  For example in the case of
   intermediate CDN you might want to hand-off immediately to CDN-C
   rather than relying on various requests flowing from A to B to C and
   back.]
"

	* text says:
"In order to minimise the
   number of direct business relationships between a CSP and a set of
   interconnected CDNs, it is assumed that a CSP will only be required/
   desire to have a direct relationship with a single CDN.  The single
   CDN selected by the CSP is referred to as "The Authoritative CDN"
"
While CDNI must certainly allow a CSP to have a relationship with a single CDN provider, it must also allow a CSP to use more than one "Upstream CDNs". The key is that the CDNI Interconnect allows the content of a CSP to be delivered by a CDN-X even if CSP does not have a relationship with CDN-X, as long as CDN-X has a relationship with a CDN that has a relationship with the CSP (or with a CDN that has a relationship with a CDN that has a relationship with CSP, or...).
I would suggest that you adjust the above text and tweak the definition of Authoritative CDN accordingly (even if a CSP uses multiple CDNs, for a given content/request there is a single Authoritative CDN)

	* the next rev of the Problem Statement will also have definitions for the terms you've introduced but that can be fixed later.

Just my take.

Francois

On 8 Jan 2011, at 22:48, Grant Watson wrote:

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

---

From: Grant Watson <[email-masked]>
Date: Tue, 11 Jan 2011 12:25:04 +0000

Hi Francois,

Thanks for your comments. Very useful and mostly I don't disagree. 

> Similarly, what you describe under b. could be considered a Use Case of its own: extend footprint/coverage beyond CDN footprint without extending CDN build out.

Agreed in the most part, will look to restructure in the next rev.

>   rather than relying on various requests flowing from A to B to C and
  
Yes, this makes sense. I was in two minds as to include or not. Its covered in the Requirements I-D I believe anyway.

> I would suggest that you adjust the above text and tweak the definition of Authoritative CDN accordingly (even if a CSP uses multiple CDNs, for a given content/request there is a single Authoritati…

Will reword in next rev.

>        * the next rev of the Problem Statement will also have definitions for the terms you've introduced but that can be fixed later.

No problem, the main intention was to socialise something early to gain wider input and support.

Cheers 

Grant