
From vkg@bell-labs.com  Tue Feb  7 09:06:14 2012
Return-Path: <vkg@bell-labs.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D5A21F881E for <cdni@ietfa.amsl.com>; Tue,  7 Feb 2012 09:06:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.817
X-Spam-Level: 
X-Spam-Status: No, score=-106.817 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7njFdXi3-ACA for <cdni@ietfa.amsl.com>; Tue,  7 Feb 2012 09:06:13 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id C4C3121F8808 for <cdni@ietf.org>; Tue,  7 Feb 2012 09:06:07 -0800 (PST)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q17H654Y006339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <cdni@ietf.org>; Tue, 7 Feb 2012 11:06:06 -0600 (CST)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q17H64GN015836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <cdni@ietf.org>; Tue, 7 Feb 2012 11:06:05 -0600
Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q17H64PG015233 for <cdni@ietf.org>; Tue, 7 Feb 2012 11:06:04 -0600 (CST)
Message-ID: <4F315AFB.7030908@bell-labs.com>
Date: Tue, 07 Feb 2012 11:10:19 -0600
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: cdni@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
X-Mailman-Approved-At: Tue, 07 Feb 2012 09:29:22 -0800
Subject: [CDNi] Call for participation: altonext
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Tue, 07 Feb 2012 17:06:15 -0000

Folks: This is a reminder on protocol extension discussion
kickoff on the new altoext mailing list (list details in email
below).  These extensions may impact the CDN use cases.  We are forming
a community of interest on the altoext mailing list and feedback from
people involved in the CDNI work will be surely useful and certainly
welcome.

Thank you.

-------- Original Message --------
Subject: ALTO extensions: new list + problem statement
Date: Mon, 30 Jan 2012 16:54:49 +0100
From: Enrico Marocco <enrico.marocco at telecomitalia.it>
To: alto at ietf.org <alto at ietf.org>

Hi folks,

the new altoext at ietf.org mailing list has just been created to
discuss possible extensions to the about-to-be-finished ALTO protocol.

We have also recently submitted a draft trying to summarize the
previous discussions on the subject:
http://tools.ietf.org/html/draft-marocco-alto-next

In a nutshell: the possible extensions, primarily intended to better
address the CDN/datacenter and server-to-server use cases, mainly
concern:
   + a server-to-client notification mechanism;
   + additional types of information, such as:
     o network link load (average, over some recent timeframe);
     o server load (average, over some recent timeframe);
     o availability of resources such as memory, content, installed
       applications.

The new mailing list has been created in order to get broader feedback
and to get together people with experience in different areas. If you
have an opinion on whether and why the proposed (and possibly further)
extensions will be a good or a bad idea, you can join the discussion
at: https://www.ietf.org/mailman/listinfo/altoext

-- 

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
Web:   http://ect.bell-labs.com/who/vkg/

From Jan.Seedorf@neclab.eu  Fri Feb 10 06:57:48 2012
Return-Path: <Jan.Seedorf@neclab.eu>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E694D21F84F9 for <cdni@ietfa.amsl.com>; Fri, 10 Feb 2012 06:57:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4Ct9xaE8fwg for <cdni@ietfa.amsl.com>; Fri, 10 Feb 2012 06:57:47 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 366D021F84F8 for <cdni@ietf.org>; Fri, 10 Feb 2012 06:57:47 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 1D13228000207 for <cdni@ietf.org>; Fri, 10 Feb 2012 15:57:46 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8TR+TQQs7YM for <cdni@ietf.org>; Fri, 10 Feb 2012 15:57:46 +0100 (CET)
Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id EF59E28000206 for <cdni@ietf.org>; Fri, 10 Feb 2012 15:57:40 +0100 (CET)
Received: from PALLENE.office.hd ([169.254.1.103]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Fri, 10 Feb 2012 15:57:41 +0100
From: Jan Seedorf <Jan.Seedorf@neclab.eu>
To: "cdni@ietf.org" <cdni@ietf.org>
Thread-Topic: Question regarding downstream CDN selection
Thread-Index: AczoAzqhH0Gxf7unQsKRfBfXt4YXFQ==
Date: Fri, 10 Feb 2012 14:57:40 +0000
Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24EE7153@PALLENE.office.hd>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.2.227]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [CDNi] Question regarding downstream CDN selection
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Fri, 10 Feb 2012 14:57:49 -0000

Folks,

I have a question regarding downstream CDN selection. The introduction of t=
he CDNI problem statement draft says: "As an example, a CSP could contract =
with an "authoritative" CDN Provider for the delivery of content and that a=
uthoritative CDN Provider could contract with one or more downstream CDN Pr=
ovider(s) to distribute and deliver some or all of the content on behalf of=
 the authoritative CDN Provider.  The formation and details of any business=
 relationships between a CSP and a CDN Provider and between one CDN Provide=
r and another CDN Provider are out of scope of this document.  However, no =
standards or open specifications currently exist to facilitate such CDN int=
erconnection."

My question is if we always assume this model, where there is an "authorita=
tive" CDN provider which transitively has itself contracted several downstr=
eam CDN providers. Or do we account for the possibility that potentially a =
CSP has own its own made several independent agreements with other CDNs (e.=
g. because they are covering different geographical areas). If we want to c=
onsider the latter case, how does the upstream CDN know for a given downstr=
eam CDN if it serves the content for a given CSP?

 - Jan

> -----Original Message-----
> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of
> Francois Le Faucheur
> Sent: Monday, January 30, 2012 2:38 PM
> To: cdni@ietf.org
> Subject: [CDNi] Working Group Last Call on draft-ietf-cdni-use-cases-03.t=
xt
>=20
> All,
>=20
> This is the start of a two-week working group last call on draft-ietf-cdn=
i-use-
> cases-03.txt:
> https://datatracker.ietf.org/doc/draft-ietf-cdni-use-cases/
>=20
> This working group last call will end 13 Feb 2012. Please send your comme=
nts
> to the CDNI mailing list.
>=20
> Francois & Rich
>=20
>=20
> Begin forwarded message:
>=20
>=20
> 	From: <gilles.bertrand@orange.com>
>=20
> 	Date: 30 January 2012 12:12:50 CET
>=20
> 	To: <cdni@ietf.org>
>=20
> 	Subject: [CDNi] TR: I-D Action: draft-ietf-cdni-use-cases-03.txt
>=20
>=20
> 	Hi,
>=20
> 	We have submitted a revision addressing Kent's comments.
>=20
> 	http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-iet=
f-
> cdni-use-cases-02.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-cdni-use=
-
> cases-03.txt
>=20
> 	Best regards,
>=20
> 	Gilles
>=20
>=20
>=20
>=20
> 	-----Message d'origine-----
> 	De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la
> part de internet-drafts@ietf.org
> 	Envoy=E9 : lundi 30 janvier 2012 12:07
> 	=C0 : i-d-announce@ietf.org
> 	Cc : cdni@ietf.org
> 	Objet : [CDNi] I-D Action: draft-ietf-cdni-use-cases-03.txt
>=20
>=20
> 	A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Content Delivery Networks
> Interconnection Working Group of the IETF.
>=20
> 	Title           : Use Cases for Content Delivery Network Interconnection
> 	Author(s)       : Gilles Bertrand
> 	                         Stephan Emile
> 	                         Grant Watson
> 	                         Trevor Burbridge
> 	                         Philip Eardley
> 	                         Kevin Ma
> 	Filename        : draft-ietf-cdni-use-cases-03.txt
> 	Pages           : 18
> 	Date            : 2012-01-30
>=20
> 	  Content Delivery Networks (CDNs) are commonly used for
> improving the
> 	  End User experience of a content delivery service, at a reasonable
> 	  cost.  This document outlines real world use cases (not technical
> 	  solutions) for interconnecting CDNs.  It focuses on use cases that
> 	  correspond to identified industry needs and that are expected to be
> 	  realized once a CDN Interconnection (CDNI) solution is available.
> 	  This document can be used to provide guidance to the CDNI WG
> about
> 	  the interconnection arrangements to be supported and to validate
> the
> 	  requirements of the various CDNI interfaces.
>=20
>=20
> 	A URL for this Internet-Draft is:
> 	http://www.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-03.txt
>=20
> 	Internet-Drafts are also available by anonymous FTP at:
> 	ftp://ftp.ietf.org/internet-drafts/
>=20
> 	This Internet-Draft can be retrieved at:
> 	ftp://ftp.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-03.txt
>=20
> 	_______________________________________________
> 	CDNi mailing list
> 	CDNi@ietf.org
> 	https://www.ietf.org/mailman/listinfo/cdni
> 	_______________________________________________
> 	CDNi mailing list
> 	CDNi@ietf.org
> 	https://www.ietf.org/mailman/listinfo/cdni
>=20
>=20
>=20


From ina@juniper.net  Fri Feb 10 10:18:40 2012
Return-Path: <ina@juniper.net>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F8321F86FD for <cdni@ietfa.amsl.com>; Fri, 10 Feb 2012 10:18:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.064
X-Spam-Level: 
X-Spam-Status: No, score=-6.064 tagged_above=-999 required=5 tests=[AWL=0.535,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saRcNZJNoPIv for <cdni@ietfa.amsl.com>; Fri, 10 Feb 2012 10:18:39 -0800 (PST)
Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2E08621F86E1 for <cdni@ietf.org>; Fri, 10 Feb 2012 10:18:39 -0800 (PST)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTzVfeHy4WWZsJhtoIP3R+st4dwQE+io4@postini.com; Fri, 10 Feb 2012 10:18:39 PST
Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 10 Feb 2012 10:16:43 -0800
From: Ina Minei <ina@juniper.net>
To: Jan Seedorf <Jan.Seedorf@neclab.eu>, "cdni@ietf.org" <cdni@ietf.org>
Date: Fri, 10 Feb 2012 10:16:39 -0800
Thread-Topic: Question regarding downstream CDN selection
Thread-Index: AczoAzqhH0Gxf7unQsKRfBfXt4YXFQAFyaQQ
Message-ID: <189716C74BBB9C4095FE8CA503B1FC3A5762A589C0@EMBX02-HQ.jnpr.net>
References: <2779C9F0771F974CAD742BAE6D9904FE24EE7153@PALLENE.office.hd>
In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE24EE7153@PALLENE.office.hd>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
x-exclaimer-md-config: f8e27f27-03b2-4c3e-9447-119194e72cb6
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [CDNi] Question regarding downstream CDN selection
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Fri, 10 Feb 2012 18:18:40 -0000

Jan,=20

The answer to that question depends on how you assume redirection is done i=
n the case you are describing, and I think this boils down to the different=
 models of CDN federations.=20

The first (the one described in the quote), relies on bilateral agreements.=
 In that case, the request is redirected to the authoritative, who will  re=
direct to the best downstream. =20

The second model (the one you describe), sounds like an exchange model, wit=
h multiple members of the exchange having a relation to the same CSP, and t=
he request being redirected to a coordinating entity for the exchange.  In =
the second case, as you are pointing out, user location information is not =
enough to determine the CDN from which the content will be served (because =
that CDN may not be serving content for the CSP), and the set of candidate =
CDNs has to be determined based on the content.=20

Ina=20

-----Original Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Jan=
 Seedorf
Sent: Friday, February 10, 2012 6:58 AM
To: cdni@ietf.org
Subject: [CDNi] Question regarding downstream CDN selection

Folks,

I have a question regarding downstream CDN selection. The introduction of t=
he CDNI problem statement draft says: "As an example, a CSP could contract =
with an "authoritative" CDN Provider for the delivery of content and that a=
uthoritative CDN Provider could contract with one or more downstream CDN Pr=
ovider(s) to distribute and deliver some or all of the content on behalf of=
 the authoritative CDN Provider.  The formation and details of any business=
 relationships between a CSP and a CDN Provider and between one CDN Provide=
r and another CDN Provider are out of scope of this document.  However, no =
standards or open specifications currently exist to facilitate such CDN int=
erconnection."

My question is if we always assume this model, where there is an "authorita=
tive" CDN provider which transitively has itself contracted several downstr=
eam CDN providers. Or do we account for the possibility that potentially a =
CSP has own its own made several independent agreements with other CDNs (e.=
g. because they are covering different geographical areas). If we want to c=
onsider the latter case, how does the upstream CDN know for a given downstr=
eam CDN if it serves the content for a given CSP?

 - Jan

> -----Original Message-----
> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of
> Francois Le Faucheur
> Sent: Monday, January 30, 2012 2:38 PM
> To: cdni@ietf.org
> Subject: [CDNi] Working Group Last Call on draft-ietf-cdni-use-cases-03.t=
xt
>=20
> All,
>=20
> This is the start of a two-week working group last call on draft-ietf-cdn=
i-use-
> cases-03.txt:
> https://datatracker.ietf.org/doc/draft-ietf-cdni-use-cases/
>=20
> This working group last call will end 13 Feb 2012. Please send your comme=
nts
> to the CDNI mailing list.
>=20
> Francois & Rich
>=20
>=20
> Begin forwarded message:
>=20
>=20
> 	From: <gilles.bertrand@orange.com>
>=20
> 	Date: 30 January 2012 12:12:50 CET
>=20
> 	To: <cdni@ietf.org>
>=20
> 	Subject: [CDNi] TR: I-D Action: draft-ietf-cdni-use-cases-03.txt
>=20
>=20
> 	Hi,
>=20
> 	We have submitted a revision addressing Kent's comments.
>=20
> 	http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-iet=
f-
> cdni-use-cases-02.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-cdni-use=
-
> cases-03.txt
>=20
> 	Best regards,
>=20
> 	Gilles
>=20
>=20
>=20
>=20
> 	-----Message d'origine-----
> 	De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la
> part de internet-drafts@ietf.org
> 	Envoy=E9 : lundi 30 janvier 2012 12:07
> 	=C0 : i-d-announce@ietf.org
> 	Cc : cdni@ietf.org
> 	Objet : [CDNi] I-D Action: draft-ietf-cdni-use-cases-03.txt
>=20
>=20
> 	A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Content Delivery Networks
> Interconnection Working Group of the IETF.
>=20
> 	Title           : Use Cases for Content Delivery Network Interconnection
> 	Author(s)       : Gilles Bertrand
> 	                         Stephan Emile
> 	                         Grant Watson
> 	                         Trevor Burbridge
> 	                         Philip Eardley
> 	                         Kevin Ma
> 	Filename        : draft-ietf-cdni-use-cases-03.txt
> 	Pages           : 18
> 	Date            : 2012-01-30
>=20
> 	  Content Delivery Networks (CDNs) are commonly used for
> improving the
> 	  End User experience of a content delivery service, at a reasonable
> 	  cost.  This document outlines real world use cases (not technical
> 	  solutions) for interconnecting CDNs.  It focuses on use cases that
> 	  correspond to identified industry needs and that are expected to be
> 	  realized once a CDN Interconnection (CDNI) solution is available.
> 	  This document can be used to provide guidance to the CDNI WG
> about
> 	  the interconnection arrangements to be supported and to validate
> the
> 	  requirements of the various CDNI interfaces.
>=20
>=20
> 	A URL for this Internet-Draft is:
> 	http://www.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-03.txt
>=20
> 	Internet-Drafts are also available by anonymous FTP at:
> 	ftp://ftp.ietf.org/internet-drafts/
>=20
> 	This Internet-Draft can be retrieved at:
> 	ftp://ftp.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-03.txt
>=20
> 	_______________________________________________
> 	CDNi mailing list
> 	CDNi@ietf.org
> 	https://www.ietf.org/mailman/listinfo/cdni
> 	_______________________________________________
> 	CDNi mailing list
> 	CDNi@ietf.org
> 	https://www.ietf.org/mailman/listinfo/cdni
>=20
>=20
>=20

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

From gilles.bertrand@orange.com  Mon Feb 13 06:04:13 2012
Return-Path: <gilles.bertrand@orange.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB1621F8568 for <cdni@ietfa.amsl.com>; Mon, 13 Feb 2012 06:04:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.759
X-Spam-Level: 
X-Spam-Status: No, score=-5.759 tagged_above=-999 required=5 tests=[AWL=0.490,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dva79WSWuNx0 for <cdni@ietfa.amsl.com>; Mon, 13 Feb 2012 06:04:13 -0800 (PST)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id D8A3D21F8562 for <cdni@ietf.org>; Mon, 13 Feb 2012 06:04:12 -0800 (PST)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 87C195D9118 for <cdni@ietf.org>; Mon, 13 Feb 2012 15:04:11 +0100 (CET)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 7FABC5D8348 for <cdni@ietf.org>; Mon, 13 Feb 2012 15:04:11 +0100 (CET)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 13 Feb 2012 15:04:11 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 13 Feb 2012 15:04:02 +0100
Message-ID: <8E09C72DBC577D489F13A71228C0B7BF03231555@ftrdmel0.rd.francetelecom.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D Action: draft-bertrand-cdni-logging-00.txt
Thread-Index: AczqV04P2kj58bv3Su2UKn4mvvPeCwAAGnzQ
From: <gilles.bertrand@orange.com>
To: <cdni@ietf.org>
X-OriginalArrivalTime: 13 Feb 2012 14:04:11.0247 (UTC) FILETIME=[5C3DAFF0:01CCEA58]
Subject: [CDNi] TR: I-D Action: draft-bertrand-cdni-logging-00.txt
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
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/options/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, 13 Feb 2012 14:04:13 -0000

Hi everyone,

We have submitted a new draft on the Logging interface:
http://tools.ietf.org/html/draft-bertrand-cdni-logging-00=20

"This memo specifies the Logging interface between a downstream CDN
(dCDN) and an upstream CDN (uCDN). It introduces a framework, an
architecture design and a set of new requirements. Then it drafts an
information model."

Best regards,

Gilles


-----Message d'origine-----
De=A0: i-d-announce-bounces@ietf.org =
[mailto:i-d-announce-bounces@ietf.org] De la part de =
internet-drafts@ietf.org
Envoy=E9=A0: lundi 13 f=E9vrier 2012 14:56
=C0=A0: i-d-announce@ietf.org
Objet=A0: I-D Action: draft-bertrand-cdni-logging-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts =
directories.

	Title           : CDNI Logging Interface
	Author(s)       : Gilles Bertrand
                          Stephan Emile
	Filename        : draft-bertrand-cdni-logging-00.txt
	Pages           : 26
	Date            : 2012-02-13

   This memo specifies the Logging interface between a downstream CDN
   (dCDN) and an upstream CDN (uCDN).  It introduces a framework, an
   architecture design and a set of new requirements.  Then it drafts an
   information model.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-bertrand-cdni-logging-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-bertrand-cdni-logging-00.txt

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or =
ftp://ftp.ietf.org/ietf/1shadow-sites.txt

From hexiaoyan@huawei.com  Thu Feb 16 03:03:46 2012
Return-Path: <hexiaoyan@huawei.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C07221F86EB for <cdni@ietfa.amsl.com>; Thu, 16 Feb 2012 03:03:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.289
X-Spam-Level: 
X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBqhmmiMdpH8 for <cdni@ietfa.amsl.com>; Thu, 16 Feb 2012 03:03:42 -0800 (PST)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id DBD2221F86C3 for <cdni@ietf.org>; Thu, 16 Feb 2012 03:03:41 -0800 (PST)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZH00GNYG1UVE@szxga04-in.huawei.com> for cdni@ietf.org; Thu, 16 Feb 2012 19:03:30 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZH00IFFG1UVC@szxga04-in.huawei.com> for cdni@ietf.org; Thu, 16 Feb 2012 19:03:30 +0800 (CST)
Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AHE03111; Thu, 16 Feb 2012 19:02:32 +0800
Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Feb 2012 19:02:22 +0800
Received: from w36710x (10.144.4.163) by smtpscn.huawei.com (10.82.67.153) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Feb 2012 19:02:26 +0800
Date: Thu, 16 Feb 2012 19:02:26 +0800
From: HeXiaoyan <hexiaoyan@huawei.com>
X-Originating-IP: [10.144.4.163]
To: cdni@ietf.org
Message-id: <005f01ccec9a$77e2c210$67a84630$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset=utf-8
Content-language: zh-cn
Content-transfer-encoding: quoted-printable
Thread-index: AczsiosVjYrZ0GwrQ7qLUowiwIjMlQAApqLw
X-CFilter-Loop: Reflected
Subject: [CDNi] FW: New Version Notification for	draft-he-cdni-routing-request-redirection-00.txt
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Thu, 16 Feb 2012 11:03:46 -0000

Hi all,
We have submitted a draft on the routing request =
redirection=EF=BC=88Recursive mode=EF=BC=89 of RRI,
http://datatracker.ietf.org/doc/draft-he-cdni-routing-request-redirection=
/

Your comments are welcome.

Best Regards
Xiaoyan(Susan) He

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20
Sent: Thursday, February 16, 2012 5:04 PM
To: hexiaoyan@huawei.com
Cc: cheng@gsta.com; hexiaoyan@huawei.com; =
spencer.dawkins@wondermaster.com; niwei@chinamobile.com
Subject: New Version Notification for =
draft-he-cdni-routing-request-redirection-00.txt

A new version of I-D, draft-he-cdni-routing-request-redirection-00.txt =
has been successfully submitted by Xiaoyan He and posted to the IETF =
repository.

Filename:	 draft-he-cdni-routing-request-redirection
Revision:	 00
Title:		 Routing Request Redirection for CDN Interconnection
Creation date:	 2012-02-16
WG ID:		 Individual Submission
Number of pages: 13

Abstract:
  The Request Routing Interface comprises the asynchronous advertisement
of   footprint and capabilities by a dCDN that allows a uCDN to decide =
whether
to   redirect particular user requests to that dCDN; and the synchronous =
operation
of   actually redirecting a user request. This document describes =
protocol for the
part   of user requests redirection.

                                                                         =
        =20


The IETF Secretariat


From hexiaoyan@huawei.com  Thu Feb 16 03:13:16 2012
Return-Path: <hexiaoyan@huawei.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAD721F84D5 for <cdni@ietfa.amsl.com>; Thu, 16 Feb 2012 03:13:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.392
X-Spam-Level: 
X-Spam-Status: No, score=-6.392 tagged_above=-999 required=5 tests=[AWL=0.207,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbiJZAe3LJg6 for <cdni@ietfa.amsl.com>; Thu, 16 Feb 2012 03:13:12 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE2B21F873C for <cdni@ietf.org>; Thu, 16 Feb 2012 03:13:11 -0800 (PST)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZH0016QGHY5U@szxga05-in.huawei.com> for cdni@ietf.org; Thu, 16 Feb 2012 19:13:10 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZH00EF4GHYRX@szxga05-in.huawei.com> for cdni@ietf.org; Thu, 16 Feb 2012 19:13:10 +0800 (CST)
Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGW77204; Thu, 16 Feb 2012 19:13:10 +0800
Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Feb 2012 19:13:00 +0800
Received: from w36710x (10.144.4.163) by smtpscn.huawei.com (10.82.67.154) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Feb 2012 19:13:06 +0800
Date: Thu, 16 Feb 2012 19:13:06 +0800
From: HeXiaoyan <hexiaoyan@huawei.com>
X-Originating-IP: [10.144.4.163]
To: cdni@ietf.org
Message-id: <006001ccec9b$f5bad550$e1307ff0$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset=utf-8
Content-language: zh-cn
Content-transfer-encoding: 7BIT
Thread-index: Aczsm5kgXcCz/nLuTD+9l96H+xp0pgAACEeg
X-CFilter-Loop: Reflected
Subject: [CDNi] FW: New Version Notification for draft-he-cdni-cap-info-advertising-00.txt
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Thu, 16 Feb 2012 11:13:16 -0000

Hi all,
We have submitted a draft on capability advertising of CDNI,
 http://datatracker.ietf.org/doc/draft-he-cdni-cap-info-advertising/

Your comments are welcome.

Best Regards
Xiaoyan(Susan) He

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
Sent: Thursday, February 16, 2012 7:10 PM
To: hexiaoyan@huawei.com
Cc: cheng@gsta.com; hexiaoyan@huawei.com; niwei@chinamobile.com; spencer@wonderhamster.org; zhangyunfei@chinamobile.com
Subject: New Version Notification for draft-he-cdni-cap-info-advertising-00.txt

A new version of I-D, draft-he-cdni-cap-info-advertising-00.txt has been successfully submitted by Xiaoyan He and posted to the IETF repository.

Filename:	 draft-he-cdni-cap-info-advertising
Revision:	 00
Title:		 Capability Information Advertising for CDN Interconnection
Creation date:	 2012-02-16
WG ID:		 Individual Submission
Number of pages: 11

Abstract:
  This document describes protocol for Capability Information Advertising
which is   used to communicate capability information among interconnected Content
Delivery   Networks(CDNs).

                                                                                  


The IETF Secretariat


From swainner@cisco.com  Mon Feb 20 05:33:52 2012
Return-Path: <swainner@cisco.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEAD521F84CF for <cdni@ietfa.amsl.com>; Mon, 20 Feb 2012 05:33:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.332
X-Spam-Level: 
X-Spam-Status: No, score=-7.332 tagged_above=-999 required=5 tests=[AWL=1.974,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFRmp0HVIU1l for <cdni@ietfa.amsl.com>; Mon, 20 Feb 2012 05:33:47 -0800 (PST)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0990421F8493 for <cdni@ietf.org>; Mon, 20 Feb 2012 05:33:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=17016; q=dns/txt; s=iport; t=1329744827; x=1330954427; h=message-id:date:from:mime-version:cc:subject:references: in-reply-to; bh=K5X6Tk6Cu65g04VgJLcBrtIzQ728i3orVbNpF2xg/wY=; b=YAwqGwFecBeL+y66y3xFOB2yixmwP2oCU6whT3hMMi8+T8C5hwR4WkkG mvGj+XByd0bUyuIJkFYz9ByeaOL1u16Fu1OIB7kj1gf31gdzDkUvaK4MQ 0JgxvGUt1ViGsCmtoFmZu67LdWg57lWczTO1SG0S23vLDAwUcVjqShAra k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhUPAO9KQk+rRDoJ/2dsb2JhbABDr2iBB2iBB4FzAQEBBAEBAQ8BGkEJAQEMBAsRBAEBAQkWCAcJAwIBAgEVHwgBCBMBBQIBAR6HZ593AY5fiBGLfQIBCwgGDAICMAUBg1AaCSoDBQcKBoMtBIhOjGmTCw
X-IronPort-AV: E=Sophos;i="4.73,451,1325462400"; d="scan'208,217";a="31403027"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 20 Feb 2012 13:33:46 +0000
Received: from stealth-10-32-245-57.cisco.com (stealth-10-32-245-57.cisco.com [10.32.245.57]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1KDXja8030319; Mon, 20 Feb 2012 13:33:45 GMT
Message-ID: <4F424C27.5090106@cisco.com>
Date: Mon, 20 Feb 2012 08:35:35 -0500
From: Scott Wainner <swainner@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
References: <006001ccec9b$f5bad550$e1307ff0$@com>
In-Reply-To: <006001ccec9b$f5bad550$e1307ff0$@com>
Content-Type: multipart/alternative; boundary="------------000706050407000605000507"
Cc: cdni@ietf.org
Subject: Re: [CDNi] FW: New Version Notification for draft-he-cdni-cap-info-advertising-00.txt
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
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/options/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, 20 Feb 2012 13:33:52 -0000

This is a multi-part message in MIME format.
--------------000706050407000605000507
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Xiaoyan,

Section 3: Capability information description

o Resource status of each downstream

     I don't think we want the be constantly advertising changes in the 
usage percentage and available bandwidth.  The DECISION to allow or not 
allow content acquisition and the threshold upon when that decision is 
made is likely to vary and be subject to the policies of the dCDN (e.g. 
allow 60% load or allow 80% load).  In addition, the decision to acquire 
content (for dynamic acquisition) is made AFTER the decision has been 
made to redirect the client to the dCDN for content delivery.  I'm 
inclined to say the dCDN needs to indicate to the uCDN that it should or 
should not redirect clients to the dCDN and that decision is based on 
internal characteristics of the dCDN (cache-miss rates, circuit loads, 
acquisition capacities, etc.).  This probably needs to be a binary 
notification for each delivery service defined.

o Footprint of each Downstream CDN

     I think the footprint needs to be defined for each type of delivery 
service.

     I think the capacity argument above needs to be at the granularity 
of the "footprint".  Perhaps we need to define footprint.  Is that a 
continent, country, province, state, region, city.  At a macro level, we 
might indicate that the dCDN can support a delivery service in all the 
European countries, but the resources in a particular country are 
exhausted.  We now have a decision to make.  Should the uCDN continue to 
re-direct clients to the dCDN?  If it does, the costs assigned to the 
dCDN will increase as the client will be assigned a distribution node in 
the closest available location for that service.  On the contrary, the 
dCDN might increase the costs associated with distribution in that one 
country such that the uCDN decides not to re-direct the client.

o Delivery protocol supported by each Downstream CDN;

     I think this is appropriate and should be reflected in a type of 
delivery service.  Example: Microsoft Smooth Streaming is supported in 
the following countries ...; Apple HTTP Live Streaming is supported in 
the following cities ...;  Adobe HTTP Dynamic Streaming is supported on 
the following BGP networks ...

     Clearly, we need to define 'footprint'.

o Cost information of each Downstream CDN;

     How do we characterize costs?  Cost relative to what?  Not sure we 
want to include a currency converter in our protocol.  We might want to 
define cost as an abstract value that can be negotiated between the uCDN 
and dCDN.  That means the dCDN internal cost metrics need to be 
characterized in the abstract cost assignment advertised to the uCDN.  
That cost could be in any currency.  In fact, the cost could be in 
latency or distance.  As long as the two parties agree on how to assess 
cost.

o Authentication type to end user supported by each of the Downstream CDN

     I don't see this as optional.  Each dCDN is likely to expect the 
use some authentication method between the client and the delivery 
node.  That credential may be provided by the service routing function 
or some other system.  The dCDN needs to advertise the method and where 
to obtain the credentials for each type of routing request.  I think the 
uCDN will need to receive a routing request from its own client (using 
its own credentials), ascertain which dCDN the client should be 
redirected, determine the method of authentication (and perhaps obtain 
the credential on behalf of the client), and respond to the client.

5.1 Capability information description

     I'm less inclined to include usage percentages in any reports as 
the dCDN may be servicing other uCDN.  If we're talking about a maximum 
allowed threshold contracted between the uCDN and dCDN, then the usage 
percentage might be relative to that contracted streaming capacity.  Of 
course, percentage can be provided by simply providing the maximum 
contracted streaming capacity and the current streaming assignments in 
different categories:

     Streams Allowed, Streams Assigned
     Stream Bandwidth Allowed, Stream Bandwidth Consumed (this will be 
tough with ABR)
     Cached Assets Allowed, Cached Assets

     I also see in the table you have started defining 'Coverage' which 
may also be described as 'Footprint'.  Probably need to define one term 
and keep it consistent.  We then need to define the 'Coverage' or 
'Footprint' elements.

     Also need to define 'Peak Delivery Capability' or 'Guaranteed 
Minimum Capability' for a given 'Coverage'.  Contractually, some content 
owners expect their uCDN to provide high-quality content delivery 
(high-capacity streaming) and want to insure the delivery networks can 
facilitate that type of support.  If the dCDN has a capped delivery 
capability (either by the delivery node or the access infrastructure), 
the uCDN needs to know that in order to 'qualify' the dCDN for content 
delivery.

Scott Wainner



On 2/16/12 6:13 AM, HeXiaoyan wrote:
>
> Hi all,
> We have submitted a draft on capability advertising of CDNI,
> http://datatracker.ietf.org/doc/draft-he-cdni-cap-info-advertising/
>
> Your comments are welcome.
>
> Best Regards
> Xiaoyan(Susan) He
>
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Thursday, February 16, 2012 7:10 PM
> To: hexiaoyan@huawei.com
> Cc: cheng@gsta.com; hexiaoyan@huawei.com; niwei@chinamobile.com; 
> spencer@wonderhamster.org; zhangyunfei@chinamobile.com
> Subject: New Version Notification for 
> draft-he-cdni-cap-info-advertising-00.txt
>
> A new version of I-D, draft-he-cdni-cap-info-advertising-00.txt has 
> been successfully submitted by Xiaoyan He and posted to the IETF 
> repository.
>
> Filename:        draft-he-cdni-cap-info-advertising
> Revision:        00
> Title:           Capability Information Advertising for CDN 
> Interconnection
> Creation date:   2012-02-16
> WG ID:           Individual Submission
> Number of pages: 11
>
> Abstract:
>   This document describes protocol for Capability Information Advertising
> which is   used to communicate capability information among 
> interconnected Content
> Delivery   Networks(CDNs).
>
>
>
>
> The IETF Secretariat
>
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni
>


--------------000706050407000605000507
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Xiaoyan,<br>
    <br>
    Section 3: Capability information description<br>
    <br>
    o Resource status of each downstream<br>
    <br>
    &nbsp;&nbsp;&nbsp; I don't think we want the be constantly advertising changes in
    the usage percentage and available bandwidth.&nbsp; The DECISION to allow
    or not allow content acquisition and the threshold upon when that
    decision is made is likely to vary and be subject to the policies of
    the dCDN (e.g. allow 60% load or allow 80% load).&nbsp; In addition, the
    decision to acquire content (for dynamic acquisition) is made AFTER
    the decision has been made to redirect the client to the dCDN for
    content delivery.&nbsp; I'm inclined to say the dCDN needs to indicate to
    the uCDN that it should or should not redirect clients to the dCDN
    and that decision is based on internal characteristics of the dCDN
    (cache-miss rates, circuit loads, acquisition capacities, etc.).&nbsp;
    This probably needs to be a binary notification for each delivery
    service defined.<br>
    <br>
    o Footprint of each Downstream CDN<br>
    <br>
    &nbsp;&nbsp;&nbsp; I think the footprint needs to be defined for each type of
    delivery service.&nbsp; <br>
    <br>
    &nbsp;&nbsp;&nbsp; I think the capacity argument above needs to be at the
    granularity of the "footprint".&nbsp; Perhaps we need to define
    footprint.&nbsp; Is that a continent, country, province, state, region,
    city.&nbsp; At a macro level, we might indicate that the dCDN can support
    a delivery service in all the European countries, but the resources
    in a particular country are exhausted.&nbsp; We now have a decision to
    make.&nbsp; Should the uCDN continue to re-direct clients to the dCDN?&nbsp;
    If it does, the costs assigned to the dCDN will increase as the
    client will be assigned a distribution node in the closest available
    location for that service.&nbsp; On the contrary, the dCDN might increase
    the costs associated with distribution in that one country such that
    the uCDN decides not to re-direct the client.<br>
    <br>
    o Delivery protocol supported by each Downstream CDN;<br>
    <br>
    &nbsp;&nbsp;&nbsp; I think this is appropriate and should be reflected in a type of
    delivery service.&nbsp; Example: Microsoft Smooth Streaming is supported
    in the following countries ...; Apple HTTP Live Streaming is
    supported in the following cities ...;&nbsp; Adobe HTTP Dynamic Streaming
    is supported on the following BGP networks ...<br>
    <br>
    &nbsp;&nbsp;&nbsp; Clearly, we need to define 'footprint'.<br>
    <br>
    o Cost information of each Downstream CDN;<br>
    <br>
    &nbsp;&nbsp;&nbsp; How do we characterize costs?&nbsp; Cost relative to what?&nbsp; Not sure
    we want to include a currency converter in our protocol.&nbsp; We might
    want to define cost as an abstract value that can be negotiated
    between the uCDN and dCDN.&nbsp; That means the dCDN internal cost
    metrics need to be characterized in the abstract cost assignment
    advertised to the uCDN.&nbsp; That cost could be in any currency.&nbsp; In
    fact, the cost could be in latency or distance.&nbsp; As long as the two
    parties agree on how to assess cost.<br>
    <br>
    o Authentication type to end user supported by each of the
    Downstream CDN<br>
    <br>
    &nbsp;&nbsp;&nbsp; I don't see this as optional.&nbsp; Each dCDN is likely to expect the
    use some authentication method between the client and the delivery
    node.&nbsp; That credential may be provided by the service routing
    function or some other system.&nbsp; The dCDN needs to advertise the
    method and where to obtain the credentials for each type of routing
    request.&nbsp; I think the uCDN will need to receive a routing request
    from its own client (using its own credentials), ascertain which
    dCDN the client should be redirected, determine the method of
    authentication (and perhaps obtain the credential on behalf of the
    client), and respond to the client.<br>
    <br>
    5.1 Capability information description<br>
    <br>
    &nbsp;&nbsp;&nbsp; I'm less inclined to include usage percentages in any reports as
    the dCDN may be servicing other uCDN.&nbsp; If we're talking about a
    maximum allowed threshold contracted between the uCDN and dCDN, then
    the usage percentage might be relative to that contracted streaming
    capacity.&nbsp; Of course, percentage can be provided by simply providing
    the maximum contracted streaming capacity and the current streaming
    assignments in different categories:<br>
    <br>
    &nbsp;&nbsp;&nbsp; Streams Allowed, Streams Assigned<br>
    &nbsp;&nbsp;&nbsp; Stream Bandwidth Allowed, Stream Bandwidth Consumed (this will
    be tough with ABR)<br>
    &nbsp;&nbsp;&nbsp; Cached Assets Allowed, Cached Assets<br>
    <br>
    &nbsp;&nbsp;&nbsp; I also see in the table you have started defining 'Coverage'
    which may also be described as 'Footprint'.&nbsp; Probably need to define
    one term and keep it consistent.&nbsp; We then need to define the
    'Coverage' or 'Footprint' elements.<br>
    <br>
    &nbsp;&nbsp;&nbsp; Also need to define 'Peak Delivery Capability' or 'Guaranteed
    Minimum Capability' for a given 'Coverage'.&nbsp; Contractually, some
    content owners expect their uCDN to provide high-quality content
    delivery (high-capacity streaming) and want to insure the delivery
    networks can facilitate that type of support.&nbsp; If the dCDN has a
    capped delivery capability (either by the delivery node or the
    access infrastructure), the uCDN needs to know that in order to
    'qualify' the dCDN for content delivery.<br>
    <br>
    Scott Wainner<br>
    <br>
    <br>
    <br>
    On 2/16/12 6:13 AM, HeXiaoyan wrote:
    <blockquote cite="mid:006001ccec9b$f5bad550$e1307ff0$@com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="MS Exchange Server version
        6.5.7655.10">
      <title>[CDNi] FW: New Version Notification for
        draft-he-cdni-cap-info-advertising-00.txt</title>
      <!-- Converted from text/plain format -->
      <p><font size="2">Hi all,<br>
          We have submitted a draft on capability advertising of CDNI,<br>
          &nbsp;<a moz-do-not-send="true"
href="http://datatracker.ietf.org/doc/draft-he-cdni-cap-info-advertising/">http://datatracker.ietf.org/doc/draft-he-cdni-cap-info-advertising/</a><br>
          <br>
          Your comments are welcome.<br>
          <br>
          Best Regards<br>
          Xiaoyan(Susan) He<br>
          <br>
          -----Original Message-----<br>
          From: <a class="moz-txt-link-abbreviated" href="mailto:internet-drafts@ietf.org">internet-drafts@ietf.org</a> [<a moz-do-not-send="true"
            href="mailto:internet-drafts@ietf.org">mailto:internet-drafts@ietf.org</a>]<br>
          Sent: Thursday, February 16, 2012 7:10 PM<br>
          To: <a class="moz-txt-link-abbreviated" href="mailto:hexiaoyan@huawei.com">hexiaoyan@huawei.com</a><br>
          Cc: <a class="moz-txt-link-abbreviated" href="mailto:cheng@gsta.com">cheng@gsta.com</a>; <a class="moz-txt-link-abbreviated" href="mailto:hexiaoyan@huawei.com">hexiaoyan@huawei.com</a>;
          <a class="moz-txt-link-abbreviated" href="mailto:niwei@chinamobile.com">niwei@chinamobile.com</a>; <a class="moz-txt-link-abbreviated" href="mailto:spencer@wonderhamster.org">spencer@wonderhamster.org</a>;
          <a class="moz-txt-link-abbreviated" href="mailto:zhangyunfei@chinamobile.com">zhangyunfei@chinamobile.com</a><br>
          Subject: New Version Notification for
          draft-he-cdni-cap-info-advertising-00.txt<br>
          <br>
          A new version of I-D,
          draft-he-cdni-cap-info-advertising-00.txt has been
          successfully submitted by Xiaoyan He and posted to the IETF
          repository.<br>
          <br>
          Filename:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; draft-he-cdni-cap-info-advertising<br>
          Revision:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 00<br>
          Title:&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Capability Information Advertising for CDN
          Interconnection<br>
          Creation date:&nbsp;&nbsp; 2012-02-16<br>
          WG ID:&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Individual Submission<br>
          Number of pages: 11<br>
          <br>
          Abstract:<br>
          &nbsp; This document describes protocol for Capability Information
          Advertising<br>
          which is&nbsp;&nbsp; used to communicate capability information among
          interconnected Content<br>
          Delivery&nbsp;&nbsp; Networks(CDNs).<br>
          <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
          <br>
          <br>
          The IETF Secretariat<br>
          <br>
          _______________________________________________<br>
          CDNi mailing list<br>
          <a class="moz-txt-link-abbreviated" href="mailto:CDNi@ietf.org">CDNi@ietf.org</a><br>
          <a moz-do-not-send="true"
            href="https://www.ietf.org/mailman/listinfo/cdni">https://www.ietf.org/mailman/listinfo/cdni</a><br>
        </font>
      </p>
    </blockquote>
    <br>
  </body>
</html>

--------------000706050407000605000507--

From ben@niven-jenkins.co.uk  Mon Feb 20 13:10:43 2012
Return-Path: <ben@niven-jenkins.co.uk>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5690F21F858F for <cdni@ietfa.amsl.com>; Mon, 20 Feb 2012 13:10:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.366
X-Spam-Level: 
X-Spam-Status: No, score=-103.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ShWUq7ZVije for <cdni@ietfa.amsl.com>; Mon, 20 Feb 2012 13:10:42 -0800 (PST)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id B561621F8618 for <cdni@ietf.org>; Mon, 20 Feb 2012 13:10:41 -0800 (PST)
Received: from cpc10-cmbg15-2-0-cust121.5-4.cable.virginmedia.com ([86.30.246.122] helo=[192.168.0.3]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <ben@niven-jenkins.co.uk>) id 1RzaVM-0002aE-99; Mon, 20 Feb 2012 21:10:40 +0000
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
In-Reply-To: <4F424C27.5090106@cisco.com>
Date: Mon, 20 Feb 2012 21:10:38 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <06E31573-57BE-4855-B93A-F331D3B0574D@niven-jenkins.co.uk>
References: <006001ccec9b$f5bad550$e1307ff0$@com> <4F424C27.5090106@cisco.com>
To: Scott Wainner <swainner@cisco.com>
X-Mailer: Apple Mail (2.1084)
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
Cc: cdni@ietf.org
Subject: Re: [CDNi] FW: New Version Notification for draft-he-cdni-cap-info-advertising-00.txt
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
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/options/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, 20 Feb 2012 21:10:43 -0000

Colleagues,

I'd suggest that more work needs to be done on the classes of capability =
that need to be exchanged as well as specific capabilities that may be =
useful before worrying too much what the actual protocol may look like.

For example two immediate classes that come to mind are slow changing Vs =
fast changing capabilities. E.g. I would expect that the version of IP =
and individual delivery protocols supported would change slowly.

You might also want to think about how to convey non-binary (i.e. =
on/off) capabilities in a more abstract way as I'm not sure folks will =
want to expose for e.g. "I can support X more connections" etc.

Ben

On 20 Feb 2012, at 13:35, Scott Wainner wrote:

> Xiaoyan,
>=20
> Section 3: Capability information description
>=20
> o Resource status of each downstream
>=20
>     I don't think we want the be constantly advertising changes in the =
usage percentage and available bandwidth.  The DECISION to allow or not =
allow content acquisition and the threshold upon when that decision is =
made is likely to vary and be subject to the policies of the dCDN (e.g. =
allow 60% load or allow 80% load).  In addition, the decision to acquire =
content (for dynamic acquisition) is made AFTER the decision has been =
made to redirect the client to the dCDN for content delivery.  I'm =
inclined to say the dCDN needs to indicate to the uCDN that it should or =
should not redirect clients to the dCDN and that decision is based on =
internal characteristics of the dCDN (cache-miss rates, circuit loads, =
acquisition capacities, etc.).  This probably needs to be a binary =
notification for each delivery service defined.
>=20
> o Footprint of each Downstream CDN
>=20
>     I think the footprint needs to be defined for each type of =
delivery service. =20
>=20
>     I think the capacity argument above needs to be at the granularity =
of the "footprint".  Perhaps we need to define footprint.  Is that a =
continent, country, province, state, region, city.  At a macro level, we =
might indicate that the dCDN can support a delivery service in all the =
European countries, but the resources in a particular country are =
exhausted.  We now have a decision to make.  Should the uCDN continue to =
re-direct clients to the dCDN?  If it does, the costs assigned to the =
dCDN will increase as the client will be assigned a distribution node in =
the closest available location for that service.  On the contrary, the =
dCDN might increase the costs associated with distribution in that one =
country such that the uCDN decides not to re-direct the client.
>=20
> o Delivery protocol supported by each Downstream CDN;
>=20
>     I think this is appropriate and should be reflected in a type of =
delivery service.  Example: Microsoft Smooth Streaming is supported in =
the following countries ...; Apple HTTP Live Streaming is supported in =
the following cities ...;  Adobe HTTP Dynamic Streaming is supported on =
the following BGP networks ...
>=20
>     Clearly, we need to define 'footprint'.
>=20
> o Cost information of each Downstream CDN;
>=20
>     How do we characterize costs?  Cost relative to what?  Not sure we =
want to include a currency converter in our protocol.  We might want to =
define cost as an abstract value that can be negotiated between the uCDN =
and dCDN.  That means the dCDN internal cost metrics need to be =
characterized in the abstract cost assignment advertised to the uCDN.  =
That cost could be in any currency.  In fact, the cost could be in =
latency or distance.  As long as the two parties agree on how to assess =
cost.
>=20
> o Authentication type to end user supported by each of the Downstream =
CDN
>=20
>     I don't see this as optional.  Each dCDN is likely to expect the =
use some authentication method between the client and the delivery node. =
 That credential may be provided by the service routing function or some =
other system.  The dCDN needs to advertise the method and where to =
obtain the credentials for each type of routing request.  I think the =
uCDN will need to receive a routing request from its own client (using =
its own credentials), ascertain which dCDN the client should be =
redirected, determine the method of authentication (and perhaps obtain =
the credential on behalf of the client), and respond to the client.
>=20
> 5.1 Capability information description
>=20
>     I'm less inclined to include usage percentages in any reports as =
the dCDN may be servicing other uCDN.  If we're talking about a maximum =
allowed threshold contracted between the uCDN and dCDN, then the usage =
percentage might be relative to that contracted streaming capacity.  Of =
course, percentage can be provided by simply providing the maximum =
contracted streaming capacity and the current streaming assignments in =
different categories:
>=20
>     Streams Allowed, Streams Assigned
>     Stream Bandwidth Allowed, Stream Bandwidth Consumed (this will be =
tough with ABR)
>     Cached Assets Allowed, Cached Assets
>=20
>     I also see in the table you have started defining 'Coverage' which =
may also be described as 'Footprint'.  Probably need to define one term =
and keep it consistent.  We then need to define the 'Coverage' or =
'Footprint' elements.
>=20
>     Also need to define 'Peak Delivery Capability' or 'Guaranteed =
Minimum Capability' for a given 'Coverage'.  Contractually, some content =
owners expect their uCDN to provide high-quality content delivery =
(high-capacity streaming) and want to insure the delivery networks can =
facilitate that type of support.  If the dCDN has a capped delivery =
capability (either by the delivery node or the access infrastructure), =
the uCDN needs to know that in order to 'qualify' the dCDN for content =
delivery.
>=20
> Scott Wainner
>=20
>=20
>=20
> On 2/16/12 6:13 AM, HeXiaoyan wrote:
>> Hi all,
>> We have submitted a draft on capability advertising of CDNI,
>>  http://datatracker.ietf.org/doc/draft-he-cdni-cap-info-advertising/
>>=20
>> Your comments are welcome.
>>=20
>> Best Regards
>> Xiaoyan(Susan) He
>>=20
>> -----Original Message-----
>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>> Sent: Thursday, February 16, 2012 7:10 PM
>> To: hexiaoyan@huawei.com
>> Cc: cheng@gsta.com; hexiaoyan@huawei.com; niwei@chinamobile.com; =
spencer@wonderhamster.org; zhangyunfei@chinamobile.com
>> Subject: New Version Notification for =
draft-he-cdni-cap-info-advertising-00.txt
>>=20
>> A new version of I-D, draft-he-cdni-cap-info-advertising-00.txt has =
been           successfully submitted by Xiaoyan He and posted to the =
IETF repository.
>>=20
>> Filename:        draft-he-cdni-cap-info-advertising
>> Revision:        00
>> Title:           Capability Information Advertising for CDN =
Interconnection
>> Creation date:   2012-02-16
>> WG ID:           Individual Submission
>> Number of pages: 11
>>=20
>> Abstract:
>>   This document describes protocol for Capability Information =
Advertising
>> which is   used to communicate capability information among =
interconnected Content
>> Delivery   Networks(CDNs).
>>=20
>>                                                                       =
          =20
>>=20
>>=20
>> The IETF Secretariat
>>=20
>> _______________________________________________
>> CDNi mailing list
>> CDNi@ietf.org
>> https://www.ietf.org/mailman/listinfo/cdni
>>=20
>=20
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni


From swainner@cisco.com  Mon Feb 20 13:23:45 2012
Return-Path: <swainner@cisco.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0911721F860F for <cdni@ietfa.amsl.com>; Mon, 20 Feb 2012 13:23:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.965
X-Spam-Level: 
X-Spam-Status: No, score=-8.965 tagged_above=-999 required=5 tests=[AWL=1.633,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipR2lxjtStwu for <cdni@ietfa.amsl.com>; Mon, 20 Feb 2012 13:23:43 -0800 (PST)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7449321F853D for <cdni@ietf.org>; Mon, 20 Feb 2012 13:23:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=22531; q=dns/txt; s=iport; t=1329773023; x=1330982623; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=oWt1OwbbufMb0p2Haei7qrJ05T6x1fMPBu12iiHFbmc=; b=RlNNg/7uCM92Gc23FSV48mhsYh3ws+XOkly93aAvkwGCpdteGbr6wy9d 4QOtTUsD5B5nMOx7dyQmnSSEcb3KV9hVcHzTNT/S47QVJAha4Z72Oy1gh yYQQPoQ6RDe/hGmYdZKmmSOQ5TFkikrAQipYFb2mod1ehbBh5t1Y74HtX 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFAEq5Qk+rRDoG/2dsb2JhbABEr3WCDIEHgXMBAQEDAQEBAQ8BWwkBAQUHBAsRBAEBAQkWCAcJAwIBAgEVHwgBCAYNAQUCAQEeh14JoBQBjl+IO4t9AgEIAwQEBgwCAjAFAYNQGgkqAwUHCgaDLQSIToxpkws
X-IronPort-AV: E=Sophos;i="4.73,453,1325462400"; d="scan'208,217";a="31275623"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 20 Feb 2012 21:23:43 +0000
Received: from stealth-10-32-245-57.cisco.com (stealth-10-32-245-57.cisco.com [10.32.245.57]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1KLNfrw020545; Mon, 20 Feb 2012 21:23:42 GMT
Message-ID: <4F42BA4A.1090106@cisco.com>
Date: Mon, 20 Feb 2012 16:25:30 -0500
From: Scott Wainner <swainner@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
References: <006001ccec9b$f5bad550$e1307ff0$@com> <4F424C27.5090106@cisco.com> <06E31573-57BE-4855-B93A-F331D3B0574D@niven-jenkins.co.uk>
In-Reply-To: <06E31573-57BE-4855-B93A-F331D3B0574D@niven-jenkins.co.uk>
Content-Type: multipart/alternative; boundary="------------000601020704020902000906"
Cc: cdni@ietf.org
Subject: Re: [CDNi] FW: New Version Notification for draft-he-cdni-cap-info-advertising-00.txt
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
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/options/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, 20 Feb 2012 21:23:45 -0000

This is a multi-part message in MIME format.
--------------000601020704020902000906
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 2/20/12 4:10 PM, Ben Niven-Jenkins wrote:
>
> Colleagues,
>
> I'd suggest that more work needs to be done on the classes of 
> capability that need to be exchanged as well as specific capabilities 
> that may be useful before worrying too much what the actual protocol 
> may look like.
>
Agree.
>
>
> For example two immediate classes that come to mind are slow changing 
> Vs fast changing capabilities. E.g. I would expect that the version of 
> IP and individual delivery protocols supported would change slowly.
>
Agree.  There capabilities (allowed protocols, footprint, etc.) that may 
not change for days while the current ability to actually use those 
capabilities could change more frequently.
>
>
> You might also want to think about how to convey non-binary (i.e. 
> on/off) capabilities in a more abstract way as I'm not sure folks will 
> want to expose for e.g. "I can support X more connections" etc.
>
Exactly my point.  We need the uCDN to be given a simple set of go/no-go 
criteria from the dCDN.

Scott Wainner
>
>
> Ben
>
> On 20 Feb 2012, at 13:35, Scott Wainner wrote:
>
> > Xiaoyan,
> >
> > Section 3: Capability information description
> >
> > o Resource status of each downstream
> >
> >     I don't think we want the be constantly advertising changes in 
> the usage percentage and available bandwidth.  The DECISION to allow 
> or not allow content acquisition and the threshold upon when that 
> decision is made is likely to vary and be subject to the policies of 
> the dCDN (e.g. allow 60% load or allow 80% load).  In addition, the 
> decision to acquire content (for dynamic acquisition) is made AFTER 
> the decision has been made to redirect the client to the dCDN for 
> content delivery.  I'm inclined to say the dCDN needs to indicate to 
> the uCDN that it should or should not redirect clients to the dCDN and 
> that decision is based on internal characteristics of the dCDN 
> (cache-miss rates, circuit loads, acquisition capacities, etc.).  This 
> probably needs to be a binary notification for each delivery service 
> defined.
> >
> > o Footprint of each Downstream CDN
> >
> >     I think the footprint needs to be defined for each type of 
> delivery service.
> >
> >     I think the capacity argument above needs to be at the 
> granularity of the "footprint".  Perhaps we need to define footprint.  
> Is that a continent, country, province, state, region, city.  At a 
> macro level, we might indicate that the dCDN can support a delivery 
> service in all the European countries, but the resources in a 
> particular country are exhausted.  We now have a decision to make.  
> Should the uCDN continue to re-direct clients to the dCDN?  If it 
> does, the costs assigned to the dCDN will increase as the client will 
> be assigned a distribution node in the closest available location for 
> that service.  On the contrary, the dCDN might increase the costs 
> associated with distribution in that one country such that the uCDN 
> decides not to re-direct the client.
> >
> > o Delivery protocol supported by each Downstream CDN;
> >
> >     I think this is appropriate and should be reflected in a type of 
> delivery service.  Example: Microsoft Smooth Streaming is supported in 
> the following countries ...; Apple HTTP Live Streaming is supported in 
> the following cities ...;  Adobe HTTP Dynamic Streaming is supported 
> on the following BGP networks ...
> >
> >     Clearly, we need to define 'footprint'.
> >
> > o Cost information of each Downstream CDN;
> >
> >     How do we characterize costs?  Cost relative to what?  Not sure 
> we want to include a currency converter in our protocol.  We might 
> want to define cost as an abstract value that can be negotiated 
> between the uCDN and dCDN.  That means the dCDN internal cost metrics 
> need to be characterized in the abstract cost assignment advertised to 
> the uCDN.  That cost could be in any currency.  In fact, the cost 
> could be in latency or distance.  As long as the two parties agree on 
> how to assess cost.
> >
> > o Authentication type to end user supported by each of the 
> Downstream CDN
> >
> >     I don't see this as optional.  Each dCDN is likely to expect the 
> use some authentication method between the client and the delivery 
> node.  That credential may be provided by the service routing function 
> or some other system.  The dCDN needs to advertise the method and 
> where to obtain the credentials for each type of routing request.  I 
> think the uCDN will need to receive a routing request from its own 
> client (using its own credentials), ascertain which dCDN the client 
> should be redirected, determine the method of authentication (and 
> perhaps obtain the credential on behalf of the client), and respond to 
> the client.
> >
> > 5.1 Capability information description
> >
> >     I'm less inclined to include usage percentages in any reports as 
> the dCDN may be servicing other uCDN.  If we're talking about a 
> maximum allowed threshold contracted between the uCDN and dCDN, then 
> the usage percentage might be relative to that contracted streaming 
> capacity.  Of course, percentage can be provided by simply providing 
> the maximum contracted streaming capacity and the current streaming 
> assignments in different categories:
> >
> >     Streams Allowed, Streams Assigned
> >     Stream Bandwidth Allowed, Stream Bandwidth Consumed (this will 
> be tough with ABR)
> >     Cached Assets Allowed, Cached Assets
> >
> >     I also see in the table you have started defining 'Coverage' 
> which may also be described as 'Footprint'.  Probably need to define 
> one term and keep it consistent.  We then need to define the 
> 'Coverage' or 'Footprint' elements.
> >
> >     Also need to define 'Peak Delivery Capability' or 'Guaranteed 
> Minimum Capability' for a given 'Coverage'.  Contractually, some 
> content owners expect their uCDN to provide high-quality content 
> delivery (high-capacity streaming) and want to insure the delivery 
> networks can facilitate that type of support.  If the dCDN has a 
> capped delivery capability (either by the delivery node or the access 
> infrastructure), the uCDN needs to know that in order to 'qualify' the 
> dCDN for content delivery.
> >
> > Scott Wainner
> >
> >
> >
> > On 2/16/12 6:13 AM, HeXiaoyan wrote:
> >> Hi all,
> >> We have submitted a draft on capability advertising of CDNI,
> >> http://datatracker.ietf.org/doc/draft-he-cdni-cap-info-advertising/
> >>
> >> Your comments are welcome.
> >>
> >> Best Regards
> >> Xiaoyan(Susan) He
> >>
> >> -----Original Message-----
> >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> >> Sent: Thursday, February 16, 2012 7:10 PM
> >> To: hexiaoyan@huawei.com
> >> Cc: cheng@gsta.com; hexiaoyan@huawei.com; niwei@chinamobile.com; 
> spencer@wonderhamster.org; zhangyunfei@chinamobile.com
> >> Subject: New Version Notification for 
> draft-he-cdni-cap-info-advertising-00.txt
> >>
> >> A new version of I-D, draft-he-cdni-cap-info-advertising-00.txt has 
> been           successfully submitted by Xiaoyan He and posted to the 
> IETF repository.
> >>
> >> Filename:        draft-he-cdni-cap-info-advertising
> >> Revision:        00
> >> Title:           Capability Information Advertising for CDN 
> Interconnection
> >> Creation date:   2012-02-16
> >> WG ID:           Individual Submission
> >> Number of pages: 11
> >>
> >> Abstract:
> >>   This document describes protocol for Capability Information 
> Advertising
> >> which is   used to communicate capability information among 
> interconnected Content
> >> Delivery   Networks(CDNs).
> >>
> >>
> >>
> >>
> >> The IETF Secretariat
> >>
> >> _______________________________________________
> >> CDNi mailing list
> >> CDNi@ietf.org
> >> https://www.ietf.org/mailman/listinfo/cdni
> >>
> >
> > _______________________________________________
> > CDNi mailing list
> > CDNi@ietf.org
> > https://www.ietf.org/mailman/listinfo/cdni
>


--------------000601020704020902000906
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 2/20/12 4:10 PM, Ben Niven-Jenkins wrote:
    <blockquote
      cite="mid:06E31573-57BE-4855-B93A-F331D3B0574D@niven-jenkins.co.uk"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="MS Exchange Server version
        6.5.7655.10">
      <title>Re: [CDNi] FW: New Version Notification for
        draft-he-cdni-cap-info-advertising-00.txt</title>
      <!--


 Converted from text/plain format -->
      <p><font size="2">Colleagues,<br>
          <br>
          I'd suggest that more work needs to be done on the classes of
          capability that need to be exchanged as well as specific
          capabilities that may be useful before worrying too much what
          the actual protocol may look like.<br>
        </font></p>
    </blockquote>
    Agree.<br>
    <blockquote
      cite="mid:06E31573-57BE-4855-B93A-F331D3B0574D@niven-jenkins.co.uk"
      type="cite">
      <p><font size="2">
          <br>
          For example two immediate classes that come to mind are slow
          changing Vs fast changing capabilities. E.g. I would expect
          that the version of IP and individual delivery protocols
          supported would change slowly.<br>
        </font></p>
    </blockquote>
    Agree.&nbsp; There capabilities (allowed protocols, footprint, etc.) that
    may not change for days while the current ability to actually use
    those capabilities could change more frequently.<br>
    <blockquote
      cite="mid:06E31573-57BE-4855-B93A-F331D3B0574D@niven-jenkins.co.uk"
      type="cite">
      <p><font size="2">
          <br>
          You might also want to think about how to convey non-binary
          (i.e. on/off) capabilities in a more abstract way as I'm not
          sure folks will want to expose for e.g. "I can support X more
          connections" etc.<br>
        </font></p>
    </blockquote>
    Exactly my point.&nbsp; We need the uCDN to be given a simple set of
    go/no-go criteria from the dCDN.<br>
    <br>
    Scott Wainner<br>
    <blockquote
      cite="mid:06E31573-57BE-4855-B93A-F331D3B0574D@niven-jenkins.co.uk"
      type="cite">
      <p><font size="2">
          <br>
          Ben<br>
          <br>
          On 20 Feb 2012, at 13:35, Scott Wainner wrote:<br>
          <br>
          &gt; Xiaoyan,<br>
          &gt;<br>
          &gt; Section 3: Capability information description<br>
          &gt;<br>
          &gt; o Resource status of each downstream<br>
          &gt;<br>
          &gt;&nbsp;&nbsp;&nbsp;&nbsp; I don't think we want the be constantly advertising
          changes in the usage percentage and available bandwidth.&nbsp; The
          DECISION to allow or not allow content acquisition and the
          threshold upon when that decision is made is likely to vary
          and be subject to the policies of the dCDN (e.g. allow 60%
          load or allow 80% load).&nbsp; In addition, the decision to acquire
          content (for dynamic acquisition) is made AFTER the decision
          has been made to redirect the client to the dCDN for content
          delivery.&nbsp; I'm inclined to say the dCDN needs to indicate to
          the uCDN that it should or should not redirect clients to the
          dCDN and that decision is based on internal characteristics of
          the dCDN (cache-miss rates, circuit loads, acquisition
          capacities, etc.).&nbsp; This probably needs to be a binary
          notification for each delivery service defined.<br>
          &gt;<br>
          &gt; o Footprint of each Downstream CDN<br>
          &gt;<br>
          &gt;&nbsp;&nbsp;&nbsp;&nbsp; I think the footprint needs to be defined for each
          type of delivery service.&nbsp;<br>
          &gt;<br>
          &gt;&nbsp;&nbsp;&nbsp;&nbsp; I think the capacity argument above needs to be at
          the granularity of the "footprint".&nbsp; Perhaps we need to define
          footprint.&nbsp; Is that a continent, country, province, state,
          region, city.&nbsp; At a macro level, we might indicate that the
          dCDN can support a delivery service in all the European
          countries, but the resources in a particular country are
          exhausted.&nbsp; We now have a decision to make.&nbsp; Should the uCDN
          continue to re-direct clients to the dCDN?&nbsp; If it does, the
          costs assigned to the dCDN will increase as the client will be
          assigned a distribution node in the closest available location
          for that service.&nbsp; On the contrary, the dCDN might increase
          the costs associated with distribution in that one country
          such that the uCDN decides not to re-direct the client.<br>
          &gt;<br>
          &gt; o Delivery protocol supported by each Downstream CDN;<br>
          &gt;<br>
          &gt;&nbsp;&nbsp;&nbsp;&nbsp; I think this is appropriate and should be reflected
          in a type of delivery service.&nbsp; Example: Microsoft Smooth
          Streaming is supported in the following countries ...; Apple
          HTTP Live Streaming is supported in the following cities ...;&nbsp;
          Adobe HTTP Dynamic Streaming is supported on the following BGP
          networks ...<br>
          &gt;<br>
          &gt;&nbsp;&nbsp;&nbsp;&nbsp; Clearly, we need to define 'footprint'.<br>
          &gt;<br>
          &gt; o Cost information of each Downstream CDN;<br>
          &gt;<br>
          &gt;&nbsp;&nbsp;&nbsp;&nbsp; How do we characterize costs?&nbsp; Cost relative to
          what?&nbsp; Not sure we want to include a currency converter in our
          protocol.&nbsp; We might want to define cost as an abstract value
          that can be negotiated between the uCDN and dCDN.&nbsp; That means
          the dCDN internal cost metrics need to be characterized in the
          abstract cost assignment advertised to the uCDN.&nbsp; That cost
          could be in any currency.&nbsp; In fact, the cost could be in
          latency or distance.&nbsp; As long as the two parties agree on how
          to assess cost.<br>
          &gt;<br>
          &gt; o Authentication type to end user supported by each of
          the Downstream CDN<br>
          &gt;<br>
          &gt;&nbsp;&nbsp;&nbsp;&nbsp; I don't see this as optional.&nbsp; Each dCDN is likely to
          expect the use some authentication method between the client
          and the delivery node.&nbsp; That credential may be provided by the
          service routing function or some other system.&nbsp; The dCDN needs
          to advertise the method and where to obtain the credentials
          for each type of routing request.&nbsp; I think the uCDN will need
          to receive a routing request from its own client (using its
          own credentials), ascertain which dCDN the client should be
          redirected, determine the method of authentication (and
          perhaps obtain the credential on behalf of the client), and
          respond to the client.<br>
          &gt;<br>
          &gt; 5.1 Capability information description<br>
          &gt;<br>
          &gt;&nbsp;&nbsp;&nbsp;&nbsp; I'm less inclined to include usage percentages in any
          reports as the dCDN may be servicing other uCDN.&nbsp; If we're
          talking about a maximum allowed threshold contracted between
          the uCDN and dCDN, then the usage percentage might be relative
          to that contracted streaming capacity.&nbsp; Of course, percentage
          can be provided by simply providing the maximum contracted
          streaming capacity and the current streaming assignments in
          different categories:<br>
          &gt;<br>
          &gt;&nbsp;&nbsp;&nbsp;&nbsp; Streams Allowed, Streams Assigned<br>
          &gt;&nbsp;&nbsp;&nbsp;&nbsp; Stream Bandwidth Allowed, Stream Bandwidth Consumed
          (this will be tough with ABR)<br>
          &gt;&nbsp;&nbsp;&nbsp;&nbsp; Cached Assets Allowed, Cached Assets<br>
          &gt;<br>
          &gt;&nbsp;&nbsp;&nbsp;&nbsp; I also see in the table you have started defining
          'Coverage' which may also be described as 'Footprint'.&nbsp;
          Probably need to define one term and keep it consistent.&nbsp; We
          then need to define the 'Coverage' or 'Footprint' elements.<br>
          &gt;<br>
          &gt;&nbsp;&nbsp;&nbsp;&nbsp; Also need to define 'Peak Delivery Capability' or
          'Guaranteed Minimum Capability' for a given 'Coverage'.&nbsp;
          Contractually, some content owners expect their uCDN to
          provide high-quality content delivery (high-capacity
          streaming) and want to insure the delivery networks can
          facilitate that type of support.&nbsp; If the dCDN has a capped
          delivery capability (either by the delivery node or the access
          infrastructure), the uCDN needs to know that in order to
          'qualify' the dCDN for content delivery.<br>
          &gt;<br>
          &gt; Scott Wainner<br>
          &gt;<br>
          &gt;<br>
          &gt;<br>
          &gt; On 2/16/12 6:13 AM, HeXiaoyan wrote:<br>
          &gt;&gt; Hi all,<br>
          &gt;&gt; We have submitted a draft on capability advertising
          of CDNI,<br>
          &gt;&gt;&nbsp; <a moz-do-not-send="true"
href="http://datatracker.ietf.org/doc/draft-he-cdni-cap-info-advertising/">http://datatracker.ietf.org/doc/draft-he-cdni-cap-info-advertising/</a><br>
          &gt;&gt;<br>
          &gt;&gt; Your comments are welcome.<br>
          &gt;&gt;<br>
          &gt;&gt; Best Regards<br>
          &gt;&gt; Xiaoyan(Susan) He<br>
          &gt;&gt;<br>
          &gt;&gt; -----Original Message-----<br>
          &gt;&gt; From: <a class="moz-txt-link-abbreviated" href="mailto:internet-drafts@ietf.org">internet-drafts@ietf.org</a> [<a
            moz-do-not-send="true"
            href="mailto:internet-drafts@ietf.org">mailto:internet-drafts@ietf.org</a>]<br>
          &gt;&gt; Sent: Thursday, February 16, 2012 7:10 PM<br>
          &gt;&gt; To: <a class="moz-txt-link-abbreviated" href="mailto:hexiaoyan@huawei.com">hexiaoyan@huawei.com</a><br>
          &gt;&gt; Cc: <a class="moz-txt-link-abbreviated" href="mailto:cheng@gsta.com">cheng@gsta.com</a>; <a class="moz-txt-link-abbreviated" href="mailto:hexiaoyan@huawei.com">hexiaoyan@huawei.com</a>;
          <a class="moz-txt-link-abbreviated" href="mailto:niwei@chinamobile.com">niwei@chinamobile.com</a>; <a class="moz-txt-link-abbreviated" href="mailto:spencer@wonderhamster.org">spencer@wonderhamster.org</a>;
          <a class="moz-txt-link-abbreviated" href="mailto:zhangyunfei@chinamobile.com">zhangyunfei@chinamobile.com</a><br>
          &gt;&gt; Subject: New Version Notification for
          draft-he-cdni-cap-info-advertising-00.txt<br>
          &gt;&gt;<br>
          &gt;&gt; A new version of I-D,
          draft-he-cdni-cap-info-advertising-00.txt has been&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
          successfully submitted by Xiaoyan He and posted to the IETF
          repository.<br>
          &gt;&gt;<br>
          &gt;&gt; Filename:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; draft-he-cdni-cap-info-advertising<br>
          &gt;&gt; Revision:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 00<br>
          &gt;&gt; Title:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Capability Information Advertising
          for CDN Interconnection<br>
          &gt;&gt; Creation date:&nbsp;&nbsp; 2012-02-16<br>
          &gt;&gt; WG ID:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Individual Submission<br>
          &gt;&gt; Number of pages: 11<br>
          &gt;&gt;<br>
          &gt;&gt; Abstract:<br>
          &gt;&gt;&nbsp;&nbsp; This document describes protocol for Capability
          Information Advertising<br>
          &gt;&gt; which is&nbsp;&nbsp; used to communicate capability information
          among interconnected Content<br>
          &gt;&gt; Delivery&nbsp;&nbsp; Networks(CDNs).<br>
          &gt;&gt;<br>
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
          &gt;&gt;<br>
          &gt;&gt;<br>
          &gt;&gt; The IETF Secretariat<br>
          &gt;&gt;<br>
          &gt;&gt; _______________________________________________<br>
          &gt;&gt; CDNi mailing list<br>
          &gt;&gt; <a class="moz-txt-link-abbreviated" href="mailto:CDNi@ietf.org">CDNi@ietf.org</a><br>
          &gt;&gt; <a moz-do-not-send="true"
            href="https://www.ietf.org/mailman/listinfo/cdni">https://www.ietf.org/mailman/listinfo/cdni</a><br>
          &gt;&gt;<br>
          &gt;<br>
          &gt; _______________________________________________<br>
          &gt; CDNi mailing list<br>
          &gt; <a class="moz-txt-link-abbreviated" href="mailto:CDNi@ietf.org">CDNi@ietf.org</a><br>
          &gt; <a moz-do-not-send="true"
            href="https://www.ietf.org/mailman/listinfo/cdni">https://www.ietf.org/mailman/listinfo/cdni</a><br>
          <br>
        </font>
      </p>
    </blockquote>
    <br>
  </body>
</html>

--------------000601020704020902000906--

From hexiaoyan@huawei.com  Tue Feb 21 04:39:45 2012
Return-Path: <hexiaoyan@huawei.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFC721F866D for <cdni@ietfa.amsl.com>; Tue, 21 Feb 2012 04:39:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.144
X-Spam-Level: 
X-Spam-Status: No, score=-6.144 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+pDM73e4fac for <cdni@ietfa.amsl.com>; Tue, 21 Feb 2012 04:39:40 -0800 (PST)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 84C4521F8668 for <cdni@ietf.org>; Tue, 21 Feb 2012 04:39:40 -0800 (PST)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZQ00MJATRPX0@szxga04-in.huawei.com> for cdni@ietf.org; Tue, 21 Feb 2012 20:38:13 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZQ00JZITRPS5@szxga04-in.huawei.com> for cdni@ietf.org; Tue, 21 Feb 2012 20:38:13 +0800 (CST)
Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AHG99929; Tue, 21 Feb 2012 20:38:12 +0800
Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 21 Feb 2012 20:37:51 +0800
Received: from w36710x (10.144.4.163) by smtpscn.huawei.com (10.82.67.153) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 21 Feb 2012 20:38:11 +0800
Date: Tue, 21 Feb 2012 20:38:06 +0800
From: HeXiaoyan <hexiaoyan@huawei.com>
In-reply-to: <06E31573-57BE-4855-B93A-F331D3B0574D@niven-jenkins.co.uk>
X-Originating-IP: [10.144.4.163]
To: 'Ben Niven-Jenkins' <ben@niven-jenkins.co.uk>, 'Scott Wainner' <swainner@cisco.com>
Message-id: <005c01ccf095$a9608490$fc218db0$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset=us-ascii
Content-language: zh-cn
Content-transfer-encoding: 7BIT
Thread-index: AczwFCGQQOnHolC+TgapJELyWIVpyAAYOC0Q
X-CFilter-Loop: Reflected
References: <006001ccec9b$f5bad550$e1307ff0$@com> <4F424C27.5090106@cisco.com> <06E31573-57BE-4855-B93A-F331D3B0574D@niven-jenkins.co.uk>
Cc: cdni@ietf.org
Subject: Re: [CDNi] FW: New Version Notification for	draft-he-cdni-cap-info-advertising-00.txt
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Tue, 21 Feb 2012 12:39:45 -0000

Scott and Ben,
This draft is a very primary version and the intention of it was to
stimulate the group to discuss capability advertising and thanks for your
comments. I agree with you that there is still a lot need to do to amend it.
As it seems that we still have divergence on what kind of capability info
need to be exchanged, I reconsider the way work on it, here is something
come into mind.
1. First we find and get agreement on the criteria that determine the
capability that needed to be exchanged. We can use these criteria to filter
the capability information and walk a step forward to define the semantics
of each. As the capability info is used to facility request routing, and
uCDNs may have vary internal routing policy, below is some criteria based on
the often mentioned use cases.
 * Make routing decision(selecting a dCDN) based on proximity, hence
footprint category info is needed.
 * Make routing decision based on minimal load, hence resource status
category info of dCDN is needed.   
 *Make routing decision based on capability , hence delivery
protocol/service type, user authentication method category info is needed.
 *Make routing decision based on minimal expense, hence cost category info
is needed.
 *Make routing decision based on optimal QoS, hence performance data is
needed, e.g. latency, distance, Peak Delivery Capability , Guaranteed
Minimum
  Capability.

2. Based on the above categories, evaluate the granularity of each kind of
capability info under the CDNI circumstance, convey the info in a abstract
way as you two suggested or uCDN prefer a more detail one ?Again, should be
thought as semantics definition.

3.Define syntax of the capability info mentioned above. Based on your
comments, here is an example of revision for your comments.
<CapabilityAd>
< IPVersion >IPV4</ IPVersion >
< ServiceStatus>1</ ServiceStatus >
<LoadStatus>  !--aggeragated
<MaxConnection>10000</ MaxConnection >
<UsedConnection>500</ UsedConnection>
<MaxDeliveryBW>20000</ MaxConnection >
<DeliveryBWUsage>5000</ DeliveryBWUsage >
</LoadStatus>
< Coverage>Country=A,State=B,City=C
< Performance >
< Latency > 10ms</ Latency >
</ Performance >
<Capability >
< DeliveryCap > Protocol="HTTP"
<LoadStatus>   !--per delivery protocol
<MaxConnection>2000</ MaxConnection >
<UsedConnection>1000</ UsedConnection >
</LoadStatus>
<Expense>900$/GM</ MaxConnection >
</ DeliveryCap >
< DeliveryCap >Protocol="RTSP/RTP"
..
</ DeliveryCap >
< SecurityCap > Authentication="RSA256"</ Authentication >
</ Capability >
</ Coverage >
< Coverage>Country=D,State=E,City=F
..
< Coverage>
</CapabilityAd> 

4.Define the protocol.


I'll prepare a revision of this draft focusing on above step 1,2 and 3 based
on our discussion , and any other colleagues who would like to
contribute/collaborate are welcome.   

Please see my other responses inline. 

Best Regards
Xiaoyan(Susan) He
> -----Original Message-----
> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of
Ben
> Niven-Jenkins
> Sent: Tuesday, February 21, 2012 5:11 AM
> To: Scott Wainner
> Cc: cdni@ietf.org
> Subject: Re: [CDNi] FW: New Version Notification for
> draft-he-cdni-cap-info-advertising-00.txt
> 
> Colleagues,
> 
> I'd suggest that more work needs to be done on the classes of capability
that
> need to be exchanged as well as specific capabilities that may be useful
before
> worrying too much what the actual protocol may look like.

[Xiaoyan] Agree. Will do this on the revision. 

> For example two immediate classes that come to mind are slow changing Vs
> fast changing capabilities. E.g. I would expect that the version of IP and
> individual delivery protocols supported would change slowly.
> 
> You might also want to think about how to convey non-binary (i.e. on/off)
> capabilities in a more abstract way as I'm not sure folks will want to
expose for
> e.g. "I can support X more connections" etc.
> 
[Xiaoyan] Will think this in the revision, hope can address it.

> Ben
> 
> On 20 Feb 2012, at 13:35, Scott Wainner wrote:
> 
> > Xiaoyan,
> >
> > Section 3: Capability information description
> >
> > o Resource status of each downstream
> >
> >     I don't think we want the be constantly advertising changes in the
> usage percentage and available bandwidth.  The DECISION to allow or not
> allow content acquisition and the threshold upon when that decision is
made is
> likely to vary and be subject to the policies of the dCDN (e.g. allow 60%
load or
> allow 80% load).  In addition, the decision to acquire content (for
dynamic
> acquisition) is made AFTER the decision has been made to redirect the
client to
> the dCDN for content delivery.  I'm inclined to say the dCDN needs to
indicate
> to the uCDN that it should or should not redirect clients to the dCDN and
that
> decision is based on internal characteristics of the dCDN (cache-miss
rates,
> circuit loads, acquisition capacities, etc.).  This probably needs to be a
binary
> notification for each delivery service defined.

[Xiaoyan] Actually, bandwidth info of the content acquisition had been
removed in the table of section 5.1 for 
Similar reason as you mentioned, I forgot synchronize to update the
description of section3. Regarding the remaining maximum
Delivery bandwidth and delivery bandwidth usage, it is relative to the
contracted value between the two CDNs, i.e. the dCDN has
Committed to provide that value of bandwidth to the uCDN. I think our
divergence is who should make the decision not to go, uCDN based
On its contracted service and its usage status of this service or the dCDN
make this decision and simply sent a binary notification to uCDN(similar 
For the maximum connection and used connection)? I don't have a strong
opinion, and would like to hear other experts' view. 

> > o Footprint of each Downstream CDN
> >
> >     I think the footprint needs to be defined for each type of delivery
> service.
> >
> >     I think the capacity argument above needs to be at the granularity
of
> the "footprint".  Perhaps we need to define footprint.  Is that a
continent,
> country, province, state, region, city.  At a macro level, we might
indicate that
> the dCDN can support a delivery service in all the European countries, but
the
> resources in a particular country are exhausted.  We now have a decision
to
> make.  Should the uCDN continue to re-direct clients to the dCDN?  If it
does,
> the costs assigned to the dCDN will increase as the client will be
assigned a
> distribution node in the closest available location for that service.  On
the
> contrary, the dCDN might increase the costs associated with distribution
in
> that one country such that the uCDN decides not to re-direct the client.

[Xiaoyan] I think this is relative to the syntax of the capability info, I
can try to
Do this in the revision if other colleagues in the group think this
expression is a good way.

> > o Delivery protocol supported by each Downstream CDN;
> >
> >     I think this is appropriate and should be reflected in a type of
delivery
> service.  Example: Microsoft Smooth Streaming is supported in the
following
> countries ...; Apple HTTP Live Streaming is supported in the following
cities ...;
> Adobe HTTP Dynamic Streaming is supported on the following BGP networks
...
[Xiaoyan] Same as previous one.

> >     Clearly, we need to define 'footprint'.
> >
> > o Cost information of each Downstream CDN;
> >
> >     How do we characterize costs?  Cost relative to what?  Not sure we
> want to include a currency converter in our protocol.  We might want to
define
> cost as an abstract value that can be negotiated between the uCDN and
dCDN.
> That means the dCDN internal cost metrics need to be characterized in the
> abstract cost assignment advertised to the uCDN.  That cost could be in
any
> currency.  In fact, the cost could be in latency or distance.  As long as
the
> two parties agree on how to assess cost.

[Xiaoyan] In the draft now I recommend we characterize cost based on data
size( per GB) delivered to end user
On behalf the uCDN, this is very straightforward. Could you explain more if
the cost is in an abstract value such as
Latency or distance, how can the uCDN implement the minimal expense policy?
Thanks. 


> > o Authentication type to end user supported by each of the Downstream
CDN
> >
> >     I don't see this as optional.  Each dCDN is likely to expect the use
some
> authentication method between the client and the delivery node.  That
> credential may be provided by the service routing function or some other
> system.  The dCDN needs to advertise the method and where to obtain the
> credentials for each type of routing request.  I think the uCDN will need
to
> receive a routing request from its own client (using its own credentials),
> ascertain which dCDN the client should be redirected, determine the method
of
> authentication (and perhaps obtain the credential on behalf of the
client), and
> respond to the client.

[Xiaoyan]Don't quite understand what you mean here, could you explain more
on the case you thought about,
what is the purpose of dCDN advertiseWhere to obtain the credential? When I
wrote this what in my mind is for
some contents the CP may require that the CDN it delegate should
authenticate the end user, CP has sent the key to the 
uCDN when they contracted, and uCDN sent it to the dCDN when they
contracted, after the dCDN receive 
a user request for the contents, it will use this key and the authentication
method to authenticate the user against token conveyed in the URL.
As not all contents need this operation, it is recommend as optional.

> > 5.1 Capability information description
> >
> >     I'm less inclined to include usage percentages in any reports as the
> dCDN may be servicing other uCDN.  If we're talking about a maximum
> allowed threshold contracted between the uCDN and dCDN, then the usage
> percentage might be relative to that contracted streaming capacity.  Of
> course, percentage can be provided by simply providing the maximum
> contracted streaming capacity and the current streaming assignments in
> different categories:
> >
> >     Streams Allowed, Streams Assigned
> >     Stream Bandwidth Allowed, Stream Bandwidth Consumed (this will be
> tough with ABR)
> >     Cached Assets Allowed, Cached Assets

[Xiaoyan]Yes, it is about a maximum allowed threshold contracted between the
CDNs. I think this is relative to your first above comment. 
Could you check again which you prefer, the detail value or a simply binary
go/not go notification?


> >     I also see in the table you have started defining 'Coverage' which
may
> also be described as 'Footprint'.  Probably need to define one term and
keep it
> consistent.  We then need to define the 'Coverage' or 'Footprint'
elements.
[Xiaoyan] Agree.

> >     Also need to define 'Peak Delivery Capability' or 'Guaranteed
Minimum
> Capability' for a given 'Coverage'.  Contractually, some content owners
expect
> their uCDN to provide high-quality content delivery (high-capacity
streaming)
> and want to insure the delivery networks can facilitate that type of
support.  If
> the dCDN has a capped delivery capability (either by the delivery node or
the
> access infrastructure), the uCDN needs to know that in order to 'qualify'
the
> dCDN for content delivery.

[Xiaoyan]I think this depend on the way of the delivery bandwidth
advertisement,
If it is a binary notification, then this may be needed to 'qualify' the
content delivery.
If it is the detail maximum contracted delivery bandwidth and the usage
info,
The uCDN can 'qualify' the content delivery through the bandwidth retained. 

> > Scott Wainner
> >
> >
> >
> > On 2/16/12 6:13 AM, HeXiaoyan wrote:
> >> Hi all,
> >> We have submitted a draft on capability advertising of CDNI,
> >>  http://datatracker.ietf.org/doc/draft-he-cdni-cap-info-advertising/
> >>
> >> Your comments are welcome.
> >>
> >> Best Regards
> >> Xiaoyan(Susan) He
> >>
> >> -----Original Message-----
> >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> >> Sent: Thursday, February 16, 2012 7:10 PM
> >> To: hexiaoyan@huawei.com
> >> Cc: cheng@gsta.com; hexiaoyan@huawei.com; niwei@chinamobile.com;
> spencer@wonderhamster.org; zhangyunfei@chinamobile.com
> >> Subject: New Version Notification for
> draft-he-cdni-cap-info-advertising-00.txt
> >>
> >> A new version of I-D, draft-he-cdni-cap-info-advertising-00.txt has
been
> successfully submitted by Xiaoyan He and posted to the IETF repository.
> >>
> >> Filename:        draft-he-cdni-cap-info-advertising
> >> Revision:        00
> >> Title:           Capability Information Advertising for CDN
> Interconnection
> >> Creation date:   2012-02-16
> >> WG ID:           Individual Submission
> >> Number of pages: 11
> >>
> >> Abstract:
> >>   This document describes protocol for Capability Information
Advertising
> >> which is   used to communicate capability information among
> interconnected Content
> >> Delivery   Networks(CDNs).
> >>
> >>
> >>
> >>
> >> The IETF Secretariat
> >>
> >> _______________________________________________
> >> CDNi mailing list
> >> CDNi@ietf.org
> >> https://www.ietf.org/mailman/listinfo/cdni
> >>
> >
> > _______________________________________________
> > CDNi mailing list
> > CDNi@ietf.org
> > https://www.ietf.org/mailman/listinfo/cdni
> 
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni


From swainner@cisco.com  Tue Feb 21 06:17:49 2012
Return-Path: <swainner@cisco.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F2B21F8826 for <cdni@ietfa.amsl.com>; Tue, 21 Feb 2012 06:17:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.209
X-Spam-Level: 
X-Spam-Status: No, score=-9.209 tagged_above=-999 required=5 tests=[AWL=0.789,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-UHtkSnFP9d for <cdni@ietfa.amsl.com>; Tue, 21 Feb 2012 06:17:42 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id C1CFE21F8823 for <cdni@ietf.org>; Tue, 21 Feb 2012 06:17:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=41443; q=dns/txt; s=iport; t=1329833862; x=1331043462; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=uykSg/0SVrNjg/Z2L1ee9QiCTcZS/Qhjkk6lBGN+Tys=; b=CMrQB/45oL5twY17V6F+ZaqXFj6PWPZp7vWQirJ2HPjN+y8FuHFZd4+9 Im992fM9anrNAC7Ljl/OmvriW2uGNd5ahjZFLSzEUgTpDWuXuA5XyBJ/T UMPTTeJRmLA1y8TJYYcoS7SmDHTWj0n0fEVh3kEvy69DNCrawMbyoBQd6 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAAGnQ0+rRDoI/2dsb2JhbABDsBaCAoEHgXMBAQEDAQEBAQ8BBxM+AwkBAQUHBAsRBAEBAQkWAQEGBwkDAgECARUfCAEIBg0BBQIBAR6HXgmZRwGOX5Asi3MBAggBAQEBAQcDAwkFAjAFAYNQGgkqAwUHCgaDLQSIT4xpkws
X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208,217";a="31536013"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 21 Feb 2012 14:17:41 +0000
Received: from stealth-10-32-245-57.cisco.com (stealth-10-32-245-57.cisco.com [10.32.245.57]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1LEHed8005600; Tue, 21 Feb 2012 14:17:40 GMT
Message-ID: <4F43A7ED.1090800@cisco.com>
Date: Tue, 21 Feb 2012 09:19:25 -0500
From: Scott Wainner <swainner@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: HeXiaoyan <hexiaoyan@huawei.com>
References: <006001ccec9b$f5bad550$e1307ff0$@com> <4F424C27.5090106@cisco.com> <06E31573-57BE-4855-B93A-F331D3B0574D@niven-jenkins.co.uk> <005c01ccf095$a9608490$fc218db0$@com>
In-Reply-To: <005c01ccf095$a9608490$fc218db0$@com>
Content-Type: multipart/alternative; boundary="------------020608020907040308010208"
Cc: cdni@ietf.org
Subject: Re: [CDNi] FW: New Version Notification fordraft-he-cdni-cap-info-advertising-00.txt
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Tue, 21 Feb 2012 14:17:49 -0000

This is a multi-part message in MIME format.
--------------020608020907040308010208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Xiaoyan (Susan) He,

Perhaps we need to delineate between baseline (mandatory) capabilities 
and enhanced (optional) capabilities.  I'm inclined to think that the 
client has communicated with the content owner's portal and chosen an 
asset to view.  At this point, the client capabilities have already 
created a filtered set of assets that are viable for delivery.  The uCDN 
needs to take this initial filter criteria into consideration.  This 
might include capabilities that are baseline requirements:

      1) protocol/service type
      2) authentication method
      3) performance criteria (guaranteed capability)

In this case, the potential set of dCDN either meet the qualification or 
they do not.  From this filtered set of dCDN, we now have the ability to 
assess the remaining set of dCDN based on enhanced requirements:

      1) proximity
      2) load
      3) cost
      4) performance criteria (target capability)

Scott

On 2/21/12 7:38 AM, HeXiaoyan wrote:
>
> Scott and Ben,
> This draft is a very primary version and the intention of it was to
> stimulate the group to discuss capability advertising and thanks for your
> comments. I agree with you that there is still a lot need to do to 
> amend it.
> As it seems that we still have divergence on what kind of capability info
> need to be exchanged, I reconsider the way work on it, here is something
> come into mind.
> 1. First we find and get agreement on the criteria that determine the
> capability that needed to be exchanged. We can use these criteria to 
> filter
> the capability information and walk a step forward to define the semantics
> of each. As the capability info is used to facility request routing, and
> uCDNs may have vary internal routing policy, below is some criteria 
> based on
> the often mentioned use cases.
>  * Make routing decision(selecting a dCDN) based on proximity, hence
> footprint category info is needed.
>  * Make routing decision based on minimal load, hence resource status
> category info of dCDN is needed.
>  *Make routing decision based on capability , hence delivery
> protocol/service type, user authentication method category info is needed.
>  *Make routing decision based on minimal expense, hence cost category info
> is needed.
>  *Make routing decision based on optimal QoS, hence performance data is
> needed, e.g. latency, distance, Peak Delivery Capability , Guaranteed
> Minimum
>   Capability.
>
> 2. Based on the above categories, evaluate the granularity of each kind of
> capability info under the CDNI circumstance, convey the info in a abstract
> way as you two suggested or uCDN prefer a more detail one ?Again, 
> should be
> thought as semantics definition.
>
> 3.Define syntax of the capability info mentioned above. Based on your
> comments, here is an example of revision for your comments.
> <CapabilityAd>
> < IPVersion >IPV4</ IPVersion >
> < ServiceStatus>1</ ServiceStatus >
> <LoadStatus>  !--aggeragated
> <MaxConnection>10000</ MaxConnection >
> <UsedConnection>500</ UsedConnection>
> <MaxDeliveryBW>20000</ MaxConnection >
> <DeliveryBWUsage>5000</ DeliveryBWUsage >
> </LoadStatus>
> < Coverage>Country=A,State=B,City=C
> < Performance >
> < Latency > 10ms</ Latency >
> </ Performance >
> <Capability >
> < DeliveryCap > Protocol="HTTP"
> <LoadStatus>   !--per delivery protocol
> <MaxConnection>2000</ MaxConnection >
> <UsedConnection>1000</ UsedConnection >
> </LoadStatus>
> <Expense>900$/GM</ MaxConnection >
> </ DeliveryCap >
> < DeliveryCap >Protocol="RTSP/RTP"
> ..
> </ DeliveryCap >
> < SecurityCap > Authentication="RSA256"</ Authentication >
> </ Capability >
> </ Coverage >
> < Coverage>Country=D,State=E,City=F
> ..
> < Coverage>
> </CapabilityAd>
>
> 4.Define the protocol.
>
>
> I'll prepare a revision of this draft focusing on above step 1,2 and 3 
> based
> on our discussion , and any other colleagues who would like to
> contribute/collaborate are welcome.
>
> Please see my other responses inline.
>
> Best Regards
> Xiaoyan(Susan) He
> > -----Original Message-----
> > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of
> Ben
> > Niven-Jenkins
> > Sent: Tuesday, February 21, 2012 5:11 AM
> > To: Scott Wainner
> > Cc: cdni@ietf.org
> > Subject: Re: [CDNi] FW: New Version Notification for
> > draft-he-cdni-cap-info-advertising-00.txt
> >
> > Colleagues,
> >
> > I'd suggest that more work needs to be done on the classes of capability
> that
> > need to be exchanged as well as specific capabilities that may be useful
> before
> > worrying too much what the actual protocol may look like.
>
> [Xiaoyan] Agree. Will do this on the revision.
>
> > For example two immediate classes that come to mind are slow changing Vs
> > fast changing capabilities. E.g. I would expect that the version of 
> IP and
> > individual delivery protocols supported would change slowly.
> >
> > You might also want to think about how to convey non-binary (i.e. 
> on/off)
> > capabilities in a more abstract way as I'm not sure folks will want to
> expose for
> > e.g. "I can support X more connections" etc.
> >
> [Xiaoyan] Will think this in the revision, hope can address it.
>
> > Ben
> >
> > On 20 Feb 2012, at 13:35, Scott Wainner wrote:
> >
> > > Xiaoyan,
> > >
> > > Section 3: Capability information description
> > >
> > > o Resource status of each downstream
> > >
> > >     I don't think we want the be constantly advertising changes in the
> > usage percentage and available bandwidth.  The DECISION to allow or not
> > allow content acquisition and the threshold upon when that decision is
> made is
> > likely to vary and be subject to the policies of the dCDN (e.g. 
> allow 60%
> load or
> > allow 80% load).  In addition, the decision to acquire content (for
> dynamic
> > acquisition) is made AFTER the decision has been made to redirect the
> client to
> > the dCDN for content delivery.  I'm inclined to say the dCDN needs to
> indicate
> > to the uCDN that it should or should not redirect clients to the 
> dCDN and
> that
> > decision is based on internal characteristics of the dCDN (cache-miss
> rates,
> > circuit loads, acquisition capacities, etc.).  This probably needs 
> to be a
> binary
> > notification for each delivery service defined.
>
> [Xiaoyan] Actually, bandwidth info of the content acquisition had been
> removed in the table of section 5.1 for
> Similar reason as you mentioned, I forgot synchronize to update the
> description of section3. Regarding the remaining maximum
> Delivery bandwidth and delivery bandwidth usage, it is relative to the
> contracted value between the two CDNs, i.e. the dCDN has
> Committed to provide that value of bandwidth to the uCDN. I think our
> divergence is who should make the decision not to go, uCDN based
> On its contracted service and its usage status of this service or the dCDN
> make this decision and simply sent a binary notification to uCDN(similar
> For the maximum connection and used connection)? I don't have a strong
> opinion, and would like to hear other experts' view.
>
> > > o Footprint of each Downstream CDN
> > >
> > >     I think the footprint needs to be defined for each type of 
> delivery
> > service.
> > >
> > >     I think the capacity argument above needs to be at the granularity
> of
> > the "footprint".  Perhaps we need to define footprint.  Is that a
> continent,
> > country, province, state, region, city.  At a macro level, we might
> indicate that
> > the dCDN can support a delivery service in all the European 
> countries, but
> the
> > resources in a particular country are exhausted.  We now have a decision
> to
> > make.  Should the uCDN continue to re-direct clients to the dCDN?  If it
> does,
> > the costs assigned to the dCDN will increase as the client will be
> assigned a
> > distribution node in the closest available location for that 
> service.  On
> the
> > contrary, the dCDN might increase the costs associated with distribution
> in
> > that one country such that the uCDN decides not to re-direct the client.
>
> [Xiaoyan] I think this is relative to the syntax of the capability info, I
> can try to
> Do this in the revision if other colleagues in the group think this
> expression is a good way.
>
> > > o Delivery protocol supported by each Downstream CDN;
> > >
> > >     I think this is appropriate and should be reflected in a type of
> delivery
> > service.  Example: Microsoft Smooth Streaming is supported in the
> following
> > countries ...; Apple HTTP Live Streaming is supported in the following
> cities ...;
> > Adobe HTTP Dynamic Streaming is supported on the following BGP networks
> ...
> [Xiaoyan] Same as previous one.
>
> > >     Clearly, we need to define 'footprint'.
> > >
> > > o Cost information of each Downstream CDN;
> > >
> > >     How do we characterize costs?  Cost relative to what?  Not sure we
> > want to include a currency converter in our protocol.  We might want to
> define
> > cost as an abstract value that can be negotiated between the uCDN and
> dCDN.
> > That means the dCDN internal cost metrics need to be characterized 
> in the
> > abstract cost assignment advertised to the uCDN.  That cost could be in
> any
> > currency.  In fact, the cost could be in latency or distance.  As 
> long as
> the
> > two parties agree on how to assess cost.
>
> [Xiaoyan] In the draft now I recommend we characterize cost based on data
> size( per GB) delivered to end user
> On behalf the uCDN, this is very straightforward. Could you explain 
> more if
> the cost is in an abstract value such as
> Latency or distance, how can the uCDN implement the minimal expense 
> policy?
> Thanks.
>
>
> > > o Authentication type to end user supported by each of the Downstream
> CDN
> > >
> > >     I don't see this as optional.  Each dCDN is likely to expect 
> the use
> some
> > authentication method between the client and the delivery node.  That
> > credential may be provided by the service routing function or some other
> > system.  The dCDN needs to advertise the method and where to obtain the
> > credentials for each type of routing request.  I think the uCDN will 
> need
> to
> > receive a routing request from its own client (using its own 
> credentials),
> > ascertain which dCDN the client should be redirected, determine the 
> method
> of
> > authentication (and perhaps obtain the credential on behalf of the
> client), and
> > respond to the client.
>
> [Xiaoyan]Don't quite understand what you mean here, could you explain more
> on the case you thought about,
> what is the purpose of dCDN advertiseWhere to obtain the credential? 
> When I
> wrote this what in my mind is for
> some contents the CP may require that the CDN it delegate should
> authenticate the end user, CP has sent the key to the
> uCDN when they contracted, and uCDN sent it to the dCDN when they
> contracted, after the dCDN receive
> a user request for the contents, it will use this key and the 
> authentication
> method to authenticate the user against token conveyed in the URL.
> As not all contents need this operation, it is recommend as optional.
>
> > > 5.1 Capability information description
> > >
> > >     I'm less inclined to include usage percentages in any reports 
> as the
> > dCDN may be servicing other uCDN.  If we're talking about a maximum
> > allowed threshold contracted between the uCDN and dCDN, then the usage
> > percentage might be relative to that contracted streaming capacity.  Of
> > course, percentage can be provided by simply providing the maximum
> > contracted streaming capacity and the current streaming assignments in
> > different categories:
> > >
> > >     Streams Allowed, Streams Assigned
> > >     Stream Bandwidth Allowed, Stream Bandwidth Consumed (this will be
> > tough with ABR)
> > >     Cached Assets Allowed, Cached Assets
>
> [Xiaoyan]Yes, it is about a maximum allowed threshold contracted 
> between the
> CDNs. I think this is relative to your first above comment.
> Could you check again which you prefer, the detail value or a simply 
> binary
> go/not go notification?
>
>
> > >     I also see in the table you have started defining 'Coverage' which
> may
> > also be described as 'Footprint'.  Probably need to define one term and
> keep it
> > consistent.  We then need to define the 'Coverage' or 'Footprint'
> elements.
> [Xiaoyan] Agree.
>
> > >     Also need to define 'Peak Delivery Capability' or 'Guaranteed
> Minimum
> > Capability' for a given 'Coverage'.  Contractually, some content owners
> expect
> > their uCDN to provide high-quality content delivery (high-capacity
> streaming)
> > and want to insure the delivery networks can facilitate that type of
> support.  If
> > the dCDN has a capped delivery capability (either by the delivery 
> node or
> the
> > access infrastructure), the uCDN needs to know that in order to 
> 'qualify'
> the
> > dCDN for content delivery.
>
> [Xiaoyan]I think this depend on the way of the delivery bandwidth
> advertisement,
> If it is a binary notification, then this may be needed to 'qualify' the
> content delivery.
> If it is the detail maximum contracted delivery bandwidth and the usage
> info,
> The uCDN can 'qualify' the content delivery through the bandwidth 
> retained.
>
> > > Scott Wainner
> > >
> > >
> > >
> > > On 2/16/12 6:13 AM, HeXiaoyan wrote:
> > >> Hi all,
> > >> We have submitted a draft on capability advertising of CDNI,
> > >> http://datatracker.ietf.org/doc/draft-he-cdni-cap-info-advertising/
> > >>
> > >> Your comments are welcome.
> > >>
> > >> Best Regards
> > >> Xiaoyan(Susan) He
> > >>
> > >> -----Original Message-----
> > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > >> Sent: Thursday, February 16, 2012 7:10 PM
> > >> To: hexiaoyan@huawei.com
> > >> Cc: cheng@gsta.com; hexiaoyan@huawei.com; niwei@chinamobile.com;
> > spencer@wonderhamster.org; zhangyunfei@chinamobile.com
> > >> Subject: New Version Notification for
> > draft-he-cdni-cap-info-advertising-00.txt
> > >>
> > >> A new version of I-D, draft-he-cdni-cap-info-advertising-00.txt has
> been
> > successfully submitted by Xiaoyan He and posted to the IETF repository.
> > >>
> > >> Filename:        draft-he-cdni-cap-info-advertising
> > >> Revision:        00
> > >> Title:           Capability Information Advertising for CDN
> > Interconnection
> > >> Creation date:   2012-02-16
> > >> WG ID:           Individual Submission
> > >> Number of pages: 11
> > >>
> > >> Abstract:
> > >>   This document describes protocol for Capability Information
> Advertising
> > >> which is   used to communicate capability information among
> > interconnected Content
> > >> Delivery   Networks(CDNs).
> > >>
> > >>
> > >>
> > >>
> > >> The IETF Secretariat
> > >>
> > >> _______________________________________________
> > >> CDNi mailing list
> > >> CDNi@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/cdni
> > >>
> > >
> > > _______________________________________________
> > > CDNi mailing list
> > > CDNi@ietf.org
> > > https://www.ietf.org/mailman/listinfo/cdni
> >
> > _______________________________________________
> > CDNi mailing list
> > CDNi@ietf.org
> > https://www.ietf.org/mailman/listinfo/cdni
>


--------------020608020907040308010208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <font size="2">Xiaoyan (Susan) He</font>,<br>
    <br>
    Perhaps we need to delineate between baseline (mandatory)
    capabilities and enhanced (optional) capabilities.&nbsp; I'm inclined to
    think that the client has communicated with the content owner's
    portal and chosen an asset to view.&nbsp; At this point, the client
    capabilities have already created a filtered set of assets that are
    viable for delivery.&nbsp; The uCDN needs to take this initial filter
    criteria into consideration.&nbsp; This might include capabilities that
    are baseline requirements:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp; 1) protocol/service type<br>
    &nbsp;&nbsp;&nbsp;&nbsp; 2) authentication method <br>
    &nbsp;&nbsp;&nbsp;&nbsp; 3) performance criteria (guaranteed capability)<br>
    <br>
    In this case, the potential set of dCDN either meet the
    qualification or they do not.&nbsp; From this filtered set of dCDN, we
    now have the ability to assess the remaining set of dCDN based on
    enhanced requirements:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp; 1) proximity<br>
    &nbsp;&nbsp;&nbsp;&nbsp; 2) load<br>
    &nbsp;&nbsp;&nbsp;&nbsp; 3) cost<br>
    &nbsp;&nbsp;&nbsp;&nbsp; 4) performance criteria (target capability)<br>
    <br>
    Scott<br>
    <br>
    On 2/21/12 7:38 AM, HeXiaoyan wrote:
    <blockquote cite="mid:005c01ccf095$a9608490$fc218db0$@com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="MS Exchange Server version
        6.5.7655.10">
      <title>RE: [CDNi] FW: New Version Notification
        fordraft-he-cdni-cap-info-advertising-00.txt</title>
      <!-- Converted from text/plain format -->
      <p><font size="2">Scott and Ben,<br>
          This draft is a very primary version and the intention of it
          was to<br>
          stimulate the group to discuss capability advertising and
          thanks for your<br>
          comments. I agree with you that there is still a lot need to
          do to amend it.<br>
          As it seems that we still have divergence on what kind of
          capability info<br>
          need to be exchanged, I reconsider the way work on it, here is
          something<br>
          come into mind.<br>
          1. First we find and get agreement on the criteria that
          determine the<br>
          capability that needed to be exchanged. We can use these
          criteria to filter<br>
          the capability information and walk a step forward to define
          the semantics<br>
          of each. As the capability info is used to facility request
          routing, and<br>
          uCDNs may have vary internal routing policy, below is some
          criteria based on<br>
          the often mentioned use cases.<br>
          &nbsp;* Make routing decision(selecting a dCDN) based on proximity,
          hence<br>
          footprint category info is needed.<br>
          &nbsp;* Make routing decision based on minimal load, hence resource
          status<br>
          category info of dCDN is needed.&nbsp;&nbsp;<br>
          &nbsp;*Make routing decision based on capability , hence delivery<br>
          protocol/service type, user authentication method category
          info is needed.<br>
          &nbsp;*Make routing decision based on minimal expense, hence cost
          category info<br>
          is needed.<br>
          &nbsp;*Make routing decision based on optimal QoS, hence
          performance data is<br>
          needed, e.g. latency, distance, Peak Delivery Capability ,
          Guaranteed<br>
          Minimum<br>
          &nbsp; Capability.<br>
          <br>
          2. Based on the above categories, evaluate the granularity of
          each kind of<br>
          capability info under the CDNI circumstance, convey the info
          in a abstract<br>
          way as you two suggested or uCDN prefer a more detail one
          ?Again, should be<br>
          thought as semantics definition.<br>
          <br>
          3.Define syntax of the capability info mentioned above. Based
          on your<br>
          comments, here is an example of revision for your comments.<br>
          &lt;CapabilityAd&gt;<br>
          &lt; IPVersion &gt;IPV4&lt;/ IPVersion &gt;<br>
          &lt; ServiceStatus&gt;1&lt;/ ServiceStatus &gt;<br>
          &lt;LoadStatus&gt;&nbsp; !--aggeragated<br>
          &lt;MaxConnection&gt;10000&lt;/ MaxConnection &gt;<br>
          &lt;UsedConnection&gt;500&lt;/ UsedConnection&gt;<br>
          &lt;MaxDeliveryBW&gt;20000&lt;/ MaxConnection &gt;<br>
          &lt;DeliveryBWUsage&gt;5000&lt;/ DeliveryBWUsage &gt;<br>
          &lt;/LoadStatus&gt;<br>
          &lt; Coverage&gt;Country=A,State=B,City=C<br>
          &lt; Performance &gt;<br>
          &lt; Latency &gt; 10ms&lt;/ Latency &gt;<br>
          &lt;/ Performance &gt;<br>
          &lt;Capability &gt;<br>
          &lt; DeliveryCap &gt; Protocol="HTTP"<br>
          &lt;LoadStatus&gt;&nbsp;&nbsp; !--per delivery protocol<br>
          &lt;MaxConnection&gt;2000&lt;/ MaxConnection &gt;<br>
          &lt;UsedConnection&gt;1000&lt;/ UsedConnection &gt;<br>
          &lt;/LoadStatus&gt;<br>
          &lt;Expense&gt;900$/GM&lt;/ MaxConnection &gt;<br>
          &lt;/ DeliveryCap &gt;<br>
          &lt; DeliveryCap &gt;Protocol="RTSP/RTP"<br>
          ..<br>
          &lt;/ DeliveryCap &gt;<br>
          &lt; SecurityCap &gt; Authentication="RSA256"&lt;/
          Authentication &gt;<br>
          &lt;/ Capability &gt;<br>
          &lt;/ Coverage &gt;<br>
          &lt; Coverage&gt;Country=D,State=E,City=F<br>
          ..<br>
          &lt; Coverage&gt;<br>
          &lt;/CapabilityAd&gt;<br>
          <br>
          4.Define the protocol.<br>
          <br>
          <br>
          I'll prepare a revision of this draft focusing on above step
          1,2 and 3 based<br>
          on our discussion , and any other colleagues who would like to<br>
          contribute/collaborate are welcome.&nbsp;&nbsp;<br>
          <br>
          Please see my other responses inline.<br>
          <br>
          Best Regards<br>
          Xiaoyan(Susan) He<br>
          &gt; -----Original Message-----<br>
          &gt; From: <a class="moz-txt-link-abbreviated" href="mailto:cdni-bounces@ietf.org">cdni-bounces@ietf.org</a> [<a moz-do-not-send="true"
            href="mailto:cdni-bounces@ietf.org">mailto:cdni-bounces@ietf.org</a>]
          On Behalf Of<br>
          Ben<br>
          &gt; Niven-Jenkins<br>
          &gt; Sent: Tuesday, February 21, 2012 5:11 AM<br>
          &gt; To: Scott Wainner<br>
          &gt; Cc: <a class="moz-txt-link-abbreviated" href="mailto:cdni@ietf.org">cdni@ietf.org</a><br>
          &gt; Subject: Re: [CDNi] FW: New Version Notification for<br>
          &gt; draft-he-cdni-cap-info-advertising-00.txt<br>
          &gt;<br>
          &gt; Colleagues,<br>
          &gt;<br>
          &gt; I'd suggest that more work needs to be done on the
          classes of capability<br>
          that<br>
          &gt; need to be exchanged as well as specific capabilities
          that may be useful<br>
          before<br>
          &gt; worrying too much what the actual protocol may look like.<br>
          <br>
          [Xiaoyan] Agree. Will do this on the revision.<br>
          <br>
          &gt; For example two immediate classes that come to mind are
          slow changing Vs<br>
          &gt; fast changing capabilities. E.g. I would expect that the
          version of IP and<br>
          &gt; individual delivery protocols supported would change
          slowly.<br>
          &gt;<br>
          &gt; You might also want to think about how to convey
          non-binary (i.e. on/off)<br>
          &gt; capabilities in a more abstract way as I'm not sure folks
          will want to<br>
          expose for<br>
          &gt; e.g. "I can support X more connections" etc.<br>
          &gt;<br>
          [Xiaoyan] Will think this in the revision, hope can address
          it.<br>
          <br>
          &gt; Ben<br>
          &gt;<br>
          &gt; On 20 Feb 2012, at 13:35, Scott Wainner wrote:<br>
          &gt;<br>
          &gt; &gt; Xiaoyan,<br>
          &gt; &gt;<br>
          &gt; &gt; Section 3: Capability information description<br>
          &gt; &gt;<br>
          &gt; &gt; o Resource status of each downstream<br>
          &gt; &gt;<br>
          &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; I don't think we want the be constantly
          advertising changes in the<br>
          &gt; usage percentage and available bandwidth.&nbsp; The DECISION
          to allow or not<br>
          &gt; allow content acquisition and the threshold upon when
          that decision is<br>
          made is<br>
          &gt; likely to vary and be subject to the policies of the dCDN
          (e.g. allow 60%<br>
          load or<br>
          &gt; allow 80% load).&nbsp; In addition, the decision to acquire
          content (for<br>
          dynamic<br>
          &gt; acquisition) is made AFTER the decision has been made to
          redirect the<br>
          client to<br>
          &gt; the dCDN for content delivery.&nbsp; I'm inclined to say the
          dCDN needs to<br>
          indicate<br>
          &gt; to the uCDN that it should or should not redirect clients
          to the dCDN and<br>
          that<br>
          &gt; decision is based on internal characteristics of the dCDN
          (cache-miss<br>
          rates,<br>
          &gt; circuit loads, acquisition capacities, etc.).&nbsp; This
          probably needs to be a<br>
          binary<br>
          &gt; notification for each delivery service defined.<br>
          <br>
          [Xiaoyan] Actually, bandwidth info of the content acquisition
          had been<br>
          removed in the table of section 5.1 for<br>
          Similar reason as you mentioned, I forgot synchronize to
          update the<br>
          description of section3. Regarding the remaining maximum<br>
          Delivery bandwidth and delivery bandwidth usage, it is
          relative to the<br>
          contracted value between the two CDNs, i.e. the dCDN has<br>
          Committed to provide that value of bandwidth to the uCDN. I
          think our<br>
          divergence is who should make the decision not to go, uCDN
          based<br>
          On its contracted service and its usage status of this service
          or the dCDN<br>
          make this decision and simply sent a binary notification to
          uCDN(similar<br>
          For the maximum connection and used connection)? I don't have
          a strong<br>
          opinion, and would like to hear other experts' view.<br>
          <br>
          &gt; &gt; o Footprint of each Downstream CDN<br>
          &gt; &gt;<br>
          &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; I think the footprint needs to be defined for
          each type of delivery<br>
          &gt; service.<br>
          &gt; &gt;<br>
          &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; I think the capacity argument above needs to be
          at the granularity<br>
          of<br>
          &gt; the "footprint".&nbsp; Perhaps we need to define footprint.&nbsp;
          Is that a<br>
          continent,<br>
          &gt; country, province, state, region, city.&nbsp; At a macro
          level, we might<br>
          indicate that<br>
          &gt; the dCDN can support a delivery service in all the
          European countries, but<br>
          the<br>
          &gt; resources in a particular country are exhausted.&nbsp; We now
          have a decision<br>
          to<br>
          &gt; make.&nbsp; Should the uCDN continue to re-direct clients to
          the dCDN?&nbsp; If it<br>
          does,<br>
          &gt; the costs assigned to the dCDN will increase as the
          client will be<br>
          assigned a<br>
          &gt; distribution node in the closest available location for
          that service.&nbsp; On<br>
          the<br>
          &gt; contrary, the dCDN might increase the costs associated
          with distribution<br>
          in<br>
          &gt; that one country such that the uCDN decides not to
          re-direct the client.<br>
          <br>
          [Xiaoyan] I think this is relative to the syntax of the
          capability info, I<br>
          can try to<br>
          Do this in the revision if other colleagues in the group think
          this<br>
          expression is a good way.<br>
          <br>
          &gt; &gt; o Delivery protocol supported by each Downstream
          CDN;<br>
          &gt; &gt;<br>
          &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; I think this is appropriate and should be
          reflected in a type of<br>
          delivery<br>
          &gt; service.&nbsp; Example: Microsoft Smooth Streaming is
          supported in the<br>
          following<br>
          &gt; countries ...; Apple HTTP Live Streaming is supported in
          the following<br>
          cities ...;<br>
          &gt; Adobe HTTP Dynamic Streaming is supported on the
          following BGP networks<br>
          ...<br>
          [Xiaoyan] Same as previous one.<br>
          <br>
          &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Clearly, we need to define 'footprint'.<br>
          &gt; &gt;<br>
          &gt; &gt; o Cost information of each Downstream CDN;<br>
          &gt; &gt;<br>
          &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; How do we characterize costs?&nbsp; Cost relative to
          what?&nbsp; Not sure we<br>
          &gt; want to include a currency converter in our protocol.&nbsp; We
          might want to<br>
          define<br>
          &gt; cost as an abstract value that can be negotiated between
          the uCDN and<br>
          dCDN.<br>
          &gt; That means the dCDN internal cost metrics need to be
          characterized in the<br>
          &gt; abstract cost assignment advertised to the uCDN.&nbsp; That
          cost could be in<br>
          any<br>
          &gt; currency.&nbsp; In fact, the cost could be in latency or
          distance.&nbsp; As long as<br>
          the<br>
          &gt; two parties agree on how to assess cost.<br>
          <br>
          [Xiaoyan] In the draft now I recommend we characterize cost
          based on data<br>
          size( per GB) delivered to end user<br>
          On behalf the uCDN, this is very straightforward. Could you
          explain more if<br>
          the cost is in an abstract value such as<br>
          Latency or distance, how can the uCDN implement the minimal
          expense policy?<br>
          Thanks.<br>
          <br>
          <br>
          &gt; &gt; o Authentication type to end user supported by each
          of the Downstream<br>
          CDN<br>
          &gt; &gt;<br>
          &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; I don't see this as optional.&nbsp; Each dCDN is
          likely to expect the use<br>
          some<br>
          &gt; authentication method between the client and the delivery
          node.&nbsp; That<br>
          &gt; credential may be provided by the service routing
          function or some other<br>
          &gt; system.&nbsp; The dCDN needs to advertise the method and where
          to obtain the<br>
          &gt; credentials for each type of routing request.&nbsp; I think
          the uCDN will need<br>
          to<br>
          &gt; receive a routing request from its own client (using its
          own credentials),<br>
          &gt; ascertain which dCDN the client should be redirected,
          determine the method<br>
          of<br>
          &gt; authentication (and perhaps obtain the credential on
          behalf of the<br>
          client), and<br>
          &gt; respond to the client.<br>
          <br>
          [Xiaoyan]Don't quite understand what you mean here, could you
          explain more<br>
          on the case you thought about,<br>
          what is the purpose of dCDN advertiseWhere to obtain the
          credential? When I<br>
          wrote this what in my mind is for<br>
          some contents the CP may require that the CDN it delegate
          should<br>
          authenticate the end user, CP has sent the key to the<br>
          uCDN when they contracted, and uCDN sent it to the dCDN when
          they<br>
          contracted, after the dCDN receive<br>
          a user request for the contents, it will use this key and the
          authentication<br>
          method to authenticate the user against token conveyed in the
          URL.<br>
          As not all contents need this operation, it is recommend as
          optional.<br>
          <br>
          &gt; &gt; 5.1 Capability information description<br>
          &gt; &gt;<br>
          &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; I'm less inclined to include usage percentages
          in any reports as the<br>
          &gt; dCDN may be servicing other uCDN.&nbsp; If we're talking about
          a maximum<br>
          &gt; allowed threshold contracted between the uCDN and dCDN,
          then the usage<br>
          &gt; percentage might be relative to that contracted streaming
          capacity.&nbsp; Of<br>
          &gt; course, percentage can be provided by simply providing
          the maximum<br>
          &gt; contracted streaming capacity and the current streaming
          assignments in<br>
          &gt; different categories:<br>
          &gt; &gt;<br>
          &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Streams Allowed, Streams Assigned<br>
          &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Stream Bandwidth Allowed, Stream Bandwidth
          Consumed (this will be<br>
          &gt; tough with ABR)<br>
          &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Cached Assets Allowed, Cached Assets<br>
          <br>
          [Xiaoyan]Yes, it is about a maximum allowed threshold
          contracted between the<br>
          CDNs. I think this is relative to your first above comment.<br>
          Could you check again which you prefer, the detail value or a
          simply binary<br>
          go/not go notification?<br>
          <br>
          <br>
          &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; I also see in the table you have started
          defining 'Coverage' which<br>
          may<br>
          &gt; also be described as 'Footprint'.&nbsp; Probably need to
          define one term and<br>
          keep it<br>
          &gt; consistent.&nbsp; We then need to define the 'Coverage' or
          'Footprint'<br>
          elements.<br>
          [Xiaoyan] Agree.<br>
          <br>
          &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Also need to define 'Peak Delivery Capability'
          or 'Guaranteed<br>
          Minimum<br>
          &gt; Capability' for a given 'Coverage'.&nbsp; Contractually, some
          content owners<br>
          expect<br>
          &gt; their uCDN to provide high-quality content delivery
          (high-capacity<br>
          streaming)<br>
          &gt; and want to insure the delivery networks can facilitate
          that type of<br>
          support.&nbsp; If<br>
          &gt; the dCDN has a capped delivery capability (either by the
          delivery node or<br>
          the<br>
          &gt; access infrastructure), the uCDN needs to know that in
          order to 'qualify'<br>
          the<br>
          &gt; dCDN for content delivery.<br>
          <br>
          [Xiaoyan]I think this depend on the way of the delivery
          bandwidth<br>
          advertisement,<br>
          If it is a binary notification, then this may be needed to
          'qualify' the<br>
          content delivery.<br>
          If it is the detail maximum contracted delivery bandwidth and
          the usage<br>
          info,<br>
          The uCDN can 'qualify' the content delivery through the
          bandwidth retained.<br>
          <br>
          &gt; &gt; Scott Wainner<br>
          &gt; &gt;<br>
          &gt; &gt;<br>
          &gt; &gt;<br>
          &gt; &gt; On 2/16/12 6:13 AM, HeXiaoyan wrote:<br>
          &gt; &gt;&gt; Hi all,<br>
          &gt; &gt;&gt; We have submitted a draft on capability
          advertising of CDNI,<br>
          &gt; &gt;&gt;&nbsp; <a moz-do-not-send="true"
href="http://datatracker.ietf.org/doc/draft-he-cdni-cap-info-advertising/">http://datatracker.ietf.org/doc/draft-he-cdni-cap-info-advertising/</a><br>
          &gt; &gt;&gt;<br>
          &gt; &gt;&gt; Your comments are welcome.<br>
          &gt; &gt;&gt;<br>
          &gt; &gt;&gt; Best Regards<br>
          &gt; &gt;&gt; Xiaoyan(Susan) He<br>
          &gt; &gt;&gt;<br>
          &gt; &gt;&gt; -----Original Message-----<br>
          &gt; &gt;&gt; From: <a class="moz-txt-link-abbreviated" href="mailto:internet-drafts@ietf.org">internet-drafts@ietf.org</a> [<a
            moz-do-not-send="true"
            href="mailto:internet-drafts@ietf.org">mailto:internet-drafts@ietf.org</a>]<br>
          &gt; &gt;&gt; Sent: Thursday, February 16, 2012 7:10 PM<br>
          &gt; &gt;&gt; To: <a class="moz-txt-link-abbreviated" href="mailto:hexiaoyan@huawei.com">hexiaoyan@huawei.com</a><br>
          &gt; &gt;&gt; Cc: <a class="moz-txt-link-abbreviated" href="mailto:cheng@gsta.com">cheng@gsta.com</a>; <a class="moz-txt-link-abbreviated" href="mailto:hexiaoyan@huawei.com">hexiaoyan@huawei.com</a>;
          <a class="moz-txt-link-abbreviated" href="mailto:niwei@chinamobile.com">niwei@chinamobile.com</a>;<br>
          &gt; <a class="moz-txt-link-abbreviated" href="mailto:spencer@wonderhamster.org">spencer@wonderhamster.org</a>; <a class="moz-txt-link-abbreviated" href="mailto:zhangyunfei@chinamobile.com">zhangyunfei@chinamobile.com</a><br>
          &gt; &gt;&gt; Subject: New Version Notification for<br>
          &gt; draft-he-cdni-cap-info-advertising-00.txt<br>
          &gt; &gt;&gt;<br>
          &gt; &gt;&gt; A new version of I-D,
          draft-he-cdni-cap-info-advertising-00.txt has<br>
          been<br>
          &gt; successfully submitted by Xiaoyan He and posted to the
          IETF repository.<br>
          &gt; &gt;&gt;<br>
          &gt; &gt;&gt; Filename:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
          draft-he-cdni-cap-info-advertising<br>
          &gt; &gt;&gt; Revision:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 00<br>
          &gt; &gt;&gt; Title:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Capability Information
          Advertising for CDN<br>
          &gt; Interconnection<br>
          &gt; &gt;&gt; Creation date:&nbsp;&nbsp; 2012-02-16<br>
          &gt; &gt;&gt; WG ID:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Individual Submission<br>
          &gt; &gt;&gt; Number of pages: 11<br>
          &gt; &gt;&gt;<br>
          &gt; &gt;&gt; Abstract:<br>
          &gt; &gt;&gt;&nbsp;&nbsp; This document describes protocol for
          Capability Information<br>
          Advertising<br>
          &gt; &gt;&gt; which is&nbsp;&nbsp; used to communicate capability
          information among<br>
          &gt; interconnected Content<br>
          &gt; &gt;&gt; Delivery&nbsp;&nbsp; Networks(CDNs).<br>
          &gt; &gt;&gt;<br>
          &gt; &gt;&gt;<br>
          &gt; &gt;&gt;<br>
          &gt; &gt;&gt;<br>
          &gt; &gt;&gt; The IETF Secretariat<br>
          &gt; &gt;&gt;<br>
          &gt; &gt;&gt; _______________________________________________<br>
          &gt; &gt;&gt; CDNi mailing list<br>
          &gt; &gt;&gt; <a class="moz-txt-link-abbreviated" href="mailto:CDNi@ietf.org">CDNi@ietf.org</a><br>
          &gt; &gt;&gt; <a moz-do-not-send="true"
            href="https://www.ietf.org/mailman/listinfo/cdni">https://www.ietf.org/mailman/listinfo/cdni</a><br>
          &gt; &gt;&gt;<br>
          &gt; &gt;<br>
          &gt; &gt; _______________________________________________<br>
          &gt; &gt; CDNi mailing list<br>
          &gt; &gt; <a class="moz-txt-link-abbreviated" href="mailto:CDNi@ietf.org">CDNi@ietf.org</a><br>
          &gt; &gt; <a moz-do-not-send="true"
            href="https://www.ietf.org/mailman/listinfo/cdni">https://www.ietf.org/mailman/listinfo/cdni</a><br>
          &gt;<br>
          &gt; _______________________________________________<br>
          &gt; CDNi mailing list<br>
          &gt; <a class="moz-txt-link-abbreviated" href="mailto:CDNi@ietf.org">CDNi@ietf.org</a><br>
          &gt; <a moz-do-not-send="true"
            href="https://www.ietf.org/mailman/listinfo/cdni">https://www.ietf.org/mailman/listinfo/cdni</a><br>
          <br>
        </font>
      </p>
    </blockquote>
    <br>
  </body>
</html>

--------------020608020907040308010208--

From hexiaoyan@huawei.com  Wed Feb 22 00:53:11 2012
Return-Path: <hexiaoyan@huawei.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E76621F898C for <cdni@ietfa.amsl.com>; Wed, 22 Feb 2012 00:53:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.814
X-Spam-Level: 
X-Spam-Status: No, score=-5.814 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLrx0AFNAlyn for <cdni@ietfa.amsl.com>; Wed, 22 Feb 2012 00:52:56 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id DB99221F898D for <cdni@ietf.org>; Wed, 22 Feb 2012 00:52:51 -0800 (PST)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZS001UADWQ2H@szxga05-in.huawei.com> for cdni@ietf.org; Wed, 22 Feb 2012 16:50:50 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZS00CQVDWQ5R@szxga05-in.huawei.com> for cdni@ietf.org; Wed, 22 Feb 2012 16:50:50 +0800 (CST)
Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGZ63018; Wed, 22 Feb 2012 16:50:49 +0800
Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Feb 2012 16:50:30 +0800
Received: from w36710x (10.144.4.163) by smtpscn.huawei.com (10.82.67.160) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Feb 2012 16:50:47 +0800
Date: Wed, 22 Feb 2012 16:50:46 +0800
From: HeXiaoyan <hexiaoyan@huawei.com>
In-reply-to: <4F43A7ED.1090800@cisco.com>
X-Originating-IP: [10.144.4.163]
To: 'Scott Wainner' <swainner@cisco.com>
Message-id: <00b001ccf13f$121f8130$365e8390$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: multipart/alternative; boundary="Boundary_(ID_oHXCmZECwgqyHQBMF2UfxQ)"
Content-language: zh-cn
Thread-index: Aczwo75NaISmhK72RGWWOX0y+6834gAlYcBg
X-CFilter-Loop: Reflected
References: <006001ccec9b$f5bad550$e1307ff0$@com> <4F424C27.5090106@cisco.com> <06E31573-57BE-4855-B93A-F331D3B0574D@niven-jenkins.co.uk> <005c01ccf095$a9608490$fc218db0$@com> <4F43A7ED.1090800@cisco.com>
Cc: cdni@ietf.org
Subject: Re: [CDNi] FW: New Version Notification fordraft-he-cdni-cap-info-advertising-00.txt
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Wed, 22 Feb 2012 08:53:11 -0000

--Boundary_(ID_oHXCmZECwgqyHQBMF2UfxQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Scott,

Inline, thanks.

 

Best Regards

Xiaoyan(Susan) He

From: Scott Wainner [mailto:swainner@cisco.com] 
Sent: Tuesday, February 21, 2012 10:19 PM
To: HeXiaoyan
Cc: Ben Niven-Jenkins; cdni@ietf.org
Subject: Re: [CDNi] FW: New Version Notification
fordraft-he-cdni-cap-info-advertising-00.txt

 

Xiaoyan (Susan) He,

Perhaps we need to delineate between baseline (mandatory) capabilities and
enhanced (optional) capabilities.  I'm inclined to think that the client has
communicated with the content owner's portal and chosen an asset to view.
At this point, the client capabilities have already created a filtered set
of assets that are viable for delivery.  The uCDN needs to take this initial
filter criteria into consideration.  This might include capabilities that
are baseline requirements:

     1) protocol/service type
     2) authentication method 
     3) performance criteria (guaranteed capability)
[Xiaoyan] In my understanding,  in the context of CDN/CDNI, these info
finally should be reflected as part of the metadata correlated with the
content.  To 'qualify' the delivery service , CP defines the metadata and
send this metadata to the contracted uCDN,   uCDN send it to contracted
dCDNs as well for same reason.  uCDN then use this metadata to filter the
dCDNs while doing the routing request redirection, to facilitate that, dCDN
needs to advertise capability corresponding to this metadata in advance. As
the metadata interface still has not been settled(what kind of capabilities
included in the CDNI metadata), we cannot  deduce which are baseline
requirements now but can give some and adjust based on metadata interface
later when it is settled down.
In this case, the potential set of dCDN either meet the qualification or
they do not.  From this filtered set of dCDN, we now have the ability to
assess the remaining set of dCDN based on enhanced requirements:

     1) proximity
     2) load
     3) cost
     4) performance criteria (target capability)
[Xiaoyan] These actually  are all information related to the local routing
policy of uCDN, to meet the policy, I don't think they should be kept as
optional.


Scott

On 2/21/12 7:38 AM, HeXiaoyan wrote: 

Scott and Ben,
This draft is a very primary version and the intention of it was to
stimulate the group to discuss capability advertising and thanks for your
comments. I agree with you that there is still a lot need to do to amend it.
As it seems that we still have divergence on what kind of capability info
need to be exchanged, I reconsider the way work on it, here is something
come into mind.
1. First we find and get agreement on the criteria that determine the
capability that needed to be exchanged. We can use these criteria to filter
the capability information and walk a step forward to define the semantics
of each. As the capability info is used to facility request routing, and
uCDNs may have vary internal routing policy, below is some criteria based on
the often mentioned use cases.
 * Make routing decision(selecting a dCDN) based on proximity, hence
footprint category info is needed.
 * Make routing decision based on minimal load, hence resource status
category info of dCDN is needed.  
 *Make routing decision based on capability , hence delivery
protocol/service type, user authentication method category info is needed.
 *Make routing decision based on minimal expense, hence cost category info
is needed.
 *Make routing decision based on optimal QoS, hence performance data is
needed, e.g. latency, distance, Peak Delivery Capability , Guaranteed
Minimum
  Capability.

2. Based on the above categories, evaluate the granularity of each kind of
capability info under the CDNI circumstance, convey the info in a abstract
way as you two suggested or uCDN prefer a more detail one ?Again, should be
thought as semantics definition.

3.Define syntax of the capability info mentioned above. Based on your
comments, here is an example of revision for your comments.
<CapabilityAd>
< IPVersion >IPV4</ IPVersion >
< ServiceStatus>1</ ServiceStatus >
<LoadStatus>  !--aggeragated
<MaxConnection>10000</ MaxConnection >
<UsedConnection>500</ UsedConnection>
<MaxDeliveryBW>20000</ MaxConnection >
<DeliveryBWUsage>5000</ DeliveryBWUsage >
</LoadStatus>
< Coverage>Country=A,State=B,City=C
< Performance >
< Latency > 10ms</ Latency >
</ Performance >
<Capability >
< DeliveryCap > Protocol="HTTP"
<LoadStatus>   !--per delivery protocol
<MaxConnection>2000</ MaxConnection >
<UsedConnection>1000</ UsedConnection >
</LoadStatus>
<Expense>900$/GM</ MaxConnection >
</ DeliveryCap >
< DeliveryCap >Protocol="RTSP/RTP"
..
</ DeliveryCap >
< SecurityCap > Authentication="RSA256"</ Authentication >
</ Capability >
</ Coverage >
< Coverage>Country=D,State=E,City=F
..
< Coverage>
</CapabilityAd>

4.Define the protocol.


I'll prepare a revision of this draft focusing on above step 1,2 and 3 based
on our discussion , and any other colleagues who would like to
contribute/collaborate are welcome.  

Please see my other responses inline.

Best Regards
Xiaoyan(Susan) He
> -----Original Message-----
> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of
Ben
> Niven-Jenkins
> Sent: Tuesday, February 21, 2012 5:11 AM
> To: Scott Wainner
> Cc: cdni@ietf.org
> Subject: Re: [CDNi] FW: New Version Notification for
> draft-he-cdni-cap-info-advertising-00.txt
>
> Colleagues,
>
> I'd suggest that more work needs to be done on the classes of capability
that
> need to be exchanged as well as specific capabilities that may be useful
before
> worrying too much what the actual protocol may look like.

[Xiaoyan] Agree. Will do this on the revision.

> For example two immediate classes that come to mind are slow changing Vs
> fast changing capabilities. E.g. I would expect that the version of IP and
> individual delivery protocols supported would change slowly.
>
> You might also want to think about how to convey non-binary (i.e. on/off)
> capabilities in a more abstract way as I'm not sure folks will want to
expose for
> e.g. "I can support X more connections" etc.
>
[Xiaoyan] Will think this in the revision, hope can address it.

> Ben
>
> On 20 Feb 2012, at 13:35, Scott Wainner wrote:
>
> > Xiaoyan,
> >
> > Section 3: Capability information description
> >
> > o Resource status of each downstream
> >
> >     I don't think we want the be constantly advertising changes in the
> usage percentage and available bandwidth.  The DECISION to allow or not
> allow content acquisition and the threshold upon when that decision is
made is
> likely to vary and be subject to the policies of the dCDN (e.g. allow 60%
load or
> allow 80% load).  In addition, the decision to acquire content (for
dynamic
> acquisition) is made AFTER the decision has been made to redirect the
client to
> the dCDN for content delivery.  I'm inclined to say the dCDN needs to
indicate
> to the uCDN that it should or should not redirect clients to the dCDN and
that
> decision is based on internal characteristics of the dCDN (cache-miss
rates,
> circuit loads, acquisition capacities, etc.).  This probably needs to be a
binary
> notification for each delivery service defined.

[Xiaoyan] Actually, bandwidth info of the content acquisition had been
removed in the table of section 5.1 for
Similar reason as you mentioned, I forgot synchronize to update the
description of section3. Regarding the remaining maximum
Delivery bandwidth and delivery bandwidth usage, it is relative to the
contracted value between the two CDNs, i.e. the dCDN has
Committed to provide that value of bandwidth to the uCDN. I think our
divergence is who should make the decision not to go, uCDN based
On its contracted service and its usage status of this service or the dCDN
make this decision and simply sent a binary notification to uCDN(similar
For the maximum connection and used connection)? I don't have a strong
opinion, and would like to hear other experts' view.

> > o Footprint of each Downstream CDN
> >
> >     I think the footprint needs to be defined for each type of delivery
> service.
> >
> >     I think the capacity argument above needs to be at the granularity
of
> the "footprint".  Perhaps we need to define footprint.  Is that a
continent,
> country, province, state, region, city.  At a macro level, we might
indicate that
> the dCDN can support a delivery service in all the European countries, but
the
> resources in a particular country are exhausted.  We now have a decision
to
> make.  Should the uCDN continue to re-direct clients to the dCDN?  If it
does,
> the costs assigned to the dCDN will increase as the client will be
assigned a
> distribution node in the closest available location for that service.  On
the
> contrary, the dCDN might increase the costs associated with distribution
in
> that one country such that the uCDN decides not to re-direct the client.

[Xiaoyan] I think this is relative to the syntax of the capability info, I
can try to
Do this in the revision if other colleagues in the group think this
expression is a good way.

> > o Delivery protocol supported by each Downstream CDN;
> >
> >     I think this is appropriate and should be reflected in a type of
delivery
> service.  Example: Microsoft Smooth Streaming is supported in the
following
> countries ...; Apple HTTP Live Streaming is supported in the following
cities ...;
> Adobe HTTP Dynamic Streaming is supported on the following BGP networks
...
[Xiaoyan] Same as previous one.

> >     Clearly, we need to define 'footprint'.
> >
> > o Cost information of each Downstream CDN;
> >
> >     How do we characterize costs?  Cost relative to what?  Not sure we
> want to include a currency converter in our protocol.  We might want to
define
> cost as an abstract value that can be negotiated between the uCDN and
dCDN.
> That means the dCDN internal cost metrics need to be characterized in the
> abstract cost assignment advertised to the uCDN.  That cost could be in
any
> currency.  In fact, the cost could be in latency or distance.  As long as
the
> two parties agree on how to assess cost.

[Xiaoyan] In the draft now I recommend we characterize cost based on data
size( per GB) delivered to end user
On behalf the uCDN, this is very straightforward. Could you explain more if
the cost is in an abstract value such as
Latency or distance, how can the uCDN implement the minimal expense policy?
Thanks.


> > o Authentication type to end user supported by each of the Downstream
CDN
> >
> >     I don't see this as optional.  Each dCDN is likely to expect the use
some
> authentication method between the client and the delivery node.  That
> credential may be provided by the service routing function or some other
> system.  The dCDN needs to advertise the method and where to obtain the
> credentials for each type of routing request.  I think the uCDN will need
to
> receive a routing request from its own client (using its own credentials),
> ascertain which dCDN the client should be redirected, determine the method
of
> authentication (and perhaps obtain the credential on behalf of the
client), and
> respond to the client.

[Xiaoyan]Don't quite understand what you mean here, could you explain more
on the case you thought about,
what is the purpose of dCDN advertiseWhere to obtain the credential? When I
wrote this what in my mind is for
some contents the CP may require that the CDN it delegate should
authenticate the end user, CP has sent the key to the
uCDN when they contracted, and uCDN sent it to the dCDN when they
contracted, after the dCDN receive
a user request for the contents, it will use this key and the authentication
method to authenticate the user against token conveyed in the URL.
As not all contents need this operation, it is recommend as optional.

> > 5.1 Capability information description
> >
> >     I'm less inclined to include usage percentages in any reports as the
> dCDN may be servicing other uCDN.  If we're talking about a maximum
> allowed threshold contracted between the uCDN and dCDN, then the usage
> percentage might be relative to that contracted streaming capacity.  Of
> course, percentage can be provided by simply providing the maximum
> contracted streaming capacity and the current streaming assignments in
> different categories:
> >
> >     Streams Allowed, Streams Assigned
> >     Stream Bandwidth Allowed, Stream Bandwidth Consumed (this will be
> tough with ABR)
> >     Cached Assets Allowed, Cached Assets

[Xiaoyan]Yes, it is about a maximum allowed threshold contracted between the
CDNs. I think this is relative to your first above comment.
Could you check again which you prefer, the detail value or a simply binary
go/not go notification?


> >     I also see in the table you have started defining 'Coverage' which
may
> also be described as 'Footprint'.  Probably need to define one term and
keep it
> consistent.  We then need to define the 'Coverage' or 'Footprint'
elements.
[Xiaoyan] Agree.

> >     Also need to define 'Peak Delivery Capability' or 'Guaranteed
Minimum
> Capability' for a given 'Coverage'.  Contractually, some content owners
expect
> their uCDN to provide high-quality content delivery (high-capacity
streaming)
> and want to insure the delivery networks can facilitate that type of
support.  If
> the dCDN has a capped delivery capability (either by the delivery node or
the
> access infrastructure), the uCDN needs to know that in order to 'qualify'
the
> dCDN for content delivery.

[Xiaoyan]I think this depend on the way of the delivery bandwidth
advertisement,
If it is a binary notification, then this may be needed to 'qualify' the
content delivery.
If it is the detail maximum contracted delivery bandwidth and the usage
info,
The uCDN can 'qualify' the content delivery through the bandwidth retained.

> > Scott Wainner
> >
> >
> >
> > On 2/16/12 6:13 AM, HeXiaoyan wrote:
> >> Hi all,
> >> We have submitted a draft on capability advertising of CDNI,
> >>  http://datatracker.ietf.org/doc/draft-he-cdni-cap-info-advertising/
> >>
> >> Your comments are welcome.
> >>
> >> Best Regards
> >> Xiaoyan(Susan) He
> >>
> >> -----Original Message-----
> >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> >> Sent: Thursday, February 16, 2012 7:10 PM
> >> To: hexiaoyan@huawei.com
> >> Cc: cheng@gsta.com; hexiaoyan@huawei.com; niwei@chinamobile.com;
> spencer@wonderhamster.org; zhangyunfei@chinamobile.com
> >> Subject: New Version Notification for
> draft-he-cdni-cap-info-advertising-00.txt
> >>
> >> A new version of I-D, draft-he-cdni-cap-info-advertising-00.txt has
been
> successfully submitted by Xiaoyan He and posted to the IETF repository.
> >>
> >> Filename:        draft-he-cdni-cap-info-advertising
> >> Revision:        00
> >> Title:           Capability Information Advertising for CDN
> Interconnection
> >> Creation date:   2012-02-16
> >> WG ID:           Individual Submission
> >> Number of pages: 11
> >>
> >> Abstract:
> >>   This document describes protocol for Capability Information
Advertising
> >> which is   used to communicate capability information among
> interconnected Content
> >> Delivery   Networks(CDNs).
> >>
> >>
> >>
> >>
> >> The IETF Secretariat
> >>
> >> _______________________________________________
> >> CDNi mailing list
> >> CDNi@ietf.org
> >> https://www.ietf.org/mailman/listinfo/cdni
> >>
> >
> > _______________________________________________
> > CDNi mailing list
> > CDNi@ietf.org
> > https://www.ietf.org/mailman/listinfo/cdni
>
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni

 


--Boundary_(ID_oHXCmZECwgqyHQBMF2UfxQ)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><title>RE: [CDNi] FW: New Version Notification fordraft-he-cdni-cap-info-advertising-00.txt</title><style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=white lang=ZH-CN link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span lang=EN-US style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D'>Scott,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D'>Inline, thanks.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div><p class=MsoNormal><span lang=EN-US style='font-size:10.0pt;font-family:SimSun;color:#1F497D'>Best Regards</span><span lang=EN-US style='font-family:SimSun;color:#1F497D'><o:p></o:p></span></p></div><p class=MsoNormal><span lang=EN-US style='font-size:10.0pt;font-family:SimSun;color:#1F497D'>Xiaoyan(Susan) He</span><span lang=EN-US style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><div style='b
 order:no
 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> Scott Wainner [mailto:swainner@cisco.com] <br><b>Sent:</b> Tuesday, February 21, 2012 10:19 PM<br><b>To:</b> HeXiaoyan<br><b>Cc:</b> Ben Niven-Jenkins; cdni@ietf.org<br><b>Subject:</b> Re: [CDNi] FW: New Version Notification fordraft-he-cdni-cap-info-advertising-00.txt<o:p></o:p></span></p></div></div><p class=MsoNormal><span lang=EN-US><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:10.0pt'>Xiaoyan (Susan) He</span><span lang=EN-US>,<br><br>Perhaps we need to delineate between baseline (mandatory) capabilities and enhanced (optional) capabilities.&nbsp; I'm inclined to think that the client has communic
 ated wit
tal and chosen an asset to view.&nbsp; At this point, the client capabilities have already created a filtered set of assets that are viable for delivery.&nbsp; The uCDN needs to take this initial filter criteria into consideration.&nbsp; This might include capabilities that are baseline requirements:<br><br>&nbsp;&nbsp;&nbsp;&nbsp; 1) protocol/service type<br>&nbsp;&nbsp;&nbsp;&nbsp; 2) authentication method <br>&nbsp;&nbsp;&nbsp;&nbsp; 3) performance criteria (guaranteed capability)<br></span><span lang=EN-US style='color:#1F497D'>[Xiaoyan] In my understanding, &nbsp;in the context of CDN/CDNI, these info finally should be reflected as part of the metadata correlated with the content. &nbsp;To &#8216;qualify&#8217; the delivery service , CP defines the metadata and send this metadata to the contracted uCDN, &nbsp;&nbsp;uCDN send it to contracted dCDNs as well for same reason. &nbsp;uCDN then use this metadata to filter the dCDNs while doing the routing request redirection, t
 o facili
advertise capability corresponding to this metadata in advance. As the metadata interface still has not been settled(what kind of capabilities included in the CDNI metadata), we cannot &nbsp;deduce which are baseline requirements now but can give some and adjust based on metadata interface later when it is settled down.</span><span lang=EN-US><br>In this case, the potential set of dCDN either meet the qualification or they do not.&nbsp; From this filtered set of dCDN, we now have the ability to assess the remaining set of dCDN based on enhanced requirements:<br><br>&nbsp;&nbsp;&nbsp;&nbsp; 1) proximity<br>&nbsp;&nbsp;&nbsp;&nbsp; 2) load<br>&nbsp;&nbsp;&nbsp;&nbsp; 3) cost<br>&nbsp;&nbsp;&nbsp;&nbsp; 4) performance criteria (target capability)<br></span><span lang=EN-US style='color:#1F497D'>[Xiaoyan] These actually &nbsp;are all information related to the local routing policy of uCDN, to meet the policy, I don&#8217;t think they should be kept as optional.<o:p></o:p></span><
 /p><p cl
EN-US><br>Scott<br><br>On 2/21/12 7:38 AM, HeXiaoyan wrote: <o:p></o:p></span></p><p style='margin-bottom:12.0pt'><span lang=EN-US style='font-size:10.0pt'>Scott and Ben,<br>This draft is a very primary version and the intention of it was to<br>stimulate the group to discuss capability advertising and thanks for your<br>comments. I agree with you that there is still a lot need to do to amend it.<br>As it seems that we still have divergence on what kind of capability info<br>need to be exchanged, I reconsider the way work on it, here is something<br>come into mind.<br>1. First we find and get agreement on the criteria that determine the<br>capability that needed to be exchanged. We can use these criteria to filter<br>the capability information and walk a step forward to define the semantics<br>of each. As the capability info is used to facility request routing, and<br>uCDNs may have vary internal routing policy, below is some criteria based on<br>the often mentioned use cases.
 <br>&nbs
(selecting a dCDN) based on proximity, hence<br>footprint category info is needed.<br>&nbsp;* Make routing decision based on minimal load, hence resource status<br>category info of dCDN is needed.&nbsp;&nbsp;<br>&nbsp;*Make routing decision based on capability , hence delivery<br>protocol/service type, user authentication method category info is needed.<br>&nbsp;*Make routing decision based on minimal expense, hence cost category info<br>is needed.<br>&nbsp;*Make routing decision based on optimal QoS, hence performance data is<br>needed, e.g. latency, distance, Peak Delivery Capability , Guaranteed<br>Minimum<br>&nbsp; Capability.<br><br>2. Based on the above categories, evaluate the granularity of each kind of<br>capability info under the CDNI circumstance, convey the info in a abstract<br>way as you two suggested or uCDN prefer a more detail one ?Again, should be<br>thought as semantics definition.<br><br>3.Define syntax of the capability info mentioned above. Based on your
 <br>comm
of revision for your comments.<br>&lt;CapabilityAd&gt;<br>&lt; IPVersion &gt;IPV4&lt;/ IPVersion &gt;<br>&lt; ServiceStatus&gt;1&lt;/ ServiceStatus &gt;<br>&lt;LoadStatus&gt;&nbsp; !--aggeragated<br>&lt;MaxConnection&gt;10000&lt;/ MaxConnection &gt;<br>&lt;UsedConnection&gt;500&lt;/ UsedConnection&gt;<br>&lt;MaxDeliveryBW&gt;20000&lt;/ MaxConnection &gt;<br>&lt;DeliveryBWUsage&gt;5000&lt;/ DeliveryBWUsage &gt;<br>&lt;/LoadStatus&gt;<br>&lt; Coverage&gt;Country=A,State=B,City=C<br>&lt; Performance &gt;<br>&lt; Latency &gt; 10ms&lt;/ Latency &gt;<br>&lt;/ Performance &gt;<br>&lt;Capability &gt;<br>&lt; DeliveryCap &gt; Protocol=&quot;HTTP&quot;<br>&lt;LoadStatus&gt;&nbsp;&nbsp; !--per delivery protocol<br>&lt;MaxConnection&gt;2000&lt;/ MaxConnection &gt;<br>&lt;UsedConnection&gt;1000&lt;/ UsedConnection &gt;<br>&lt;/LoadStatus&gt;<br>&lt;Expense&gt;900$/GM&lt;/ MaxConnection &gt;<br>&lt;/ DeliveryCap &gt;<br>&lt; DeliveryCap &gt;Protocol=&quot;RTSP/RTP&quot;<br>..<br>&lt;/ Deli
 veryCap 
&gt; Authentication=&quot;RSA256&quot;&lt;/ Authentication &gt;<br>&lt;/ Capability &gt;<br>&lt;/ Coverage &gt;<br>&lt; Coverage&gt;Country=D,State=E,City=F<br>..<br>&lt; Coverage&gt;<br>&lt;/CapabilityAd&gt;<br><br>4.Define the protocol.<br><br><br>I'll prepare a revision of this draft focusing on above step 1,2 and 3 based<br>on our discussion , and any other colleagues who would like to<br>contribute/collaborate are welcome.&nbsp;&nbsp;<br><br>Please see my other responses inline.<br><br>Best Regards<br>Xiaoyan(Susan) He<br>&gt; -----Original Message-----<br>&gt; From: <a href="mailto:cdni-bounces@ietf.org">cdni-bounces@ietf.org</a> [<a href="mailto:cdni-bounces@ietf.org">mailto:cdni-bounces@ietf.org</a>] On Behalf Of<br>Ben<br>&gt; Niven-Jenkins<br>&gt; Sent: Tuesday, February 21, 2012 5:11 AM<br>&gt; To: Scott Wainner<br>&gt; Cc: <a href="mailto:cdni@ietf.org">cdni@ietf.org</a><br>&gt; Subject: Re: [CDNi] FW: New Version Notification for<br>&gt; draft-he-cdni-cap-info-ad
 vertisin
Colleagues,<br>&gt;<br>&gt; I'd suggest that more work needs to be done on the classes of capability<br>that<br>&gt; need to be exchanged as well as specific capabilities that may be useful<br>before<br>&gt; worrying too much what the actual protocol may look like.<br><br>[Xiaoyan] Agree. Will do this on the revision.<br><br>&gt; For example two immediate classes that come to mind are slow changing Vs<br>&gt; fast changing capabilities. E.g. I would expect that the version of IP and<br>&gt; individual delivery protocols supported would change slowly.<br>&gt;<br>&gt; You might also want to think about how to convey non-binary (i.e. on/off)<br>&gt; capabilities in a more abstract way as I'm not sure folks will want to<br>expose for<br>&gt; e.g. &quot;I can support X more connections&quot; etc.<br>&gt;<br>[Xiaoyan] Will think this in the revision, hope can address it.<br><br>&gt; Ben<br>&gt;<br>&gt; On 20 Feb 2012, at 13:35, Scott Wainner wrote:<br>&gt;<br>&gt; &gt; Xiaoyan,<br>
 &gt; &gt
 Capability information description<br>&gt; &gt;<br>&gt; &gt; o Resource status of each downstream<br>&gt; &gt;<br>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; I don't think we want the be constantly advertising changes in the<br>&gt; usage percentage and available bandwidth.&nbsp; The DECISION to allow or not<br>&gt; allow content acquisition and the threshold upon when that decision is<br>made is<br>&gt; likely to vary and be subject to the policies of the dCDN (e.g. allow 60%<br>load or<br>&gt; allow 80% load).&nbsp; In addition, the decision to acquire content (for<br>dynamic<br>&gt; acquisition) is made AFTER the decision has been made to redirect the<br>client to<br>&gt; the dCDN for content delivery.&nbsp; I'm inclined to say the dCDN needs to<br>indicate<br>&gt; to the uCDN that it should or should not redirect clients to the dCDN and<br>that<br>&gt; decision is based on internal characteristics of the dCDN (cache-miss<br>rates,<br>&gt; circuit loads, acquisition capacities, etc
 .).&nbsp
be a<br>binary<br>&gt; notification for each delivery service defined.<br><br>[Xiaoyan] Actually, bandwidth info of the content acquisition had been<br>removed in the table of section 5.1 for<br>Similar reason as you mentioned, I forgot synchronize to update the<br>description of section3. Regarding the remaining maximum<br>Delivery bandwidth and delivery bandwidth usage, it is relative to the<br>contracted value between the two CDNs, i.e. the dCDN has<br>Committed to provide that value of bandwidth to the uCDN. I think our<br>divergence is who should make the decision not to go, uCDN based<br>On its contracted service and its usage status of this service or the dCDN<br>make this decision and simply sent a binary notification to uCDN(similar<br>For the maximum connection and used connection)? I don't have a strong<br>opinion, and would like to hear other experts' view.<br><br>&gt; &gt; o Footprint of each Downstream CDN<br>&gt; &gt;<br>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; I thin
 k the fo
ed for each type of delivery<br>&gt; service.<br>&gt; &gt;<br>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; I think the capacity argument above needs to be at the granularity<br>of<br>&gt; the &quot;footprint&quot;.&nbsp; Perhaps we need to define footprint.&nbsp; Is that a<br>continent,<br>&gt; country, province, state, region, city.&nbsp; At a macro level, we might<br>indicate that<br>&gt; the dCDN can support a delivery service in all the European countries, but<br>the<br>&gt; resources in a particular country are exhausted.&nbsp; We now have a decision<br>to<br>&gt; make.&nbsp; Should the uCDN continue to re-direct clients to the dCDN?&nbsp; If it<br>does,<br>&gt; the costs assigned to the dCDN will increase as the client will be<br>assigned a<br>&gt; distribution node in the closest available location for that service.&nbsp; On<br>the<br>&gt; contrary, the dCDN might increase the costs associated with distribution<br>in<br>&gt; that one country such that the uCDN decides not to re-d
 irect th
] I think this is relative to the syntax of the capability info, I<br>can try to<br>Do this in the revision if other colleagues in the group think this<br>expression is a good way.<br><br>&gt; &gt; o Delivery protocol supported by each Downstream CDN;<br>&gt; &gt;<br>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; I think this is appropriate and should be reflected in a type of<br>delivery<br>&gt; service.&nbsp; Example: Microsoft Smooth Streaming is supported in the<br>following<br>&gt; countries ...; Apple HTTP Live Streaming is supported in the following<br>cities ...;<br>&gt; Adobe HTTP Dynamic Streaming is supported on the following BGP networks<br>...<br>[Xiaoyan] Same as previous one.<br><br>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Clearly, we need to define 'footprint'.<br>&gt; &gt;<br>&gt; &gt; o Cost information of each Downstream CDN;<br>&gt; &gt;<br>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; How do we characterize costs?&nbsp; Cost relative to what?&nbsp; Not sure we<br>&gt; want to include a 
 currency
l.&nbsp; We might want to<br>define<br>&gt; cost as an abstract value that can be negotiated between the uCDN and<br>dCDN.<br>&gt; That means the dCDN internal cost metrics need to be characterized in the<br>&gt; abstract cost assignment advertised to the uCDN.&nbsp; That cost could be in<br>any<br>&gt; currency.&nbsp; In fact, the cost could be in latency or distance.&nbsp; As long as<br>the<br>&gt; two parties agree on how to assess cost.<br><br>[Xiaoyan] In the draft now I recommend we characterize cost based on data<br>size( per GB) delivered to end user<br>On behalf the uCDN, this is very straightforward. Could you explain more if<br>the cost is in an abstract value such as<br>Latency or distance, how can the uCDN implement the minimal expense policy?<br>Thanks.<br><br><br>&gt; &gt; o Authentication type to end user supported by each of the Downstream<br>CDN<br>&gt; &gt;<br>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; I don't see this as optional.&nbsp; Each dCDN is likely to expec
 t the us
ication method between the client and the delivery node.&nbsp; That<br>&gt; credential may be provided by the service routing function or some other<br>&gt; system.&nbsp; The dCDN needs to advertise the method and where to obtain the<br>&gt; credentials for each type of routing request.&nbsp; I think the uCDN will need<br>to<br>&gt; receive a routing request from its own client (using its own credentials),<br>&gt; ascertain which dCDN the client should be redirected, determine the method<br>of<br>&gt; authentication (and perhaps obtain the credential on behalf of the<br>client), and<br>&gt; respond to the client.<br><br>[Xiaoyan]Don't quite understand what you mean here, could you explain more<br>on the case you thought about,<br>what is the purpose of dCDN advertiseWhere to obtain the credential? When I<br>wrote this what in my mind is for<br>some contents the CP may require that the CDN it delegate should<br>authenticate the end user, CP has sent the key to the<br>uCDN when
  they co
t to the dCDN when they<br>contracted, after the dCDN receive<br>a user request for the contents, it will use this key and the authentication<br>method to authenticate the user against token conveyed in the URL.<br>As not all contents need this operation, it is recommend as optional.<br><br>&gt; &gt; 5.1 Capability information description<br>&gt; &gt;<br>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; I'm less inclined to include usage percentages in any reports as the<br>&gt; dCDN may be servicing other uCDN.&nbsp; If we're talking about a maximum<br>&gt; allowed threshold contracted between the uCDN and dCDN, then the usage<br>&gt; percentage might be relative to that contracted streaming capacity.&nbsp; Of<br>&gt; course, percentage can be provided by simply providing the maximum<br>&gt; contracted streaming capacity and the current streaming assignments in<br>&gt; different categories:<br>&gt; &gt;<br>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Streams Allowed, Streams Assigned<br>&gt; &gt;&nbsp
 ;&nbsp;&
dth Allowed, Stream Bandwidth Consumed (this will be<br>&gt; tough with ABR)<br>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Cached Assets Allowed, Cached Assets<br><br>[Xiaoyan]Yes, it is about a maximum allowed threshold contracted between the<br>CDNs. I think this is relative to your first above comment.<br>Could you check again which you prefer, the detail value or a simply binary<br>go/not go notification?<br><br><br>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; I also see in the table you have started defining 'Coverage' which<br>may<br>&gt; also be described as 'Footprint'.&nbsp; Probably need to define one term and<br>keep it<br>&gt; consistent.&nbsp; We then need to define the 'Coverage' or 'Footprint'<br>elements.<br>[Xiaoyan] Agree.<br><br>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Also need to define 'Peak Delivery Capability' or 'Guaranteed<br>Minimum<br>&gt; Capability' for a given 'Coverage'.&nbsp; Contractually, some content owners<br>expect<br>&gt; their uCDN to provide high-quality content
  deliver
ming)<br>&gt; and want to insure the delivery networks can facilitate that type of<br>support.&nbsp; If<br>&gt; the dCDN has a capped delivery capability (either by the delivery node or<br>the<br>&gt; access infrastructure), the uCDN needs to know that in order to 'qualify'<br>the<br>&gt; dCDN for content delivery.<br><br>[Xiaoyan]I think this depend on the way of the delivery bandwidth<br>advertisement,<br>If it is a binary notification, then this may be needed to 'qualify' the<br>content delivery.<br>If it is the detail maximum contracted delivery bandwidth and the usage<br>info,<br>The uCDN can 'qualify' the content delivery through the bandwidth retained.<br><br>&gt; &gt; Scott Wainner<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt; On 2/16/12 6:13 AM, HeXiaoyan wrote:<br>&gt; &gt;&gt; Hi all,<br>&gt; &gt;&gt; We have submitted a draft on capability advertising of CDNI,<br>&gt; &gt;&gt;&nbsp; <a href="http://datatracker.ietf.org/doc/draft-he-cdni-cap-info-advertising/
 ">http:/
/draft-he-cdni-cap-info-advertising/</a><br>&gt; &gt;&gt;<br>&gt; &gt;&gt; Your comments are welcome.<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; Best Regards<br>&gt; &gt;&gt; Xiaoyan(Susan) He<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; -----Original Message-----<br>&gt; &gt;&gt; From: <a href="mailto:internet-drafts@ietf.org">internet-drafts@ietf.org</a> [<a href="mailto:internet-drafts@ietf.org">mailto:internet-drafts@ietf.org</a>]<br>&gt; &gt;&gt; Sent: Thursday, February 16, 2012 7:10 PM<br>&gt; &gt;&gt; To: <a href="mailto:hexiaoyan@huawei.com">hexiaoyan@huawei.com</a><br>&gt; &gt;&gt; Cc: <a href="mailto:cheng@gsta.com">cheng@gsta.com</a>; <a href="mailto:hexiaoyan@huawei.com">hexiaoyan@huawei.com</a>; <a href="mailto:niwei@chinamobile.com">niwei@chinamobile.com</a>;<br>&gt; <a href="mailto:spencer@wonderhamster.org">spencer@wonderhamster.org</a>; <a href="mailto:zhangyunfei@chinamobile.com">zhangyunfei@chinamobile.com</a><br>&gt; &gt;&gt; Subject: New Version Notification for<br>&gt; dra
 ft-he-cd
0.txt<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; A new version of I-D, draft-he-cdni-cap-info-advertising-00.txt has<br>been<br>&gt; successfully submitted by Xiaoyan He and posted to the IETF repository.<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; Filename:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; draft-he-cdni-cap-info-advertising<br>&gt; &gt;&gt; Revision:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 00<br>&gt; &gt;&gt; Title:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Capability Information Advertising for CDN<br>&gt; Interconnection<br>&gt; &gt;&gt; Creation date:&nbsp;&nbsp; 2012-02-16<br>&gt; &gt;&gt; WG ID:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Individual Submission<br>&gt; &gt;&gt; Number of pages: 11<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; Abstract:<br>&gt; &gt;&gt;&nbsp;&nbsp; This document describes protocol for Capability Information<br>Advertising<br>&gt; &gt;&gt; which is&nbsp;&nbsp; used to communicate capability information among<br>&gt; interconn
 ected Co
livery&nbsp;&nbsp; Networks(CDNs).<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; The IETF Secretariat<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; _______________________________________________<br>&gt; &gt;&gt; CDNi mailing list<br>&gt; &gt;&gt; <a href="mailto:CDNi@ietf.org">CDNi@ietf.org</a><br>&gt; &gt;&gt; <a href="https://www.ietf.org/mailman/listinfo/cdni">https://www.ietf.org/mailman/listinfo/cdni</a><br>&gt; &gt;&gt;<br>&gt; &gt;<br>&gt; &gt; _______________________________________________<br>&gt; &gt; CDNi mailing list<br>&gt; &gt; <a href="mailto:CDNi@ietf.org">CDNi@ietf.org</a><br>&gt; &gt; <a href="https://www.ietf.org/mailman/listinfo/cdni">https://www.ietf.org/mailman/listinfo/cdni</a><br>&gt;<br>&gt; _______________________________________________<br>&gt; CDNi mailing list<br>&gt; <a href="mailto:CDNi@ietf.org">CDNi@ietf.org</a><br>&gt; <a href="https://www.ietf.org/mailman/listinfo/cdni">https://www.ietf.org/mailman/listinfo/cdni</
 a></span
o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p>&nbsp;</o:p></span></p></div></div></body></html>

--Boundary_(ID_oHXCmZECwgqyHQBMF2UfxQ)--

From flefauch@cisco.com  Wed Feb 22 08:31:26 2012
Return-Path: <flefauch@cisco.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECBE21F87DD for <cdni@ietfa.amsl.com>; Wed, 22 Feb 2012 08:31:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.057
X-Spam-Level: 
X-Spam-Status: No, score=-10.057 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucHPMkh2joUt for <cdni@ietfa.amsl.com>; Wed, 22 Feb 2012 08:31:21 -0800 (PST)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2B74C21F87AD for <cdni@ietf.org>; Wed, 22 Feb 2012 08:31:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=12136; q=dns/txt; s=iport; t=1329928281; x=1331137881; h=from:mime-version:subject:date:in-reply-to:to:references: message-id; bh=wqXo8aEBUlIgxLt5ZQaTaMPWAJa/hJIrgfOeZ5dK0Q0=; b=BdxutB2rg9863qq8QIk388Nrv0mZVfqzIgctdnGSVBp8NyRqZ5RzR0xn K85GQSGVO+ZlwUt+2A3S/0laPhBiyfrOdEZtYKoTWTuWR1ySCjuvgtJWi 1iTWSWz1EJy26/PMNyAGyOiQ3h+bigSCcWW6lxw/lB+2v5nlf8OtDEkj4 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FAKoXRU+Q/khM/2dsb2JhbABDqVcBiGyBB4FzAQEBAwEBAQEPAVsQCwsRAwECKAcnHwkIGQkSB4dfCZkUAZ8IjEkHAgUCAQcBChYUFAsRCAEMhFsZAwoLCyUCEBAMBggSAQUGgk1jBJU4km6BVBA
X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208,217";a="66817587"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 22 Feb 2012 16:31:19 +0000
Received: from ams-flefauch-8716.cisco.com (ams-flefauch-8716.cisco.com [10.55.161.199]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1MGVJto004813 for <cdni@ietf.org>; Wed, 22 Feb 2012 16:31:19 GMT
From: Francois Le Faucheur <flefauch@cisco.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-328--566224493
Date: Wed, 22 Feb 2012 17:31:33 +0100
In-Reply-To: <4715AB6C-6566-4E09-BCE1-1B7F5C604C80@cisco.com>
To: cdni@ietf.org
References: <8E09C72DBC577D489F13A71228C0B7BF031722A3@ftrdmel0.rd.francetelecom.fr> <4715AB6C-6566-4E09-BCE1-1B7F5C604C80@cisco.com>
Message-Id: <562ECB2F-4F36-4AF1-AD30-EEEC9146DCFC@cisco.com>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [CDNi] Working Group Last Call on draft-ietf-cdni-use-cases-03.txt
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Wed, 22 Feb 2012 16:31:26 -0000

--Apple-Mail-328--566224493
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Folks,

The Last Call period for draft-ietf-cdni-use-cases has now closed, but =
we haven't received any comments, so we'll extend it until 2 March.
=20
As per the show of hand at the last IETF meeting, quite a few of you are =
familiar with this document. So can you please have a look at the latest =
version and pass on your comments, or a brief statement like "I think =
it's ready" or "I think it needs rework before going further", so we can =
get explicit confirmation that the document is ready (or not) from the =
WG perspective.

Thanks

Francois & Rich


On 30 Jan 2012, at 14:37, Francois Le Faucheur wrote:

> All,
>=20
> This is the start of a two-week working group last call on =
draft-ietf-cdni-use-cases-03.txt:
> https://datatracker.ietf.org/doc/draft-ietf-cdni-use-cases/
>=20
> This working group last call will end 13 Feb 2012. Please send your =
comments to the CDNI mailing list.
>=20
> Francois & Rich
>=20
>=20
> Begin forwarded message:
>=20
>> From: <gilles.bertrand@orange.com>
>> Date: 30 January 2012 12:12:50 CET
>> To: <cdni@ietf.org>
>> Subject: [CDNi] TR: I-D Action: draft-ietf-cdni-use-cases-03.txt
>>=20
>> Hi,
>>=20
>> We have submitted a revision addressing Kent's comments.
>>=20
>> =
http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-ietf-=
cdni-use-cases-02.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-cdni-use-=
cases-03.txt=20
>>=20
>> Best regards,
>>=20
>> Gilles
>>=20
>>=20
>>=20
>>=20
>> -----Message d'origine-----
>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part =
de internet-drafts@ietf.org
>> Envoy=E9 : lundi 30 janvier 2012 12:07
>> =C0 : i-d-announce@ietf.org
>> Cc : cdni@ietf.org
>> Objet : [CDNi] I-D Action: draft-ietf-cdni-use-cases-03.txt
>>=20
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories. This draft is a work item of the Content Delivery Networks =
Interconnection Working Group of the IETF.
>>=20
>> 	Title           : Use Cases for Content Delivery Network =
Interconnection
>> 	Author(s)       : Gilles Bertrand
>>                          Stephan Emile
>>                          Grant Watson
>>                          Trevor Burbridge
>>                          Philip Eardley
>>                          Kevin Ma
>> 	Filename        : draft-ietf-cdni-use-cases-03.txt
>> 	Pages           : 18
>> 	Date            : 2012-01-30
>>=20
>>   Content Delivery Networks (CDNs) are commonly used for improving =
the
>>   End User experience of a content delivery service, at a reasonable
>>   cost.  This document outlines real world use cases (not technical
>>   solutions) for interconnecting CDNs.  It focuses on use cases that
>>   correspond to identified industry needs and that are expected to be
>>   realized once a CDN Interconnection (CDNI) solution is available.
>>   This document can be used to provide guidance to the CDNI WG about
>>   the interconnection arrangements to be supported and to validate =
the
>>   requirements of the various CDNI interfaces.
>>=20
>>=20
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-03.txt
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-03.txt
>>=20
>> _______________________________________________
>> CDNi mailing list
>> CDNi@ietf.org
>> https://www.ietf.org/mailman/listinfo/cdni
>> _______________________________________________
>> CDNi mailing list
>> CDNi@ietf.org
>> https://www.ietf.org/mailman/listinfo/cdni
>=20
>=20
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni



--Apple-Mail-328--566224493
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
">Folks,<div><br><div>The Last Call period =
for&nbsp;draft-ietf-cdni-use-cases has now closed, but we haven't =
received any&nbsp;comments, so we'll extend it until 2 =
March.</div><div>&nbsp;</div><div>As per the show of hand at the last =
IETF meeting, quite a few of you are familiar with this document. So can =
you please have a look at the latest version and pass on your comments, =
or a brief statement like "I think it's ready" or "I think it needs =
rework before going further", so we can get explicit confirmation that =
the document is ready (or not) from the WG =
perspective.</div><div><br></div><div>Thanks</div><div><br></div><div>Fran=
cois &amp; Rich<br><div><br></div><div><br><div><div>On 30 Jan 2012, at =
14:37, Francois Le Faucheur wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div>All,<br><br>This is the =
start of a two-week working group last call on =
draft-ietf-cdni-use-cases-03.txt:<br><a =
href=3D"https://datatracker.ietf.org/doc/draft-ietf-cdni-use-cases/">https=
://datatracker.ietf.org/doc/draft-ietf-cdni-use-cases/</a><br><br>This =
working group last call will end 13 Feb 2012. Please send your comments =
to the CDNI mailing list.<br><br>Francois &amp; =
Rich</div><div><br></div><div><br><div>Begin forwarded message:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;"><span style=3D"font-family:'Helvetica'; =
font-size:medium; color:rgba(0, 0, 0, 1);"><b>From: </b></span><span =
style=3D"font-family:'Helvetica'; font-size:medium;">&lt;<a =
href=3D"mailto:gilles.bertrand@orange.com">gilles.bertrand@orange.com</a>&=
gt;<br></span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px;"><span =
style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, =
1);"><b>Date: </b></span><span style=3D"font-family:'Helvetica'; =
font-size:medium;">30 January 2012 12:12:50 CET<br></span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;"><span style=3D"font-family:'Helvetica'; =
font-size:medium; color:rgba(0, 0, 0, 1);"><b>To: </b></span><span =
style=3D"font-family:'Helvetica'; font-size:medium;">&lt;<a =
href=3D"mailto:cdni@ietf.org">cdni@ietf.org</a>&gt;<br></span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;"><span style=3D"font-family:'Helvetica'; =
font-size:medium; color:rgba(0, 0, 0, 1);"><b>Subject: </b></span><span =
style=3D"font-family:'Helvetica'; font-size:medium;"><b>[CDNi] TR:  I-D =
Action: =
draft-ietf-cdni-use-cases-03.txt</b><br></span></div><br><div>Hi,<br><br>W=
e have submitted a revision addressing Kent's comments.<br><br><a =
href=3D"http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/dra=
ft-ietf-cdni-use-cases-02.txt&amp;url2=3Dhttp://tools.ietf.org/id/draft-ie=
tf-cdni-use-cases-03.txt">http://tools.ietf.org//rfcdiff?url1=3Dhttp://too=
ls.ietf.org/id/draft-ietf-cdni-use-cases-02.txt&amp;url2=3Dhttp://tools.ie=
tf.org/id/draft-ietf-cdni-use-cases-03.txt</a> <br><br>Best =
regards,<br><br>Gilles<br><br><br><br><br>-----Message =
d'origine-----<br>De&nbsp;: <a =
href=3D"mailto:cdni-bounces@ietf.org">cdni-bounces@ietf.org</a> =
[mailto:cdni-bounces@ietf.org] De la part de <a =
href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org</a><br>E=
nvoy=E9&nbsp;: lundi 30 janvier 2012 12:07<br>=C0&nbsp;: <a =
href=3D"mailto:i-d-announce@ietf.org">i-d-announce@ietf.org</a><br>Cc&nbsp=
;: <a href=3D"mailto:cdni@ietf.org">cdni@ietf.org</a><br>Objet&nbsp;: =
[CDNi] I-D Action: draft-ietf-cdni-use-cases-03.txt<br><br><br>A New =
Internet-Draft is available from the on-line Internet-Drafts =
directories. This draft is a work item of the Content Delivery Networks =
Interconnection Working Group of the IETF.<br><br><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Title =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: Use Cases =
for Content Delivery Network Interconnection<br><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Author(s) =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: Gilles Bertrand<br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Stephan Emile<br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Grant Watson<br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Trevor Burbridge<br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Philip Eardley<br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Kevin Ma<br><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>Filename &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: =
draft-ietf-cdni-use-cases-03.txt<br><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>Pages =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: =
18<br><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>Date =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: =
2012-01-30<br><br> &nbsp;&nbsp;Content Delivery Networks (CDNs) are =
commonly used for improving the<br> &nbsp;&nbsp;End User experience of a =
content delivery service, at a reasonable<br> &nbsp;&nbsp;cost. =
&nbsp;This document outlines real world use cases (not technical<br> =
&nbsp;&nbsp;solutions) for interconnecting CDNs. &nbsp;It focuses on use =
cases that<br> &nbsp;&nbsp;correspond to identified industry needs and =
that are expected to be<br> &nbsp;&nbsp;realized once a CDN =
Interconnection (CDNI) solution is available.<br> &nbsp;&nbsp;This =
document can be used to provide guidance to the CDNI WG about<br> =
&nbsp;&nbsp;the interconnection arrangements to be supported and to =
validate the<br> &nbsp;&nbsp;requirements of the various CDNI =
interfaces.<br><br><br>A URL for this Internet-Draft is:<br><a =
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-03.t=
xt">http://www.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-03.txt</=
a><br><br>Internet-Drafts are also available by anonymous FTP at:<br><a =
href=3D"ftp://ftp.ietf.org/internet-drafts/">ftp://ftp.ietf.org/internet-d=
rafts/</a><br><br>This Internet-Draft can be retrieved =
at:<br>ftp://ftp.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-03.txt=
<br><br>_______________________________________________<br>CDNi mailing =
list<br>CDNi@ietf.org<br>https://www.ietf.org/mailman/listinfo/cdni<br>___=
____________________________________________<br>CDNi mailing =
list<br>CDNi@ietf.org<br>https://www.ietf.org/mailman/listinfo/cdni<br></d=
iv></blockquote></div><br><div apple-content-edited=3D"true">
=
<div></div></div><br></div>_______________________________________________=
<br>CDNi mailing list<br><a =
href=3D"mailto:CDNi@ietf.org">CDNi@ietf.org</a><br>https://www.ietf.org/ma=
ilman/listinfo/cdni<br></blockquote></div><br><div =
apple-content-edited=3D"true">
<div><span class=3D"Apple-style-span" style=3D"font-family: Times; =
"></span></div></div><br></div></div></div></body></html>=

--Apple-Mail-328--566224493--

From flefauch@cisco.com  Wed Feb 22 08:59:50 2012
Return-Path: <flefauch@cisco.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CEE21F8659 for <cdni@ietfa.amsl.com>; Wed, 22 Feb 2012 08:59:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.079
X-Spam-Level: 
X-Spam-Status: No, score=-10.079 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkMV8Uw2ag+q for <cdni@ietfa.amsl.com>; Wed, 22 Feb 2012 08:59:46 -0800 (PST)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 401DE21F85CD for <cdni@ietf.org>; Wed, 22 Feb 2012 08:59:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=6115; q=dns/txt; s=iport; t=1329929982; x=1331139582; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=CYphrTSNnh5U9QJCOqokqWivCvQSzOToXRhpz6JSjHE=; b=YcULRud8kF6R0LpIOCcv2kJij0/WTQgMPpSbWBKZrkQSH3HsZ0dyu8Wl 1BYgoRiID7z/D6LcX0zyHB+sNX5S0DHjA2+vkgpIdEb9rKVsSmo8NcrL0 VyFnoaoLa7g7P2YqwK2hKHbpdNqkUlzUeU1nUmEls557RWWq1IoS5+2NJ Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAK8eRU+Q/khN/2dsb2JhbABDskSBB4FzAQEBAwEBAQEPAVsLBQsLEQMBAgEnBycfCQgZCRIHh18JmQ0BnwmMUAIFAgESBhABCAsDBAsCCwIFCggBDIU8AhAQDAYIEgEFBoJNYwSVOJJugVQQ
X-IronPort-AV: E=Sophos;i="4.73,465,1325462400"; d="scan'208";a="66820824"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 22 Feb 2012 16:59:41 +0000
Received: from ams-flefauch-8716.cisco.com (ams-flefauch-8716.cisco.com [10.55.161.199]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1MGxeIS011896; Wed, 22 Feb 2012 16:59:40 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: Francois Le Faucheur <flefauch@cisco.com>
In-Reply-To: <562ECB2F-4F36-4AF1-AD30-EEEC9146DCFC@cisco.com>
Date: Wed, 22 Feb 2012 17:59:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <088BA1E4-8C19-4A43-B0EE-BBCF6D599BF0@cisco.com>
References: <8E09C72DBC577D489F13A71228C0B7BF031722A3@ftrdmel0.rd.francetelecom.fr> <4715AB6C-6566-4E09-BCE1-1B7F5C604C80@cisco.com> <562ECB2F-4F36-4AF1-AD30-EEEC9146DCFC@cisco.com>
To: draft-ietf-cdni-use-cases@tools.ietf.org
X-Mailer: Apple Mail (2.1084)
Cc: cdni@ietf.org
Subject: Re: [CDNi] Working Group Last Call on draft-ietf-cdni-use-cases-03.txt
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Wed, 22 Feb 2012 16:59:50 -0000

To cdni-use-cases authors,

I had another look and here are a few additional comments:

1) references to the "CDNI Working Group":
The IESG recommends we avoid referring to the Working Groups because =
those are only ephemeral and will be outlasted by this document.
For example:
"This document can be used to provide guidance to the CDNI WG about
   the interconnection arrangements to be supported and to validate the
   requirements of the various CDNI interfaces.
"
I suggest this is rephrased into something like "This 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]".

2) references to the "CDNI solution":
The IESG requires that we do not refer to "solutions" from a given =
Working Group as this is too vague and changing.
For example:
"It focuses on use cases that correspond to identified industry needs =
and that are expected to be
   realized once a CDN Interconnection (CDNI) solution is available.
"
Perhaps this could be rephrased into something like:
"It focuses on use cases that correspond to identified industry needs =
and that are expected to be
   realized once open interfaces and protocols supporting =
interconnection of CDNs are specified and implemented."

3) "1.4.  The Need for CDN Interconnection Standards"
I think this section is in complete overlap with the =
cdni-problem-statement. In fact, it actually starts with:
"   The problem statement draft [I-D.ietf-cdni-problem-statement]
   describes extensively the CDNI problem space and explains why CDNI
   standards are required.
"
I suggest this section be removed altogether, and a reference to the =
cdni-problem-statement should appear earlier in the document (i.e. in =
teh first paragraphs of section 1).


Cheers

Francois

On 22 Feb 2012, at 17:31, Francois Le Faucheur wrote:

> Folks,
>=20
> The Last Call period for draft-ietf-cdni-use-cases has now closed, but =
we haven't received any comments, so we'll extend it until 2 March.
> =20
> As per the show of hand at the last IETF meeting, quite a few of you =
are familiar with this document. So can you please have a look at the =
latest version and pass on your comments, or a brief statement like "I =
think it's ready" or "I think it needs rework before going further", so =
we can get explicit confirmation that the document is ready (or not) =
from the WG perspective.
>=20
> Thanks
>=20
> Francois & Rich
>=20
>=20
> On 30 Jan 2012, at 14:37, Francois Le Faucheur wrote:
>=20
>> All,
>>=20
>> This is the start of a two-week working group last call on =
draft-ietf-cdni-use-cases-03.txt:
>> https://datatracker.ietf.org/doc/draft-ietf-cdni-use-cases/
>>=20
>> This working group last call will end 13 Feb 2012. Please send your =
comments to the CDNI mailing list.
>>=20
>> Francois & Rich
>>=20
>>=20
>> Begin forwarded message:
>>=20
>>> From: <gilles.bertrand@orange.com>
>>> Date: 30 January 2012 12:12:50 CET
>>> To: <cdni@ietf.org>
>>> Subject: [CDNi] TR: I-D Action: draft-ietf-cdni-use-cases-03.txt
>>>=20
>>> Hi,
>>>=20
>>> We have submitted a revision addressing Kent's comments.
>>>=20
>>> =
http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-ietf-=
cdni-use-cases-02.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-cdni-use-=
cases-03.txt=20
>>>=20
>>> Best regards,
>>>=20
>>> Gilles
>>>=20
>>>=20
>>>=20
>>>=20
>>> -----Message d'origine-----
>>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part =
de internet-drafts@ietf.org
>>> Envoy=E9 : lundi 30 janvier 2012 12:07
>>> =C0 : i-d-announce@ietf.org
>>> Cc : cdni@ietf.org
>>> Objet : [CDNi] I-D Action: draft-ietf-cdni-use-cases-03.txt
>>>=20
>>>=20
>>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories. This draft is a work item of the Content Delivery Networks =
Interconnection Working Group of the IETF.
>>>=20
>>> 	Title           : Use Cases for Content Delivery Network =
Interconnection
>>> 	Author(s)       : Gilles Bertrand
>>>                          Stephan Emile
>>>                          Grant Watson
>>>                          Trevor Burbridge
>>>                          Philip Eardley
>>>                          Kevin Ma
>>> 	Filename        : draft-ietf-cdni-use-cases-03.txt
>>> 	Pages           : 18
>>> 	Date            : 2012-01-30
>>>=20
>>>   Content Delivery Networks (CDNs) are commonly used for improving =
the
>>>   End User experience of a content delivery service, at a reasonable
>>>   cost.  This document outlines real world use cases (not technical
>>>   solutions) for interconnecting CDNs.  It focuses on use cases that
>>>   correspond to identified industry needs and that are expected to =
be
>>>   realized once a CDN Interconnection (CDNI) solution is available.
>>>   This document can be used to provide guidance to the CDNI WG about
>>>   the interconnection arrangements to be supported and to validate =
the
>>>   requirements of the various CDNI interfaces.
>>>=20
>>>=20
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-03.txt
>>>=20
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>=20
>>> This Internet-Draft can be retrieved at:
>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-03.txt
>>>=20
>>> _______________________________________________
>>> CDNi mailing list
>>> CDNi@ietf.org
>>> https://www.ietf.org/mailman/listinfo/cdni
>>> _______________________________________________
>>> CDNi mailing list
>>> CDNi@ietf.org
>>> https://www.ietf.org/mailman/listinfo/cdni
>>=20
>>=20
>> _______________________________________________
>> CDNi mailing list
>> CDNi@ietf.org
>> https://www.ietf.org/mailman/listinfo/cdni
>=20
>=20
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni


From flefauch@cisco.com  Thu Feb 23 23:24:17 2012
Return-Path: <flefauch@cisco.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B04E21E801B for <cdni@ietfa.amsl.com>; Thu, 23 Feb 2012 23:24:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.099
X-Spam-Level: 
X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzReSqCloviP for <cdni@ietfa.amsl.com>; Thu, 23 Feb 2012 23:24:16 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4386B21E800C for <cdni@ietf.org>; Thu, 23 Feb 2012 23:24:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=469; q=dns/txt; s=iport; t=1330068256; x=1331277856; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=wu/RTbY2lm2Qoi6jCvhyd6aLVcjqjwryqeWvWuKiAp0=; b=GO7NL5xp0EUXvUv6lDopSRy9zOmZ6Wrnc/T3CV/Dckm6UGYF6kqz71AV sbtKM6zTPW+SiQFNUbgbYTaqUQ0dDZdpn6qcT2ZZKn2+07RmDLzkK7kC6 0f5rJRZLVRCi5BKg5Pl91mlh/YpFTNBw24jfzd2Y2adO4qOXh7NlvkIw/ 8=;
X-IronPort-AV: E=Sophos;i="4.73,474,1325462400"; d="scan'208";a="130443103"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 24 Feb 2012 07:24:15 +0000
Received: from ams-flefauch-8715.cisco.com (ams-flefauch-8715.cisco.com [10.55.161.198]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1O7OERx012971; Fri, 24 Feb 2012 07:24:15 GMT
From: Francois Le Faucheur <flefauch@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 24 Feb 2012 08:24:08 +0100
Message-Id: <C82AC529-D936-45E2-A903-968B4030A639@cisco.com>
To: cdni@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [CDNi] Tentative CDNI sessions schedule for IETF-83
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Fri, 24 Feb 2012 07:24:17 -0000

Hello,

For information, the CDNI sessions have been tentatively scheduled to =
Thursday afternoon and Friday morning.
Note that this may be modified until the IETF-83 agenda is finales (on 2 =
March 2012).

   ---------------------------------------------
   cdni Session 1
   Thursday, Afternoon Session I 1300-1500

   ---------------------------------------------
   cdni Session 2
   Friday, Morning Session I 0900-1100

Cheers

Francois & Rich=

From ray.vanbrandenburg@tno.nl  Fri Feb 24 08:03:04 2012
Return-Path: <ray.vanbrandenburg@tno.nl>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3B421F8817 for <cdni@ietfa.amsl.com>; Fri, 24 Feb 2012 08:03:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level: 
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[AWL=0.305,  BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZ16uofFQGJV for <cdni@ietfa.amsl.com>; Fri, 24 Feb 2012 08:03:03 -0800 (PST)
Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 1B91321F87EB for <cdni@ietf.org>; Fri, 24 Feb 2012 08:03:02 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.73,476,1325458800"; d="scan'208,217";a="14618388"
Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1b.tno.nl with ESMTP; 24 Feb 2012 17:03:01 +0100
Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.71]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.01.0323.003; Fri, 24 Feb 2012 17:03:01 +0100
From: "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>
To: "cdni@ietf.org" <cdni@ietf.org>
Thread-Topic: New draft on HTTP Adaptive Streaming and CDNI
Thread-Index: AQHM8w3IYRbNg6xbTEmgWw9FChCjsw==
Date: Fri, 24 Feb 2012 16:03:00 +0000
Message-ID: <8855A934-878A-4B1C-BD90-C4A173288A45@tno.nl>
References: <20120224155054.22549.25411.idtracker@ietfa.amsl.com>
In-Reply-To: <20120224155054.22549.25411.idtracker@ietfa.amsl.com>
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_8855A934878A4B1CBD90C4A173288A45tnonl_"
MIME-Version: 1.0
Subject: [CDNi] New draft on HTTP Adaptive Streaming and CDNI
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Fri, 24 Feb 2012 16:03:04 -0000

--_000_8855A934878A4B1CBD90C4A173288A45tnonl_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear CDNI WG,

We have just uploaded a new I-D that discusses the impact of HTTP Adaptive =
Streaming on the CDNI interfaces. Our intent with this draft is not to prop=
ose solutions, but to spur discussion on this topic. In order to do so, it =
describes some issues that are unique to adaptive streaming in a CDNI conte=
xt. Some of the topics discussed might also be relevant when discussing the=
 CDNI Framework draft.

Please review the draft and if you have any comments, lets discuss them on =
the list.

@Chairs, if possible I would be available for giving a short presentation o=
n this draft during the upcoming Paris meeting.

Best regards,

Ray van Brandenburg



Begin forwarded message:

From: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
Date: 24 februari 2012 16:50:54 GMT+01:00
To: <ray.vanbrandenburg@tno.nl<mailto:ray.vanbrandenburg@tno.nl>>
Cc: <ray.vanbrandenburg@tno.nl<mailto:ray.vanbrandenburg@tno.nl>>
Subject: New Version Notification for draft-brandenburg-cdni-has-00.txt

A new version of I-D, draft-brandenburg-cdni-has-00.txt has been successful=
ly submitted by Ray Brandenburg and posted to the IETF repository.

Filename:     draft-brandenburg-cdni-has
Revision:     00
Title:         Models for adaptive-streaming-aware CDN Interconnection
Creation date:     2012-02-24
WG ID:         Individual Submission
Number of pages: 15

Abstract:
  This documents presents thougths on the potential impact of
  supporting HTTP Adaptive Streaming technologies in CDN
  Interconnection scenarios.  Our intent is to spur discussion on how
  the different CDNI interfaces should deal with content delivered
  using adaptive streaming technologies.




The IETF Secretariat
This e-mail and its contents are subject to the DISCLAIMER at http://www.tn=
o.nl/emaildisclaimer

--_000_8855A934878A4B1CBD90C4A173288A45tnonl_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii">
</head>
<body bgcolor=3D"#FFFFFF">
<div>Dear CDNI WG,</div>
<div><br>
</div>
<div>We have just uploaded a new I-D that discusses the impact of HTTP Adap=
tive Streaming on the CDNI interfaces.&nbsp;Our intent with this draft is n=
ot to propose solutions, but to spur discussion on this topic. In order to =
do so, it describes some issues that
 are unique to adaptive streaming in a CDNI context. Some of the topics dis=
cussed might also be relevant when discussing the CDNI Framework draft.&nbs=
p;</div>
<div><br>
</div>
<div>Please review the draft and if you have any comments, lets discuss the=
m on the list.</div>
<div><br>
</div>
<div>@Chairs, if possible I would be available for giving a short presentat=
ion on this draft during the upcoming Paris meeting.</div>
<div><br>
</div>
<div>Best regards,</div>
<div><br>
</div>
<div>Ray van Brandenburg</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
Begin forwarded message:<br>
<br>
</div>
<blockquote type=3D"cite">
<div><b>From:</b> &lt;<a href=3D"mailto:internet-drafts@ietf.org">internet-=
drafts@ietf.org</a>&gt;<br>
<b>Date:</b> 24 februari 2012 16:50:54 GMT&#43;01:00<br>
<b>To:</b> &lt;<a href=3D"mailto:ray.vanbrandenburg@tno.nl">ray.vanbrandenb=
urg@tno.nl</a>&gt;<br>
<b>Cc:</b> &lt;<a href=3D"mailto:ray.vanbrandenburg@tno.nl">ray.vanbrandenb=
urg@tno.nl</a>&gt;<br>
<b>Subject:</b> <b>New Version Notification for draft-brandenburg-cdni-has-=
00.txt</b><br>
<br>
</div>
</blockquote>
<div></div>
<blockquote type=3D"cite">
<div><span>A new version of I-D, draft-brandenburg-cdni-has-00.txt has been=
 successfully submitted by Ray Brandenburg and posted to the IETF repositor=
y.</span><br>
<span></span><br>
<span>Filename: &nbsp; &nbsp; draft-brandenburg-cdni-has</span><br>
<span>Revision: &nbsp; &nbsp; 00</span><br>
<span>Title: &nbsp; &nbsp; &nbsp; &nbsp; Models for adaptive-streaming-awar=
e CDN Interconnection</span><br>
<span>Creation date: &nbsp; &nbsp; 2012-02-24</span><br>
<span>WG ID: &nbsp; &nbsp; &nbsp; &nbsp; Individual Submission</span><br>
<span>Number of pages: 15</span><br>
<span></span><br>
<span>Abstract:</span><br>
<span>&nbsp;&nbsp;This documents presents thougths on the potential impact =
of</span><br>
<span>&nbsp;&nbsp;supporting HTTP Adaptive Streaming technologies in CDN</s=
pan><br>
<span>&nbsp;&nbsp;Interconnection scenarios. &nbsp;Our intent is to spur di=
scussion on how</span><br>
<span>&nbsp;&nbsp;the different CDNI interfaces should deal with content de=
livered</span><br>
<span>&nbsp;&nbsp;using adaptive streaming technologies.</span><br>
<span></span><br>
<span></span><br>
<span></span><br>
<span></span><br>
<span>The IETF Secretariat</span><br>
</div>
</blockquote>
<font face=3D"monospace">This e-mail and its contents are subject to the DI=
SCLAIMER at http://www.tno.nl/emaildisclaimer</font></body>
</html>

--_000_8855A934878A4B1CBD90C4A173288A45tnonl_--


From ray.vanbrandenburg@tno.nl  Fri Feb 24 08:09:39 2012
Return-Path: <ray.vanbrandenburg@tno.nl>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5423821F84D7 for <cdni@ietfa.amsl.com>; Fri, 24 Feb 2012 08:09:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.242
X-Spam-Level: 
X-Spam-Status: No, score=-0.242 tagged_above=-999 required=5 tests=[AWL=0.261,  BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRxaw+HIXmJ2 for <cdni@ietfa.amsl.com>; Fri, 24 Feb 2012 08:09:38 -0800 (PST)
Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9954721F867C for <cdni@ietf.org>; Fri, 24 Feb 2012 08:09:37 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.73,476,1325458800"; d="scan'208,217";a="64921931"
Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1a.tno.nl with ESMTP; 24 Feb 2012 17:09:31 +0100
Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.71]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.01.0323.003; Fri, 24 Feb 2012 17:09:30 +0100
From: "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>
To: "cdni@ietf.org" <cdni@ietf.org>
Thread-Topic: [CDNi] New draft on HTTP Adaptive Streaming and CDNI
Thread-Index: AQHM8w6w4C0IHqR160O72O9u7kWkMg==
Date: Fri, 24 Feb 2012 16:09:29 +0000
Message-ID: <5DC46020-8C6F-44D8-9524-2AB73C390ADB@tno.nl>
References: <20120224155054.22549.25411.idtracker@ietfa.amsl.com>, <8855A934-878A-4B1C-BD90-C4A173288A45@tno.nl>
In-Reply-To: <8855A934-878A-4B1C-BD90-C4A173288A45@tno.nl>
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_5DC460208C6F44D895242AB73C390ADBtnonl_"
MIME-Version: 1.0
Subject: Re: [CDNi] New draft on HTTP Adaptive Streaming and CDNI
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Fri, 24 Feb 2012 16:09:39 -0000

--_000_5DC460208C6F44D895242AB73C390ADBtnonl_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

And the URL, for extra convenience:

http://tools.ietf.org/id/draft-brandenburg-cdni-has-00.txt

Ray


On 24 feb. 2012, at 17:03, "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@=
tno.nl<mailto:ray.vanbrandenburg@tno.nl>> wrote:

Dear CDNI WG,

We have just uploaded a new I-D that discusses the impact of HTTP Adaptive =
Streaming on the CDNI interfaces. Our intent with this draft is not to prop=
ose solutions, but to spur discussion on this topic. In order to do so, it =
describes some issues that are unique to adaptive streaming in a CDNI conte=
xt. Some of the topics discussed might also be relevant when discussing the=
 CDNI Framework draft.

Please review the draft and if you have any comments, lets discuss them on =
the list.

@Chairs, if possible I would be available for giving a short presentation o=
n this draft during the upcoming Paris meeting.

Best regards,

Ray van Brandenburg



Begin forwarded message:

From: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
Date: 24 februari 2012 16:50:54 GMT+01:00
To: <ray.vanbrandenburg@tno.nl<mailto:ray.vanbrandenburg@tno.nl>>
Cc: <ray.vanbrandenburg@tno.nl<mailto:ray.vanbrandenburg@tno.nl>>
Subject: New Version Notification for draft-brandenburg-cdni-has-00.txt

A new version of I-D, draft-brandenburg-cdni-has-00.txt has been successful=
ly submitted by Ray Brandenburg and posted to the IETF repository.

Filename:     draft-brandenburg-cdni-has
Revision:     00
Title:         Models for adaptive-streaming-aware CDN Interconnection
Creation date:     2012-02-24
WG ID:         Individual Submission
Number of pages: 15

Abstract:
  This documents presents thougths on the potential impact of
  supporting HTTP Adaptive Streaming technologies in CDN
  Interconnection scenarios.  Our intent is to spur discussion on how
  the different CDNI interfaces should deal with content delivered
  using adaptive streaming technologies.




The IETF Secretariat
This e-mail and its contents are subject to the DISCLAIMER at http://www.tn=
o.nl/emaildisclaimer
_______________________________________________
CDNi mailing list
CDNi@ietf.org<mailto:CDNi@ietf.org>
https://www.ietf.org/mailman/listinfo/cdni

--_000_5DC460208C6F44D895242AB73C390ADBtnonl_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body bgcolor=3D"#FFFFFF">
<div>And the URL, for extra convenience:</div>
<div><br>
</div>
<div><a href=3D"http://tools.ietf.org/id/draft-brandenburg-cdni-has-00.txt"=
>http://tools.ietf.org/id/draft-brandenburg-cdni-has-00.txt</a></div>
<div><br>
</div>
<div>Ray</div>
<div><br>
<br>
On 24 feb. 2012, at 17:03, &quot;Brandenburg, R. (Ray) van&quot; &lt;<a hre=
f=3D"mailto:ray.vanbrandenburg@tno.nl">ray.vanbrandenburg@tno.nl</a>&gt; wr=
ote:<br>
<br>
</div>
<div></div>
<blockquote type=3D"cite">
<div>
<div>Dear CDNI WG,</div>
<div><br>
</div>
<div>We have just uploaded a new I-D that discusses the impact of HTTP Adap=
tive Streaming on the CDNI interfaces.&nbsp;Our intent with this draft is n=
ot to propose solutions, but to spur discussion on this topic. In order to =
do so, it describes some issues that
 are unique to adaptive streaming in a CDNI context. Some of the topics dis=
cussed might also be relevant when discussing the CDNI Framework draft.&nbs=
p;</div>
<div><br>
</div>
<div>Please review the draft and if you have any comments, lets discuss the=
m on the list.</div>
<div><br>
</div>
<div>@Chairs, if possible I would be available for giving a short presentat=
ion on this draft during the upcoming Paris meeting.</div>
<div><br>
</div>
<div>Best regards,</div>
<div><br>
</div>
<div>Ray van Brandenburg</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
Begin forwarded message:<br>
<br>
</div>
<blockquote type=3D"cite">
<div><b>From:</b> &lt;<a href=3D"mailto:internet-drafts@ietf.org">internet-=
drafts@ietf.org</a>&gt;<br>
<b>Date:</b> 24 februari 2012 16:50:54 GMT&#43;01:00<br>
<b>To:</b> &lt;<a href=3D"mailto:ray.vanbrandenburg@tno.nl">ray.vanbrandenb=
urg@tno.nl</a>&gt;<br>
<b>Cc:</b> &lt;<a href=3D"mailto:ray.vanbrandenburg@tno.nl">ray.vanbrandenb=
urg@tno.nl</a>&gt;<br>
<b>Subject:</b> <b>New Version Notification for draft-brandenburg-cdni-has-=
00.txt</b><br>
<br>
</div>
</blockquote>
<div></div>
<blockquote type=3D"cite">
<div><span>A new version of I-D, draft-brandenburg-cdni-has-00.txt has been=
 successfully submitted by Ray Brandenburg and posted to the IETF repositor=
y.</span><br>
<span></span><br>
<span>Filename: &nbsp; &nbsp; draft-brandenburg-cdni-has</span><br>
<span>Revision: &nbsp; &nbsp; 00</span><br>
<span>Title: &nbsp; &nbsp; &nbsp; &nbsp; Models for adaptive-streaming-awar=
e CDN Interconnection</span><br>
<span>Creation date: &nbsp; &nbsp; 2012-02-24</span><br>
<span>WG ID: &nbsp; &nbsp; &nbsp; &nbsp; Individual Submission</span><br>
<span>Number of pages: 15</span><br>
<span></span><br>
<span>Abstract:</span><br>
<span>&nbsp;&nbsp;This documents presents thougths on the potential impact =
of</span><br>
<span>&nbsp;&nbsp;supporting HTTP Adaptive Streaming technologies in CDN</s=
pan><br>
<span>&nbsp;&nbsp;Interconnection scenarios. &nbsp;Our intent is to spur di=
scussion on how</span><br>
<span>&nbsp;&nbsp;the different CDNI interfaces should deal with content de=
livered</span><br>
<span>&nbsp;&nbsp;using adaptive streaming technologies.</span><br>
<span></span><br>
<span></span><br>
<span></span><br>
<span></span><br>
<span>The IETF Secretariat</span><br>
</div>
</blockquote>
<font face=3D"monospace">This e-mail and its contents are subject to the DI=
SCLAIMER at
<a href=3D"http://www.tno.nl/emaildisclaimer">http://www.tno.nl/emaildiscla=
imer</a></font>
</div>
</blockquote>
<blockquote type=3D"cite">
<div><span>_______________________________________________</span><br>
<span>CDNi mailing list</span><br>
<span><a href=3D"mailto:CDNi@ietf.org">CDNi@ietf.org</a></span><br>
<span><a href=3D"https://www.ietf.org/mailman/listinfo/cdni">https://www.ie=
tf.org/mailman/listinfo/cdni</a></span><br>
</div>
</blockquote>
</body>
</html>

--_000_5DC460208C6F44D895242AB73C390ADBtnonl_--

From flefauch@cisco.com  Fri Feb 24 08:36:28 2012
Return-Path: <flefauch@cisco.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441E321F87E4 for <cdni@ietfa.amsl.com>; Fri, 24 Feb 2012 08:36:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.117
X-Spam-Level: 
X-Spam-Status: No, score=-10.117 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwmkKWGAKiSN for <cdni@ietfa.amsl.com>; Fri, 24 Feb 2012 08:36:27 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4C51421F87C8 for <cdni@ietf.org>; Fri, 24 Feb 2012 08:36:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=6375; q=dns/txt; s=iport; t=1330101368; x=1331310968; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=IvV85yQaXkACQc3pTXYox8+MrrxmKD5+B6Mu+W8IQ0o=; b=lbOqJppNnaWSJLCXNzhjPhKn9AaJTo/dBhHwM+IWuR8pvQyHQlvrLxhH Zy2L7WRNv+ELbQUG/bKEc90PFchlB1+nqLhd7tJ09DqwH8oNsbnrGtZ5K IfEfJ6uQ/WklDPDIgBThrnhh+zsuW6AZqB1WfM+o9LQ0wSPWXPvwrJpuJ I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAFO7R0+Q/khL/2dsb2JhbABDsxiBB4FzAQEBAwEBAQEPAVsLBQsLEQMBAi8nKAgGARIbB4dfBQugNgGWfol4gwMKBgICBgQBBgEJBgIYFAsRCAEMCoRSIxcGGQUJCgUMDAYIEgyCTWMElTuScIFb
X-IronPort-AV: E=Sophos;i="4.73,476,1325462400";  d="scan'208,217";a="130516574"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 24 Feb 2012 16:36:03 +0000
Received: from ams-flefauch-8715.cisco.com (ams-flefauch-8715.cisco.com [10.55.161.198]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1OGa2tj008568; Fri, 24 Feb 2012 16:36:02 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-143--393146461
From: Francois Le Faucheur <flefauch@cisco.com>
In-Reply-To: <8855A934-878A-4B1C-BD90-C4A173288A45@tno.nl>
Date: Fri, 24 Feb 2012 17:36:11 +0100
Message-Id: <0505CCB8-C4CF-4154-ABBB-23EC19891E92@cisco.com>
References: <20120224155054.22549.25411.idtracker@ietfa.amsl.com> <8855A934-878A-4B1C-BD90-C4A173288A45@tno.nl>
To: Aaron Falk <aaron.falk@gmail.com>, Bruce Davie <bdavie@nicira.com>, Larry Peterson <lpeterson@verivue.com>, "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>
X-Mailer: Apple Mail (2.1084)
Cc: cdni@ietf.org
Subject: Re: [CDNi] New draft on HTTP Adaptive Streaming and CDNI
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Fri, 24 Feb 2012 16:36:28 -0000

--Apple-Mail-143--393146461
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

As discussed earlier on the list, I believe we agreed that =
cdni-framework would discuss adaptive streaming and how it impacts the =
CDNI solution. So this new document may provide additional input in that =
exercise.

Cheers

Francois

On 24 Feb 2012, at 17:03, Brandenburg, R. (Ray) van wrote:

> Dear CDNI WG,
>=20
> We have just uploaded a new I-D that discusses the impact of HTTP =
Adaptive Streaming on the CDNI interfaces. Our intent with this draft is =
not to propose solutions, but to spur discussion on this topic. In order =
to do so, it describes some issues that are unique to adaptive streaming =
in a CDNI context. Some of the topics discussed might also be relevant =
when discussing the CDNI Framework draft.=20
>=20
> Please review the draft and if you have any comments, lets discuss =
them on the list.
>=20
> @Chairs, if possible I would be available for giving a short =
presentation on this draft during the upcoming Paris meeting.
>=20
> Best regards,
>=20
> Ray van Brandenburg
>=20
>=20
>=20
> Begin forwarded message:
>=20
>> From: <internet-drafts@ietf.org>
>> Date: 24 februari 2012 16:50:54 GMT+01:00
>> To: <ray.vanbrandenburg@tno.nl>
>> Cc: <ray.vanbrandenburg@tno.nl>
>> Subject: New Version Notification for =
draft-brandenburg-cdni-has-00.txt
>>=20
>> A new version of I-D, draft-brandenburg-cdni-has-00.txt has been =
successfully submitted by Ray Brandenburg and posted to the IETF =
repository.
>>=20
>> Filename:     draft-brandenburg-cdni-has
>> Revision:     00
>> Title:         Models for adaptive-streaming-aware CDN =
Interconnection
>> Creation date:     2012-02-24
>> WG ID:         Individual Submission
>> Number of pages: 15
>>=20
>> Abstract:
>>   This documents presents thougths on the potential impact of
>>   supporting HTTP Adaptive Streaming technologies in CDN
>>   Interconnection scenarios.  Our intent is to spur discussion on how
>>   the different CDNI interfaces should deal with content delivered
>>   using adaptive streaming technologies.
>>=20
>>=20
>>=20
>>=20
>> The IETF Secretariat
> This e-mail and its contents are subject to the DISCLAIMER at =
http://www.tno.nl/emaildisclaimer
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni


--Apple-Mail-143--393146461
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi,<div><br></div><div>As discussed earlier on the list, I believe we agreed that cdni-framework would discuss adaptive streaming and how it impacts the CDNI solution. So this new document may provide additional input in that exercise.</div><div><br></div><div>Cheers</div><div><br></div><div>Francois</div><div><br><div><div>On 24 Feb 2012, at 17:03, Brandenburg, R. (Ray) van wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

<div bgcolor="#FFFFFF">
<div>Dear CDNI WG,</div>
<div><br>
</div>
<div>We have just uploaded a new I-D that discusses the impact of HTTP Adaptive Streaming on the CDNI interfaces.&nbsp;Our intent with this draft is not to propose solutions, but to spur discussion on this topic. In order to do so, it describes some issues that
 are unique to adaptive streaming in a CDNI context. Some of the topics discussed might also be relevant when discussing the CDNI Framework draft.&nbsp;</div>
<div><br>
</div>
<div>Please review the draft and if you have any comments, lets discuss them on the list.</div>
<div><br>
</div>
<div>@Chairs, if possible I would be available for giving a short presentation on this draft during the upcoming Paris meeting.</div>
<div><br>
</div>
<div>Best regards,</div>
<div><br>
</div>
<div>Ray van Brandenburg</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
Begin forwarded message:<br>
<br>
</div>
<blockquote type="cite">
<div><b>From:</b> &lt;<a href="mailto:internet-drafts@ietf.org">internet-drafts@ietf.org</a>&gt;<br>
<b>Date:</b> 24 februari 2012 16:50:54 GMT+01:00<br>
<b>To:</b> &lt;<a href="mailto:ray.vanbrandenburg@tno.nl">ray.vanbrandenburg@tno.nl</a>&gt;<br>
<b>Cc:</b> &lt;<a href="mailto:ray.vanbrandenburg@tno.nl">ray.vanbrandenburg@tno.nl</a>&gt;<br>
<b>Subject:</b> <b>New Version Notification for draft-brandenburg-cdni-has-00.txt</b><br>
<br>
</div>
</blockquote>
<div></div>
<blockquote type="cite">
<div><span>A new version of I-D, draft-brandenburg-cdni-has-00.txt has been successfully submitted by Ray Brandenburg and posted to the IETF repository.</span><br>
<span></span><br>
<span>Filename: &nbsp; &nbsp; draft-brandenburg-cdni-has</span><br>
<span>Revision: &nbsp; &nbsp; 00</span><br>
<span>Title: &nbsp; &nbsp; &nbsp; &nbsp; Models for adaptive-streaming-aware CDN Interconnection</span><br>
<span>Creation date: &nbsp; &nbsp; 2012-02-24</span><br>
<span>WG ID: &nbsp; &nbsp; &nbsp; &nbsp; Individual Submission</span><br>
<span>Number of pages: 15</span><br>
<span></span><br>
<span>Abstract:</span><br>
<span>&nbsp;&nbsp;This documents presents thougths on the potential impact of</span><br>
<span>&nbsp;&nbsp;supporting HTTP Adaptive Streaming technologies in CDN</span><br>
<span>&nbsp;&nbsp;Interconnection scenarios. &nbsp;Our intent is to spur discussion on how</span><br>
<span>&nbsp;&nbsp;the different CDNI interfaces should deal with content delivered</span><br>
<span>&nbsp;&nbsp;using adaptive streaming technologies.</span><br>
<span></span><br>
<span></span><br>
<span></span><br>
<span></span><br>
<span>The IETF Secretariat</span><br>
</div>
</blockquote>
<font face="monospace">This e-mail and its contents are subject to the DISCLAIMER at <a href="http://www.tno.nl/emaildisclaimer">http://www.tno.nl/emaildisclaimer</a></font></div>

_______________________________________________<br>CDNi mailing list<br><a href="mailto:CDNi@ietf.org">CDNi@ietf.org</a><br>https://www.ietf.org/mailman/listinfo/cdni<br></blockquote></div><br></div></body></html>
--Apple-Mail-143--393146461--

From gilles.bertrand@orange.com  Mon Feb 27 07:39:19 2012
Return-Path: <gilles.bertrand@orange.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8D321F8742 for <cdni@ietfa.amsl.com>; Mon, 27 Feb 2012 07:39:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.841
X-Spam-Level: 
X-Spam-Status: No, score=-5.841 tagged_above=-999 required=5 tests=[AWL=0.408,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7zEP-Nuu+Gr for <cdni@ietfa.amsl.com>; Mon, 27 Feb 2012 07:39:17 -0800 (PST)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 494F421F8730 for <cdni@ietf.org>; Mon, 27 Feb 2012 07:39:00 -0800 (PST)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 719175D88DF; Mon, 27 Feb 2012 16:38:58 +0100 (CET)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 64DF35D86E4; Mon, 27 Feb 2012 16:38:58 +0100 (CET)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 27 Feb 2012 16:38:58 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 27 Feb 2012 16:38:37 +0100
Message-ID: <8E09C72DBC577D489F13A71228C0B7BF032C4A5B@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <088BA1E4-8C19-4A43-B0EE-BBCF6D599BF0@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [CDNi] Working Group Last Call ondraft-ietf-cdni-use-cases-03.txt
Thread-Index: Aczxg2X6yuT05G8CRyWxes/5hNtU6wD4fNYw
References: <8E09C72DBC577D489F13A71228C0B7BF031722A3@ftrdmel0.rd.francetelecom.fr><4715AB6C-6566-4E09-BCE1-1B7F5C604C80@cisco.com><562ECB2F-4F36-4AF1-AD30-EEEC9146DCFC@cisco.com> <088BA1E4-8C19-4A43-B0EE-BBCF6D599BF0@cisco.com>
From: <gilles.bertrand@orange.com>
To: <flefauch@cisco.com>, <draft-ietf-cdni-use-cases@tools.ietf.org>
X-OriginalArrivalTime: 27 Feb 2012 15:38:58.0144 (UTC) FILETIME=[EBADCE00:01CCF565]
Cc: cdni@ietf.org
Subject: Re: [CDNi] Working Group Last Call ondraft-ietf-cdni-use-cases-03.txt
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
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/options/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, 27 Feb 2012 15:39:20 -0000

Hi Fran=E7ois,

thanks for this review.=20

We will wait for any other comment on the list until march 2nd (end of =
extended last-call period) and submit a final revision.

Best regards,

Gilles


-----Message d'origine-----
De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part =
de Francois Le Faucheur
Envoy=E9=A0: mercredi 22 f=E9vrier 2012 18:00
=C0=A0: draft-ietf-cdni-use-cases@tools.ietf.org
Cc=A0: cdni@ietf.org
Objet=A0: Re: [CDNi] Working Group Last Call =
ondraft-ietf-cdni-use-cases-03.txt

To cdni-use-cases authors,

I had another look and here are a few additional comments:

1) references to the "CDNI Working Group":
The IESG recommends we avoid referring to the Working Groups because =
those are only ephemeral and will be outlasted by this document.
For example:
"This document can be used to provide guidance to the CDNI WG about
   the interconnection arrangements to be supported and to validate the
   requirements of the various CDNI interfaces.
"
I suggest this is rephrased into something like "This 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]".

2) references to the "CDNI solution":
The IESG requires that we do not refer to "solutions" from a given =
Working Group as this is too vague and changing.
For example:
"It focuses on use cases that correspond to identified industry needs =
and that are expected to be
   realized once a CDN Interconnection (CDNI) solution is available.
"
Perhaps this could be rephrased into something like:
"It focuses on use cases that correspond to identified industry needs =
and that are expected to be
   realized once open interfaces and protocols supporting =
interconnection of CDNs are specified and implemented."

3) "1.4.  The Need for CDN Interconnection Standards"
I think this section is in complete overlap with the =
cdni-problem-statement. In fact, it actually starts with:
"   The problem statement draft [I-D.ietf-cdni-problem-statement]
   describes extensively the CDNI problem space and explains why CDNI
   standards are required.
"
I suggest this section be removed altogether, and a reference to the =
cdni-problem-statement should appear earlier in the document (i.e. in =
teh first paragraphs of section 1).


Cheers

Francois

On 22 Feb 2012, at 17:31, Francois Le Faucheur wrote:

> Folks,
>=20
> The Last Call period for draft-ietf-cdni-use-cases has now closed, but =
we haven't received any comments, so we'll extend it until 2 March.
> =20
> As per the show of hand at the last IETF meeting, quite a few of you =
are familiar with this document. So can you please have a look at the =
latest version and pass on your comments, or a brief statement like "I =
think it's ready" or "I think it needs rework before going further", so =
we can get explicit confirmation that the document is ready (or not) =
from the WG perspective.
>=20
> Thanks
>=20
> Francois & Rich
>=20
>=20
> On 30 Jan 2012, at 14:37, Francois Le Faucheur wrote:
>=20
>> All,
>>=20
>> This is the start of a two-week working group last call on =
draft-ietf-cdni-use-cases-03.txt:
>> https://datatracker.ietf.org/doc/draft-ietf-cdni-use-cases/
>>=20
>> This working group last call will end 13 Feb 2012. Please send your =
comments to the CDNI mailing list.
>>=20
>> Francois & Rich
>>=20
>>=20
>> Begin forwarded message:
>>=20
>>> From: <gilles.bertrand@orange.com>
>>> Date: 30 January 2012 12:12:50 CET
>>> To: <cdni@ietf.org>
>>> Subject: [CDNi] TR: I-D Action: draft-ietf-cdni-use-cases-03.txt
>>>=20
>>> Hi,
>>>=20
>>> We have submitted a revision addressing Kent's comments.
>>>=20
>>> =
http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-i
>>> =
etf-cdni-use-cases-02.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-c
>>> dni-use-cases-03.txt
>>>=20
>>> Best regards,
>>>=20
>>> Gilles
>>>=20
>>>=20
>>>=20
>>>=20
>>> -----Message d'origine-----
>>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part =

>>> de internet-drafts@ietf.org Envoy=E9 : lundi 30 janvier 2012 12:07 =
=C0 :=20
>>> i-d-announce@ietf.org Cc : cdni@ietf.org Objet : [CDNi] I-D Action:=20
>>> draft-ietf-cdni-use-cases-03.txt
>>>=20
>>>=20
>>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories. This draft is a work item of the Content Delivery Networks =
Interconnection Working Group of the IETF.
>>>=20
>>> 	Title           : Use Cases for Content Delivery Network =
Interconnection
>>> 	Author(s)       : Gilles Bertrand
>>>                          Stephan Emile
>>>                          Grant Watson
>>>                          Trevor Burbridge
>>>                          Philip Eardley
>>>                          Kevin Ma
>>> 	Filename        : draft-ietf-cdni-use-cases-03.txt
>>> 	Pages           : 18
>>> 	Date            : 2012-01-30
>>>=20
>>>   Content Delivery Networks (CDNs) are commonly used for improving =
the
>>>   End User experience of a content delivery service, at a reasonable
>>>   cost.  This document outlines real world use cases (not technical
>>>   solutions) for interconnecting CDNs.  It focuses on use cases that
>>>   correspond to identified industry needs and that are expected to =
be
>>>   realized once a CDN Interconnection (CDNI) solution is available.
>>>   This document can be used to provide guidance to the CDNI WG about
>>>   the interconnection arrangements to be supported and to validate =
the
>>>   requirements of the various CDNI interfaces.
>>>=20
>>>=20
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-03.txt
>>>=20
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>=20
>>> This Internet-Draft can be retrieved at:
>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-03.txt
>>>=20
>>> _______________________________________________
>>> CDNi mailing list
>>> CDNi@ietf.org
>>> https://www.ietf.org/mailman/listinfo/cdni
>>> _______________________________________________
>>> CDNi mailing list
>>> CDNi@ietf.org
>>> https://www.ietf.org/mailman/listinfo/cdni
>>=20
>>=20
>> _______________________________________________
>> CDNi mailing list
>> CDNi@ietf.org
>> https://www.ietf.org/mailman/listinfo/cdni
>=20
>=20
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

From Jan.Seedorf@neclab.eu  Tue Feb 28 06:54:24 2012
Return-Path: <Jan.Seedorf@neclab.eu>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2D121F8513 for <cdni@ietfa.amsl.com>; Tue, 28 Feb 2012 06:54:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trA3u94SMwJM for <cdni@ietfa.amsl.com>; Tue, 28 Feb 2012 06:54:23 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 47F7921F848A for <cdni@ietf.org>; Tue, 28 Feb 2012 06:54:23 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 75391280000F8; Tue, 28 Feb 2012 15:54:22 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0P6fg7Pa8+o6; Tue, 28 Feb 2012 15:54:22 +0100 (CET)
Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 5726628000084; Tue, 28 Feb 2012 15:54:12 +0100 (CET)
Received: from DAPHNIS.office.hd ([169.254.2.41]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 28 Feb 2012 15:53:51 +0100
From: Jan Seedorf <Jan.Seedorf@neclab.eu>
To: Ina Minei <ina@juniper.net>, "cdni@ietf.org" <cdni@ietf.org>
Thread-Topic: Question regarding downstream CDN selection
Thread-Index: AczoAzqhH0Gxf7unQsKRfBfXt4YXFQAFyaQQA4NenDA=
Date: Tue, 28 Feb 2012 14:53:51 +0000
Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24F11CAE@DAPHNIS.office.hd>
References: <2779C9F0771F974CAD742BAE6D9904FE24EE7153@PALLENE.office.hd> <189716C74BBB9C4095FE8CA503B1FC3A5762A589C0@EMBX02-HQ.jnpr.net>
In-Reply-To: <189716C74BBB9C4095FE8CA503B1FC3A5762A589C0@EMBX02-HQ.jnpr.net>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.2.227]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [CDNi] Question regarding downstream CDN selection
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Tue, 28 Feb 2012 14:54:24 -0000

Dear Ina,

Thanks for your reply and sorry for my late answer. From your answer, it se=
ems my description of the two different models was clear :), which is good.

Still, my question to this WG remains: do we assume either model or are we =
considering both of them?

And if we consider the second model (independent agreements with CP), is th=
e fact that a dCDN can serve content for a given CP part of the "capabiliti=
es" part of the request routing interface?

 - Jan

> -----Original Message-----
> From: Ina Minei [mailto:ina@juniper.net]
> Sent: Friday, February 10, 2012 7:17 PM
> To: Jan Seedorf; cdni@ietf.org
> Subject: RE: Question regarding downstream CDN selection
>=20
> Jan,
>=20
> The answer to that question depends on how you assume redirection is
> done in the case you are describing, and I think this boils down to the
> different models of CDN federations.
>=20
> The first (the one described in the quote), relies on bilateral agreement=
s. In
> that case, the request is redirected to the authoritative, who will  redi=
rect to
> the best downstream.
>=20
> The second model (the one you describe), sounds like an exchange model,
> with multiple members of the exchange having a relation to the same CSP,
> and the request being redirected to a coordinating entity for the exchang=
e.
> In the second case, as you are pointing out, user location information is=
 not
> enough to determine the CDN from which the content will be served
> (because that CDN may not be serving content for the CSP), and the set of
> candidate CDNs has to be determined based on the content.
>=20
> Ina
>=20
> -----Original Message-----
> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of
> Jan Seedorf
> Sent: Friday, February 10, 2012 6:58 AM
> To: cdni@ietf.org
> Subject: [CDNi] Question regarding downstream CDN selection
>=20
> Folks,
>=20
> I have a question regarding downstream CDN selection. The introduction of
> the CDNI problem statement draft says: "As an example, a CSP could contra=
ct
> with an "authoritative" CDN Provider for the delivery of content and that
> authoritative CDN Provider could contract with one or more downstream
> CDN Provider(s) to distribute and deliver some or all of the content on b=
ehalf
> of the authoritative CDN Provider.  The formation and details of any busi=
ness
> relationships between a CSP and a CDN Provider and between one CDN
> Provider and another CDN Provider are out of scope of this document.
> However, no standards or open specifications currently exist to facilitat=
e such
> CDN interconnection."
>=20
> My question is if we always assume this model, where there is an
> "authoritative" CDN provider which transitively has itself contracted sev=
eral
> downstream CDN providers. Or do we account for the possibility that
> potentially a CSP has own its own made several independent agreements
> with other CDNs (e.g. because they are covering different geographical
> areas). If we want to consider the latter case, how does the upstream CDN
> know for a given downstream CDN if it serves the content for a given CSP?
>=20
>  - Jan
>=20
> > -----Original Message-----
> > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of
> > Francois Le Faucheur
> > Sent: Monday, January 30, 2012 2:38 PM
> > To: cdni@ietf.org
> > Subject: [CDNi] Working Group Last Call on draft-ietf-cdni-use-cases-03=
.txt
> >
> > All,
> >
> > This is the start of a two-week working group last call on draft-ietf-c=
dni-
> use-
> > cases-03.txt:
> > https://datatracker.ietf.org/doc/draft-ietf-cdni-use-cases/
> >
> > This working group last call will end 13 Feb 2012. Please send your
> comments
> > to the CDNI mailing list.
> >
> > Francois & Rich
> >
> >
> > Begin forwarded message:
> >
> >
> > 	From: <gilles.bertrand@orange.com>
> >
> > 	Date: 30 January 2012 12:12:50 CET
> >
> > 	To: <cdni@ietf.org>
> >
> > 	Subject: [CDNi] TR: I-D Action: draft-ietf-cdni-use-cases-03.txt
> >
> >
> > 	Hi,
> >
> > 	We have submitted a revision addressing Kent's comments.
> >
> > 	http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-i=
etf-
> > cdni-use-cases-02.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-cdni-u=
se-
> > cases-03.txt
> >
> > 	Best regards,
> >
> > 	Gilles
> >
> >
> >
> >
> > 	-----Message d'origine-----
> > 	De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la
> > part de internet-drafts@ietf.org
> > 	Envoy=E9 : lundi 30 janvier 2012 12:07
> > 	=C0 : i-d-announce@ietf.org
> > 	Cc : cdni@ietf.org
> > 	Objet : [CDNi] I-D Action: draft-ietf-cdni-use-cases-03.txt
> >
> >
> > 	A New Internet-Draft is available from the on-line Internet-Drafts
> > directories. This draft is a work item of the Content Delivery Networks
> > Interconnection Working Group of the IETF.
> >
> > 	Title           : Use Cases for Content Delivery Network Interconnecti=
on
> > 	Author(s)       : Gilles Bertrand
> > 	                         Stephan Emile
> > 	                         Grant Watson
> > 	                         Trevor Burbridge
> > 	                         Philip Eardley
> > 	                         Kevin Ma
> > 	Filename        : draft-ietf-cdni-use-cases-03.txt
> > 	Pages           : 18
> > 	Date            : 2012-01-30
> >
> > 	  Content Delivery Networks (CDNs) are commonly used for
> > improving the
> > 	  End User experience of a content delivery service, at a reasonable
> > 	  cost.  This document outlines real world use cases (not technical
> > 	  solutions) for interconnecting CDNs.  It focuses on use cases that
> > 	  correspond to identified industry needs and that are expected to be
> > 	  realized once a CDN Interconnection (CDNI) solution is available.
> > 	  This document can be used to provide guidance to the CDNI WG
> > about
> > 	  the interconnection arrangements to be supported and to validate
> > the
> > 	  requirements of the various CDNI interfaces.
> >
> >
> > 	A URL for this Internet-Draft is:
> > 	http://www.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-03.txt
> >
> > 	Internet-Drafts are also available by anonymous FTP at:
> > 	ftp://ftp.ietf.org/internet-drafts/
> >
> > 	This Internet-Draft can be retrieved at:
> > 	ftp://ftp.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-03.txt
> >
> > 	_______________________________________________
> > 	CDNi mailing list
> > 	CDNi@ietf.org
> > 	https://www.ietf.org/mailman/listinfo/cdni
> > 	_______________________________________________
> > 	CDNi mailing list
> > 	CDNi@ietf.org
> > 	https://www.ietf.org/mailman/listinfo/cdni
> >
> >
> >
>=20
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni

From Jan.Seedorf@neclab.eu  Tue Feb 28 08:15:19 2012
Return-Path: <Jan.Seedorf@neclab.eu>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1AA421F864E for <cdni@ietfa.amsl.com>; Tue, 28 Feb 2012 08:15:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zu12zjJYet4Z for <cdni@ietfa.amsl.com>; Tue, 28 Feb 2012 08:15:18 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id AD65121F85D8 for <cdni@ietf.org>; Tue, 28 Feb 2012 08:15:18 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 1D5BA280000F8; Tue, 28 Feb 2012 17:15:18 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PZAOUhhyMLG; Tue, 28 Feb 2012 17:15:18 +0100 (CET)
Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id F306F28000084; Tue, 28 Feb 2012 17:14:57 +0100 (CET)
Received: from DAPHNIS.office.hd ([169.254.2.41]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 28 Feb 2012 17:14:53 +0100
From: Jan Seedorf <Jan.Seedorf@neclab.eu>
To: "stefano previdi (sprevidi@cisco.com)" <sprevidi@cisco.com>, "flefauch@cisco.com" <flefauch@cisco.com>, "jmedved@juniper.net" <jmedved@juniper.net>, "cdni@ietf.org" <cdni@ietf.org>
Thread-Topic: Questions on draft-previdi-cdni-footprint-advertisement-00
Thread-Index: Acz2Lv2ue6S3SGEmQby1HP94jyog0Q==
Date: Tue, 28 Feb 2012 16:14:56 +0000
Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24F11D2A@DAPHNIS.office.hd>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.2.227]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [CDNi] Questions on draft-previdi-cdni-footprint-advertisement-00
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Tue, 28 Feb 2012 16:15:19 -0000

Dear authors of the BGP CDNI Footprint Advertisement draft,

I have some questions, maybe you can clarify:
-- BGP communities are currently used per AS, e.g. 100:500 means AS 100 is =
attaching a value of 100 to a given route. In your scheme, do you intend to=
 use communities per footprint identifier, e.g. 100:200:300 means AS 100 is=
 attaching a value of 300 for footprint identifier 100:200?
-- section 4.2.3 says " The CDNI Connectivity Advertisement contains a new =
(TBD) attribute called Origin_AS_PATH that contains the AS_PATH value descr=
ibing the distance (expressed in AS Hop Count) between the CDN and the adve=
rtised connected footprint."; in the examples in section 7, however, Origin=
_AS_PATH is not the AS hop count but the ID of the source AS; I assume it i=
s a mistake in the example, correct?
-- in your scheme, how can you explicitly express costs (e.g. latency, band=
width, monetary costs, ...) to a certain footprint identifier? I understand=
 a ranking, but it is not clear to me how you express explicit costs. Via a=
n extended community value per footprint identifier?
-- what is confusing to me is that original BGP connectivity refers to AS-l=
evel routing, while CDN connectivity to me is (in principle) quite independ=
ent from AS-level routing. For instance, I can very well imagine 2 CDNs whi=
ch have a direct bilateral CDN-interconnection agreement, but which have ma=
ny AS-hops between their footprints. So the connectivity via AS-level BGP f=
ootprints is very confusing to me. Maybe you can explain it.


Thanks for answering,

 - Jan

From sprevidi@cisco.com  Tue Feb 28 09:55:49 2012
Return-Path: <sprevidi@cisco.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C8E21F8699 for <cdni@ietfa.amsl.com>; Tue, 28 Feb 2012 09:55:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.499
X-Spam-Level: 
X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqU+4lzpyWFf for <cdni@ietfa.amsl.com>; Tue, 28 Feb 2012 09:55:48 -0800 (PST)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id C491D21F8551 for <cdni@ietf.org>; Tue, 28 Feb 2012 09:55:47 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q1SHtCBl008980 for <cdni@ietf.org>; Tue, 28 Feb 2012 18:55:12 +0100 (CET)
Received: from dhcp-10-55-89-11.cisco.com (dhcp-10-55-89-11.cisco.com [10.55.89.11]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q1SHt9Zv011596; Tue, 28 Feb 2012 18:55:10 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: stefano previdi <sprevidi@cisco.com>
In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE24F11D2A@DAPHNIS.office.hd>
Date: Tue, 28 Feb 2012 18:55:09 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <075049AD-E2B9-40DA-8900-F54E7B6AF64E@cisco.com>
References: <2779C9F0771F974CAD742BAE6D9904FE24F11D2A@DAPHNIS.office.hd>
To: Jan Seedorf <Jan.Seedorf@neclab.eu>
X-Mailer: Apple Mail (2.1257)
Cc: Jan Medved <jmedved@juniper.net>, cdni@ietf.org
Subject: Re: [CDNi] Questions on draft-previdi-cdni-footprint-advertisement-00
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Tue, 28 Feb 2012 17:55:49 -0000

Hi Jan,

I'm in the process of submitting version 01 which has some changes in=20
terminology and encoding options. I'll try to address your questions=20
below.

On Feb 28, 2012, at 5:14 PM, Jan Seedorf wrote:
> Dear authors of the BGP CDNI Footprint Advertisement draft,
>=20
> I have some questions, maybe you can clarify:
> -- BGP communities are currently used per AS, e.g. 100:500 means AS =
100 is attaching a value of 100 to a given route.


to be more precise, in your example AS100 is attaching a value of 500.


> In your scheme, do you intend to use communities per footprint =
identifier, e.g. 100:200:300 means AS 100 is attaching a value of 300 =
for footprint identifier 100:200?


not really. We propose the use of BGP Extended community (RFC4360) for=20=

FPE Identifiers.


> -- section 4.2.3 says " The CDNI Connectivity Advertisement contains a =
new (TBD) attribute called Origin_AS_PATH that contains the AS_PATH =
value describing the distance (expressed in AS Hop Count) between the =
CDN and the advertised connected footprint."; in the examples in section =
7, however, Origin_AS_PATH is not the AS hop count but the ID of the =
source AS; I assume it is a mistake in the example, correct?


nope, the example is correct. AS_PATH Attribute in BGP contains the list=20=

of AS# the update traversed. AS hop-count is computed when you process=20=

the update.

Origin_AS_PATH has the same format.


> -- in your scheme, how can you explicitly express costs (e.g. latency, =
bandwidth, monetary costs, ...) to a certain footprint identifier? I =
understand a ranking, but it is not clear to me how you express explicit =
costs. Via an extended community value per footprint identifier?


BGP distane is based on AS hop-count. THere's no topology involved (as =
you=20
rarely exchange topology between ASs).

However, nothing prevents to use BGP attributes (MED, Communities) in =
order
to represent preferences that could also be based on costs.


> -- what is confusing to me is that original BGP connectivity refers to =
AS-level routing, while CDN connectivity to me is (in principle) quite =
independent from AS-level routing.


We use a tool called BGP but we use it in the CDNI context.=20

So, the messaging and the signaling will reflect the shape of the CDNI =
Mesh=20
and not the Internet mesh.


> For instance, I can very well imagine 2 CDNs which have a direct =
bilateral CDN-interconnection agreement, but which have many AS-hops =
between their footprints. So the connectivity via AS-level BGP =
footprints is very confusing to me. Maybe you can explain it.


AS number (in the CDNI context) refers to the CDN using such AS number.=20=

The different CDN BGP sessions you will have will tell you about all CDN=20=

interconnectivity. This is not related to the underneath inter-AS=20
connectivity.

In the new draft I also include a topology example that, hopefully, will
help...

s.


>=20
>=20
> Thanks for answering,
>=20
> - Jan
>=20


From sprevidi@cisco.com  Tue Feb 28 10:25:35 2012
Return-Path: <sprevidi@cisco.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5667621F8645 for <cdni@ietfa.amsl.com>; Tue, 28 Feb 2012 10:25:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.509
X-Spam-Level: 
X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7VHfEk2meyE for <cdni@ietfa.amsl.com>; Tue, 28 Feb 2012 10:25:34 -0800 (PST)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5142A21F85E3 for <cdni@ietf.org>; Tue, 28 Feb 2012 10:25:34 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q1SHxeF0009593 for <cdni@ietf.org>; Tue, 28 Feb 2012 18:59:40 +0100 (CET)
Received: from dhcp-10-55-89-11.cisco.com (dhcp-10-55-89-11.cisco.com [10.55.89.11]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q1SHxbG5014777; Tue, 28 Feb 2012 18:59:37 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: stefano previdi <sprevidi@cisco.com>
In-Reply-To: <075049AD-E2B9-40DA-8900-F54E7B6AF64E@cisco.com>
Date: Tue, 28 Feb 2012 18:59:36 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <CE4BCB20-76FB-4535-AA3D-85C3FF9743B3@cisco.com>
References: <2779C9F0771F974CAD742BAE6D9904FE24F11D2A@DAPHNIS.office.hd> <075049AD-E2B9-40DA-8900-F54E7B6AF64E@cisco.com>
To: Jan Seedorf <Jan.Seedorf@neclab.eu>
X-Mailer: Apple Mail (2.1257)
Cc: "Jan Medved \(jmedved\)" <jmedved@cisco.com>, cdni@ietf.org
Subject: Re: [CDNi] Questions on draft-previdi-cdni-footprint-advertisement-00
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Tue, 28 Feb 2012 18:25:35 -0000

<resending with correct authors email>


On Feb 28, 2012, at 6:55 PM, stefano previdi wrote:

Hi Jan,

I'm in the process of submitting version 01 which has some changes in=20
terminology and encoding options. I'll try to address your questions=20
below.

On Feb 28, 2012, at 5:14 PM, Jan Seedorf wrote:
> Dear authors of the BGP CDNI Footprint Advertisement draft,
>=20
> I have some questions, maybe you can clarify:
> -- BGP communities are currently used per AS, e.g. 100:500 means AS =
100 is attaching a value of 100 to a given route.


to be more precise, in your example AS100 is attaching a value of 500.


> In your scheme, do you intend to use communities per footprint =
identifier, e.g. 100:200:300 means AS 100 is attaching a value of 300 =
for footprint identifier 100:200?


not really. We propose the use of BGP Extended community (RFC4360) for=20=

FPE Identifiers.


> -- section 4.2.3 says " The CDNI Connectivity Advertisement contains a =
new (TBD) attribute called Origin_AS_PATH that contains the AS_PATH =
value describing the distance (expressed in AS Hop Count) between the =
CDN and the advertised connected footprint."; in the examples in section =
7, however, Origin_AS_PATH is not the AS hop count but the ID of the =
source AS; I assume it is a mistake in the example, correct?


nope, the example is correct. AS_PATH Attribute in BGP contains the list=20=

of AS# the update traversed. AS hop-count is computed when you process=20=

the update.

Origin_AS_PATH has the same format.


> -- in your scheme, how can you explicitly express costs (e.g. latency, =
bandwidth, monetary costs, ...) to a certain footprint identifier? I =
understand a ranking, but it is not clear to me how you express explicit =
costs. Via an extended community value per footprint identifier?


BGP distane is based on AS hop-count. THere's no topology involved (as =
you=20
rarely exchange topology between ASs).

However, nothing prevents to use BGP attributes (MED, Communities) in =
order
to represent preferences that could also be based on costs.


> -- what is confusing to me is that original BGP connectivity refers to =
AS-level routing, while CDN connectivity to me is (in principle) quite =
independent from AS-level routing.


We use a tool called BGP but we use it in the CDNI context.=20

So, the messaging and the signaling will reflect the shape of the CDNI =
Mesh=20
and not the Internet mesh.


> For instance, I can very well imagine 2 CDNs which have a direct =
bilateral CDN-interconnection agreement, but which have many AS-hops =
between their footprints. So the connectivity via AS-level BGP =
footprints is very confusing to me. Maybe you can explain it.


AS number (in the CDNI context) refers to the CDN using such AS number.=20=

The different CDN BGP sessions you will have will tell you about all CDN=20=

interconnectivity. This is not related to the underneath inter-AS=20
connectivity.

In the new draft I also include a topology example that, hopefully, will
help...

s.


>=20
>=20
> Thanks for answering,
>=20
> - Jan
>=20




From robmry@gmail.com  Wed Feb 29 14:34:08 2012
Return-Path: <robmry@gmail.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB3B21E802A for <cdni@ietfa.amsl.com>; Wed, 29 Feb 2012 14:34:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNuL8Vx-ZEsS for <cdni@ietfa.amsl.com>; Wed, 29 Feb 2012 14:34:07 -0800 (PST)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 96F6F21F86D3 for <cdni@ietf.org>; Wed, 29 Feb 2012 14:34:07 -0800 (PST)
Received: by wicr5 with SMTP id r5so3101145wic.31 for <cdni@ietf.org>; Wed, 29 Feb 2012 14:34:04 -0800 (PST)
Received-SPF: pass (google.com: domain of robmry@gmail.com designates 10.180.86.9 as permitted sender) client-ip=10.180.86.9; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of robmry@gmail.com designates 10.180.86.9 as permitted sender) smtp.mail=robmry@gmail.com; dkim=pass header.i=robmry@gmail.com
Received: from mr.google.com ([10.180.86.9]) by 10.180.86.9 with SMTP id l9mr4789879wiz.15.1330554844864 (num_hops = 1); Wed, 29 Feb 2012 14:34:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=dQXnmI+4gsYJuj8Nka5cJ3zxoZx+rED11acWuLQ4ixs=; b=x/DxxCpwRCa3KKJI5VbMz3+ev1YgFj3RXmGwAHuztzyZyeENsf7cNYLMuw5l/gB1JP sJaZtQs0wo/0ODMzdLdysO0NMlAsj4Ne+rVi1dDLG+3ZKRXhtOPC+4gZGwnRWBILnW8n I1Sjy4UbuFwVw5XVP99vDcWWEqVcnIGzWF8qU=
MIME-Version: 1.0
Received: by 10.180.86.9 with SMTP id l9mr3868990wiz.15.1330554844824; Wed, 29 Feb 2012 14:34:04 -0800 (PST)
Received: by 10.216.232.215 with HTTP; Wed, 29 Feb 2012 14:34:04 -0800 (PST)
Date: Wed, 29 Feb 2012 22:34:04 +0000
Message-ID: <CAP_G3VNq7HPM7ru7eEk5Ktb9eHaakZ=W7U+fgNHdSO_4qKK82g@mail.gmail.com>
From: Rob Murray <robmry@gmail.com>
To: cdni@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [CDNi] CDNI Triggers interface
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Wed, 29 Feb 2012 22:37:03 -0000

Hi all,

I've just uploaded a new draft that proposes a CDNI Triggers interface ...

    http://tools.ietf.org/html/draft-murray-cdni-triggers-00

There was some discussion at the last WG meeting about whether triggers
fit best as part of the control or metadata interface - the suggestion was
that concrete proposals for the interface might help us spot commonality
with one or the other, so let's see!

Please take a look, your comments are welcome.

Best regards,
Rob.


On 29/02/2012 19:37, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
wrote:

>A new version of I-D, draft-murray-cdni-triggers-00.txt has been
>successfully submitted by Rob Murray and posted to the IETF repository.
>
>Filename:	 draft-murray-cdni-triggers
>Revision:	 00
>Title:		 CDN Interconnect Triggers
>Creation date:	 2012-02-29
>WG ID:		 Individual Submission
>Number of pages: 33
>
>Abstract:
>   This document proposes a mechanism for a CDN to trigger activity in
>   an interconnected CDN that is configured to deliver content on its
>   behalf.  The upstream CDN can use this mechanism to request that the
>   downstream CDN pre-positions metadata or content, or that it re-
>   validate or purge metadata or content.  The upstream CDN can monitor
>   the status of activity that it has triggered in the downstream CDN.
>
>
>
>
>
>
>The IETF Secretariat
