Re: [CDNi] CDNI Use Cases

Francois Le Faucheur <flefauch@cisco.com> Mon, 10 January 2011 17:41 UTC

Return-Path: <flefauch@cisco.com>
X-Original-To: cdni@core3.amsl.com
Delivered-To: cdni@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA2843A6AFE for <cdni@core3.amsl.com>; Mon, 10 Jan 2011 09:41:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.409
X-Spam-Level:
X-Spam-Status: No, score=-10.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CugVZjx+2gAd for <cdni@core3.amsl.com>; Mon, 10 Jan 2011 09:41:22 -0800 (PST)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 8AF593A67AB for <cdni@ietf.org>; Mon, 10 Jan 2011 09:41:22 -0800 (PST)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 10 Jan 2011 17:43:36 +0000
Received: from ams-flefauch-8713.cisco.com (ams-flefauch-8713.cisco.com [10.55.161.196]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p0AHhZqp024198; Mon, 10 Jan 2011 17:43:35 GMT
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Francois Le Faucheur <flefauch@cisco.com>
In-Reply-To: <7870FF6F-4534-4224-968F-C31CAFE0C6E9@gmail.com>
Date: Mon, 10 Jan 2011 18:43:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <83720BF5-9A94-4463-BB7A-AEFE5FA39076@cisco.com>
References: <7870FF6F-4534-4224-968F-C31CAFE0C6E9@gmail.com>
To: Grant Watson <watson.gm@gmail.com>
X-Mailer: Apple Mail (2.1082)
Cc: cdni@ietf.org
Subject: Re: [CDNi] CDNI Use Cases
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" <cdni.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/cdni>, <mailto:cdni-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cdni>
List-Post: <mailto:cdni@ietf.org>
List-Help: <mailto:cdni-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cdni>, <mailto:cdni-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jan 2011 17:41:24 -0000

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:

> 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
> grant.watson@bt.com
> 
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni