From Jan.Seedorf@neclab.eu Fri Jul 6 08:28:09 2012 Return-Path: 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 3373C21F869F for ; Fri, 6 Jul 2012 08:28:09 -0700 (PDT) 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 HdUNADH+u2hA for ; Fri, 6 Jul 2012 08:28:08 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1465121F860F for ; Fri, 6 Jul 2012 08:28:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 0899910176C; Fri, 6 Jul 2012 17:29:44 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsP8yR7ShH4O; Fri, 6 Jul 2012 17:29:43 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id E2D1C10176B; Fri, 6 Jul 2012 17:29:33 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.191]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Fri, 6 Jul 2012 17:29:53 +0200 From: Jan Seedorf To: Francois Le Faucheur , Jan Seedorf Thread-Topic: [CDNi] Notes from May 30th Design Team Conf Call on "Footprint / Capabilities" Thread-Index: Ac0/+AAx1BBZ6z5uSdC8UfhKh9F8YwCPdrkABlV63EA= Date: Fri, 6 Jul 2012 15:29:52 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24FFFED5@PALLENE.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE24FD5FA0@Polydeuces.office.hd> <4BCEB5FB-EF80-497F-9084-377564194DCB@cisco.com> In-Reply-To: <4BCEB5FB-EF80-497F-9084-377564194DCB@cisco.com> 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 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Notes from May 30th Design Team Conf Call on "Footprint / Capabilities" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 15:28:09 -0000 Hi Francois, Thanks for the additional comments. I am currently updating the "Footprint = / Capabilities" semantics draft so that it captures these discussions and t= he points where we found some agreement. - Jan > -----Original Message----- > From: Francois Le Faucheur [mailto:flefauch@cisco.com] > Sent: Monday, June 04, 2012 1:39 PM > To: Jan Seedorf > Cc: Francois Le Faucheur; cdni@ietf.org > Subject: Re: [CDNi] Notes from May 30th Design Team Conf Call on > "Footprint / Capabilities" >=20 > Hello Jan, >=20 > Thanks for extracting the highlights of our discussion. A few minor comme= nts > below: >=20 > On 1 Jun 2012, at 15:12, Jan Seedorf wrote: >=20 > > Dear all, > > > > Please find attached my notes from the "Footprint / Capabilities" desig= n > team virtual meeting we had this week. > > > > - Jan > > > > Notes CDNI Footprint/Capabilities Call - May 30, 2012 > > *************************************************** > > -- introduction from Francois on goals and scope of the call > > -- Jon/Stefano: summarize status quo, still quite a few open issues and= no > definition for footprint yet, lately some more email activity > > -- agreement that ISP-owned CDN is a main use case, if not the most > important use case; Francois: use-case doc covers multiple scenarios, inc= l. > ISP-CDNs > > -- Jon: focusing on ISP-CDN may simplify things a lot, if for each IP-a= ddress > only one dCDN can serve it; Stefano/Francois: we should not look at only = this > case; > > -- Francois: solution must be able to support a situation with overlapp= ing > footprint, right? Agreement from Stefano, agreement that different dCDN > may claim overlapping footprints > > -- Francois: business models may have an impact on who makes CDN > selection decisions >=20 > Following that, I think there was some discussion and eventually some > agreement that there might be more models but there is one model that we > are clear we need to make work: model where the decision is made by > the uCDN (i.e. uCDN selects the dCDN). >=20 > > -- Stefano: why not focus on a single scenario and focus on the > mechanism? > > -- Enrico: should dCDN advertise where they have the caches or what the > bandwidth is? we need to take the incentive away for the dCDN to cheat > > -- Jon: there are other choices than prefixes for footprints, e.g. "Nor= th > America" or cache locations > > -- Stefano: we should start with a simple case, so prefixes could be a > starting point > > -- Allan: location of caches say nothing about the connectivity to endp= oints > on the Internet > > -- Enrico: we need to have the dCDN advertise something the uCDN can > verify, otherwise dCDN will cheat > > -- Francois: dCDN information should be verifiable, that's a key point = to > note down >=20 > Another related point I tried to make then is that "existence of an incen= tive > to cheat" and "cheat-ability" are more or less common to all "footprint" > approaches. >=20 > > -- Francois: a cheating dCDN may not be the end of the world because > there are strong contractual agreements between uCDN and dCDN > > -- agreement that we do not consider real-time verification of dCDN > statements but afterwards verification of cheating dCDN is fine > > -- Francois: let's try to converge - a) upstream CDN makes the decision= , b) > let's not try to hard to make dCDN information immediately verifiable, >=20 > s/try to hard/try too hard/ >=20 > > c) prefix is probably inevitable as one core footprint definition we co= uld > start working with; Jon: agree with this process suggestion > > -- Jon: how does a over-the-top CDN derive its footprint? > > -- Stefano: would limit the scope, uCDN decision should be made > autonomously > > -- Jon: we need the semantics of what a footprint is/means > > -- Francois: semantic of footprint can be simply willingness to serve > > -- Allan: AS-hops is in fact a metric for quality, hard to define via S= LA for all > users what "good quality" means > > -- Jon: also a question where the work gets done, at the dCDN or at the > uCDN > > -- Francois: footprint means "willingness to serve", we have agreed on = that; >=20 > or perhaps more accurately : footprint means "willingness to serve" + "so= me > topology information to help uCDN assess in how good a position the willi= ng > CDN actually is to serve well". >=20 > > we also have agreed that the uCDN needs more information, >=20 > What I meant here is that the uCDN, to make its dCDN selection, will like= ly > make use of other information than what is provided by the CDNI Footprint > & Advertisement interface (e.g. price between uCDN and dCDN, past > observation of dCDN quality,...). >=20 > Francois >=20 > > there are several proposals how to do this > > -- Jon: need to discuss more on resource advertisement model vs. > coverage / willingness to serve model > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Mon Jul 9 04:55:48 2012 Return-Path: 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 63C9321F876C for ; Mon, 9 Jul 2012 04:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Nra0UztA6mlE for ; Mon, 9 Jul 2012 04:55:47 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id D301721F876A for ; Mon, 9 Jul 2012 04:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=650; q=dns/txt; s=iport; t=1341834972; x=1343044572; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=w+wYytVHL7OPTCfJ+IK+nFOTjrG+pwPVMj+YN8bZ7uA=; b=h8s/GO/Fc9eGzZ0eTelhgiNqkcH2gONY9gWJzzzpPGWE0BlxCv/13wZu jx1Ie1iQHSizGnmRXDZskBIMMTjN5/icgYHltPTu7Ig5N3Vmn0Nt3TqVj 4B1vku0zAU9dvZMYUdRZ45zf73a0kD6E8zlbxwVNDfsIpbpJminZstAGI o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogFAHHG+k+tJXHA/2dsb2JhbABFtAyDYIEHgicSASdRAT5CJwQ1h2uZdYEonzOLQIUsYAOVNo4fgWaCXw X-IronPort-AV: E=Sophos;i="4.77,552,1336348800"; d="scan'208";a="99990936" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 09 Jul 2012 11:56:12 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q69BuCuN007653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Jul 2012 11:56:12 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.17]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0298.004; Mon, 9 Jul 2012 06:56:12 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Agenda requests for CDNI at IETF 84/Vancouver Thread-Index: AQHNXcnVLhLMKP30okeLJRi9vpy1VA== Date: Mon, 9 Jul 2012 11:56:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.195] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19028.005 x-tm-as-result: No--26.242200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Agenda requests for CDNI at IETF 84/Vancouver 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 11:55:48 -0000 Folks, =20 Please send us your agenda requests for the upcoming CDNI WG meeting at IET= F 84. Priority will be given to items on the charter, or to topics already = discussed on the list. =20 If you have requests for agenda slots at the Vancouver meeting, please send= them to Rich and me by August 17, identifying the draft, the length of the= desired scheduled slot and the name of the speaker.=20 =20 Two timeslots have been scheduled for CDNI dring the Vancouver Meeting: * TUESDAY, July 31, 2012 | 0900-1020 Morning Session I * TUESDAY, July 31, 2012 | 1520-1650 Afternoon Session II Cheers =20 -- Francois and Rich= From flefauch@cisco.com Mon Jul 9 06:59:10 2012 Return-Path: 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 29ADC11E8093 for ; Mon, 9 Jul 2012 06:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 f+Mtu+e1LwaJ for ; Mon, 9 Jul 2012 06:59:09 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2FA11E8079 for ; Mon, 9 Jul 2012 06:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=959; q=dns/txt; s=iport; t=1341842374; x=1343051974; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+LJtXYv3SjuSEDZP9uTqeo+wMpTCD2b6w3EViWszDmg=; b=SPQ2cesgST8PQrofTeYDqJgcuhaAuDmc80X2tGqZiOJYdyGTZbGPEbfv LEtm6lKvQ4Huc7udNmaAA6HGYMWNG0MOQ/pr+0JsfqxzaQnmmeoCG6nLt S8hq5XUlqk2QtFCYxQz3S3T21NPzZRtrdLq9HBBT1MTSLTvsKgdBhBOBK o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAH/j+k+tJXG+/2dsb2JhbABFt2yBB4IgAQEBAwEBAQEPASc0CwULAgEINhAnCyUCBA4FIodlBgubRp9DBItAhSxgA5U2jh+BZoJf X-IronPort-AV: E=Sophos;i="4.77,552,1336348800"; d="scan'208";a="100044557" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 09 Jul 2012 13:59:31 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q69DxVJl021070 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Jul 2012 13:59:31 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.17]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0298.004; Mon, 9 Jul 2012 08:59:29 -0500 From: "Francois Le Faucheur (flefauch)" To: "Francois Le Faucheur (flefauch)" Thread-Topic: [CDNi] Agenda requests for CDNI at IETF 84/Vancouver Thread-Index: AQHNXdsOxO3s8JZGmkyHwEDcRrsd0A== Date: Mon, 9 Jul 2012 13:59:29 +0000 Message-ID: <6D68D2B2-0A04-4434-8F2F-D93F5C040F7F@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.195] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19028.005 x-tm-as-result: No--34.525000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <74842028C4E38E47AA626ED613058FD0@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Agenda requests for CDNI at IETF 84/Vancouver 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 13:59:10 -0000 On 9 Jul 2012, at 13:56, Francois Le Faucheur (flefauch) wrote: > Folks, >=20 > Please send us your agenda requests for the upcoming CDNI WG meeting at I= ETF 84. Priority will be given to items on the charter, or to topics alread= y discussed on the list. >=20 > If you have requests for agenda slots at the Vancouver meeting, please se= nd them to Rich and me by August 17, This should read July 17 of course. Sorry for the mistake. Francois > identifying the draft, the length of the desired scheduled slot and the n= ame of the speaker.=20 >=20 > Two timeslots have been scheduled for CDNI dring the Vancouver Meeting: > * TUESDAY, July 31, 2012 | 0900-1020 Morning Session I > * TUESDAY, July 31, 2012 | 1520-1650 Afternoon Session II >=20 > Cheers >=20 > -- Francois and Rich > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From iesg-secretary@ietf.org Mon Jul 9 09:32:53 2012 Return-Path: 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 7DA4911E810E; Mon, 9 Jul 2012 09:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 ripdnaNYYOpV; Mon, 9 Jul 2012 09:32:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8F711E8134; Mon, 9 Jul 2012 09:32:52 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120709163252.26679.15295.idtracker@ietfa.amsl.com> Date: Mon, 09 Jul 2012 09:32:52 -0700 Cc: cdni chair , cdni mailing list , RFC Editor Subject: [CDNi] Document Action: 'Content Distribution Network Interconnection (CDNI) Problem Statement' to Informational RFC (draft-ietf-cdni-problem-statement-08.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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 16:32:53 -0000 The IESG has approved the following document: - 'Content Distribution Network Interconnection (CDNI) Problem Statement' (draft-ietf-cdni-problem-statement-08.txt) as Informational RFC This document is the product of the Content Delivery Networks Interconnection Working Group. The IESG contact persons are Martin Stiemerling and Wesley Eddy. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-cdni-problem-statement/ Technical Summary Content Delivery Networks (CDNs) provide numerous benefits: reduced delivery cost for cacheable content, improved quality of experience for End Users and increased robustness of delivery. For these reasons they are frequently used for large-scale content delivery. As a result, existing CDN Providers are scaling up their infrastructure and many Network Service Providers (NSPs) are deploying their own CDNs. It is generally desirable that a given content item can be delivered to an End User regardless of that End User's location or attachment network. This is the motivation for interconnecting standalone CDNs so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. However, no standards or open specifications currently exist to facilitate such CDN interconnection. The goal of this document is to outline the problem area of CDN interconnection for the IETF CDNI (CDN Interconnection) working group. Working Group Summary There was strong consensus in the CDNI WG to publish this document as its Problem Statement. Document Quality Despite many existing CDN implementations, there are no implementations of CDN interconnection that resolve the functional and operational challenges raised in this Problem Statement. Personnel Richard Woundy (richard_woundy@cable.comcast.com) is the Document Shepherd. Martin Stiemerling is the Responsible Area Director. RFC Editor Note Please replace the first paragraph in Appendix A. "Design considerations for realizing the CDNI Interfaces" with this text OLD This section expands on how CDNI interfaces can reuse and leverage existing protocols before describing each CDNI interface individually and highlighting example candidate protocols that could be considered for reuse or leveraging to implement the CDNI interfaces. NEW This section expands on how CDNI interfaces can reuse and leverage existing protocols before describing each CDNI interface individually and highlighting example candidate protocols that could be considered for reuse or leveraging to implement the CDNI interfaces. However, the options discussed here are purely examples and do not present any consensus on protocols to be used later on. From gilles.bertrand@orange.com Mon Jul 9 10:00:42 2012 Return-Path: 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 6BFC911E80F1 for ; Mon, 9 Jul 2012 10:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[AWL=1.265, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 LjtZH+LbJIpi for ; Mon, 9 Jul 2012 10:00:41 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 76F5E11E80E8 for ; Mon, 9 Jul 2012 10:00:41 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 3D2EB18C185 for ; Mon, 9 Jul 2012 19:01:06 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 25E7823804B for ; Mon, 9 Jul 2012 19:01:06 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Mon, 9 Jul 2012 19:01:02 +0200 From: To: "cdni@ietf.org" Thread-Topic: I-D Action: draft-lelouedec-cdni-request-routing-00.txt Thread-Index: AQHNXfOnkNbM7QU0fkCX0/bmdVoXZ5chK2SQ Date: Mon, 9 Jul 2012 17:00:52 +0000 Message-ID: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.9.151524 Cc: Pilarski Marcin - Korpo TP , MARREC Anne RD-CORE Subject: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 17:00:42 -0000 Hi everyone, We have just submitted the draft below. We are convinced that it will help = the WG to progress on the CDNI routing issues.=20 http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00=20 Any feedback is very welcome. 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 9 juillet 2012 18:55 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-lelouedec-cdni-request-routing-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : CDNI Request Routing Author(s) : Yannick Le Louedec Anne Marrec Gilles Bertrand Marcin Pilarski Filename : draft-lelouedec-cdni-request-routing-00.txt Pages : 30 Date : 2012-07-09 Abstract: The present document proposes to clarify the CDNI Request Routing interface introduced in [I-D.ietf-cdni-framework] and [I-D.ietf-cdni- problem-statement], as well as related terminology. In particular the present document proposes to split the CDNI Request Routing interface into two separate interfaces with clearer roles, named respectively CDNI Routing interface and CDNI Downstream Resource Identifier Signaling interface (CDNI DRIS interface). This part of the CDN interconnection framework the IETF has been referring to so far with the term "CDNI Request Routing" is just another routing, signaling and forwarding problem in a long series of the telecommunication history. For example, one can draw a direct analogy between the IP/MPLS-TE framework and the CDN interconnection framework. In addition, this document recommends that the specification of ALL CDN interconnection interfaces in the scope of the CDNI IETF WG relies on the equivalent concept to IP prefix for CDN interconnection, named 'contentRequestScope'. This highly useful and powerful concept SHALL be used to simplify the specification of ALL CDN interconnection interfaces, as well as to ensure performance and scalability in CDN interconnection. All these proposals can be smoothly integrated in the WG drafts, especially [I-D.ietf-cdni-framework] and [I-D.ietf-cdni-requirements], as they essentially propose (useful) clarifications of the existing framework. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-routing There's also a htmlized version available at: http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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.ie= tf.org/ietf/1shadow-sites.txt ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From ben@niven-jenkins.co.uk Mon Jul 9 11:40:43 2012 Return-Path: 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 D25B521F882C for ; Mon, 9 Jul 2012 11:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.052 X-Spam-Level: X-Spam-Status: No, score=-102.052 tagged_above=-999 required=5 tests=[AWL=0.547, 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 rFRXCfqYzF27 for ; Mon, 9 Jul 2012 11:40:43 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9053D21F8818 for ; Mon, 9 Jul 2012 11:40:42 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginmedia.com ([86.14.227.47] helo=[192.168.0.33]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SoItN-0005bv-Js; Mon, 09 Jul 2012 19:41:06 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Ben Niven-Jenkins In-Reply-To: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> Date: Mon, 9 Jul 2012 19:41:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" , Pilarski Marcin - Korpo TP , MARREC Anne RD-CORE Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 18:40:43 -0000 Colleagues, I started reading draft-lelouedec-cdni-request-routing-00 and this text = caught my eye: Quoting [I-D.ietf-cdni-problem-statement ], "The CDNI Request Routing interface enables a Request Routing function in an upstream CDN to query a Request Routing function in a downstream CDN to determine if the downstream CDN is able (and willing) to accept the delegated content request". The "ability" and the "willingness" of the downstream CDN to accept the delegated content request match two fully different processes in CDN interconnection. And the description of both these processes should be reviewed and clarified for the following reasons: o Regarding the former process, i.e. related to the "ability" ("enables a Request Routing function in an upstream CDN to query a Request Routing function in a downstream CDN to determine if the downstream CDN is able (...) to accept the delegated content request"), a routing protocol is used to achieve such a process, called routing process, in many other technologies and networks (IP, ATM, etc.). In all these technologies, it is the downstream entity that provides routing information to the upstream entity. The same approach should be applied to CDN interconnection. The reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2, dCDN 3, and then it selects one of them based on their responses") would suffer from latency, signaling overhead and/or lack of reactivity to events that impact the ability of the downstream CDNs to accept delegated content requests. o Regarding the latter process, i.e. related to the "willingness" ("enables a Request Routing function in an upstream CDN to query a Request Routing function in a downstream CDN to determine if the downstream CDN (...) is willing (...)to accept the delegated content request"), it is to be noted that the relationship between a uCDN and a dCDN is always in the frame of a contractual agreement between the administrative entity owning the uCDN, acting as the customer, and the administrative entity owning the dCDN, acting as the service provider. Therefore, consider a case where * the uCDN has a content request to redirect which is in full conformance with the terms of this contractual agreement, and * the uCDN has selected this dCDN. As the uCDN knows, thanks to the routing information exchanged via the aforementioned routing process, that the dCDN is able to accept this content request, the uCDN MAY redirect the content request to the dCDN and the dCDN MUST accept the content request. Exchanging over the CDNI Request Routing interface information about the "willingness" of the dCDN to accept the content request is not relevant. I think you might be over thinking what we wrote in the problem = statement. What was in the problem statement was meant to convey that an upstream = CDN could make a request to a downstream CDN to say "how do I redirect = this request to you" and the downstream CDN could reply with either "her = is how to redirect it", or "no I can't/won't take that content delivery = right now", reasons may include the uCDN has requested a delivery of a = protocol the dCDN does not support (possibly in error) or the dCDN has = no capacity right now etc. Ben On 9 Jul 2012, at 18:00, wrote: > Hi everyone, >=20 > We have just submitted the draft below. We are convinced that it will = help the WG to progress on the CDNI routing issues.=20 >=20 > http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00=20 >=20 > Any feedback is very welcome. >=20 > Best regards, >=20 > Gilles >=20 >=20 > -----Message d'origine----- > De : i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] De la part de = internet-drafts@ietf.org > Envoy=E9 : lundi 9 juillet 2012 18:55 > =C0 : i-d-announce@ietf.org > Objet : I-D Action: draft-lelouedec-cdni-request-routing-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : CDNI Request Routing > Author(s) : Yannick Le Louedec > Anne Marrec > Gilles Bertrand > Marcin Pilarski > Filename : draft-lelouedec-cdni-request-routing-00.txt > Pages : 30 > Date : 2012-07-09 >=20 > Abstract: > The present document proposes to clarify the CDNI Request Routing > interface introduced in [I-D.ietf-cdni-framework] and = [I-D.ietf-cdni- > problem-statement], as well as related terminology. >=20 > In particular the present document proposes to split the CDNI = Request > Routing interface into two separate interfaces with clearer roles, > named respectively CDNI Routing interface and CDNI Downstream > Resource Identifier Signaling interface (CDNI DRIS interface). >=20 > This part of the CDN interconnection framework the IETF has been > referring to so far with the term "CDNI Request Routing" is just > another routing, signaling and forwarding problem in a long series = of > the telecommunication history. For example, one can draw a direct > analogy between the IP/MPLS-TE framework and the CDN interconnection > framework. >=20 > In addition, this document recommends that the specification of ALL > CDN interconnection interfaces in the scope of the CDNI IETF WG > relies on the equivalent concept to IP prefix for CDN > interconnection, named 'contentRequestScope'. This highly useful = and > powerful concept SHALL be used to simplify the specification of ALL > CDN interconnection interfaces, as well as to ensure performance and > scalability in CDN interconnection. >=20 > All these proposals can be smoothly integrated in the WG drafts, > especially [I-D.ietf-cdni-framework] and > [I-D.ietf-cdni-requirements], as they essentially propose (useful) > clarifications of the existing framework. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-routing >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From yannick.lelouedec@orange.com Mon Jul 9 12:04:46 2012 Return-Path: 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 B991511E80F3 for ; Mon, 9 Jul 2012 12:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=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 P2mKYTRR2w6L for ; Mon, 9 Jul 2012 12:04:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0742911E8118 for ; Mon, 9 Jul 2012 12:04:44 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 9BC2C18C1A4; Mon, 9 Jul 2012 21:05:09 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 8098335C065; Mon, 9 Jul 2012 21:05:09 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Mon, 9 Jul 2012 21:05:05 +0200 From: To: Ben Niven-Jenkins , BERTRAND Gilles RD-CORE , "cdni@ietf.org" Thread-Topic: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt Thread-Index: AQHNXgJqStc0UltWBEOFYGPrvXLHeZchSTfQ Date: Mon, 9 Jul 2012 19:05:05 +0000 Message-ID: <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> In-Reply-To: <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.9.151524 Cc: Pilarski Marcin - Korpo TP , MARREC Anne RD-CORE Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 19:04:46 -0000 Hi Ben, all, Ben, quoting you mail below, "... the downstream CDN could reply with eithe= r "here is how to redirect it"",=20 =3D> This is the role of the CDNI DRIS interface to provide the uCDN with t= his information, and we target to make its specification public before Vanc= ouver meeting so that everyone may read it before the meeting and get full = knowledge of our proposal about this part of CDNI request routing. Ben, quoting you mail below, "... or "no I can't/won't take that content de= livery right now", reasons may include the uCDN has requested a delivery of= a protocol the dCDN does not support (possibly in error). =3D> This is the role of the CDNI logging interface to provide the uCDN wit= h this information. Ben, quoting you mail below, "... or "no I can't/won't take that content de= livery right now", reasons may include ... the dCDN has no capacity right n= ow etc." =3D> This is the role of the CDNI routing interface to provide the uCDN wit= h this information. So we may conclude we are in line basically, which is a good point. We just aimed at checking there was a common understanding on this point. The key point for us here is that we don't want this sentence extracted fro= m draft-ietf-cdni-problem-statement be interpreted as: ". and the dCDN MUST= accept the content request except when it has not the "ability" to do so." The fact that the dCDN is temporary unable to handle content request correc= tly is not a valid reason for the dCDN to be discharged of its obligations = to the uCDN. The contract set between the uCDN and the dCDN remains valid anyway, and th= e obligations of the dCDN as well. The dCDN must announce to the uCDN that it is temporary unable, as soon as = possible, via the CDNI routing interface. And the uCDN must take this information into account in its CDN selection p= rocess as soon as possible. Then if the uCDN decides to continue to redirect content requests to the dC= DN, the uCDN MAY perfectly do it, but the uCDN knows these content requests= will be lost. We could even imagine the situation where the uCDN continues to do it inten= tionally, because it has no better option and the content request will be l= ost anyway. For example in the case where neither the uCDN nor the other do= wnstream CDNs of the uCDN cannot manage correctly the content request, the = uCDN could do it intentionally so as to be able to clearly prove (with CDNI= logging information) that it is the dCDN, not the uCDN, who is at fault. But, of course, if there are alternative backup options, the normal reactio= n of the uCDN is to stop as soon as possible to redirect content requests t= o the dCDN when the uCDN knows that the dCDN is unable to handle them corre= ctly. So, to be clear, we would prefer the sentence to be understood as: ". and the dCDN MUST accept the content request.=20 And if it cannot handle correctly the redirected content request it receive= s, the content request is lost. For example the dCDN generates a response t= o the content request with an error message, or no response at all. And in = parallel the CDNI logging interface may be used to exchange logs correspond= ing to this problem. Anyway the dCDN MAY NOT redirect that content request = back towards the uCDN."=20 Exactly as in IP networks: IP packets are not sent back towards the origin = by a downstream router under failure or congestion. In both networks (IP and CDN), the reason is the same. If the dCDN redirects back a content request to the uCDN, this generates a = loop.=20 To manage this would introduce a very high complexity. And this would be just to try to save the content requests redirected by th= e uCDN to the dCDN in the timeslot between the time the dCDN gets down and = the time the uCDN takes this failure into account in its CDN selection proc= ess. It is much better to try to reduce this timeslot as much as possible, with = routing optimizations (we will propose as soon as possible). Rather than introducing additional complexities (to manage redirection to t= he uCDN) in the framework. By the way, as you know, the IESG has just approved today the 'Content Dist= ribution Network Interconnection (CDNI) Problem Statement' draft as informa= tional RFC. This is a good point. And, as you may see in the draft "CDNI request routing", we do not propose = to modify this problem statement draft. We want know to focus now on getting the specifications of all CDNI interfa= ces ready as soon as possible. Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de B= en Niven-Jenkins Envoy=E9=A0: lundi 9 juillet 2012 20:41 =C0=A0: BERTRAND Gilles RD-CORE Cc=A0: cdni@ietf.org; Pilarski Marcin - Korpo TP; MARREC Anne RD-CORE Objet=A0: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-0= 0.txt Colleagues, I started reading draft-lelouedec-cdni-request-routing-00 and this text cau= ght my eye: Quoting [I-D.ietf-cdni-problem-statement ], "The CDNI Request Routing interface enables a Request Routing function in an upstream CDN to query a Request Routing function in a downstream CDN to determine if the downstream CDN is able (and willing) to accept the delegated content request". The "ability" and the "willingness" of the downstream CDN to accept the delegated content request match two fully different processes in CDN interconnection. And the description of both these processes should be reviewed and clarified for the following reasons: o Regarding the former process, i.e. related to the "ability" ("enables a Request Routing function in an upstream CDN to query a Request Routing function in a downstream CDN to determine if the downstream CDN is able (...) to accept the delegated content request"), a routing protocol is used to achieve such a process, called routing process, in many other technologies and networks (IP, ATM, etc.). In all these technologies, it is the downstream entity that provides routing information to the upstream entity. The same approach should be applied to CDN interconnection. The reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2, dCDN 3, and then it selects one of them based on their responses") would suffer from latency, signaling overhead and/or lack of reactivity to events that impact the ability of the downstream CDNs to accept delegated content requests. o Regarding the latter process, i.e. related to the "willingness" ("enables a Request Routing function in an upstream CDN to query a Request Routing function in a downstream CDN to determine if the downstream CDN (...) is willing (...)to accept the delegated content request"), it is to be noted that the relationship between a uCDN and a dCDN is always in the frame of a contractual agreement between the administrative entity owning the uCDN, acting as the customer, and the administrative entity owning the dCDN, acting as the service provider. Therefore, consider a case where * the uCDN has a content request to redirect which is in full conformance with the terms of this contractual agreement, and * the uCDN has selected this dCDN. As the uCDN knows, thanks to the routing information exchanged via the aforementioned routing process, that the dCDN is able to accept this content request, the uCDN MAY redirect the content request to the dCDN and the dCDN MUST accept the content request. Exchanging over the CDNI Request Routing interface information about the "willingness" of the dCDN to accept the content request is not relevant. I think you might be over thinking what we wrote in the problem statement. What was in the problem statement was meant to convey that an upstream CDN = could make a request to a downstream CDN to say "how do I redirect this req= uest to you" and the downstream CDN could reply with either "her is how to = redirect it", or "no I can't/won't take that content delivery right now", r= easons may include the uCDN has requested a delivery of a protocol the dCDN= does not support (possibly in error) or the dCDN has no capacity right now= etc. Ben On 9 Jul 2012, at 18:00, wrote: > Hi everyone, >=20 > We have just submitted the draft below. We are convinced that it will hel= p the WG to progress on the CDNI routing issues.=20 >=20 > http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00=20 >=20 > Any feedback is very welcome. >=20 > Best regards, >=20 > Gilles >=20 >=20 > -----Message d'origine----- > De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]= De la part de internet-drafts@ietf.org > Envoy=E9 : lundi 9 juillet 2012 18:55 > =C0 : i-d-announce@ietf.org > Objet : I-D Action: draft-lelouedec-cdni-request-routing-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : CDNI Request Routing > Author(s) : Yannick Le Louedec > Anne Marrec > Gilles Bertrand > Marcin Pilarski > Filename : draft-lelouedec-cdni-request-routing-00.txt > Pages : 30 > Date : 2012-07-09 >=20 > Abstract: > The present document proposes to clarify the CDNI Request Routing > interface introduced in [I-D.ietf-cdni-framework] and [I-D.ietf-cdni- > problem-statement], as well as related terminology. >=20 > In particular the present document proposes to split the CDNI Request > Routing interface into two separate interfaces with clearer roles, > named respectively CDNI Routing interface and CDNI Downstream > Resource Identifier Signaling interface (CDNI DRIS interface). >=20 > This part of the CDN interconnection framework the IETF has been > referring to so far with the term "CDNI Request Routing" is just > another routing, signaling and forwarding problem in a long series of > the telecommunication history. For example, one can draw a direct > analogy between the IP/MPLS-TE framework and the CDN interconnection > framework. >=20 > In addition, this document recommends that the specification of ALL > CDN interconnection interfaces in the scope of the CDNI IETF WG > relies on the equivalent concept to IP prefix for CDN > interconnection, named 'contentRequestScope'. This highly useful and > powerful concept SHALL be used to simplify the specification of ALL > CDN interconnection interfaces, as well as to ensure performance and > scalability in CDN interconnection. >=20 > All these proposals can be smoothly integrated in the WG drafts, > especially [I-D.ietf-cdni-framework] and > [I-D.ietf-cdni-requirements], as they essentially propose (useful) > clarifications of the existing framework. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-routing >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From mcaulfie@cisco.com Mon Jul 9 12:44:18 2012 Return-Path: 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 C364A11E820E for ; Mon, 9 Jul 2012 12:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[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 1w1YLNDQRi6a for ; Mon, 9 Jul 2012 12:44:18 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id DA88E11E820C for ; Mon, 9 Jul 2012 12:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcaulfie@cisco.com; l=8567; q=dns/txt; s=iport; t=1341863083; x=1343072683; h=from:to:cc:subject:date:message-id:mime-version; bh=X3psLAhk0h5P0erhNzpoNKh8tgZDYDXlZpRYm+r7pzo=; b=abYR4cOvH5EphHz4pwJ49nOhc3mnX9PUbfyDg0CJdi1V9s6o/PthYX6V ll86V9F4byxFQTpENUrfwkJC2KApzz0XsTIXSHO0DWD9yU3eSNPksWKWb kCxmd429FWI31HizvqfahANLdmZk7tfVfQ8npd2IWzm484UnBvXvlEiky 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHIz+0+tJV2b/2dsb2JhbABFgkqsKAGJA4EHgiIBBBIBGkwSASpWJgEEDg0ah2sLm22gIZBsYAOWSI0NgWaCXw X-IronPort-AV: E=Sophos;i="4.77,553,1336348800"; d="scan'208,217";a="100163343" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 09 Jul 2012 19:44:43 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q69JihFr005794 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Jul 2012 19:44:43 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0298.004; Mon, 9 Jul 2012 14:44:42 -0500 From: "Matt Caulfield (mcaulfie)" To: "cdni@ietf.org" Thread-Topic: New Metadata Interface Draft (draft-cjlmw-cdni-metadata-00) Thread-Index: Ac1eC0YVScB5jeVWTF6OpuGDrKcS+g== Date: Mon, 9 Jul 2012 19:44:41 +0000 Message-ID: <166EBB70C264A9479E459B01B1BA6C9201B060@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.183.10] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19028.004 x-tm-as-result: No--33.131400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_166EBB70C264A9479E459B01B1BA6C9201B060xmbalnx03ciscocom_" MIME-Version: 1.0 Cc: "Ben Niven-Jenkins \(ben@velocix.com\)" Subject: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni-metadata-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 19:44:18 -0000 --_000_166EBB70C264A9479E459B01B1BA6C9201B060xmbalnx03ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi everyone, As we announced in April, a group of us (Ben Niven-Jenkins, Kent Leung, Rob= Murray, Grant Watson, and I) have been working on a merge of two of the CD= NI metadata interface proposals: - draft-caulfield-cdni-metadata-core-00 - draft-jenkins-cdni-metadata-00 The merged draft has now been submitted: http://tools.ietf.org/html/draft-c= jlmw-cdni-metadata-00 We will be presenting on this draft in Vancouver. Any feedback on the list = is also appreciated. Thanks, Matt --_000_166EBB70C264A9479E459B01B1BA6C9201B060xmbalnx03ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi everyone,

 

As we announced in April, a group of us (= Ben Niven-Jenkins, Kent Leung, Rob Murray, Grant Watson, and I) have been w= orking on a merge of two of the CDNI metadata interface proposals:

-   &nbs= p;   draft-caulfield-cdni-metadata-cor= e-00

-   &nbs= p;   draft-jenkins-cdni-metadata-00

 

The merged draft has now been submitted: = http://tools.ietf.org/html/draft-cjlmw-cdni-metadata-00

 

We will be presenting on this draft in Va= ncouver. Any feedback on the list is also appreciated.

 

Thanks,

Matt

 

 

       = ;            &n= bsp;            = ;            &n= bsp;            = ;        

--_000_166EBB70C264A9479E459B01B1BA6C9201B060xmbalnx03ciscocom_-- From ben@niven-jenkins.co.uk Mon Jul 9 22:37:52 2012 Return-Path: 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 64DE111E814C for ; Mon, 9 Jul 2012 22:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.234 X-Spam-Level: X-Spam-Status: No, score=-102.234 tagged_above=-999 required=5 tests=[AWL=0.365, 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 j8MNz6sQa56h for ; Mon, 9 Jul 2012 22:37:51 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 93F3811E814E for ; Mon, 9 Jul 2012 22:37:50 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginmedia.com ([86.14.227.47] helo=[192.168.0.33]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SoT9L-0008AI-KJ; Tue, 10 Jul 2012 06:38:16 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Ben Niven-Jenkins In-Reply-To: <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> Date: Tue, 10 Jul 2012 06:38:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: Pilarski Marcin - Korpo TP , "cdni@ietf.org" , MARREC Anne RD-CORE Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 05:37:52 -0000 Yannick, Please see inline. On 9 Jul 2012, at 20:05, wrote: > Hi Ben, all, >=20 > Ben, quoting you mail below, "... the downstream CDN could reply with = either "here is how to redirect it"",=20 >=20 > =3D> This is the role of the CDNI DRIS interface to provide the uCDN = with this information, and we target to make its specification public = before Vancouver meeting so that everyone may read it before the meeting = and get full knowledge of our proposal about this part of CDNI request = routing. >=20 > Ben, quoting you mail below, "... or "no I can't/won't take that = content delivery right now", reasons may include the uCDN has requested = a delivery of a protocol the dCDN does not support (possibly in error). >=20 > =3D> This is the role of the CDNI logging interface to provide the = uCDN with this information. I agree this information should be logged but the Request Routing = interface (what you call the DRIS) also needs to be able to indicate a = failure. Otherwise the uCDN will 'blindly' redirect the the dCDN and the delivery = will fail leading to poor end user experience. > Ben, quoting you mail below, "... or "no I can't/won't take that = content delivery right now", reasons may include ... the dCDN has no = capacity right now etc." >=20 > =3D> This is the role of the CDNI routing interface to provide the = uCDN with this information. It is the role of the CDN capability/routing interface to advertise = broad capabilities etc not to give extremely fine grained real-time = information on exactly the state of the dCDN. Even if the capability/routing interface is real-time there are likely = to still be race conditions where we need the dCDN to be about to = indicate a failure to accept a redirect through the request routing/DRIS = interface > So we may conclude we are in line basically, which is a good point. > We just aimed at checking there was a common understanding on this = point. >=20 > The key point for us here is that we don't want this sentence = extracted from draft-ietf-cdni-problem-statement be interpreted as: ". = and the dCDN MUST accept the content request except when it has not the = "ability" to do so." Why not? IMO that is a valid scenario for some use cases. > The fact that the dCDN is temporary unable to handle content request = correctly is not a valid reason for the dCDN to be discharged of its = obligations to the uCDN. > The contract set between the uCDN and the dCDN remains valid anyway, = and the obligations of the dCDN as well. Correct, but that contract may not be the same for all uCDNs & dCDNs, = for example a uCDN may not have a guarantee that a dCDN can handle = everything it is requested to handle but the contract may only be that = the dCDN guarantees to handle up to a certain volume of traffic. > The dCDN must announce to the uCDN that it is temporary unable, as = soon as possible, via the CDNI routing interface. > And the uCDN must take this information into account in its CDN = selection process as soon as possible. > Then if the uCDN decides to continue to redirect content requests to = the dCDN, the uCDN MAY perfectly do it, but the uCDN knows these content = requests will be lost. What happens in the period between the dCDN being unable to handle = requests and the time it takes to advertise that to the uCDN and for the = uCDN to process & incorporate that new knowledge? Are requests blindly = forwarded to the dCDN which is unable to handle them leading to poor = user experience? > We could even imagine the situation where the uCDN continues to do it = intentionally, because it has no better option and the content request = will be lost anyway. For example in the case where neither the uCDN nor = the other downstream CDNs of the uCDN cannot manage correctly the = content request, the uCDN could do it intentionally so as to be able to = clearly prove (with CDNI logging information) that it is the dCDN, not = the uCDN, who is at fault. > But, of course, if there are alternative backup options, the normal = reaction of the uCDN is to stop as soon as possible to redirect content = requests to the dCDN when the uCDN knows that the dCDN is unable to = handle them correctly. >=20 > So, to be clear, we would prefer the sentence to be understood as: > ". and the dCDN MUST accept the content request.=20 > And if it cannot handle correctly the redirected content request it = receives, the content request is lost. What about scenarios where the uCDN has a choice of dCDNs (e.g. two = national-wide CDNs offering services at different costs), the uCDN may = elect to query both dCDNs and decide based on their responses which one = to choose. If the dCDN is unable to satisfy the request the uCDN needs = to know that so that it can fallback to the (more expensive in this = example) dCDN. > For example the dCDN generates a response to the content request with = an error message, or no response at all. And in parallel the CDNI = logging interface may be used to exchange logs corresponding to this = problem. Anyway the dCDN MAY NOT redirect that content request back = towards the uCDN."=20 >=20 > Exactly as in IP networks: IP packets are not sent back towards the = origin by a downstream router under failure or congestion. In a routed IP network, there is often a small packet loss while the = network re-converges, by enabling the dCDN to refuse a redirection at = CDNI Request Routing/DRIS query time we can reduce that window by giving = the uCDN the option to take an alternative action (e.g. try another = dCDN) while the routing/capability information re-converges. > In both networks (IP and CDN), the reason is the same. > If the dCDN redirects back a content request to the uCDN, this = generates a loop.=20 Loop avoidance is a separate issue IMO to whether we should allow a dCDN = to be able to communicate "I am unable/unwilling to take that content = delivery at this time". Regards Ben > To manage this would introduce a very high complexity. > And this would be just to try to save the content requests redirected = by the uCDN to the dCDN in the timeslot between the time the dCDN gets = down and the time the uCDN takes this failure into account in its CDN = selection process. > It is much better to try to reduce this timeslot as much as possible, = with routing optimizations (we will propose as soon as possible). > Rather than introducing additional complexities (to manage redirection = to the uCDN) in the framework. >=20 >=20 > By the way, as you know, the IESG has just approved today the 'Content = Distribution Network Interconnection (CDNI) Problem Statement' draft as = informational RFC. This is a good point. > And, as you may see in the draft "CDNI request routing", we do not = propose to modify this problem statement draft. > We want know to focus now on getting the specifications of all CDNI = interfaces ready as soon as possible. >=20 > Best regards, >=20 > Yannick Le Lou=E9dec. >=20 >=20 > -----Message d'origine----- > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part = de Ben Niven-Jenkins > Envoy=E9 : lundi 9 juillet 2012 20:41 > =C0 : BERTRAND Gilles RD-CORE > Cc : cdni@ietf.org; Pilarski Marcin - Korpo TP; MARREC Anne RD-CORE > Objet : Re: [CDNi] TR: I-D Action: = draft-lelouedec-cdni-request-routing-00.txt >=20 > Colleagues, >=20 > I started reading draft-lelouedec-cdni-request-routing-00 and this = text caught my eye: >=20 > Quoting [I-D.ietf-cdni-problem-statement > ], "The CDNI Request Routing > interface enables a Request Routing function in an upstream CDN to > query a Request Routing function in a downstream CDN to determine if > the downstream CDN is able (and willing) to accept the delegated > content request". >=20 > The "ability" and the "willingness" of the downstream CDN to accept > the delegated content request match two fully different processes in > CDN interconnection. And the description of both these processes > should be reviewed and clarified for the following reasons: >=20 > o Regarding the former process, i.e. related to the "ability" > ("enables a Request Routing function in an upstream CDN to query = a > Request Routing function in a downstream CDN to determine if the > downstream CDN is able (...) to accept the delegated content > request"), a routing protocol is used to achieve such a process, > called routing process, in many other technologies and networks > (IP, ATM, etc.). In all these technologies, it is the downstream > entity that provides routing information to the upstream entity. > The same approach should be applied to CDN interconnection. The > reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN = 2, > dCDN 3, and then it selects one of them based on their = responses") > would suffer from latency, signaling overhead and/or lack of > reactivity to events that impact the ability of the downstream > CDNs to accept delegated content requests. >=20 > o Regarding the latter process, i.e. related to the "willingness" > ("enables a Request Routing function in an upstream CDN to query = a > Request Routing function in a downstream CDN to determine if the > downstream CDN (...) is willing (...)to accept the delegated > content request"), it is to be noted that the relationship = between > a uCDN and a dCDN is always in the frame of a contractual > agreement between the administrative entity owning the uCDN, > acting as the customer, and the administrative entity owning the > dCDN, acting as the service provider. Therefore, consider a case > where >=20 > * the uCDN has a content request to redirect which is in full > conformance with the terms of this contractual agreement, and >=20 > * the uCDN has selected this dCDN. >=20 > As the uCDN knows, thanks to the routing information exchanged = via > the aforementioned routing process, that the dCDN is able to > accept this content request, the uCDN MAY redirect the content > request to the dCDN and the dCDN MUST accept the content request. > Exchanging over the CDNI Request Routing interface information > about the "willingness" of the dCDN to accept the content request > is not relevant. >=20 > I think you might be over thinking what we wrote in the problem = statement. >=20 > What was in the problem statement was meant to convey that an upstream = CDN could make a request to a downstream CDN to say "how do I redirect = this request to you" and the downstream CDN could reply with either "her = is how to redirect it", or "no I can't/won't take that content delivery = right now", reasons may include the uCDN has requested a delivery of a = protocol the dCDN does not support (possibly in error) or the dCDN has = no capacity right now etc. >=20 > Ben >=20 > On 9 Jul 2012, at 18:00, wrote: >=20 >> Hi everyone, >>=20 >> We have just submitted the draft below. We are convinced that it will = help the WG to progress on the CDNI routing issues.=20 >>=20 >> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00=20 >>=20 >> Any feedback is very welcome. >>=20 >> Best regards, >>=20 >> Gilles >>=20 >>=20 >> -----Message d'origine----- >> De : i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] De la part de = internet-drafts@ietf.org >> Envoy=E9 : lundi 9 juillet 2012 18:55 >> =C0 : i-d-announce@ietf.org >> Objet : I-D Action: draft-lelouedec-cdni-request-routing-00.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >>=20 >> Title : CDNI Request Routing >> Author(s) : Yannick Le Louedec >> Anne Marrec >> Gilles Bertrand >> Marcin Pilarski >> Filename : draft-lelouedec-cdni-request-routing-00.txt >> Pages : 30 >> Date : 2012-07-09 >>=20 >> Abstract: >> The present document proposes to clarify the CDNI Request Routing >> interface introduced in [I-D.ietf-cdni-framework] and = [I-D.ietf-cdni- >> problem-statement], as well as related terminology. >>=20 >> In particular the present document proposes to split the CDNI = Request >> Routing interface into two separate interfaces with clearer roles, >> named respectively CDNI Routing interface and CDNI Downstream >> Resource Identifier Signaling interface (CDNI DRIS interface). >>=20 >> This part of the CDN interconnection framework the IETF has been >> referring to so far with the term "CDNI Request Routing" is just >> another routing, signaling and forwarding problem in a long series = of >> the telecommunication history. For example, one can draw a direct >> analogy between the IP/MPLS-TE framework and the CDN interconnection >> framework. >>=20 >> In addition, this document recommends that the specification of ALL >> CDN interconnection interfaces in the scope of the CDNI IETF WG >> relies on the equivalent concept to IP prefix for CDN >> interconnection, named 'contentRequestScope'. This highly useful = and >> powerful concept SHALL be used to simplify the specification of ALL >> CDN interconnection interfaces, as well as to ensure performance and >> scalability in CDN interconnection. >>=20 >> All these proposals can be smoothly integrated in the WG drafts, >> especially [I-D.ietf-cdni-framework] and >> [I-D.ietf-cdni-requirements], as they essentially propose (useful) >> clarifications of the existing framework. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-routing >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> 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 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >> France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or = privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> 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 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > Thank you. >=20 From ray.vanbrandenburg@tno.nl Tue Jul 10 00:19:19 2012 Return-Path: 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 7B69211E8121 for ; Tue, 10 Jul 2012 00:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.152 X-Spam-Level: * X-Spam-Status: No, score=1.152 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_QP_LONG_LINE=1.396] 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 EVxsy6EFemd0 for ; Tue, 10 Jul 2012 00:19:18 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC3811E80D1 for ; Tue, 10 Jul 2012 00:19:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,558,1336341600"; d="scan'208";a="15722064" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1b.tno.nl with ESMTP; 10 Jul 2012 09:19:42 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.152]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.02.0298.004; Tue, 10 Jul 2012 09:19:42 +0200 From: "Brandenburg, R. (Ray) van" To: Ben Niven-Jenkins , "yannick.lelouedec@orange.com" Thread-Topic: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt Thread-Index: AQHNXl47wTvj/yUIuE6cgCkhzleNz5ciGhJQ Date: Tue, 10 Jul 2012 07:19:42 +0000 Message-ID: References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "cdni@ietf.org" , Pilarski Marcin - Korpo TP , MARREC Anne RD-CORE Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 07:19:19 -0000 Hi Yannick, Ben, I tend to agree with Ben here. When reading the draft, I got the feeling th= at the draft seems to assume a lot about the relationship between the uCDN = and dCDN. For example, I don't see why the CDNI Request Routing interface s= hould state that a dCDN MUST deliver the content if it has indicated its ab= ility to do so earlier in either a contractual agreement or in the capabili= ty interface. I understand that in most cases, the contractual agreement mi= ght indeed impose this behavior on the dCDN, but I don't think this type of= behavior should be imposed by the protocol we're developing here. = It was always my assumption that the Request Routing Interface would at lea= st include the option of allowing the uCDN to query the dCDN for every cont= ent request whether the dCDN is willing to deliver that particular request. = I will send my full review of the draft later. = Ray -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben= Niven-Jenkins Sent: dinsdag 10 juli 2012 7:38 To: yannick.lelouedec@orange.com Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00= .txt Yannick, Please see inline. On 9 Jul 2012, at 20:05, wrote: > Hi Ben, all, > = > Ben, quoting you mail below, "... the downstream CDN could reply with = > either "here is how to redirect it"", > = > =3D> This is the role of the CDNI DRIS interface to provide the uCDN with= this information, and we target to make its specification public before Va= ncouver meeting so that everyone may read it before the meeting and get ful= l knowledge of our proposal about this part of CDNI request routing. > = > Ben, quoting you mail below, "... or "no I can't/won't take that content = delivery right now", reasons may include the uCDN has requested a delivery = of a protocol the dCDN does not support (possibly in error). > = > =3D> This is the role of the CDNI logging interface to provide the uCDN w= ith this information. I agree this information should be logged but the Request Routing interface= (what you call the DRIS) also needs to be able to indicate a failure. Otherwise the uCDN will 'blindly' redirect the the dCDN and the delivery wi= ll fail leading to poor end user experience. > Ben, quoting you mail below, "... or "no I can't/won't take that content = delivery right now", reasons may include ... the dCDN has no capacity right= now etc." > = > =3D> This is the role of the CDNI routing interface to provide the uCDN w= ith this information. It is the role of the CDN capability/routing interface to advertise broad c= apabilities etc not to give extremely fine grained real-time information on= exactly the state of the dCDN. Even if the capability/routing interface is real-time there are likely to s= till be race conditions where we need the dCDN to be about to indicate a fa= ilure to accept a redirect through the request routing/DRIS interface > So we may conclude we are in line basically, which is a good point. > We just aimed at checking there was a common understanding on this point. > = > The key point for us here is that we don't want this sentence extracted f= rom draft-ietf-cdni-problem-statement be interpreted as: ". and the dCDN MU= ST accept the content request except when it has not the "ability" to do so= ." Why not? IMO that is a valid scenario for some use cases. > The fact that the dCDN is temporary unable to handle content request corr= ectly is not a valid reason for the dCDN to be discharged of its obligation= s to the uCDN. > The contract set between the uCDN and the dCDN remains valid anyway, and = the obligations of the dCDN as well. Correct, but that contract may not be the same for all uCDNs & dCDNs, for e= xample a uCDN may not have a guarantee that a dCDN can handle everything it= is requested to handle but the contract may only be that the dCDN guarante= es to handle up to a certain volume of traffic. > The dCDN must announce to the uCDN that it is temporary unable, as soon a= s possible, via the CDNI routing interface. > And the uCDN must take this information into account in its CDN selection= process as soon as possible. > Then if the uCDN decides to continue to redirect content requests to the = dCDN, the uCDN MAY perfectly do it, but the uCDN knows these content reques= ts will be lost. What happens in the period between the dCDN being unable to handle requests= and the time it takes to advertise that to the uCDN and for the uCDN to pr= ocess & incorporate that new knowledge? Are requests blindly forwarded to t= he dCDN which is unable to handle them leading to poor user experience? > We could even imagine the situation where the uCDN continues to do it int= entionally, because it has no better option and the content request will be= lost anyway. For example in the case where neither the uCDN nor the other = downstream CDNs of the uCDN cannot manage correctly the content request, th= e uCDN could do it intentionally so as to be able to clearly prove (with CD= NI logging information) that it is the dCDN, not the uCDN, who is at fault. > But, of course, if there are alternative backup options, the normal react= ion of the uCDN is to stop as soon as possible to redirect content requests= to the dCDN when the uCDN knows that the dCDN is unable to handle them cor= rectly. > = > So, to be clear, we would prefer the sentence to be understood as: > ". and the dCDN MUST accept the content request. = > And if it cannot handle correctly the redirected content request it recei= ves, the content request is lost. What about scenarios where the uCDN has a choice of dCDNs (e.g. two nationa= l-wide CDNs offering services at different costs), the uCDN may elect to qu= ery both dCDNs and decide based on their responses which one to choose. If = the dCDN is unable to satisfy the request the uCDN needs to know that so th= at it can fallback to the (more expensive in this example) dCDN. > For example the dCDN generates a response to the content request with an = error message, or no response at all. And in parallel the CDNI logging inte= rface may be used to exchange logs corresponding to this problem. Anyway th= e dCDN MAY NOT redirect that content request back towards the uCDN." = > = > Exactly as in IP networks: IP packets are not sent back towards the origi= n by a downstream router under failure or congestion. In a routed IP network, there is often a small packet loss while the networ= k re-converges, by enabling the dCDN to refuse a redirection at CDNI Reques= t Routing/DRIS query time we can reduce that window by giving the uCDN the = option to take an alternative action (e.g. try another dCDN) while the rout= ing/capability information re-converges. > In both networks (IP and CDN), the reason is the same. > If the dCDN redirects back a content request to the uCDN, this generates = a loop. = Loop avoidance is a separate issue IMO to whether we should allow a dCDN to= be able to communicate "I am unable/unwilling to take that content deliver= y at this time". Regards Ben > To manage this would introduce a very high complexity. > And this would be just to try to save the content requests redirected by = the uCDN to the dCDN in the timeslot between the time the dCDN gets down an= d the time the uCDN takes this failure into account in its CDN selection pr= ocess. > It is much better to try to reduce this timeslot as much as possible, wit= h routing optimizations (we will propose as soon as possible). > Rather than introducing additional complexities (to manage redirection to= the uCDN) in the framework. > = > = > By the way, as you know, the IESG has just approved today the 'Content Di= stribution Network Interconnection (CDNI) Problem Statement' draft as infor= mational RFC. This is a good point. > And, as you may see in the draft "CDNI request routing", we do not propos= e to modify this problem statement draft. > We want know to focus now on getting the specifications of all CDNI inter= faces ready as soon as possible. > = > Best regards, > = > Yannick Le Lou=E9dec. > = > = > -----Message d'origine----- > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part = > de Ben Niven-Jenkins Envoy=E9 : lundi 9 juillet 2012 20:41 =C0 : BERTRAND = > Gilles RD-CORE Cc : cdni@ietf.org; Pilarski Marcin - Korpo TP; MARREC = > Anne RD-CORE Objet : Re: [CDNi] TR: I-D Action: = > draft-lelouedec-cdni-request-routing-00.txt > = > Colleagues, > = > I started reading draft-lelouedec-cdni-request-routing-00 and this text c= aught my eye: > = > Quoting [I-D.ietf-cdni-problem-statement ], "The CDNI Request = > Routing > interface enables a Request Routing function in an upstream CDN to > query a Request Routing function in a downstream CDN to determine if > the downstream CDN is able (and willing) to accept the delegated > content request". > = > The "ability" and the "willingness" of the downstream CDN to accept > the delegated content request match two fully different processes in > CDN interconnection. And the description of both these processes > should be reviewed and clarified for the following reasons: > = > o Regarding the former process, i.e. related to the "ability" > ("enables a Request Routing function in an upstream CDN to query a > Request Routing function in a downstream CDN to determine if the > downstream CDN is able (...) to accept the delegated content > request"), a routing protocol is used to achieve such a process, > called routing process, in many other technologies and networks > (IP, ATM, etc.). In all these technologies, it is the downstream > entity that provides routing information to the upstream entity. > The same approach should be applied to CDN interconnection. The > reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2, > dCDN 3, and then it selects one of them based on their responses") > would suffer from latency, signaling overhead and/or lack of > reactivity to events that impact the ability of the downstream > CDNs to accept delegated content requests. > = > o Regarding the latter process, i.e. related to the "willingness" > ("enables a Request Routing function in an upstream CDN to query a > Request Routing function in a downstream CDN to determine if the > downstream CDN (...) is willing (...)to accept the delegated > content request"), it is to be noted that the relationship between > a uCDN and a dCDN is always in the frame of a contractual > agreement between the administrative entity owning the uCDN, > acting as the customer, and the administrative entity owning the > dCDN, acting as the service provider. Therefore, consider a case > where > = > * the uCDN has a content request to redirect which is in full > conformance with the terms of this contractual agreement, and > = > * the uCDN has selected this dCDN. > = > As the uCDN knows, thanks to the routing information exchanged via > the aforementioned routing process, that the dCDN is able to > accept this content request, the uCDN MAY redirect the content > request to the dCDN and the dCDN MUST accept the content request. > Exchanging over the CDNI Request Routing interface information > about the "willingness" of the dCDN to accept the content request > is not relevant. > = > I think you might be over thinking what we wrote in the problem statement. > = > What was in the problem statement was meant to convey that an upstream CD= N could make a request to a downstream CDN to say "how do I redirect this r= equest to you" and the downstream CDN could reply with either "her is how t= o redirect it", or "no I can't/won't take that content delivery right now",= reasons may include the uCDN has requested a delivery of a protocol the dC= DN does not support (possibly in error) or the dCDN has no capacity right n= ow etc. > = > Ben > = > On 9 Jul 2012, at 18:00, wrote: > = >> Hi everyone, >> = >> We have just submitted the draft below. We are convinced that it will he= lp the WG to progress on the CDNI routing issues. = >> = >> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >> = >> Any feedback is very welcome. >> = >> Best regards, >> = >> Gilles >> = >> = >> -----Message d'origine----- >> De : i-d-announce-bounces@ietf.org = >> [mailto:i-d-announce-bounces@ietf.org] De la part de = >> internet-drafts@ietf.org Envoy=E9 : lundi 9 juillet 2012 18:55 =C0 : = >> i-d-announce@ietf.org Objet : I-D Action: = >> draft-lelouedec-cdni-request-routing-00.txt >> = >> = >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> = >> = >> Title : CDNI Request Routing >> Author(s) : Yannick Le Louedec >> Anne Marrec >> Gilles Bertrand >> Marcin Pilarski >> Filename : draft-lelouedec-cdni-request-routing-00.txt >> Pages : 30 >> Date : 2012-07-09 >> = >> Abstract: >> The present document proposes to clarify the CDNI Request Routing = >> interface introduced in [I-D.ietf-cdni-framework] and [I-D.ietf-cdni- = >> problem-statement], as well as related terminology. >> = >> In particular the present document proposes to split the CDNI = >> Request Routing interface into two separate interfaces with clearer = >> roles, named respectively CDNI Routing interface and CDNI Downstream = >> Resource Identifier Signaling interface (CDNI DRIS interface). >> = >> This part of the CDN interconnection framework the IETF has been = >> referring to so far with the term "CDNI Request Routing" is just = >> another routing, signaling and forwarding problem in a long series of = >> the telecommunication history. For example, one can draw a direct = >> analogy between the IP/MPLS-TE framework and the CDN interconnection = >> framework. >> = >> In addition, this document recommends that the specification of ALL = >> CDN interconnection interfaces in the scope of the CDNI IETF WG = >> relies on the equivalent concept to IP prefix for CDN = >> interconnection, named 'contentRequestScope'. This highly useful and = >> powerful concept SHALL be used to simplify the specification of ALL = >> CDN interconnection interfaces, as well as to ensure performance and = >> scalability in CDN interconnection. >> = >> All these proposals can be smoothly integrated in the WG drafts, = >> especially [I-D.ietf-cdni-framework] and = >> [I-D.ietf-cdni-requirements], as they essentially propose (useful) = >> clarifications of the existing framework. >> = >> = >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-routing >> = >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >> = >> = >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> = >> _______________________________________________ >> 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 >> = >> _____________________________________________________________________ >> ____________________________________________________ >> = >> Ce message et ses pieces jointes peuvent contenir des informations = >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, = >> exploites ou copies sans autorisation. Si vous avez recu ce message = >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >> = >> This message and its attachments may contain confidential or = >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for mess= ages that have been modified, changed or falsified. >> Thank you. >> = >> _______________________________________________ >> 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 > = > ______________________________________________________________________ > ___________________________________________________ > = > Ce message et ses pieces jointes peuvent contenir des informations = > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, = > exploites ou copies sans autorisation. Si vous avez recu ce message = > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, France Telecom - Orange decline toute responsabilite si ce message a e= te altere, deforme ou falsifie. Merci. > = > This message and its attachments may contain confidential or = > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. > = _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From yannick.lelouedec@orange.com Tue Jul 10 02:15:09 2012 Return-Path: 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 57D5D11E80B7 for ; Tue, 10 Jul 2012 02:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=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 MmlVj2C9Rx1x for ; Tue, 10 Jul 2012 02:15:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1ED11E808E for ; Tue, 10 Jul 2012 02:15:05 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id F28692DC31B; Tue, 10 Jul 2012 11:15:31 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id D729135C045; Tue, 10 Jul 2012 11:15:31 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Tue, 10 Jul 2012 11:15:27 +0200 From: To: Ben Niven-Jenkins Thread-Topic: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt Thread-Index: AQHNXl4+FbkrQXSpW0OtdmHifLoRFZciOrZQ Date: Tue, 10 Jul 2012 09:15:26 +0000 Message-ID: <4475_1341911731_4FFBF2B3_4475_4500_1_c732b4d9-1beb-40c8-8381-1da9c58c7368@PEXCVZYH01.corporate.adroot.infra.ftgroup> References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.10.71528 Cc: Pilarski Marcin - Korpo TP , "cdni@ietf.org" , MARREC Anne RD-CORE Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 09:15:09 -0000 Hi Ben, All, Good. These are exactly the comments we expected to receive. This gives us the opportunity to share additional comments, and thus to eas= e an efficient meeting in Vancouver. 1) In the case where "the uCDN has requested a delivery of a protocol the d= CDN does not support (possibly in error)", quoting your mail: "the Request = Routing interface. also needs to be able to indicate a failure". We do not agree with that, and this does not solve the problem you mention = anyway. First example, please consider the case where:=20 *** the uCDN receives a content request from an end user agent *** for this content request, the uCDN has requested over the CDNI request = routing interface a delivery of a protocol that the dCDN does support (and = that is in full conformance with the terms of the contractual agreement bet= ween the uCDN and the dCDN); let us consider this protocol is HTTP,=20 *** the dCDN sends a response to the uCDN over the CDNI request routing int= erface that validates the CDNI request routing request. *** the uCDN then erroneously generates a response to the content request (= to redirect this content request to the dCDN) with the RTSP protocol. =20=20=20 As you can see, your proposal does not solve anyway the problem you mention= . This content request will be lost. Second example, please consider the case where:=20 *** the uCDN receives a content request from an end user agent *** for this content request the uCDN has requested over the CDNI request r= outing interface a delivery of a protocol that the dCDN does support (and t= hat is in full conformance with the terms of the contractual agreement betw= een the uCDN and the dCDN); let us consider this protocol is HTTP,=20 *** the dCDN sends a response to the uCDN over the CDNI request routing int= erface that validates the CDNI request routing request. *** the uCDN then generates a response to the content request (to redirect = this content request to the dCDN) with the HTTP protocol. *** a failure happens in the dCDN before the redirected content request arr= ives to the dCDN and this failure makes the dCDN unable to handle correctly= the content request. The content request will be lost also in this second example. This second example is to stress out that, whatever the specifications of t= he CDNI interfaces, if the redirection of the content request relies on the= end user (case of applicative content request redirection: HTTP redirectio= n, RTSP redirection) or its local DNS server (case of DNS based content req= uest redirection), the uCDN ALWAYS 'blindly' redirects the content request = to the dCDN and the delivery may fail if a failure happens at the same time= in the dCDN (leading indeed to poor end user experience). This is, we would say, the so-called debate between the PUSH and PULL CDNI = routing approaches: *** The PUSH approach consists in the dCDN to take the initiative to announ= ce to the uCDN that it is temporary unable, as soon as possible, via the CD= NI routing interface. *** The PULL approach consists in the uCDN to query its downstream CDNs (dC= DN 1, dCDN 2, dCDN 3, etc.), via the CDNI request routing interface, and th= en to select one of them based on their responses received over the CDNI re= quest routing interface.=20 In both these approaches there is indeed ALWAYS a 'blind' window, between t= he time the dCDN sends its latest message over the CDNI request routing int= erface to the uCDN and the time the redirected content request reaches the = selected dCDN, where there is anyway no guarantee the redirected content re= quest will be correctly handled by the dCDN and no possibility to save this= redirected content request if the dCDN has got down. The PULL approach imposes the uCDN to send a request over the CDNI request = routing interfaces set up with some or all of its dCDNs EVERYTIME it receiv= es a content request he may wish to redirect towards one of these dCDNs. This would suffer from latency, signaling overhead and/or lack of reactivit= y to events that impact the ability of the downstream CDNs to accept delega= ted content requests. Moreover these issues are exacerbated in the recursiv= e mode in the case of cascaded CDNs topology (when each dCDN of the uCDN ha= s its own dCDNs which have their own dCDNs.).=20 And anyway this does not provide full guarantee that the content request wi= ll be correctly handled by the dCDN. The PUSH does not provide full guarantee either (as full guarantee is anywa= y impossible to ensure). But it addresses much better all the scalability a= nd performance issues faced by the PULL approach.=20=20=20=20 As mentioned below, the objective is then to reduce as much as possible thi= s 'blind' window. So, to sum up, the IETF CDNI WG has the following options and it should mak= e a choice as soon as possible. *** Adopt the PUSH routing approach and work on routing optimization to red= uce the "blind" window (as IETF did for IP routing). *** Adopt the PULL routing approach, knowing there will be anyway a "bind" = window too, and knowing the impacts in terms of scalability, latency, signa= ling overhead of this option. *** or Adopt both approaches, knowing this option will be the longest to sp= ecify (while market players need standards urgently). 2) Quoting your mail: "It is the role of the CDN capability/routing interfa= ce to advertise broad capabilities etc not to give extremely fine grained r= eal-time information on exactly the state of the dCDN." We do not agree. Both cases/approaches could be possibly envisioned. Otherwise please explain and justify what is the difference and/or limit be= tween "broad capabilities" and "extremely fine grained real-time informatio= n". Let us consider the situation where the dCDN is temporarily overloaded, i.e= . it is temporary not able to handle requests correctly. In this situation, one can distinguish 2 possible cases/approaches. This de= pends basically on whether the corresponding content delivery service has s= trong quality requirements or not. *** Case 1 (typically for high quality content delivery services) This is the case where the uCDN MUST absolutely avoid to redirect content r= equests, even temporary, to this dCDN that cannot manage them, even tempora= ry.=20 The uCDN MUST take this information "This dCDN is temporary unable to handl= e requests" into account in its CDN selection process. This information is obtained via the CDNI routing process (CDNI routing int= erface). Either the dCDN sends a routing update with this information. Or the dCDN is so overloaded that it cannot send any message, even keepaliv= e messages; therefore the uCDN detects it does not receive keep-alive messa= ges anymore and thus it infers that the dCDN is unavailable. Anyway it stops to select this dCDN for the next content request redirectio= ns. Once the overload situation is over, the dCDN sends routing updates and/or = routing keep-alive messages to inform the uCDN that it is back to a nominal= situation. The uCDN may then select it again. *** Case 2 ("best effort" service) This is the case where the uCDN and dCDN consider they may tolerate tempora= ry overload situations without taking this into account in the CDN selectio= n process, and thus in the CDNI routing process. No CDNI routing update is exchanged on overload situation. The content requests redirected during the overload period are lost. Just as for the "best effort" IP transport over Internet; Basically IP rout= ing protocols do not exchange such overload information. Quality and overload/congestion situation are managed by over-dimensioning = networks, by monitoring carefully congestion levels in networks, and by "tr= affic engineering" traffic (fine-tuning of BGP parameters, etc.) in case of= severe congestion situations. So both these cases/approaches could be possibly envisioned. Then it is up to the IETF members to decide on if both these cases (or only= case 2) should be captured in the specification of the CDNI routing interf= ace. We recommend to capture both cases.=20 Otherwise, as mentioned above, please explain and justify what is the diffe= rence and/or limit between "broad capabilities" and "extremely fine grained= real-time information", between an overload situation and a failure. If both cases are captured, the question, when setting CDN interconnection = in the real world, is then the compromise to set between scalability/stabil= ity in the control plane and quality of service in the transport plane. This will be up to the players who manage the interconnected CDNs to agree = on that, depending of the capability of their CDNs and the services to be s= upported, and to configure their interfaces adequately. 3) Quoting your mail : "Even if the capability/routing interface is real-ti= me there are likely to still be race conditions where we need the dCDN to b= e about to indicate a failure to accept a redirect through the request rout= ing/DRIS interface" See above, you are referring again to this 'blind' window that it is anyway= impossible to delete. 4) Quoting your mail: "Why not? IMO that is a valid scenario for some use c= ases." Because, as mentioned in my previous mail, the fact that the dCDN is tempor= ary unable to handle content request correctly is not a valid reason for th= e dCDN to be discharged of its obligations to the uCDN. The contract set be= tween the uCDN and the dCDN remains valid anyway, and the obligations of th= e dCDN as well. 5) Quoting your mail: "Correct, but that contract may not be the same for a= ll uCDNs & dCDNs, for example a uCDN may not have a guarantee that a dCDN c= an handle everything it is requested to handle but the contract may only be= that the dCDN guarantees to handle up to a certain volume of traffic." We do not claim that the contracts have to be the same for all uCDNs and dC= DNS. A given contract set between a given uCDN and a given dCDN MUST indicate ei= ther some limitations (e.g. Max number of requests per second, or Max volum= e of delivery traffic generated inside the dCDN, etc.) or even "no limitati= on". As long as the terms of this contract (these limitations or absence of limi= tations) are abided by the uCDN, the uCDN may redirect content requests to = the dCDN. And the dCDN must accept them. Because this is the deal!! And in the case the dCDN cannot, for example because of overload situation = (for example because the dCDN was not correctly dimensioned), we have the t= wo possible cases described above (see item 2 above). 6) Quoting your mail: "What happens in the period between the dCDN being un= able to handle requests and the time it takes to advertise that to the uCDN= and for the uCDN to process & incorporate that new knowledge? Are requests= blindly forwarded to the dCDN which is unable to handle them leading to po= or user experience?" See above, you are referring again to this 'blind' window that it is anyway= impossible to delete whatever the approach. 7) Quoting your mail "What about scenarios where the uCDN has a choice of d= CDNs (e.g. two national-wide CDNs offering services at different costs), th= e uCDN may elect to query both dCDNs and decide based on their responses wh= ich one to choose. If the dCDN is unable to satisfy the request the uCDN ne= eds to know that so that it can fallback to the (more expensive in this exa= mple) dCDN." See above, you are referring again to this 'blind' window that it is anyway= impossible to delete. And we would like to say "What about scenarios with recursive request routi= ng mode where the uCDN has a choice of 4 dCDNs and each of these dCDNs has = the choice of 4 dCDNs? Please provide the description of the call flows cor= responding to the worst situation in this scenario, where one has to fallba= ck to each dCDN of each dCDN, one after the other, for EVERY content reques= t. Then add a third level in the topology and do the same description.".=20 We just want to stress out the scalability and performance issues of these = fallback operations. 8) Quoting your mail "In a routed IP network, there is often a small packet= loss while the network re-converges, by enabling the dCDN to refuse a redi= rection at CDNI Request Routing/DRIS query time we can reduce that window b= y giving the uCDN the option to take an alternative action (e.g. try anothe= r dCDN) while the routing/capability information re-converges." We agree on that point: this fallback possibility could maybe help to reduc= e that window, but it cannot delete it anyway. We just claim this is not worth, knowing the drawbacks of this fallback pos= sibility. But again, the IETF CDNI WG has the following options and it shall make a c= hoice as soon as possible: *** Adopt the PUSH routing approach only *** Adopt the PULL routing approach only *** or Adopt both approaches. Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 Envoy=E9=A0: mardi 10 juillet 2012 07:38 =C0=A0: LE LOUEDEC Yannick RD-CORE Cc=A0: BERTRAND Gilles RD-CORE; cdni@ietf.org; Pilarski Marcin - Korpo TP; = MARREC Anne RD-CORE Objet=A0: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-0= 0.txt Yannick, Please see inline. On 9 Jul 2012, at 20:05, wrote: > Hi Ben, all, >=20 > Ben, quoting you mail below, "... the downstream CDN could reply with eit= her "here is how to redirect it"",=20 >=20 > =3D> This is the role of the CDNI DRIS interface to provide the uCDN with= this information, and we target to make its specification public before Va= ncouver meeting so that everyone may read it before the meeting and get ful= l knowledge of our proposal about this part of CDNI request routing. >=20 > Ben, quoting you mail below, "... or "no I can't/won't take that content = delivery right now", reasons may include the uCDN has requested a delivery = of a protocol the dCDN does not support (possibly in error). >=20 > =3D> This is the role of the CDNI logging interface to provide the uCDN w= ith this information. I agree this information should be logged but the Request Routing interface= (what you call the DRIS) also needs to be able to indicate a failure. Otherwise the uCDN will 'blindly' redirect the the dCDN and the delivery wi= ll fail leading to poor end user experience. > Ben, quoting you mail below, "... or "no I can't/won't take that content = delivery right now", reasons may include ... the dCDN has no capacity right= now etc." >=20 > =3D> This is the role of the CDNI routing interface to provide the uCDN w= ith this information. It is the role of the CDN capability/routing interface to advertise broad c= apabilities etc not to give extremely fine grained real-time information on= exactly the state of the dCDN. Even if the capability/routing interface is real-time there are likely to s= till be race conditions where we need the dCDN to be about to indicate a fa= ilure to accept a redirect through the request routing/DRIS interface > So we may conclude we are in line basically, which is a good point. > We just aimed at checking there was a common understanding on this point. >=20 > The key point for us here is that we don't want this sentence extracted f= rom draft-ietf-cdni-problem-statement be interpreted as: ". and the dCDN MU= ST accept the content request except when it has not the "ability" to do so= ." Why not? IMO that is a valid scenario for some use cases. > The fact that the dCDN is temporary unable to handle content request corr= ectly is not a valid reason for the dCDN to be discharged of its obligation= s to the uCDN. > The contract set between the uCDN and the dCDN remains valid anyway, and = the obligations of the dCDN as well. Correct, but that contract may not be the same for all uCDNs & dCDNs, for e= xample a uCDN may not have a guarantee that a dCDN can handle everything it= is requested to handle but the contract may only be that the dCDN guarante= es to handle up to a certain volume of traffic. > The dCDN must announce to the uCDN that it is temporary unable, as soon a= s possible, via the CDNI routing interface. > And the uCDN must take this information into account in its CDN selection= process as soon as possible. > Then if the uCDN decides to continue to redirect content requests to the = dCDN, the uCDN MAY perfectly do it, but the uCDN knows these content reques= ts will be lost. What happens in the period between the dCDN being unable to handle requests= and the time it takes to advertise that to the uCDN and for the uCDN to pr= ocess & incorporate that new knowledge? Are requests blindly forwarded to t= he dCDN which is unable to handle them leading to poor user experience? > We could even imagine the situation where the uCDN continues to do it int= entionally, because it has no better option and the content request will be= lost anyway. For example in the case where neither the uCDN nor the other = downstream CDNs of the uCDN cannot manage correctly the content request, th= e uCDN could do it intentionally so as to be able to clearly prove (with CD= NI logging information) that it is the dCDN, not the uCDN, who is at fault. > But, of course, if there are alternative backup options, the normal react= ion of the uCDN is to stop as soon as possible to redirect content requests= to the dCDN when the uCDN knows that the dCDN is unable to handle them cor= rectly. >=20 > So, to be clear, we would prefer the sentence to be understood as: > ". and the dCDN MUST accept the content request.=20 > And if it cannot handle correctly the redirected content request it recei= ves, the content request is lost. What about scenarios where the uCDN has a choice of dCDNs (e.g. two nationa= l-wide CDNs offering services at different costs), the uCDN may elect to qu= ery both dCDNs and decide based on their responses which one to choose. If = the dCDN is unable to satisfy the request the uCDN needs to know that so th= at it can fallback to the (more expensive in this example) dCDN. > For example the dCDN generates a response to the content request with an = error message, or no response at all. And in parallel the CDNI logging inte= rface may be used to exchange logs corresponding to this problem. Anyway th= e dCDN MAY NOT redirect that content request back towards the uCDN."=20 >=20 > Exactly as in IP networks: IP packets are not sent back towards the origi= n by a downstream router under failure or congestion. In a routed IP network, there is often a small packet loss while the networ= k re-converges, by enabling the dCDN to refuse a redirection at CDNI Reques= t Routing/DRIS query time we can reduce that window by giving the uCDN the = option to take an alternative action (e.g. try another dCDN) while the rout= ing/capability information re-converges. > In both networks (IP and CDN), the reason is the same. > If the dCDN redirects back a content request to the uCDN, this generates = a loop.=20 Loop avoidance is a separate issue IMO to whether we should allow a dCDN to= be able to communicate "I am unable/unwilling to take that content deliver= y at this time". Regards Ben > To manage this would introduce a very high complexity. > And this would be just to try to save the content requests redirected by = the uCDN to the dCDN in the timeslot between the time the dCDN gets down an= d the time the uCDN takes this failure into account in its CDN selection pr= ocess. > It is much better to try to reduce this timeslot as much as possible, wit= h routing optimizations (we will propose as soon as possible). > Rather than introducing additional complexities (to manage redirection to= the uCDN) in the framework. >=20 >=20 > By the way, as you know, the IESG has just approved today the 'Content Di= stribution Network Interconnection (CDNI) Problem Statement' draft as infor= mational RFC. This is a good point. > And, as you may see in the draft "CDNI request routing", we do not propos= e to modify this problem statement draft. > We want know to focus now on getting the specifications of all CDNI inter= faces ready as soon as possible. >=20 > Best regards, >=20 > Yannick Le Lou=E9dec. >=20 >=20 > -----Message d'origine----- > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de B= en Niven-Jenkins > Envoy=E9 : lundi 9 juillet 2012 20:41 > =C0 : BERTRAND Gilles RD-CORE > Cc : cdni@ietf.org; Pilarski Marcin - Korpo TP; MARREC Anne RD-CORE > Objet : Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-0= 0.txt >=20 > Colleagues, >=20 > I started reading draft-lelouedec-cdni-request-routing-00 and this text c= aught my eye: >=20 > Quoting [I-D.ietf-cdni-problem-statement > ], "The CDNI Request Routing > interface enables a Request Routing function in an upstream CDN to > query a Request Routing function in a downstream CDN to determine if > the downstream CDN is able (and willing) to accept the delegated > content request". >=20 > The "ability" and the "willingness" of the downstream CDN to accept > the delegated content request match two fully different processes in > CDN interconnection. And the description of both these processes > should be reviewed and clarified for the following reasons: >=20 > o Regarding the former process, i.e. related to the "ability" > ("enables a Request Routing function in an upstream CDN to query a > Request Routing function in a downstream CDN to determine if the > downstream CDN is able (...) to accept the delegated content > request"), a routing protocol is used to achieve such a process, > called routing process, in many other technologies and networks > (IP, ATM, etc.). In all these technologies, it is the downstream > entity that provides routing information to the upstream entity. > The same approach should be applied to CDN interconnection. The > reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2, > dCDN 3, and then it selects one of them based on their responses") > would suffer from latency, signaling overhead and/or lack of > reactivity to events that impact the ability of the downstream > CDNs to accept delegated content requests. >=20 > o Regarding the latter process, i.e. related to the "willingness" > ("enables a Request Routing function in an upstream CDN to query a > Request Routing function in a downstream CDN to determine if the > downstream CDN (...) is willing (...)to accept the delegated > content request"), it is to be noted that the relationship between > a uCDN and a dCDN is always in the frame of a contractual > agreement between the administrative entity owning the uCDN, > acting as the customer, and the administrative entity owning the > dCDN, acting as the service provider. Therefore, consider a case > where >=20 > * the uCDN has a content request to redirect which is in full > conformance with the terms of this contractual agreement, and >=20 > * the uCDN has selected this dCDN. >=20 > As the uCDN knows, thanks to the routing information exchanged via > the aforementioned routing process, that the dCDN is able to > accept this content request, the uCDN MAY redirect the content > request to the dCDN and the dCDN MUST accept the content request. > Exchanging over the CDNI Request Routing interface information > about the "willingness" of the dCDN to accept the content request > is not relevant. >=20 > I think you might be over thinking what we wrote in the problem statement. >=20 > What was in the problem statement was meant to convey that an upstream CD= N could make a request to a downstream CDN to say "how do I redirect this r= equest to you" and the downstream CDN could reply with either "her is how t= o redirect it", or "no I can't/won't take that content delivery right now",= reasons may include the uCDN has requested a delivery of a protocol the dC= DN does not support (possibly in error) or the dCDN has no capacity right n= ow etc. >=20 > Ben >=20 > On 9 Jul 2012, at 18:00, wrote: >=20 >> Hi everyone, >>=20 >> We have just submitted the draft below. We are convinced that it will he= lp the WG to progress on the CDNI routing issues.=20 >>=20 >> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00=20 >>=20 >> Any feedback is very welcome. >>=20 >> Best regards, >>=20 >> Gilles >>=20 >>=20 >> -----Message d'origine----- >> De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] De la part de internet-drafts@ietf.org >> Envoy=E9 : lundi 9 juillet 2012 18:55 >> =C0 : i-d-announce@ietf.org >> Objet : I-D Action: draft-lelouedec-cdni-request-routing-00.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >>=20 >>=20 >> Title : CDNI Request Routing >> Author(s) : Yannick Le Louedec >> Anne Marrec >> Gilles Bertrand >> Marcin Pilarski >> Filename : draft-lelouedec-cdni-request-routing-00.txt >> Pages : 30 >> Date : 2012-07-09 >>=20 >> Abstract: >> The present document proposes to clarify the CDNI Request Routing >> interface introduced in [I-D.ietf-cdni-framework] and [I-D.ietf-cdni- >> problem-statement], as well as related terminology. >>=20 >> In particular the present document proposes to split the CDNI Request >> Routing interface into two separate interfaces with clearer roles, >> named respectively CDNI Routing interface and CDNI Downstream >> Resource Identifier Signaling interface (CDNI DRIS interface). >>=20 >> This part of the CDN interconnection framework the IETF has been >> referring to so far with the term "CDNI Request Routing" is just >> another routing, signaling and forwarding problem in a long series of >> the telecommunication history. For example, one can draw a direct >> analogy between the IP/MPLS-TE framework and the CDN interconnection >> framework. >>=20 >> In addition, this document recommends that the specification of ALL >> CDN interconnection interfaces in the scope of the CDNI IETF WG >> relies on the equivalent concept to IP prefix for CDN >> interconnection, named 'contentRequestScope'. This highly useful and >> powerful concept SHALL be used to simplify the specification of ALL >> CDN interconnection interfaces, as well as to ensure performance and >> scalability in CDN interconnection. >>=20 >> All these proposals can be smoothly integrated in the WG drafts, >> especially [I-D.ietf-cdni-framework] and >> [I-D.ietf-cdni-requirements], as they essentially propose (useful) >> clarifications of the existing framework. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-routing >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> 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 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages= electroniques etant susceptibles d'alteration, >> France Telecom - Orange decline toute responsabilite si ce message a ete= altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or privileged = information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for mess= ages that have been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> 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 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From yannick.lelouedec@orange.com Tue Jul 10 03:00:11 2012 Return-Path: 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 99BA021F8702 for ; Tue, 10 Jul 2012 03:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=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 s8z+r-vqUbrg for ; Tue, 10 Jul 2012 03:00:09 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 34CC521F8701 for ; Tue, 10 Jul 2012 03:00:09 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 17D1E32459B; Tue, 10 Jul 2012 12:00:36 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id ECCE127C064; Tue, 10 Jul 2012 12:00:35 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Tue, 10 Jul 2012 12:00:34 +0200 From: To: "Brandenburg, R. (Ray) van" , Ben Niven-Jenkins Thread-Topic: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt Thread-Index: AQHNXm0l4Pgum6YaUEmhOdq0bl2+gZciQbmg Date: Tue, 10 Jul 2012 10:00:33 +0000 Message-ID: <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.10.71528 Cc: "cdni@ietf.org" , Pilarski Marcin - Korpo TP , MARREC Anne RD-CORE Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 10:00:11 -0000 Hi Ray, all, 1) Ray, Quoting your mail: "I don't see why the CDNI Request Routing interf= ace should state that a dCDN MUST deliver the content if it has indicated i= ts ability to do so earlier in either a contractual agreement or in the cap= ability interface." This is not what we have written. Let me try to rephrase simply. A contractual agreement is a contractual agreement.=20 It put in writings the respective obligations of the uCDN and of the dCDN.= =20 The uCDN may redirect any content request to the dCDN as long as it is in f= ull conformance with the terms of this contractual agreement (the type of t= he content request is in full conformance, the maximum number of content re= quests per second is respected, etc.).=20 In this case the dCDN may not say "Sorry, but I decide unilaterally to refu= se this content request".=20=20 Why? Because this is the deal, a contractual agreement is a contractual agr= eement! Yet the dCDN may say "I do apologize, but at this time I cannot handle corr= ectly a certain class of content requests specified in our contractual agre= ement" (for example the class of the HTTP content requests with token from = French end users, because of overload situation, failure, etc.) This is the role of the CDNI routing interface to provide the uCDN with suc= h information. (And the dCDN may be given a penalty for example if this was agreed in the = terms of the contractual agreement.) 2) Ray, Quoting your mail: "I understand that in most cases, the contractua= l agreement might indeed impose this behavior on the dCDN" Please provide the description of an example where this is not the case. Otherwise the IETF CDNI WG shall indeed consider this is ALWAYS the case.= =20 And this is an important point to be able to progress in the CDNI interface= s' specification works. If the contractual agreement does not define clearly the obligations of the= uCDN, it is impossible to dimension adequately the dCDN, neither to define= correctly the CDNI contractual agreements between the dCDN and the dCDNs o= f this dCDN. If the contractual agreement does not define clearly the obligations of the= dCDN, the dCDN may do what it wants... even to put in the trash can any co= ntent request it accepted to handle. In both situations it is impossible to ensure any quality of experience to = the end user. 3) Ray, Quoting your mail: "I don't think this type of behavior should be i= mposed by the protocol we're developing here." I do not sure I understand this sentence.=20 Every routing protocol has been defined (or at least configured) so far by = considering the expected behavior of the interconnected elements/networks.= =20=20 But maybe I will understand if you provide an example on the point 2 above. Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl]=20 Envoy=E9=A0: mardi 10 juillet 2012 09:20 =C0=A0: Ben Niven-Jenkins; LE LOUEDEC Yannick RD-CORE Cc=A0: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Objet=A0: RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-0= 0.txt Hi Yannick, Ben, I tend to agree with Ben here. When reading the draft, I got the feeling th= at the draft seems to assume a lot about the relationship between the uCDN = and dCDN. For example, I don't see why the CDNI Request Routing interface s= hould state that a dCDN MUST deliver the content if it has indicated its ab= ility to do so earlier in either a contractual agreement or in the capabili= ty interface. I understand that in most cases, the contractual agreement mi= ght indeed impose this behavior on the dCDN, but I don't think this type of= behavior should be imposed by the protocol we're developing here.=20 It was always my assumption that the Request Routing Interface would at lea= st include the option of allowing the uCDN to query the dCDN for every cont= ent request whether the dCDN is willing to deliver that particular request.= =20 I will send my full review of the draft later.=20 Ray -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben= Niven-Jenkins Sent: dinsdag 10 juli 2012 7:38 To: yannick.lelouedec@orange.com Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00= .txt Yannick, Please see inline. On 9 Jul 2012, at 20:05, wrote: > Hi Ben, all, >=20 > Ben, quoting you mail below, "... the downstream CDN could reply with=20 > either "here is how to redirect it"", >=20 > =3D> This is the role of the CDNI DRIS interface to provide the uCDN with= this information, and we target to make its specification public before Va= ncouver meeting so that everyone may read it before the meeting and get ful= l knowledge of our proposal about this part of CDNI request routing. >=20 > Ben, quoting you mail below, "... or "no I can't/won't take that content = delivery right now", reasons may include the uCDN has requested a delivery = of a protocol the dCDN does not support (possibly in error). >=20 > =3D> This is the role of the CDNI logging interface to provide the uCDN w= ith this information. I agree this information should be logged but the Request Routing interface= (what you call the DRIS) also needs to be able to indicate a failure. Otherwise the uCDN will 'blindly' redirect the the dCDN and the delivery wi= ll fail leading to poor end user experience. > Ben, quoting you mail below, "... or "no I can't/won't take that content = delivery right now", reasons may include ... the dCDN has no capacity right= now etc." >=20 > =3D> This is the role of the CDNI routing interface to provide the uCDN w= ith this information. It is the role of the CDN capability/routing interface to advertise broad c= apabilities etc not to give extremely fine grained real-time information on= exactly the state of the dCDN. Even if the capability/routing interface is real-time there are likely to s= till be race conditions where we need the dCDN to be about to indicate a fa= ilure to accept a redirect through the request routing/DRIS interface > So we may conclude we are in line basically, which is a good point. > We just aimed at checking there was a common understanding on this point. >=20 > The key point for us here is that we don't want this sentence extracted f= rom draft-ietf-cdni-problem-statement be interpreted as: ". and the dCDN MU= ST accept the content request except when it has not the "ability" to do so= ." Why not? IMO that is a valid scenario for some use cases. > The fact that the dCDN is temporary unable to handle content request corr= ectly is not a valid reason for the dCDN to be discharged of its obligation= s to the uCDN. > The contract set between the uCDN and the dCDN remains valid anyway, and = the obligations of the dCDN as well. Correct, but that contract may not be the same for all uCDNs & dCDNs, for e= xample a uCDN may not have a guarantee that a dCDN can handle everything it= is requested to handle but the contract may only be that the dCDN guarante= es to handle up to a certain volume of traffic. > The dCDN must announce to the uCDN that it is temporary unable, as soon a= s possible, via the CDNI routing interface. > And the uCDN must take this information into account in its CDN selection= process as soon as possible. > Then if the uCDN decides to continue to redirect content requests to the = dCDN, the uCDN MAY perfectly do it, but the uCDN knows these content reques= ts will be lost. What happens in the period between the dCDN being unable to handle requests= and the time it takes to advertise that to the uCDN and for the uCDN to pr= ocess & incorporate that new knowledge? Are requests blindly forwarded to t= he dCDN which is unable to handle them leading to poor user experience? > We could even imagine the situation where the uCDN continues to do it int= entionally, because it has no better option and the content request will be= lost anyway. For example in the case where neither the uCDN nor the other = downstream CDNs of the uCDN cannot manage correctly the content request, th= e uCDN could do it intentionally so as to be able to clearly prove (with CD= NI logging information) that it is the dCDN, not the uCDN, who is at fault. > But, of course, if there are alternative backup options, the normal react= ion of the uCDN is to stop as soon as possible to redirect content requests= to the dCDN when the uCDN knows that the dCDN is unable to handle them cor= rectly. >=20 > So, to be clear, we would prefer the sentence to be understood as: > ". and the dCDN MUST accept the content request.=20 > And if it cannot handle correctly the redirected content request it recei= ves, the content request is lost. What about scenarios where the uCDN has a choice of dCDNs (e.g. two nationa= l-wide CDNs offering services at different costs), the uCDN may elect to qu= ery both dCDNs and decide based on their responses which one to choose. If = the dCDN is unable to satisfy the request the uCDN needs to know that so th= at it can fallback to the (more expensive in this example) dCDN. > For example the dCDN generates a response to the content request with an = error message, or no response at all. And in parallel the CDNI logging inte= rface may be used to exchange logs corresponding to this problem. Anyway th= e dCDN MAY NOT redirect that content request back towards the uCDN."=20 >=20 > Exactly as in IP networks: IP packets are not sent back towards the origi= n by a downstream router under failure or congestion. In a routed IP network, there is often a small packet loss while the networ= k re-converges, by enabling the dCDN to refuse a redirection at CDNI Reques= t Routing/DRIS query time we can reduce that window by giving the uCDN the = option to take an alternative action (e.g. try another dCDN) while the rout= ing/capability information re-converges. > In both networks (IP and CDN), the reason is the same. > If the dCDN redirects back a content request to the uCDN, this generates = a loop.=20 Loop avoidance is a separate issue IMO to whether we should allow a dCDN to= be able to communicate "I am unable/unwilling to take that content deliver= y at this time". Regards Ben > To manage this would introduce a very high complexity. > And this would be just to try to save the content requests redirected by = the uCDN to the dCDN in the timeslot between the time the dCDN gets down an= d the time the uCDN takes this failure into account in its CDN selection pr= ocess. > It is much better to try to reduce this timeslot as much as possible, wit= h routing optimizations (we will propose as soon as possible). > Rather than introducing additional complexities (to manage redirection to= the uCDN) in the framework. >=20 >=20 > By the way, as you know, the IESG has just approved today the 'Content Di= stribution Network Interconnection (CDNI) Problem Statement' draft as infor= mational RFC. This is a good point. > And, as you may see in the draft "CDNI request routing", we do not propos= e to modify this problem statement draft. > We want know to focus now on getting the specifications of all CDNI inter= faces ready as soon as possible. >=20 > Best regards, >=20 > Yannick Le Lou=E9dec. >=20 >=20 > -----Message d'origine----- > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part=20 > de Ben Niven-Jenkins Envoy=E9 : lundi 9 juillet 2012 20:41 =C0 : BERTRAND= =20 > Gilles RD-CORE Cc : cdni@ietf.org; Pilarski Marcin - Korpo TP; MARREC=20 > Anne RD-CORE Objet : Re: [CDNi] TR: I-D Action:=20 > draft-lelouedec-cdni-request-routing-00.txt >=20 > Colleagues, >=20 > I started reading draft-lelouedec-cdni-request-routing-00 and this text c= aught my eye: >=20 > Quoting [I-D.ietf-cdni-problem-statement ], "The CDNI Request=20 > Routing > interface enables a Request Routing function in an upstream CDN to > query a Request Routing function in a downstream CDN to determine if > the downstream CDN is able (and willing) to accept the delegated > content request". >=20 > The "ability" and the "willingness" of the downstream CDN to accept > the delegated content request match two fully different processes in > CDN interconnection. And the description of both these processes > should be reviewed and clarified for the following reasons: >=20 > o Regarding the former process, i.e. related to the "ability" > ("enables a Request Routing function in an upstream CDN to query a > Request Routing function in a downstream CDN to determine if the > downstream CDN is able (...) to accept the delegated content > request"), a routing protocol is used to achieve such a process, > called routing process, in many other technologies and networks > (IP, ATM, etc.). In all these technologies, it is the downstream > entity that provides routing information to the upstream entity. > The same approach should be applied to CDN interconnection. The > reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2, > dCDN 3, and then it selects one of them based on their responses") > would suffer from latency, signaling overhead and/or lack of > reactivity to events that impact the ability of the downstream > CDNs to accept delegated content requests. >=20 > o Regarding the latter process, i.e. related to the "willingness" > ("enables a Request Routing function in an upstream CDN to query a > Request Routing function in a downstream CDN to determine if the > downstream CDN (...) is willing (...)to accept the delegated > content request"), it is to be noted that the relationship between > a uCDN and a dCDN is always in the frame of a contractual > agreement between the administrative entity owning the uCDN, > acting as the customer, and the administrative entity owning the > dCDN, acting as the service provider. Therefore, consider a case > where >=20 > * the uCDN has a content request to redirect which is in full > conformance with the terms of this contractual agreement, and >=20 > * the uCDN has selected this dCDN. >=20 > As the uCDN knows, thanks to the routing information exchanged via > the aforementioned routing process, that the dCDN is able to > accept this content request, the uCDN MAY redirect the content > request to the dCDN and the dCDN MUST accept the content request. > Exchanging over the CDNI Request Routing interface information > about the "willingness" of the dCDN to accept the content request > is not relevant. >=20 > I think you might be over thinking what we wrote in the problem statement. >=20 > What was in the problem statement was meant to convey that an upstream CD= N could make a request to a downstream CDN to say "how do I redirect this r= equest to you" and the downstream CDN could reply with either "her is how t= o redirect it", or "no I can't/won't take that content delivery right now",= reasons may include the uCDN has requested a delivery of a protocol the dC= DN does not support (possibly in error) or the dCDN has no capacity right n= ow etc. >=20 > Ben >=20 > On 9 Jul 2012, at 18:00, wrote: >=20 >> Hi everyone, >>=20 >> We have just submitted the draft below. We are convinced that it will he= lp the WG to progress on the CDNI routing issues.=20 >>=20 >> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >>=20 >> Any feedback is very welcome. >>=20 >> Best regards, >>=20 >> Gilles >>=20 >>=20 >> -----Message d'origine----- >> De : i-d-announce-bounces@ietf.org=20 >> [mailto:i-d-announce-bounces@ietf.org] De la part de=20 >> internet-drafts@ietf.org Envoy=E9 : lundi 9 juillet 2012 18:55 =C0 :=20 >> i-d-announce@ietf.org Objet : I-D Action:=20 >> draft-lelouedec-cdni-request-routing-00.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >>=20 >>=20 >> Title : CDNI Request Routing >> Author(s) : Yannick Le Louedec >> Anne Marrec >> Gilles Bertrand >> Marcin Pilarski >> Filename : draft-lelouedec-cdni-request-routing-00.txt >> Pages : 30 >> Date : 2012-07-09 >>=20 >> Abstract: >> The present document proposes to clarify the CDNI Request Routing=20=20 >> interface introduced in [I-D.ietf-cdni-framework] and [I-D.ietf-cdni-=20= =20 >> problem-statement], as well as related terminology. >>=20 >> In particular the present document proposes to split the CDNI=20 >> Request Routing interface into two separate interfaces with clearer=20 >> roles, named respectively CDNI Routing interface and CDNI Downstream=20= =20 >> Resource Identifier Signaling interface (CDNI DRIS interface). >>=20 >> This part of the CDN interconnection framework the IETF has been=20=20 >> referring to so far with the term "CDNI Request Routing" is just=20=20 >> another routing, signaling and forwarding problem in a long series of=20= =20 >> the telecommunication history. For example, one can draw a direct=20=20 >> analogy between the IP/MPLS-TE framework and the CDN interconnection=20= =20 >> framework. >>=20 >> In addition, this document recommends that the specification of ALL=20= =20 >> CDN interconnection interfaces in the scope of the CDNI IETF WG=20=20 >> relies on the equivalent concept to IP prefix for CDN=20=20 >> interconnection, named 'contentRequestScope'. This highly useful and=20= =20 >> powerful concept SHALL be used to simplify the specification of ALL=20= =20 >> CDN interconnection interfaces, as well as to ensure performance and=20= =20 >> scalability in CDN interconnection. >>=20 >> All these proposals can be smoothly integrated in the WG drafts,=20=20 >> especially [I-D.ietf-cdni-framework] and=20=20 >> [I-D.ietf-cdni-requirements], as they essentially propose (useful)=20=20 >> clarifications of the existing framework. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-routing >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> 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=20 >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >> _____________________________________________________________________ >> ____________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for mess= ages that have been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> 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 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, France Telecom - Orange decline toute responsabilite si ce message a e= te altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From yannick.lelouedec@orange.com Tue Jul 10 03:41:21 2012 Return-Path: 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 E9BD821F8716 for ; Tue, 10 Jul 2012 03:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 3ds8IYz67meD for ; Tue, 10 Jul 2012 03:41:19 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id E69FE21F8532 for ; Tue, 10 Jul 2012 03:41:18 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id BFEF018C411; Tue, 10 Jul 2012 12:41:45 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id AD10927C053; Tue, 10 Jul 2012 12:41:45 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Tue, 10 Jul 2012 12:41:39 +0200 From: To: Ben Niven-Jenkins Thread-Topic: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt Thread-Index: AQHNXl4+FbkrQXSpW0OtdmHifLoRFZciOrZQgAAWpPA= Date: Tue, 10 Jul 2012 10:41:38 +0000 Message-ID: <16337_1341916905_4FFC06E9_16337_11438_1_71d558c9-0b1f-4796-975f-21a0ad75c55a@PEXCVZYH02.corporate.adroot.infra.ftgroup> References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> <4475_1341911731_4FFBF2B3_4475_4500_1_c732b4d9-1beb-40c8-8381-1da9c58c7368@PEXCVZYH01.corporate.adroot.infra.ftgroup> In-Reply-To: <4475_1341911731_4FFBF2B3_4475_4500_1_c732b4d9-1beb-40c8-8381-1da9c58c7368@PEXCVZYH01.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.10.93317 Cc: "cdni@ietf.org" , Pilarski Marcin - Korpo TP , MARREC Anne RD-CORE Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 10:41:22 -0000 Hi Ben, all, This mail is just to complement item 5 in my mail below, as Ray made a very= close comment in the meantime. Ben, Quoting your mail: "Correct, but that contract may not be the same for= all uCDNs & dCDNs, for example a uCDN may not have a guarantee that a dCDN= can handle everything it is requested to handle but the contract may only = be that the dCDN guarantees to handle up to a certain volume of traffic." In the situation where we are up to this certain volume of traffic, this is= a typical illustration of situations where the contractual agreement does = not define clearly the obligations of the dCDN. In such a situation, if nothing more is written in the contractual agreemen= t, the dCDN may really do what it wants... even put in the trash can any re= directed content request for which the dCDN sent a message over the CDNI re= quest routing saying that it accepted to handle correctly that content requ= est. Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de y= annick.lelouedec@orange.com Envoy=E9=A0: mardi 10 juillet 2012 11:15 =C0=A0: Ben Niven-Jenkins Cc=A0: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Objet=A0: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-0= 0.txt Hi Ben, All, Good. These are exactly the comments we expected to receive. This gives us the opportunity to share additional comments, and thus to eas= e an efficient meeting in Vancouver. 1) In the case where "the uCDN has requested a delivery of a protocol the d= CDN does not support (possibly in error)", quoting your mail: "the Request = Routing interface. also needs to be able to indicate a failure". We do not agree with that, and this does not solve the problem you mention = anyway. First example, please consider the case where:=20 *** the uCDN receives a content request from an end user agent *** for this content request, the uCDN has requested over the CDNI request = routing interface a delivery of a protocol that the dCDN does support (and = that is in full conformance with the terms of the contractual agreement bet= ween the uCDN and the dCDN); let us consider this protocol is HTTP,=20 *** the dCDN sends a response to the uCDN over the CDNI request routing int= erface that validates the CDNI request routing request. *** the uCDN then erroneously generates a response to the content request (= to redirect this content request to the dCDN) with the RTSP protocol. =20=20=20 As you can see, your proposal does not solve anyway the problem you mention= . This content request will be lost. Second example, please consider the case where:=20 *** the uCDN receives a content request from an end user agent *** for this content request the uCDN has requested over the CDNI request r= outing interface a delivery of a protocol that the dCDN does support (and t= hat is in full conformance with the terms of the contractual agreement betw= een the uCDN and the dCDN); let us consider this protocol is HTTP,=20 *** the dCDN sends a response to the uCDN over the CDNI request routing int= erface that validates the CDNI request routing request. *** the uCDN then generates a response to the content request (to redirect = this content request to the dCDN) with the HTTP protocol. *** a failure happens in the dCDN before the redirected content request arr= ives to the dCDN and this failure makes the dCDN unable to handle correctly= the content request. The content request will be lost also in this second example. This second example is to stress out that, whatever the specifications of t= he CDNI interfaces, if the redirection of the content request relies on the= end user (case of applicative content request redirection: HTTP redirectio= n, RTSP redirection) or its local DNS server (case of DNS based content req= uest redirection), the uCDN ALWAYS 'blindly' redirects the content request = to the dCDN and the delivery may fail if a failure happens at the same time= in the dCDN (leading indeed to poor end user experience). This is, we would say, the so-called debate between the PUSH and PULL CDNI = routing approaches: *** The PUSH approach consists in the dCDN to take the initiative to announ= ce to the uCDN that it is temporary unable, as soon as possible, via the CD= NI routing interface. *** The PULL approach consists in the uCDN to query its downstream CDNs (dC= DN 1, dCDN 2, dCDN 3, etc.), via the CDNI request routing interface, and th= en to select one of them based on their responses received over the CDNI re= quest routing interface.=20 In both these approaches there is indeed ALWAYS a 'blind' window, between t= he time the dCDN sends its latest message over the CDNI request routing int= erface to the uCDN and the time the redirected content request reaches the = selected dCDN, where there is anyway no guarantee the redirected content re= quest will be correctly handled by the dCDN and no possibility to save this= redirected content request if the dCDN has got down. The PULL approach imposes the uCDN to send a request over the CDNI request = routing interfaces set up with some or all of its dCDNs EVERYTIME it receiv= es a content request he may wish to redirect towards one of these dCDNs. This would suffer from latency, signaling overhead and/or lack of reactivit= y to events that impact the ability of the downstream CDNs to accept delega= ted content requests. Moreover these issues are exacerbated in the recursiv= e mode in the case of cascaded CDNs topology (when each dCDN of the uCDN ha= s its own dCDNs which have their own dCDNs.).=20 And anyway this does not provide full guarantee that the content request wi= ll be correctly handled by the dCDN. The PUSH does not provide full guarantee either (as full guarantee is anywa= y impossible to ensure). But it addresses much better all the scalability a= nd performance issues faced by the PULL approach.=20=20=20=20 As mentioned below, the objective is then to reduce as much as possible thi= s 'blind' window. So, to sum up, the IETF CDNI WG has the following options and it should mak= e a choice as soon as possible. *** Adopt the PUSH routing approach and work on routing optimization to red= uce the "blind" window (as IETF did for IP routing). *** Adopt the PULL routing approach, knowing there will be anyway a "bind" = window too, and knowing the impacts in terms of scalability, latency, signa= ling overhead of this option. *** or Adopt both approaches, knowing this option will be the longest to sp= ecify (while market players need standards urgently). 2) Quoting your mail: "It is the role of the CDN capability/routing interfa= ce to advertise broad capabilities etc not to give extremely fine grained r= eal-time information on exactly the state of the dCDN." We do not agree. Both cases/approaches could be possibly envisioned. Otherwise please explain and justify what is the difference and/or limit be= tween "broad capabilities" and "extremely fine grained real-time informatio= n". Let us consider the situation where the dCDN is temporarily overloaded, i.e= . it is temporary not able to handle requests correctly. In this situation, one can distinguish 2 possible cases/approaches. This de= pends basically on whether the corresponding content delivery service has s= trong quality requirements or not. *** Case 1 (typically for high quality content delivery services) This is the case where the uCDN MUST absolutely avoid to redirect content r= equests, even temporary, to this dCDN that cannot manage them, even tempora= ry.=20 The uCDN MUST take this information "This dCDN is temporary unable to handl= e requests" into account in its CDN selection process. This information is obtained via the CDNI routing process (CDNI routing int= erface). Either the dCDN sends a routing update with this information. Or the dCDN is so overloaded that it cannot send any message, even keepaliv= e messages; therefore the uCDN detects it does not receive keep-alive messa= ges anymore and thus it infers that the dCDN is unavailable. Anyway it stops to select this dCDN for the next content request redirectio= ns. Once the overload situation is over, the dCDN sends routing updates and/or = routing keep-alive messages to inform the uCDN that it is back to a nominal= situation. The uCDN may then select it again. *** Case 2 ("best effort" service) This is the case where the uCDN and dCDN consider they may tolerate tempora= ry overload situations without taking this into account in the CDN selectio= n process, and thus in the CDNI routing process. No CDNI routing update is exchanged on overload situation. The content requests redirected during the overload period are lost. Just as for the "best effort" IP transport over Internet; Basically IP rout= ing protocols do not exchange such overload information. Quality and overload/congestion situation are managed by over-dimensioning = networks, by monitoring carefully congestion levels in networks, and by "tr= affic engineering" traffic (fine-tuning of BGP parameters, etc.) in case of= severe congestion situations. So both these cases/approaches could be possibly envisioned. Then it is up to the IETF members to decide on if both these cases (or only= case 2) should be captured in the specification of the CDNI routing interf= ace. We recommend to capture both cases.=20 Otherwise, as mentioned above, please explain and justify what is the diffe= rence and/or limit between "broad capabilities" and "extremely fine grained= real-time information", between an overload situation and a failure. If both cases are captured, the question, when setting CDN interconnection = in the real world, is then the compromise to set between scalability/stabil= ity in the control plane and quality of service in the transport plane. This will be up to the players who manage the interconnected CDNs to agree = on that, depending of the capability of their CDNs and the services to be s= upported, and to configure their interfaces adequately. 3) Quoting your mail : "Even if the capability/routing interface is real-ti= me there are likely to still be race conditions where we need the dCDN to b= e about to indicate a failure to accept a redirect through the request rout= ing/DRIS interface" See above, you are referring again to this 'blind' window that it is anyway= impossible to delete. 4) Quoting your mail: "Why not? IMO that is a valid scenario for some use c= ases." Because, as mentioned in my previous mail, the fact that the dCDN is tempor= ary unable to handle content request correctly is not a valid reason for th= e dCDN to be discharged of its obligations to the uCDN. The contract set be= tween the uCDN and the dCDN remains valid anyway, and the obligations of th= e dCDN as well. 5) Quoting your mail: "Correct, but that contract may not be the same for a= ll uCDNs & dCDNs, for example a uCDN may not have a guarantee that a dCDN c= an handle everything it is requested to handle but the contract may only be= that the dCDN guarantees to handle up to a certain volume of traffic." We do not claim that the contracts have to be the same for all uCDNs and dC= DNS. A given contract set between a given uCDN and a given dCDN MUST indicate ei= ther some limitations (e.g. Max number of requests per second, or Max volum= e of delivery traffic generated inside the dCDN, etc.) or even "no limitati= on". As long as the terms of this contract (these limitations or absence of limi= tations) are abided by the uCDN, the uCDN may redirect content requests to = the dCDN. And the dCDN must accept them. Because this is the deal!! And in the case the dCDN cannot, for example because of overload situation = (for example because the dCDN was not correctly dimensioned), we have the t= wo possible cases described above (see item 2 above). 6) Quoting your mail: "What happens in the period between the dCDN being un= able to handle requests and the time it takes to advertise that to the uCDN= and for the uCDN to process & incorporate that new knowledge? Are requests= blindly forwarded to the dCDN which is unable to handle them leading to po= or user experience?" See above, you are referring again to this 'blind' window that it is anyway= impossible to delete whatever the approach. 7) Quoting your mail "What about scenarios where the uCDN has a choice of d= CDNs (e.g. two national-wide CDNs offering services at different costs), th= e uCDN may elect to query both dCDNs and decide based on their responses wh= ich one to choose. If the dCDN is unable to satisfy the request the uCDN ne= eds to know that so that it can fallback to the (more expensive in this exa= mple) dCDN." See above, you are referring again to this 'blind' window that it is anyway= impossible to delete. And we would like to say "What about scenarios with recursive request routi= ng mode where the uCDN has a choice of 4 dCDNs and each of these dCDNs has = the choice of 4 dCDNs? Please provide the description of the call flows cor= responding to the worst situation in this scenario, where one has to fallba= ck to each dCDN of each dCDN, one after the other, for EVERY content reques= t. Then add a third level in the topology and do the same description.".=20 We just want to stress out the scalability and performance issues of these = fallback operations. 8) Quoting your mail "In a routed IP network, there is often a small packet= loss while the network re-converges, by enabling the dCDN to refuse a redi= rection at CDNI Request Routing/DRIS query time we can reduce that window b= y giving the uCDN the option to take an alternative action (e.g. try anothe= r dCDN) while the routing/capability information re-converges." We agree on that point: this fallback possibility could maybe help to reduc= e that window, but it cannot delete it anyway. We just claim this is not worth, knowing the drawbacks of this fallback pos= sibility. But again, the IETF CDNI WG has the following options and it shall make a c= hoice as soon as possible: *** Adopt the PUSH routing approach only *** Adopt the PULL routing approach only *** or Adopt both approaches. Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 Envoy=E9=A0: mardi 10 juillet 2012 07:38 =C0=A0: LE LOUEDEC Yannick RD-CORE Cc=A0: BERTRAND Gilles RD-CORE; cdni@ietf.org; Pilarski Marcin - Korpo TP; = MARREC Anne RD-CORE Objet=A0: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-0= 0.txt Yannick, Please see inline. On 9 Jul 2012, at 20:05, wrote: > Hi Ben, all, >=20 > Ben, quoting you mail below, "... the downstream CDN could reply with eit= her "here is how to redirect it"",=20 >=20 > =3D> This is the role of the CDNI DRIS interface to provide the uCDN with= this information, and we target to make its specification public before Va= ncouver meeting so that everyone may read it before the meeting and get ful= l knowledge of our proposal about this part of CDNI request routing. >=20 > Ben, quoting you mail below, "... or "no I can't/won't take that content = delivery right now", reasons may include the uCDN has requested a delivery = of a protocol the dCDN does not support (possibly in error). >=20 > =3D> This is the role of the CDNI logging interface to provide the uCDN w= ith this information. I agree this information should be logged but the Request Routing interface= (what you call the DRIS) also needs to be able to indicate a failure. Otherwise the uCDN will 'blindly' redirect the the dCDN and the delivery wi= ll fail leading to poor end user experience. > Ben, quoting you mail below, "... or "no I can't/won't take that content = delivery right now", reasons may include ... the dCDN has no capacity right= now etc." >=20 > =3D> This is the role of the CDNI routing interface to provide the uCDN w= ith this information. It is the role of the CDN capability/routing interface to advertise broad c= apabilities etc not to give extremely fine grained real-time information on= exactly the state of the dCDN. Even if the capability/routing interface is real-time there are likely to s= till be race conditions where we need the dCDN to be about to indicate a fa= ilure to accept a redirect through the request routing/DRIS interface > So we may conclude we are in line basically, which is a good point. > We just aimed at checking there was a common understanding on this point. >=20 > The key point for us here is that we don't want this sentence extracted f= rom draft-ietf-cdni-problem-statement be interpreted as: ". and the dCDN MU= ST accept the content request except when it has not the "ability" to do so= ." Why not? IMO that is a valid scenario for some use cases. > The fact that the dCDN is temporary unable to handle content request corr= ectly is not a valid reason for the dCDN to be discharged of its obligation= s to the uCDN. > The contract set between the uCDN and the dCDN remains valid anyway, and = the obligations of the dCDN as well. Correct, but that contract may not be the same for all uCDNs & dCDNs, for e= xample a uCDN may not have a guarantee that a dCDN can handle everything it= is requested to handle but the contract may only be that the dCDN guarante= es to handle up to a certain volume of traffic. > The dCDN must announce to the uCDN that it is temporary unable, as soon a= s possible, via the CDNI routing interface. > And the uCDN must take this information into account in its CDN selection= process as soon as possible. > Then if the uCDN decides to continue to redirect content requests to the = dCDN, the uCDN MAY perfectly do it, but the uCDN knows these content reques= ts will be lost. What happens in the period between the dCDN being unable to handle requests= and the time it takes to advertise that to the uCDN and for the uCDN to pr= ocess & incorporate that new knowledge? Are requests blindly forwarded to t= he dCDN which is unable to handle them leading to poor user experience? > We could even imagine the situation where the uCDN continues to do it int= entionally, because it has no better option and the content request will be= lost anyway. For example in the case where neither the uCDN nor the other = downstream CDNs of the uCDN cannot manage correctly the content request, th= e uCDN could do it intentionally so as to be able to clearly prove (with CD= NI logging information) that it is the dCDN, not the uCDN, who is at fault. > But, of course, if there are alternative backup options, the normal react= ion of the uCDN is to stop as soon as possible to redirect content requests= to the dCDN when the uCDN knows that the dCDN is unable to handle them cor= rectly. >=20 > So, to be clear, we would prefer the sentence to be understood as: > ". and the dCDN MUST accept the content request.=20 > And if it cannot handle correctly the redirected content request it recei= ves, the content request is lost. What about scenarios where the uCDN has a choice of dCDNs (e.g. two nationa= l-wide CDNs offering services at different costs), the uCDN may elect to qu= ery both dCDNs and decide based on their responses which one to choose. If = the dCDN is unable to satisfy the request the uCDN needs to know that so th= at it can fallback to the (more expensive in this example) dCDN. > For example the dCDN generates a response to the content request with an = error message, or no response at all. And in parallel the CDNI logging inte= rface may be used to exchange logs corresponding to this problem. Anyway th= e dCDN MAY NOT redirect that content request back towards the uCDN."=20 >=20 > Exactly as in IP networks: IP packets are not sent back towards the origi= n by a downstream router under failure or congestion. In a routed IP network, there is often a small packet loss while the networ= k re-converges, by enabling the dCDN to refuse a redirection at CDNI Reques= t Routing/DRIS query time we can reduce that window by giving the uCDN the = option to take an alternative action (e.g. try another dCDN) while the rout= ing/capability information re-converges. > In both networks (IP and CDN), the reason is the same. > If the dCDN redirects back a content request to the uCDN, this generates = a loop.=20 Loop avoidance is a separate issue IMO to whether we should allow a dCDN to= be able to communicate "I am unable/unwilling to take that content deliver= y at this time". Regards Ben > To manage this would introduce a very high complexity. > And this would be just to try to save the content requests redirected by = the uCDN to the dCDN in the timeslot between the time the dCDN gets down an= d the time the uCDN takes this failure into account in its CDN selection pr= ocess. > It is much better to try to reduce this timeslot as much as possible, wit= h routing optimizations (we will propose as soon as possible). > Rather than introducing additional complexities (to manage redirection to= the uCDN) in the framework. >=20 >=20 > By the way, as you know, the IESG has just approved today the 'Content Di= stribution Network Interconnection (CDNI) Problem Statement' draft as infor= mational RFC. This is a good point. > And, as you may see in the draft "CDNI request routing", we do not propos= e to modify this problem statement draft. > We want know to focus now on getting the specifications of all CDNI inter= faces ready as soon as possible. >=20 > Best regards, >=20 > Yannick Le Lou=E9dec. >=20 >=20 > -----Message d'origine----- > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de B= en Niven-Jenkins > Envoy=E9 : lundi 9 juillet 2012 20:41 > =C0 : BERTRAND Gilles RD-CORE > Cc : cdni@ietf.org; Pilarski Marcin - Korpo TP; MARREC Anne RD-CORE > Objet : Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-0= 0.txt >=20 > Colleagues, >=20 > I started reading draft-lelouedec-cdni-request-routing-00 and this text c= aught my eye: >=20 > Quoting [I-D.ietf-cdni-problem-statement > ], "The CDNI Request Routing > interface enables a Request Routing function in an upstream CDN to > query a Request Routing function in a downstream CDN to determine if > the downstream CDN is able (and willing) to accept the delegated > content request". >=20 > The "ability" and the "willingness" of the downstream CDN to accept > the delegated content request match two fully different processes in > CDN interconnection. And the description of both these processes > should be reviewed and clarified for the following reasons: >=20 > o Regarding the former process, i.e. related to the "ability" > ("enables a Request Routing function in an upstream CDN to query a > Request Routing function in a downstream CDN to determine if the > downstream CDN is able (...) to accept the delegated content > request"), a routing protocol is used to achieve such a process, > called routing process, in many other technologies and networks > (IP, ATM, etc.). In all these technologies, it is the downstream > entity that provides routing information to the upstream entity. > The same approach should be applied to CDN interconnection. The > reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2, > dCDN 3, and then it selects one of them based on their responses") > would suffer from latency, signaling overhead and/or lack of > reactivity to events that impact the ability of the downstream > CDNs to accept delegated content requests. >=20 > o Regarding the latter process, i.e. related to the "willingness" > ("enables a Request Routing function in an upstream CDN to query a > Request Routing function in a downstream CDN to determine if the > downstream CDN (...) is willing (...)to accept the delegated > content request"), it is to be noted that the relationship between > a uCDN and a dCDN is always in the frame of a contractual > agreement between the administrative entity owning the uCDN, > acting as the customer, and the administrative entity owning the > dCDN, acting as the service provider. Therefore, consider a case > where >=20 > * the uCDN has a content request to redirect which is in full > conformance with the terms of this contractual agreement, and >=20 > * the uCDN has selected this dCDN. >=20 > As the uCDN knows, thanks to the routing information exchanged via > the aforementioned routing process, that the dCDN is able to > accept this content request, the uCDN MAY redirect the content > request to the dCDN and the dCDN MUST accept the content request. > Exchanging over the CDNI Request Routing interface information > about the "willingness" of the dCDN to accept the content request > is not relevant. >=20 > I think you might be over thinking what we wrote in the problem statement. >=20 > What was in the problem statement was meant to convey that an upstream CD= N could make a request to a downstream CDN to say "how do I redirect this r= equest to you" and the downstream CDN could reply with either "her is how t= o redirect it", or "no I can't/won't take that content delivery right now",= reasons may include the uCDN has requested a delivery of a protocol the dC= DN does not support (possibly in error) or the dCDN has no capacity right n= ow etc. >=20 > Ben >=20 > On 9 Jul 2012, at 18:00, wrote: >=20 >> Hi everyone, >>=20 >> We have just submitted the draft below. We are convinced that it will he= lp the WG to progress on the CDNI routing issues.=20 >>=20 >> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00=20 >>=20 >> Any feedback is very welcome. >>=20 >> Best regards, >>=20 >> Gilles >>=20 >>=20 >> -----Message d'origine----- >> De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] De la part de internet-drafts@ietf.org >> Envoy=E9 : lundi 9 juillet 2012 18:55 >> =C0 : i-d-announce@ietf.org >> Objet : I-D Action: draft-lelouedec-cdni-request-routing-00.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >>=20 >>=20 >> Title : CDNI Request Routing >> Author(s) : Yannick Le Louedec >> Anne Marrec >> Gilles Bertrand >> Marcin Pilarski >> Filename : draft-lelouedec-cdni-request-routing-00.txt >> Pages : 30 >> Date : 2012-07-09 >>=20 >> Abstract: >> The present document proposes to clarify the CDNI Request Routing >> interface introduced in [I-D.ietf-cdni-framework] and [I-D.ietf-cdni- >> problem-statement], as well as related terminology. >>=20 >> In particular the present document proposes to split the CDNI Request >> Routing interface into two separate interfaces with clearer roles, >> named respectively CDNI Routing interface and CDNI Downstream >> Resource Identifier Signaling interface (CDNI DRIS interface). >>=20 >> This part of the CDN interconnection framework the IETF has been >> referring to so far with the term "CDNI Request Routing" is just >> another routing, signaling and forwarding problem in a long series of >> the telecommunication history. For example, one can draw a direct >> analogy between the IP/MPLS-TE framework and the CDN interconnection >> framework. >>=20 >> In addition, this document recommends that the specification of ALL >> CDN interconnection interfaces in the scope of the CDNI IETF WG >> relies on the equivalent concept to IP prefix for CDN >> interconnection, named 'contentRequestScope'. This highly useful and >> powerful concept SHALL be used to simplify the specification of ALL >> CDN interconnection interfaces, as well as to ensure performance and >> scalability in CDN interconnection. >>=20 >> All these proposals can be smoothly integrated in the WG drafts, >> especially [I-D.ietf-cdni-framework] and >> [I-D.ietf-cdni-requirements], as they essentially propose (useful) >> clarifications of the existing framework. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-routing >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> 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 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages= electroniques etant susceptibles d'alteration, >> France Telecom - Orange decline toute responsabilite si ce message a ete= altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or privileged = information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for mess= ages that have been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> 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 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From ray.vanbrandenburg@tno.nl Tue Jul 10 06:13:07 2012 Return-Path: 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 252FE21F859A for ; Tue, 10 Jul 2012 06:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.441 X-Spam-Level: X-Spam-Status: No, score=0.441 tagged_above=-999 required=5 tests=[AWL=0.945, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 RMQAt1nvKsl7 for ; Tue, 10 Jul 2012 06:13:05 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 53C2221F8534 for ; Tue, 10 Jul 2012 06:13:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,559,1336341600"; d="scan'208";a="15730393" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 10 Jul 2012 15:13:28 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.152]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.02.0298.004; Tue, 10 Jul 2012 15:13:28 +0200 From: "Brandenburg, R. (Ray) van" To: "yannick.lelouedec@orange.com" , "Ben Niven-Jenkins" Thread-Topic: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt Thread-Index: AQHNXl47wTvj/yUIuE6cgCkhzleNz5ciGhJQgAANWoCAAFNwYA== Date: Tue, 10 Jul 2012 13:13:28 +0000 Message-ID: References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> In-Reply-To: <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" , Pilarski Marcin - Korpo TP , MARREC Anne RD-CORE Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 13:13:07 -0000 Hi Yannick, See comments inline. In general: IMO the CDNI interfaces should be abstracted from any kind of c= ontractual/business agreement that might or might not exist between a dCDN = and uCDN. The current drafts seems to assume some particular type of contra= ctual agreement between CDNs that might not always be the case. Ray -----Original Message----- From: yannick.lelouedec@orange.com [mailto:yannick.lelouedec@orange.com]=20 Sent: dinsdag 10 juli 2012 12:01 To: Brandenburg, R. (Ray) van; Ben Niven-Jenkins Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Subject: RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00= .txt Hi Ray, all, 1) Ray, Quoting your mail: "I don't see why the CDNI Request Routing interf= ace should state that a dCDN MUST deliver the content if it has indicated i= ts ability to do so earlier in either a contractual agreement or in the cap= ability interface." This is not what we have written. Let me try to rephrase simply. A contractual agreement is a contractual agreement.=20 It put in writings the respective obligations of the uCDN and of the dCDN.= =20 The uCDN may redirect any content request to the dCDN as long as it is in f= ull conformance with the terms of this contractual agreement (the type of t= he content request is in full conformance, the maximum number of content re= quests per second is respected, etc.).=20 In this case the dCDN may not say "Sorry, but I decide unilaterally to refu= se this content request". =20 [RvB]: This is where we disagree. IMHO, the type of behavior you describe (= the dCDN not living up to its obligation) should not be enforced by the CDN= I Interfaces. If a dCDN does not live up to its contractual agreement, this= should be something that is handled on a business level, not on a protocol= level. Why? Because this is the deal, a contractual agreement is a contractual agr= eement! Yet the dCDN may say "I do apologize, but at this time I cannot handle corr= ectly a certain class of content requests specified in our contractual agre= ement" (for example the class of the HTTP content requests with token from = French end users, because of overload situation, failure, etc.) This is the= role of the CDNI routing interface to provide the uCDN with such informati= on. (And the dCDN may be given a penalty for example if this was agreed in the = terms of the contractual agreement.) 2) Ray, Quoting your mail: "I understand that in most cases, the contractua= l agreement might indeed impose this behavior on the dCDN" Please provide the description of an example where this is not the case. Otherwise the IETF CDNI WG shall indeed consider this is ALWAYS the case.=20 [RvB]: I can't remember ever seeing such a discussion on the WG list. Anywa= y: one example of a contractual agreement between two CDNs is one in which = the uCDN and dCDN have agreed that the dCDN will deliver some content on be= half of a uCDN, but decide on a per-request basis whether it wants to do so= (and is for example paid per request). In these cases, the dCDN needs to h= ave the ability to deny delivery on a per-request basis.=20 And this is an important point to be able to progress in the CDNI interface= s' specification works. If the contractual agreement does not define clearly the obligations of the= uCDN, it is impossible to dimension adequately the dCDN, neither to define= correctly the CDNI contractual agreements between the dCDN and the dCDNs o= f this dCDN. If the contractual agreement does not define clearly the obligations of the= dCDN, the dCDN may do what it wants... even to put in the trash can any co= ntent request it accepted to handle. [RvB]: Exactly, this is something that needs to be discussed on a business/= contractual level and not on a technical level. That is way IMHO the CDNI I= nterfaces should not make ANY assumptions on what was agreed on a contractu= al level.=20 In both situations it is impossible to ensure any quality of experience to = the end user. 3) Ray, Quoting your mail: "I don't think this type of behavior should be i= mposed by the protocol we're developing here." I do not sure I understand this sentence.=20 Every routing protocol has been defined (or at least configured) so far by = considering the expected behavior of the interconnected elements/networks. = =20 [RvB]: Every routing protocol defines the expected behavior of interconnect= ed elements/networks on a technical level, not on a business level. Having = a dCDN say 'I'm not willing to deliver this content' is perfectly fine fro= m a technical perspective, although it could be problematic from a contract= ual perspective.=20 But maybe I will understand if you provide an example on the point 2 above. Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] Envoy=E9=A0: mardi 10 juillet 2012 09:20 =C0=A0: Ben Niven-Jenkins; LE LOUEDEC Yannick RD-CORE Cc=A0: Pilarski Marci= n - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Objet=A0: RE: [CDNi] TR: I= -D Action: draft-lelouedec-cdni-request-routing-00.txt Hi Yannick, Ben, I tend to agree with Ben here. When reading the draft, I got the feeling th= at the draft seems to assume a lot about the relationship between the uCDN = and dCDN. For example, I don't see why the CDNI Request Routing interface s= hould state that a dCDN MUST deliver the content if it has indicated its ab= ility to do so earlier in either a contractual agreement or in the capabili= ty interface. I understand that in most cases, the contractual agreement mi= ght indeed impose this behavior on the dCDN, but I don't think this type of= behavior should be imposed by the protocol we're developing here.=20 It was always my assumption that the Request Routing Interface would at lea= st include the option of allowing the uCDN to query the dCDN for every cont= ent request whether the dCDN is willing to deliver that particular request.= =20 I will send my full review of the draft later.=20 Ray -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben= Niven-Jenkins Sent: dinsdag 10 juli 2012 7:38 To: yannick.lelouedec@orange.com Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00= .txt Yannick, Please see inline. On 9 Jul 2012, at 20:05, wrote: > Hi Ben, all, >=20 > Ben, quoting you mail below, "... the downstream CDN could reply with=20 > either "here is how to redirect it"", >=20 > =3D> This is the role of the CDNI DRIS interface to provide the uCDN with= this information, and we target to make its specification public before Va= ncouver meeting so that everyone may read it before the meeting and get ful= l knowledge of our proposal about this part of CDNI request routing. >=20 > Ben, quoting you mail below, "... or "no I can't/won't take that content = delivery right now", reasons may include the uCDN has requested a delivery = of a protocol the dCDN does not support (possibly in error). >=20 > =3D> This is the role of the CDNI logging interface to provide the uCDN w= ith this information. I agree this information should be logged but the Request Routing interface= (what you call the DRIS) also needs to be able to indicate a failure. Otherwise the uCDN will 'blindly' redirect the the dCDN and the delivery wi= ll fail leading to poor end user experience. > Ben, quoting you mail below, "... or "no I can't/won't take that content = delivery right now", reasons may include ... the dCDN has no capacity right= now etc." >=20 > =3D> This is the role of the CDNI routing interface to provide the uCDN w= ith this information. It is the role of the CDN capability/routing interface to advertise broad c= apabilities etc not to give extremely fine grained real-time information on= exactly the state of the dCDN. Even if the capability/routing interface is real-time there are likely to s= till be race conditions where we need the dCDN to be about to indicate a fa= ilure to accept a redirect through the request routing/DRIS interface > So we may conclude we are in line basically, which is a good point. > We just aimed at checking there was a common understanding on this point. >=20 > The key point for us here is that we don't want this sentence extracted f= rom draft-ietf-cdni-problem-statement be interpreted as: ". and the dCDN MU= ST accept the content request except when it has not the "ability" to do so= ." Why not? IMO that is a valid scenario for some use cases. > The fact that the dCDN is temporary unable to handle content request corr= ectly is not a valid reason for the dCDN to be discharged of its obligation= s to the uCDN. > The contract set between the uCDN and the dCDN remains valid anyway, and = the obligations of the dCDN as well. Correct, but that contract may not be the same for all uCDNs & dCDNs, for e= xample a uCDN may not have a guarantee that a dCDN can handle everything it= is requested to handle but the contract may only be that the dCDN guarante= es to handle up to a certain volume of traffic. > The dCDN must announce to the uCDN that it is temporary unable, as soon a= s possible, via the CDNI routing interface. > And the uCDN must take this information into account in its CDN selection= process as soon as possible. > Then if the uCDN decides to continue to redirect content requests to the = dCDN, the uCDN MAY perfectly do it, but the uCDN knows these content reques= ts will be lost. What happens in the period between the dCDN being unable to handle requests= and the time it takes to advertise that to the uCDN and for the uCDN to pr= ocess & incorporate that new knowledge? Are requests blindly forwarded to t= he dCDN which is unable to handle them leading to poor user experience? > We could even imagine the situation where the uCDN continues to do it int= entionally, because it has no better option and the content request will be= lost anyway. For example in the case where neither the uCDN nor the other = downstream CDNs of the uCDN cannot manage correctly the content request, th= e uCDN could do it intentionally so as to be able to clearly prove (with CD= NI logging information) that it is the dCDN, not the uCDN, who is at fault. > But, of course, if there are alternative backup options, the normal react= ion of the uCDN is to stop as soon as possible to redirect content requests= to the dCDN when the uCDN knows that the dCDN is unable to handle them cor= rectly. >=20 > So, to be clear, we would prefer the sentence to be understood as: > ". and the dCDN MUST accept the content request.=20 > And if it cannot handle correctly the redirected content request it recei= ves, the content request is lost. What about scenarios where the uCDN has a choice of dCDNs (e.g. two nationa= l-wide CDNs offering services at different costs), the uCDN may elect to qu= ery both dCDNs and decide based on their responses which one to choose. If = the dCDN is unable to satisfy the request the uCDN needs to know that so th= at it can fallback to the (more expensive in this example) dCDN. > For example the dCDN generates a response to the content request with an = error message, or no response at all. And in parallel the CDNI logging inte= rface may be used to exchange logs corresponding to this problem. Anyway th= e dCDN MAY NOT redirect that content request back towards the uCDN."=20 >=20 > Exactly as in IP networks: IP packets are not sent back towards the origi= n by a downstream router under failure or congestion. In a routed IP network, there is often a small packet loss while the networ= k re-converges, by enabling the dCDN to refuse a redirection at CDNI Reques= t Routing/DRIS query time we can reduce that window by giving the uCDN the = option to take an alternative action (e.g. try another dCDN) while the rout= ing/capability information re-converges. > In both networks (IP and CDN), the reason is the same. > If the dCDN redirects back a content request to the uCDN, this generates = a loop.=20 Loop avoidance is a separate issue IMO to whether we should allow a dCDN to= be able to communicate "I am unable/unwilling to take that content deliver= y at this time". Regards Ben > To manage this would introduce a very high complexity. > And this would be just to try to save the content requests redirected by = the uCDN to the dCDN in the timeslot between the time the dCDN gets down an= d the time the uCDN takes this failure into account in its CDN selection pr= ocess. > It is much better to try to reduce this timeslot as much as possible, wit= h routing optimizations (we will propose as soon as possible). > Rather than introducing additional complexities (to manage redirection to= the uCDN) in the framework. >=20 >=20 > By the way, as you know, the IESG has just approved today the 'Content Di= stribution Network Interconnection (CDNI) Problem Statement' draft as infor= mational RFC. This is a good point. > And, as you may see in the draft "CDNI request routing", we do not propos= e to modify this problem statement draft. > We want know to focus now on getting the specifications of all CDNI inter= faces ready as soon as possible. >=20 > Best regards, >=20 > Yannick Le Lou=E9dec. >=20 >=20 > -----Message d'origine----- > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part=20 > de Ben Niven-Jenkins Envoy=E9 : lundi 9 juillet 2012 20:41 =C0 : BERTRAND= =20 > Gilles RD-CORE Cc : cdni@ietf.org; Pilarski Marcin - Korpo TP; MARREC=20 > Anne RD-CORE Objet : Re: [CDNi] TR: I-D Action: > draft-lelouedec-cdni-request-routing-00.txt >=20 > Colleagues, >=20 > I started reading draft-lelouedec-cdni-request-routing-00 and this text c= aught my eye: >=20 > Quoting [I-D.ietf-cdni-problem-statement ], "The CDNI Request=20 > Routing > interface enables a Request Routing function in an upstream CDN to > query a Request Routing function in a downstream CDN to determine if > the downstream CDN is able (and willing) to accept the delegated > content request". >=20 > The "ability" and the "willingness" of the downstream CDN to accept > the delegated content request match two fully different processes in > CDN interconnection. And the description of both these processes > should be reviewed and clarified for the following reasons: >=20 > o Regarding the former process, i.e. related to the "ability" > ("enables a Request Routing function in an upstream CDN to query a > Request Routing function in a downstream CDN to determine if the > downstream CDN is able (...) to accept the delegated content > request"), a routing protocol is used to achieve such a process, > called routing process, in many other technologies and networks > (IP, ATM, etc.). In all these technologies, it is the downstream > entity that provides routing information to the upstream entity. > The same approach should be applied to CDN interconnection. The > reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2, > dCDN 3, and then it selects one of them based on their responses") > would suffer from latency, signaling overhead and/or lack of > reactivity to events that impact the ability of the downstream > CDNs to accept delegated content requests. >=20 > o Regarding the latter process, i.e. related to the "willingness" > ("enables a Request Routing function in an upstream CDN to query a > Request Routing function in a downstream CDN to determine if the > downstream CDN (...) is willing (...)to accept the delegated > content request"), it is to be noted that the relationship between > a uCDN and a dCDN is always in the frame of a contractual > agreement between the administrative entity owning the uCDN, > acting as the customer, and the administrative entity owning the > dCDN, acting as the service provider. Therefore, consider a case > where >=20 > * the uCDN has a content request to redirect which is in full > conformance with the terms of this contractual agreement, and >=20 > * the uCDN has selected this dCDN. >=20 > As the uCDN knows, thanks to the routing information exchanged via > the aforementioned routing process, that the dCDN is able to > accept this content request, the uCDN MAY redirect the content > request to the dCDN and the dCDN MUST accept the content request. > Exchanging over the CDNI Request Routing interface information > about the "willingness" of the dCDN to accept the content request > is not relevant. >=20 > I think you might be over thinking what we wrote in the problem statement= . >=20 > What was in the problem statement was meant to convey that an upstream CD= N could make a request to a downstream CDN to say "how do I redirect this r= equest to you" and the downstream CDN could reply with either "her is how t= o redirect it", or "no I can't/won't take that content delivery right now",= reasons may include the uCDN has requested a delivery of a protocol the dC= DN does not support (possibly in error) or the dCDN has no capacity right n= ow etc. >=20 > Ben >=20 > On 9 Jul 2012, at 18:00, wrote: >=20 >> Hi everyone, >>=20 >> We have just submitted the draft below. We are convinced that it will he= lp the WG to progress on the CDNI routing issues.=20 >>=20 >> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >>=20 >> Any feedback is very welcome. >>=20 >> Best regards, >>=20 >> Gilles >>=20 >>=20 >> -----Message d'origine----- >> De : i-d-announce-bounces@ietf.org >> [mailto:i-d-announce-bounces@ietf.org] De la part de=20 >> internet-drafts@ietf.org Envoy=E9 : lundi 9 juillet 2012 18:55 =C0 : >> i-d-announce@ietf.org Objet : I-D Action:=20 >> draft-lelouedec-cdni-request-routing-00.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >>=20 >>=20 >> Title : CDNI Request Routing >> Author(s) : Yannick Le Louedec >> Anne Marrec >> Gilles Bertrand >> Marcin Pilarski >> Filename : draft-lelouedec-cdni-request-routing-00.txt >> Pages : 30 >> Date : 2012-07-09 >>=20 >> Abstract: >> The present document proposes to clarify the CDNI Request Routing=20 >> interface introduced in [I-D.ietf-cdni-framework] and [I-D.ietf-cdni-=20 >> problem-statement], as well as related terminology. >>=20 >> In particular the present document proposes to split the CDNI=20 >> Request Routing interface into two separate interfaces with clearer=20 >> roles, named respectively CDNI Routing interface and CDNI Downstream=20 >> Resource Identifier Signaling interface (CDNI DRIS interface). >>=20 >> This part of the CDN interconnection framework the IETF has been=20 >> referring to so far with the term "CDNI Request Routing" is just=20 >> another routing, signaling and forwarding problem in a long series of=20 >> the telecommunication history. For example, one can draw a direct=20 >> analogy between the IP/MPLS-TE framework and the CDN interconnection=20 >> framework. >>=20 >> In addition, this document recommends that the specification of ALL=20 >> CDN interconnection interfaces in the scope of the CDNI IETF WG=20 >> relies on the equivalent concept to IP prefix for CDN=20 >> interconnection, named 'contentRequestScope'. This highly useful and=20 >> powerful concept SHALL be used to simplify the specification of ALL=20 >> CDN interconnection interfaces, as well as to ensure performance and=20 >> scalability in CDN interconnection. >>=20 >> All these proposals can be smoothly integrated in the WG drafts,=20 >> especially [I-D.ietf-cdni-framework] and=20 >> [I-D.ietf-cdni-requirements], as they essentially propose (useful)=20 >> clarifications of the existing framework. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-routing >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> 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=20 >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >> _____________________________________________________________________ >> ____________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for mess= ages that have been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> 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 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, France Telecom - Orange decline toute responsabilite si ce message a e= te altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, France Telecom - = Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From internet-drafts@ietf.org Tue Jul 10 06:31:47 2012 Return-Path: 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 642AB21F86C3; Tue, 10 Jul 2012 06:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 VxAmkoWj+iNw; Tue, 10 Jul 2012 06:31:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B248321F86C2; Tue, 10 Jul 2012 06:31:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120710133146.20992.12462.idtracker@ietfa.amsl.com> Date: Tue, 10 Jul 2012 06:31:46 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-use-cases-09.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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 13:31:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : Use Cases for Content Delivery Network Interconnection Author(s) : Gilles Bertrand Stephan Emile Trevor Burbridge Philip Eardley Kevin J. Ma Grant Watson Filename : draft-ietf-cdni-use-cases-09.txt Pages : 16 Date : 2012-07-10 Abstract: Content Delivery Networks (CDNs) are commonly used for improving the End User experience of a content delivery service while keeping cost at a reasonable level. This document 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. The document can be used to guide the definition of the requirements to be supported by CDN Interconnection (CDNI) interfaces. It obsoletes RFC 3570. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-use-cases There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-use-cases-09 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-use-cases-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yannick.lelouedec@orange.com Tue Jul 10 07:32:45 2012 Return-Path: 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 EF75811E80EC for ; Tue, 10 Jul 2012 07:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=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 ffcVVjS8OzCb for ; Tue, 10 Jul 2012 07:32:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACE111E807F for ; Tue, 10 Jul 2012 07:32:41 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 19BA13B4232; Tue, 10 Jul 2012 16:33:09 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id EF53F4C066; Tue, 10 Jul 2012 16:33:08 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Tue, 10 Jul 2012 16:33:03 +0200 From: To: "Brandenburg, R. (Ray) van" , Ben Niven-Jenkins Thread-Topic: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt Thread-Index: AQHNXl47wTvj/yUIuE6cgCkhzleNz5ciGhJQgAANWoCAAFNwYIAAGDKQ Date: Tue, 10 Jul 2012 14:33:02 +0000 Message-ID: <2040_1341930789_4FFC3D24_2040_2504_1_b86bff40-ae68-40c0-b8e5-060f51be6864@PEXCVZYH02.corporate.adroot.infra.ftgroup> References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.10.134230 Cc: "cdni@ietf.org" , Pilarski Marcin - Korpo TP , MARREC Anne RD-CORE Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 14:32:45 -0000 Hi Ray, 1) Ray, quoting your mail: "The current drafts seems to assume some particu= lar type of contractual agreement between CDNs that might not always be the= case." Please quote the draft. Please let us know exactly to which sentence(s) of the draft you are referr= ing to. Otherwise it is hard to discuss and comment on your email.=20 2) Ray, Quoting your mail: "If a dCDN does not live up to its contractual a= greement, this should be something that is handled on a business level, not= on a protocol level." Maybe there is a deep misunderstanding.=20 So I will try to be clear again. We do not propose the CDNI routing interface to be used by the dCDN to send= a message saying "Sorry, but I decide unilaterally to refuse this content = request".=20 We do not propose the CDNI routing interface to be used to handle any aspec= t relating to a dCDN deciding unilaterally to stop living up to its contrac= tual agreement. Please let us know where you saw such an idea in this IETF draft "CDNI requ= est routing".=20 The only role of the CDNI routing interface is to be used to advertise CDNI= routing information from the downstream CDN to the upstream CDN. And this is the description given in this IETF draft. 3) Ray, quoting your mail: "one example of a contractual agreement between = two CDNs is one in which the uCDN and dCDN have agreed that the dCDN will d= eliver some content on behalf of a uCDN, but decide on a per-request basis = whether it wants to do so (and is for example paid per request). In these c= ases, the dCDN needs to have the ability to deny delivery on a per-request = basis." Let me try to fully understand your point: Are you really meaning that in this case the dCDN has in reality absolutely= no obligation with regards to the uCDN? Are you really meaning that in this case the dCDN decides alone, in real ti= me, and for each content request, whether it denies or accepts to ensure de= livery? Are you really meaning that in this case the dCDN decides alone, in real ti= me, and for each content request, whether it denies or accepts to ensure de= livery, and this even if the dCDN has the capability to deliver the content? Are you really meaning that in this case the dCDN may possibly response neg= atively to all requests for content request redirection submitted by the uC= DN over the CDNI request routing interface? (i.e. that possibly the uCDN wi= ll never be allowed/invited to redirect a content request to the dCDN?) =20 4) Ray, quoting your mail: "Every routing protocol defines the expected beh= avior of interconnected elements/networks on a technical level, not on a bu= siness level."=20 Again, this is not what I have written, and this is not the idea we want to= share. I wrote "Every routing protocol has been defined (or at least configured) s= o far by considering the expected behavior of the interconnected elements/n= etworks."=20=20 That's all. I can rephrase this sentence the following way: "we must know what we expec= t to do with a protocol to design it correctly." And IHMO this is an evidence; I don't know any other way to proceed. Besides, let us consider BGP (which is by the way an option proposed by som= e IETF members to implement this CDNI routing interface). In IP networks, BGP configurations in IP routers are defined as per the bus= iness relationships (valley free policy, etc.). Of course the business relationships determine the BGP configurations. And of course BGP has been designed so as to allow to configure IP intercon= nections adequately depending on the corresponding Customer/provider, sibli= ng and peering contractual agreements. But this does not mean that BGP "defines the expected behavior of interconn= ected elements/networks... on a business level." Even if we can indeed infer quite accurately the business relationships bet= ween ISP from the BGP configuration of their IP routers (see CAIDA project)= , but this is another story. Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl]=20 Envoy=E9=A0: mardi 10 juillet 2012 15:13 =C0=A0: LE LOUEDEC Yannick RD-CORE; Ben Niven-Jenkins Cc=A0: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Objet=A0: RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-0= 0.txt Hi Yannick, See comments inline. In general: IMO the CDNI interfaces should be abstracted from any kind of c= ontractual/business agreement that might or might not exist between a dCDN = and uCDN. The current drafts seems to assume some particular type of contra= ctual agreement between CDNs that might not always be the case. Ray -----Original Message----- From: yannick.lelouedec@orange.com [mailto:yannick.lelouedec@orange.com]=20 Sent: dinsdag 10 juli 2012 12:01 To: Brandenburg, R. (Ray) van; Ben Niven-Jenkins Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Subject: RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00= .txt Hi Ray, all, 1) Ray, Quoting your mail: "I don't see why the CDNI Request Routing interf= ace should state that a dCDN MUST deliver the content if it has indicated i= ts ability to do so earlier in either a contractual agreement or in the cap= ability interface." This is not what we have written. Let me try to rephrase simply. A contractual agreement is a contractual agreement.=20 It put in writings the respective obligations of the uCDN and of the dCDN.= =20 The uCDN may redirect any content request to the dCDN as long as it is in f= ull conformance with the terms of this contractual agreement (the type of t= he content request is in full conformance, the maximum number of content re= quests per second is respected, etc.).=20 In this case the dCDN may not say "Sorry, but I decide unilaterally to refu= se this content request".=20=20 [RvB]: This is where we disagree. IMHO, the type of behavior you describe (= the dCDN not living up to its obligation) should not be enforced by the CDN= I Interfaces. If a dCDN does not live up to its contractual agreement, this= should be something that is handled on a business level, not on a protocol= level. Why? Because this is the deal, a contractual agreement is a contractual agr= eement! Yet the dCDN may say "I do apologize, but at this time I cannot handle corr= ectly a certain class of content requests specified in our contractual agre= ement" (for example the class of the HTTP content requests with token from = French end users, because of overload situation, failure, etc.) This is the= role of the CDNI routing interface to provide the uCDN with such informati= on. (And the dCDN may be given a penalty for example if this was agreed in the = terms of the contractual agreement.) 2) Ray, Quoting your mail: "I understand that in most cases, the contractua= l agreement might indeed impose this behavior on the dCDN" Please provide the description of an example where this is not the case. Otherwise the IETF CDNI WG shall indeed consider this is ALWAYS the case.= =20 [RvB]: I can't remember ever seeing such a discussion on the WG list. Anywa= y: one example of a contractual agreement between two CDNs is one in which = the uCDN and dCDN have agreed that the dCDN will deliver some content on be= half of a uCDN, but decide on a per-request basis whether it wants to do so= (and is for example paid per request). In these cases, the dCDN needs to h= ave the ability to deny delivery on a per-request basis.=20 And this is an important point to be able to progress in the CDNI interface= s' specification works. If the contractual agreement does not define clearly the obligations of the= uCDN, it is impossible to dimension adequately the dCDN, neither to define= correctly the CDNI contractual agreements between the dCDN and the dCDNs o= f this dCDN. If the contractual agreement does not define clearly the obligations of the= dCDN, the dCDN may do what it wants... even to put in the trash can any co= ntent request it accepted to handle. [RvB]: Exactly, this is something that needs to be discussed on a business/= contractual level and not on a technical level. That is way IMHO the CDNI I= nterfaces should not make ANY assumptions on what was agreed on a contractu= al level.=20 In both situations it is impossible to ensure any quality of experience to = the end user. 3) Ray, Quoting your mail: "I don't think this type of behavior should be i= mposed by the protocol we're developing here." I do not sure I understand this sentence.=20 Every routing protocol has been defined (or at least configured) so far by = considering the expected behavior of the interconnected elements/networks.= =20=20 [RvB]: Every routing protocol defines the expected behavior of interconnect= ed elements/networks on a technical level, not on a business level. Having = a dCDN say 'I'm not willing to deliver this content' is perfectly fine fro= m a technical perspective, although it could be problematic from a contract= ual perspective.=20 But maybe I will understand if you provide an example on the point 2 above. Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] Envoy=E9=A0: mardi 10 juillet 2012 09:20 =C0=A0: Ben Niven-Jenkins; LE LOUEDEC Yannick RD-CORE Cc=A0: Pilarski Marci= n - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Objet=A0: RE: [CDNi] TR: I= -D Action: draft-lelouedec-cdni-request-routing-00.txt Hi Yannick, Ben, I tend to agree with Ben here. When reading the draft, I got the feeling th= at the draft seems to assume a lot about the relationship between the uCDN = and dCDN. For example, I don't see why the CDNI Request Routing interface s= hould state that a dCDN MUST deliver the content if it has indicated its ab= ility to do so earlier in either a contractual agreement or in the capabili= ty interface. I understand that in most cases, the contractual agreement mi= ght indeed impose this behavior on the dCDN, but I don't think this type of= behavior should be imposed by the protocol we're developing here.=20 It was always my assumption that the Request Routing Interface would at lea= st include the option of allowing the uCDN to query the dCDN for every cont= ent request whether the dCDN is willing to deliver that particular request.= =20 I will send my full review of the draft later.=20 Ray -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben= Niven-Jenkins Sent: dinsdag 10 juli 2012 7:38 To: yannick.lelouedec@orange.com Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00= .txt Yannick, Please see inline. On 9 Jul 2012, at 20:05, wrote: > Hi Ben, all, >=20 > Ben, quoting you mail below, "... the downstream CDN could reply with=20 > either "here is how to redirect it"", >=20 > =3D> This is the role of the CDNI DRIS interface to provide the uCDN with= this information, and we target to make its specification public before Va= ncouver meeting so that everyone may read it before the meeting and get ful= l knowledge of our proposal about this part of CDNI request routing. >=20 > Ben, quoting you mail below, "... or "no I can't/won't take that content = delivery right now", reasons may include the uCDN has requested a delivery = of a protocol the dCDN does not support (possibly in error). >=20 > =3D> This is the role of the CDNI logging interface to provide the uCDN w= ith this information. I agree this information should be logged but the Request Routing interface= (what you call the DRIS) also needs to be able to indicate a failure. Otherwise the uCDN will 'blindly' redirect the the dCDN and the delivery wi= ll fail leading to poor end user experience. > Ben, quoting you mail below, "... or "no I can't/won't take that content = delivery right now", reasons may include ... the dCDN has no capacity right= now etc." >=20 > =3D> This is the role of the CDNI routing interface to provide the uCDN w= ith this information. It is the role of the CDN capability/routing interface to advertise broad c= apabilities etc not to give extremely fine grained real-time information on= exactly the state of the dCDN. Even if the capability/routing interface is real-time there are likely to s= till be race conditions where we need the dCDN to be about to indicate a fa= ilure to accept a redirect through the request routing/DRIS interface > So we may conclude we are in line basically, which is a good point. > We just aimed at checking there was a common understanding on this point. >=20 > The key point for us here is that we don't want this sentence extracted f= rom draft-ietf-cdni-problem-statement be interpreted as: ". and the dCDN MU= ST accept the content request except when it has not the "ability" to do so= ." Why not? IMO that is a valid scenario for some use cases. > The fact that the dCDN is temporary unable to handle content request corr= ectly is not a valid reason for the dCDN to be discharged of its obligation= s to the uCDN. > The contract set between the uCDN and the dCDN remains valid anyway, and = the obligations of the dCDN as well. Correct, but that contract may not be the same for all uCDNs & dCDNs, for e= xample a uCDN may not have a guarantee that a dCDN can handle everything it= is requested to handle but the contract may only be that the dCDN guarante= es to handle up to a certain volume of traffic. > The dCDN must announce to the uCDN that it is temporary unable, as soon a= s possible, via the CDNI routing interface. > And the uCDN must take this information into account in its CDN selection= process as soon as possible. > Then if the uCDN decides to continue to redirect content requests to the = dCDN, the uCDN MAY perfectly do it, but the uCDN knows these content reques= ts will be lost. What happens in the period between the dCDN being unable to handle requests= and the time it takes to advertise that to the uCDN and for the uCDN to pr= ocess & incorporate that new knowledge? Are requests blindly forwarded to t= he dCDN which is unable to handle them leading to poor user experience? > We could even imagine the situation where the uCDN continues to do it int= entionally, because it has no better option and the content request will be= lost anyway. For example in the case where neither the uCDN nor the other = downstream CDNs of the uCDN cannot manage correctly the content request, th= e uCDN could do it intentionally so as to be able to clearly prove (with CD= NI logging information) that it is the dCDN, not the uCDN, who is at fault. > But, of course, if there are alternative backup options, the normal react= ion of the uCDN is to stop as soon as possible to redirect content requests= to the dCDN when the uCDN knows that the dCDN is unable to handle them cor= rectly. >=20 > So, to be clear, we would prefer the sentence to be understood as: > ". and the dCDN MUST accept the content request.=20 > And if it cannot handle correctly the redirected content request it recei= ves, the content request is lost. What about scenarios where the uCDN has a choice of dCDNs (e.g. two nationa= l-wide CDNs offering services at different costs), the uCDN may elect to qu= ery both dCDNs and decide based on their responses which one to choose. If = the dCDN is unable to satisfy the request the uCDN needs to know that so th= at it can fallback to the (more expensive in this example) dCDN. > For example the dCDN generates a response to the content request with an = error message, or no response at all. And in parallel the CDNI logging inte= rface may be used to exchange logs corresponding to this problem. Anyway th= e dCDN MAY NOT redirect that content request back towards the uCDN."=20 >=20 > Exactly as in IP networks: IP packets are not sent back towards the origi= n by a downstream router under failure or congestion. In a routed IP network, there is often a small packet loss while the networ= k re-converges, by enabling the dCDN to refuse a redirection at CDNI Reques= t Routing/DRIS query time we can reduce that window by giving the uCDN the = option to take an alternative action (e.g. try another dCDN) while the rout= ing/capability information re-converges. > In both networks (IP and CDN), the reason is the same. > If the dCDN redirects back a content request to the uCDN, this generates = a loop.=20 Loop avoidance is a separate issue IMO to whether we should allow a dCDN to= be able to communicate "I am unable/unwilling to take that content deliver= y at this time". Regards Ben > To manage this would introduce a very high complexity. > And this would be just to try to save the content requests redirected by = the uCDN to the dCDN in the timeslot between the time the dCDN gets down an= d the time the uCDN takes this failure into account in its CDN selection pr= ocess. > It is much better to try to reduce this timeslot as much as possible, wit= h routing optimizations (we will propose as soon as possible). > Rather than introducing additional complexities (to manage redirection to= the uCDN) in the framework. >=20 >=20 > By the way, as you know, the IESG has just approved today the 'Content Di= stribution Network Interconnection (CDNI) Problem Statement' draft as infor= mational RFC. This is a good point. > And, as you may see in the draft "CDNI request routing", we do not propos= e to modify this problem statement draft. > We want know to focus now on getting the specifications of all CDNI inter= faces ready as soon as possible. >=20 > Best regards, >=20 > Yannick Le Lou=E9dec. >=20 >=20 > -----Message d'origine----- > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part=20 > de Ben Niven-Jenkins Envoy=E9 : lundi 9 juillet 2012 20:41 =C0 : BERTRAND= =20 > Gilles RD-CORE Cc : cdni@ietf.org; Pilarski Marcin - Korpo TP; MARREC=20 > Anne RD-CORE Objet : Re: [CDNi] TR: I-D Action: > draft-lelouedec-cdni-request-routing-00.txt >=20 > Colleagues, >=20 > I started reading draft-lelouedec-cdni-request-routing-00 and this text c= aught my eye: >=20 > Quoting [I-D.ietf-cdni-problem-statement ], "The CDNI Request=20 > Routing > interface enables a Request Routing function in an upstream CDN to > query a Request Routing function in a downstream CDN to determine if > the downstream CDN is able (and willing) to accept the delegated > content request". >=20 > The "ability" and the "willingness" of the downstream CDN to accept > the delegated content request match two fully different processes in > CDN interconnection. And the description of both these processes > should be reviewed and clarified for the following reasons: >=20 > o Regarding the former process, i.e. related to the "ability" > ("enables a Request Routing function in an upstream CDN to query a > Request Routing function in a downstream CDN to determine if the > downstream CDN is able (...) to accept the delegated content > request"), a routing protocol is used to achieve such a process, > called routing process, in many other technologies and networks > (IP, ATM, etc.). In all these technologies, it is the downstream > entity that provides routing information to the upstream entity. > The same approach should be applied to CDN interconnection. The > reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2, > dCDN 3, and then it selects one of them based on their responses") > would suffer from latency, signaling overhead and/or lack of > reactivity to events that impact the ability of the downstream > CDNs to accept delegated content requests. >=20 > o Regarding the latter process, i.e. related to the "willingness" > ("enables a Request Routing function in an upstream CDN to query a > Request Routing function in a downstream CDN to determine if the > downstream CDN (...) is willing (...)to accept the delegated > content request"), it is to be noted that the relationship between > a uCDN and a dCDN is always in the frame of a contractual > agreement between the administrative entity owning the uCDN, > acting as the customer, and the administrative entity owning the > dCDN, acting as the service provider. Therefore, consider a case > where >=20 > * the uCDN has a content request to redirect which is in full > conformance with the terms of this contractual agreement, and >=20 > * the uCDN has selected this dCDN. >=20 > As the uCDN knows, thanks to the routing information exchanged via > the aforementioned routing process, that the dCDN is able to > accept this content request, the uCDN MAY redirect the content > request to the dCDN and the dCDN MUST accept the content request. > Exchanging over the CDNI Request Routing interface information > about the "willingness" of the dCDN to accept the content request > is not relevant. >=20 > I think you might be over thinking what we wrote in the problem statement. >=20 > What was in the problem statement was meant to convey that an upstream CD= N could make a request to a downstream CDN to say "how do I redirect this r= equest to you" and the downstream CDN could reply with either "her is how t= o redirect it", or "no I can't/won't take that content delivery right now",= reasons may include the uCDN has requested a delivery of a protocol the dC= DN does not support (possibly in error) or the dCDN has no capacity right n= ow etc. >=20 > Ben >=20 > On 9 Jul 2012, at 18:00, wrote: >=20 >> Hi everyone, >>=20 >> We have just submitted the draft below. We are convinced that it will he= lp the WG to progress on the CDNI routing issues.=20 >>=20 >> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >>=20 >> Any feedback is very welcome. >>=20 >> Best regards, >>=20 >> Gilles >>=20 >>=20 >> -----Message d'origine----- >> De : i-d-announce-bounces@ietf.org >> [mailto:i-d-announce-bounces@ietf.org] De la part de=20 >> internet-drafts@ietf.org Envoy=E9 : lundi 9 juillet 2012 18:55 =C0 : >> i-d-announce@ietf.org Objet : I-D Action:=20 >> draft-lelouedec-cdni-request-routing-00.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >>=20 >>=20 >> Title : CDNI Request Routing >> Author(s) : Yannick Le Louedec >> Anne Marrec >> Gilles Bertrand >> Marcin Pilarski >> Filename : draft-lelouedec-cdni-request-routing-00.txt >> Pages : 30 >> Date : 2012-07-09 >>=20 >> Abstract: >> The present document proposes to clarify the CDNI Request Routing=20 >> interface introduced in [I-D.ietf-cdni-framework] and [I-D.ietf-cdni-=20 >> problem-statement], as well as related terminology. >>=20 >> In particular the present document proposes to split the CDNI=20 >> Request Routing interface into two separate interfaces with clearer=20 >> roles, named respectively CDNI Routing interface and CDNI Downstream=20 >> Resource Identifier Signaling interface (CDNI DRIS interface). >>=20 >> This part of the CDN interconnection framework the IETF has been=20 >> referring to so far with the term "CDNI Request Routing" is just=20 >> another routing, signaling and forwarding problem in a long series of=20 >> the telecommunication history. For example, one can draw a direct=20 >> analogy between the IP/MPLS-TE framework and the CDN interconnection=20 >> framework. >>=20 >> In addition, this document recommends that the specification of ALL=20 >> CDN interconnection interfaces in the scope of the CDNI IETF WG=20 >> relies on the equivalent concept to IP prefix for CDN=20 >> interconnection, named 'contentRequestScope'. This highly useful and=20 >> powerful concept SHALL be used to simplify the specification of ALL=20 >> CDN interconnection interfaces, as well as to ensure performance and=20 >> scalability in CDN interconnection. >>=20 >> All these proposals can be smoothly integrated in the WG drafts,=20 >> especially [I-D.ietf-cdni-framework] and=20 >> [I-D.ietf-cdni-requirements], as they essentially propose (useful)=20 >> clarifications of the existing framework. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-routing >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> 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=20 >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >> _____________________________________________________________________ >> ____________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for mess= ages that have been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> 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 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, France Telecom - Orange decline toute responsabilite si ce message a e= te altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, France Telecom - = Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From ray.vanbrandenburg@tno.nl Tue Jul 10 08:39:02 2012 Return-Path: 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 2D15211E808F for ; Tue, 10 Jul 2012 08:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.393 X-Spam-Level: X-Spam-Status: No, score=0.393 tagged_above=-999 required=5 tests=[AWL=0.897, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 3hWm1SCvwvA1 for ; Tue, 10 Jul 2012 08:39:00 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9014211E808E for ; Tue, 10 Jul 2012 08:38:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,559,1336341600"; d="scan'208";a="15732860" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1b.tno.nl with ESMTP; 10 Jul 2012 17:39:19 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.152]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0298.004; Tue, 10 Jul 2012 17:39:18 +0200 From: "Brandenburg, R. (Ray) van" To: " " Thread-Topic: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt Thread-Index: AQHNXl47wTvj/yUIuE6cgCkhzleNz5ciGhJQgAANWoCAAFNwYIAAGDKQ///ykoA= Date: Tue, 10 Jul 2012 15:39:17 +0000 Message-ID: <3A7EA7EE-F8D4-4094-83F2-12CD3826B662@tno.nl> References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> <2040_1341930789_4FFC3D24_2040_2504_1_b86bff40-ae68-40c0-b8e5-060f51be6864@PEXCVZYH02.corporate.adroot.infra.ftgroup> In-Reply-To: <2040_1341930789_4FFC3D24_2040_2504_1_b86bff40-ae68-40c0-b8e5-060f51be6864@PEXCVZYH02.corporate.adroot.infra.ftgroup> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" , Pilarski Marcin - Korpo TP , MARREC Anne RD-CORE Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 15:39:02 -0000 Hi Yannick, We seem to be misunderstanding each other. Maybe this will help clarify my = point: > Let me try to fully understand your point: > Are you really meaning that in this case the dCDN has in reality absolute= ly no obligation with regards to the uCDN? > Are you really meaning that in this case the dCDN decides alone, in real = time, and for each content request, whether it denies or accepts to ensure = delivery? What I mean is that I would like to have a RR Interface at least support a = model where for every content request the uCDN asks the dCDN whether it wan= ts to deliver that particular content item (I believe you call this a PULL = approach). And I would like to allow the dCDN to be able to say 'No' on thi= s request (whether it is for purposes or failure, overload, or any other re= ason). > Are you really meaning that in this case the dCDN decides alone, in real = time, and for each content request, whether it denies or accepts to ensure = delivery, and this even if the dCDN has the capability to deliver the conte= nt? Yes.=20 > Are you really meaning that in this case the dCDN may possibly response n= egatively to all requests for content request redirection submitted by the = uCDN over the CDNI request routing interface? (i.e. that possibly the uCDN = will never be allowed/invited to redirect a content request to the dCDN?) Yes. Any negative effect this may have on the business relationship betwee= n uCDN and dCDN should be handled on the business level. Ray On Jul 10, 2012, at 4:33 PM, wrote: > Hi Ray, >=20 >=20 > 1) Ray, quoting your mail: "The current drafts seems to assume some parti= cular type of contractual agreement between CDNs that might not always be t= he case." >=20 > Please quote the draft. > Please let us know exactly to which sentence(s) of the draft you are refe= rring to. > Otherwise it is hard to discuss and comment on your email.=20 >=20 >=20 > 2) Ray, Quoting your mail: "If a dCDN does not live up to its contractual= agreement, this should be something that is handled on a business level, n= ot on a protocol level." >=20 > Maybe there is a deep misunderstanding.=20 > So I will try to be clear again. > We do not propose the CDNI routing interface to be used by the dCDN to se= nd a message saying "Sorry, but I decide unilaterally to refuse this conten= t request".=20 > We do not propose the CDNI routing interface to be used to handle any asp= ect relating to a dCDN deciding unilaterally to stop living up to its contr= actual agreement. >=20 > Please let us know where you saw such an idea in this IETF draft "CDNI re= quest routing".=20 >=20 > The only role of the CDNI routing interface is to be used to advertise CD= NI routing information from the downstream CDN to the upstream CDN. > And this is the description given in this IETF draft. >=20 >=20 > 3) Ray, quoting your mail: "one example of a contractual agreement betwee= n two CDNs is one in which the uCDN and dCDN have agreed that the dCDN will= deliver some content on behalf of a uCDN, but decide on a per-request basi= s whether it wants to do so (and is for example paid per request). In these= cases, the dCDN needs to have the ability to deny delivery on a per-reques= t basis." >=20 > Let me try to fully understand your point: > Are you really meaning that in this case the dCDN has in reality absolute= ly no obligation with regards to the uCDN? > Are you really meaning that in this case the dCDN decides alone, in real = time, and for each content request, whether it denies or accepts to ensure = delivery? > Are you really meaning that in this case the dCDN decides alone, in real = time, and for each content request, whether it denies or accepts to ensure = delivery, and this even if the dCDN has the capability to deliver the conte= nt? > Are you really meaning that in this case the dCDN may possibly response n= egatively to all requests for content request redirection submitted by the = uCDN over the CDNI request routing interface? (i.e. that possibly the uCDN = will never be allowed/invited to redirect a content request to the dCDN?) >=20 >=20 > 4) Ray, quoting your mail: "Every routing protocol defines the expected b= ehavior of interconnected elements/networks on a technical level, not on a = business level."=20 >=20 > Again, this is not what I have written, and this is not the idea we want = to share. > I wrote "Every routing protocol has been defined (or at least configured)= so far by considering the expected behavior of the interconnected elements= /networks." =20 > That's all. > I can rephrase this sentence the following way: "we must know what we exp= ect to do with a protocol to design it correctly." > And IHMO this is an evidence; I don't know any other way to proceed. >=20 > Besides, let us consider BGP (which is by the way an option proposed by s= ome IETF members to implement this CDNI routing interface). > In IP networks, BGP configurations in IP routers are defined as per the b= usiness relationships (valley free policy, etc.). > Of course the business relationships determine the BGP configurations. > And of course BGP has been designed so as to allow to configure IP interc= onnections adequately depending on the corresponding Customer/provider, sib= ling and peering contractual agreements. > But this does not mean that BGP "defines the expected behavior of interco= nnected elements/networks... on a business level." > Even if we can indeed infer quite accurately the business relationships b= etween ISP from the BGP configuration of their IP routers (see CAIDA projec= t), but this is another story. >=20 >=20 > Best regards, >=20 > Yannick Le Lou=E9dec. >=20 >=20 >=20 > -----Message d'origine----- > De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl]=20 > Envoy=E9 : mardi 10 juillet 2012 15:13 > =C0 : LE LOUEDEC Yannick RD-CORE; Ben Niven-Jenkins > Cc : Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE > Objet : RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-0= 0.txt >=20 > Hi Yannick, >=20 > See comments inline. >=20 > In general: IMO the CDNI interfaces should be abstracted from any kind of= contractual/business agreement that might or might not exist between a dCD= N and uCDN. The current drafts seems to assume some particular type of cont= ractual agreement between CDNs that might not always be the case. >=20 > Ray >=20 > -----Original Message----- > From: yannick.lelouedec@orange.com [mailto:yannick.lelouedec@orange.com]= =20 > Sent: dinsdag 10 juli 2012 12:01 > To: Brandenburg, R. (Ray) van; Ben Niven-Jenkins > Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE > Subject: RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-= 00.txt >=20 > Hi Ray, all, >=20 >=20 > 1) Ray, Quoting your mail: "I don't see why the CDNI Request Routing inte= rface should state that a dCDN MUST deliver the content if it has indicated= its ability to do so earlier in either a contractual agreement or in the c= apability interface." >=20 > This is not what we have written. > Let me try to rephrase simply. >=20 > A contractual agreement is a contractual agreement.=20 > It put in writings the respective obligations of the uCDN and of the dCDN= .=20 > The uCDN may redirect any content request to the dCDN as long as it is in= full conformance with the terms of this contractual agreement (the type of= the content request is in full conformance, the maximum number of content = requests per second is respected, etc.).=20 > In this case the dCDN may not say "Sorry, but I decide unilaterally to re= fuse this content request". =20 >=20 > [RvB]: This is where we disagree. IMHO, the type of behavior you describe= (the dCDN not living up to its obligation) should not be enforced by the C= DNI Interfaces. If a dCDN does not live up to its contractual agreement, th= is should be something that is handled on a business level, not on a protoc= ol level. >=20 > Why? Because this is the deal, a contractual agreement is a contractual a= greement! > Yet the dCDN may say "I do apologize, but at this time I cannot handle co= rrectly a certain class of content requests specified in our contractual ag= reement" (for example the class of the HTTP content requests with token fro= m French end users, because of overload situation, failure, etc.) This is t= he role of the CDNI routing interface to provide the uCDN with such informa= tion. >=20 > (And the dCDN may be given a penalty for example if this was agreed in th= e terms of the contractual agreement.) >=20 >=20 > 2) Ray, Quoting your mail: "I understand that in most cases, the contract= ual agreement might indeed impose this behavior on the dCDN" >=20 > Please provide the description of an example where this is not the case. > Otherwise the IETF CDNI WG shall indeed consider this is ALWAYS the case.= =20 >=20 > [RvB]: I can't remember ever seeing such a discussion on the WG list. Any= way: one example of a contractual agreement between two CDNs is one in whic= h the uCDN and dCDN have agreed that the dCDN will deliver some content on = behalf of a uCDN, but decide on a per-request basis whether it wants to do = so (and is for example paid per request). In these cases, the dCDN needs to= have the ability to deny delivery on a per-request basis.=20 >=20 > And this is an important point to be able to progress in the CDNI interfa= ces' specification works. >=20 > If the contractual agreement does not define clearly the obligations of t= he uCDN, it is impossible to dimension adequately the dCDN, neither to defi= ne correctly the CDNI contractual agreements between the dCDN and the dCDNs= of this dCDN. > If the contractual agreement does not define clearly the obligations of t= he dCDN, the dCDN may do what it wants... even to put in the trash can any = content request it accepted to handle. >=20 > [RvB]: Exactly, this is something that needs to be discussed on a busines= s/contractual level and not on a technical level. That is way IMHO the CDNI= Interfaces should not make ANY assumptions on what was agreed on a contrac= tual level.=20 >=20 > In both situations it is impossible to ensure any quality of experience t= o the end user. >=20 >=20 > 3) Ray, Quoting your mail: "I don't think this type of behavior should be= imposed by the protocol we're developing here." >=20 > I do not sure I understand this sentence.=20 > Every routing protocol has been defined (or at least configured) so far b= y considering the expected behavior of the interconnected elements/networks= . =20 >=20 > [RvB]: Every routing protocol defines the expected behavior of interconne= cted elements/networks on a technical level, not on a business level. Havin= g a dCDN say 'I'm not willing to deliver this content' is perfectly fine f= rom a technical perspective, although it could be problematic from a contra= ctual perspective.=20 >=20 > But maybe I will understand if you provide an example on the point 2 abov= e. >=20 >=20 > Best regards, >=20 > Yannick Le Lou=E9dec. >=20 >=20 >=20 > -----Message d'origine----- > De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > Envoy=E9 : mardi 10 juillet 2012 09:20 > =C0 : Ben Niven-Jenkins; LE LOUEDEC Yannick RD-CORE Cc : Pilarski Marcin = - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR: I-D A= ction: draft-lelouedec-cdni-request-routing-00.txt >=20 > Hi Yannick, Ben, >=20 > I tend to agree with Ben here. When reading the draft, I got the feeling = that the draft seems to assume a lot about the relationship between the uCD= N and dCDN. For example, I don't see why the CDNI Request Routing interface= should state that a dCDN MUST deliver the content if it has indicated its = ability to do so earlier in either a contractual agreement or in the capabi= lity interface. I understand that in most cases, the contractual agreement = might indeed impose this behavior on the dCDN, but I don't think this type = of behavior should be imposed by the protocol we're developing here.=20 >=20 > It was always my assumption that the Request Routing Interface would at l= east include the option of allowing the uCDN to query the dCDN for every co= ntent request whether the dCDN is willing to deliver that particular reques= t.=20 >=20 > I will send my full review of the draft later.=20 >=20 > Ray >=20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of B= en Niven-Jenkins > Sent: dinsdag 10 juli 2012 7:38 > To: yannick.lelouedec@orange.com > Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE > Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-= 00.txt >=20 > Yannick, >=20 > Please see inline. >=20 > On 9 Jul 2012, at 20:05, wrote: >=20 >> Hi Ben, all, >>=20 >> Ben, quoting you mail below, "... the downstream CDN could reply with=20 >> either "here is how to redirect it"", >>=20 >> =3D> This is the role of the CDNI DRIS interface to provide the uCDN wit= h this information, and we target to make its specification public before V= ancouver meeting so that everyone may read it before the meeting and get fu= ll knowledge of our proposal about this part of CDNI request routing. >>=20 >> Ben, quoting you mail below, "... or "no I can't/won't take that content= delivery right now", reasons may include the uCDN has requested a delivery= of a protocol the dCDN does not support (possibly in error). >>=20 >> =3D> This is the role of the CDNI logging interface to provide the uCDN = with this information. >=20 > I agree this information should be logged but the Request Routing interfa= ce (what you call the DRIS) also needs to be able to indicate a failure. >=20 > Otherwise the uCDN will 'blindly' redirect the the dCDN and the delivery = will fail leading to poor end user experience. >=20 >> Ben, quoting you mail below, "... or "no I can't/won't take that content= delivery right now", reasons may include ... the dCDN has no capacity righ= t now etc." >>=20 >> =3D> This is the role of the CDNI routing interface to provide the uCDN = with this information. >=20 > It is the role of the CDN capability/routing interface to advertise broad= capabilities etc not to give extremely fine grained real-time information = on exactly the state of the dCDN. >=20 > Even if the capability/routing interface is real-time there are likely to= still be race conditions where we need the dCDN to be about to indicate a = failure to accept a redirect through the request routing/DRIS interface >=20 >> So we may conclude we are in line basically, which is a good point. >> We just aimed at checking there was a common understanding on this point= . >>=20 >> The key point for us here is that we don't want this sentence extracted = from draft-ietf-cdni-problem-statement be interpreted as: ". and the dCDN M= UST accept the content request except when it has not the "ability" to do s= o." >=20 > Why not? IMO that is a valid scenario for some use cases. >=20 >> The fact that the dCDN is temporary unable to handle content request cor= rectly is not a valid reason for the dCDN to be discharged of its obligatio= ns to the uCDN. >> The contract set between the uCDN and the dCDN remains valid anyway, and= the obligations of the dCDN as well. >=20 > Correct, but that contract may not be the same for all uCDNs & dCDNs, for= example a uCDN may not have a guarantee that a dCDN can handle everything = it is requested to handle but the contract may only be that the dCDN guaran= tees to handle up to a certain volume of traffic. >=20 >> The dCDN must announce to the uCDN that it is temporary unable, as soon = as possible, via the CDNI routing interface. >> And the uCDN must take this information into account in its CDN selectio= n process as soon as possible. >> Then if the uCDN decides to continue to redirect content requests to the= dCDN, the uCDN MAY perfectly do it, but the uCDN knows these content reque= sts will be lost. >=20 > What happens in the period between the dCDN being unable to handle reques= ts and the time it takes to advertise that to the uCDN and for the uCDN to = process & incorporate that new knowledge? Are requests blindly forwarded to= the dCDN which is unable to handle them leading to poor user experience? >=20 >> We could even imagine the situation where the uCDN continues to do it in= tentionally, because it has no better option and the content request will b= e lost anyway. For example in the case where neither the uCDN nor the other= downstream CDNs of the uCDN cannot manage correctly the content request, t= he uCDN could do it intentionally so as to be able to clearly prove (with C= DNI logging information) that it is the dCDN, not the uCDN, who is at fault= . >> But, of course, if there are alternative backup options, the normal reac= tion of the uCDN is to stop as soon as possible to redirect content request= s to the dCDN when the uCDN knows that the dCDN is unable to handle them co= rrectly. >>=20 >> So, to be clear, we would prefer the sentence to be understood as: >> ". and the dCDN MUST accept the content request.=20 >> And if it cannot handle correctly the redirected content request it rece= ives, the content request is lost. >=20 > What about scenarios where the uCDN has a choice of dCDNs (e.g. two natio= nal-wide CDNs offering services at different costs), the uCDN may elect to = query both dCDNs and decide based on their responses which one to choose. I= f the dCDN is unable to satisfy the request the uCDN needs to know that so = that it can fallback to the (more expensive in this example) dCDN. >=20 >> For example the dCDN generates a response to the content request with an= error message, or no response at all. And in parallel the CDNI logging int= erface may be used to exchange logs corresponding to this problem. Anyway t= he dCDN MAY NOT redirect that content request back towards the uCDN."=20 >>=20 >> Exactly as in IP networks: IP packets are not sent back towards the orig= in by a downstream router under failure or congestion. >=20 > In a routed IP network, there is often a small packet loss while the netw= ork re-converges, by enabling the dCDN to refuse a redirection at CDNI Requ= est Routing/DRIS query time we can reduce that window by giving the uCDN th= e option to take an alternative action (e.g. try another dCDN) while the ro= uting/capability information re-converges. >=20 >> In both networks (IP and CDN), the reason is the same. >> If the dCDN redirects back a content request to the uCDN, this generates= a loop.=20 >=20 > Loop avoidance is a separate issue IMO to whether we should allow a dCDN = to be able to communicate "I am unable/unwilling to take that content deliv= ery at this time". >=20 > Regards > Ben >=20 >> To manage this would introduce a very high complexity. >> And this would be just to try to save the content requests redirected by= the uCDN to the dCDN in the timeslot between the time the dCDN gets down a= nd the time the uCDN takes this failure into account in its CDN selection p= rocess. >> It is much better to try to reduce this timeslot as much as possible, wi= th routing optimizations (we will propose as soon as possible). >> Rather than introducing additional complexities (to manage redirection t= o the uCDN) in the framework. >>=20 >>=20 >> By the way, as you know, the IESG has just approved today the 'Content D= istribution Network Interconnection (CDNI) Problem Statement' draft as info= rmational RFC. This is a good point. >> And, as you may see in the draft "CDNI request routing", we do not propo= se to modify this problem statement draft. >> We want know to focus now on getting the specifications of all CDNI inte= rfaces ready as soon as possible. >>=20 >> Best regards, >>=20 >> Yannick Le Lou=E9dec. >>=20 >>=20 >> -----Message d'origine----- >> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part=20 >> de Ben Niven-Jenkins Envoy=E9 : lundi 9 juillet 2012 20:41 =C0 : BERTRAN= D=20 >> Gilles RD-CORE Cc : cdni@ietf.org; Pilarski Marcin - Korpo TP; MARREC=20 >> Anne RD-CORE Objet : Re: [CDNi] TR: I-D Action: >> draft-lelouedec-cdni-request-routing-00.txt >>=20 >> Colleagues, >>=20 >> I started reading draft-lelouedec-cdni-request-routing-00 and this text = caught my eye: >>=20 >> Quoting [I-D.ietf-cdni-problem-statement ], "The CDNI Request=20 >> Routing >> interface enables a Request Routing function in an upstream CDN to >> query a Request Routing function in a downstream CDN to determine if >> the downstream CDN is able (and willing) to accept the delegated >> content request". >>=20 >> The "ability" and the "willingness" of the downstream CDN to accept >> the delegated content request match two fully different processes in >> CDN interconnection. And the description of both these processes >> should be reviewed and clarified for the following reasons: >>=20 >> o Regarding the former process, i.e. related to the "ability" >> ("enables a Request Routing function in an upstream CDN to query a >> Request Routing function in a downstream CDN to determine if the >> downstream CDN is able (...) to accept the delegated content >> request"), a routing protocol is used to achieve such a process, >> called routing process, in many other technologies and networks >> (IP, ATM, etc.). In all these technologies, it is the downstream >> entity that provides routing information to the upstream entity. >> The same approach should be applied to CDN interconnection. The >> reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2, >> dCDN 3, and then it selects one of them based on their responses") >> would suffer from latency, signaling overhead and/or lack of >> reactivity to events that impact the ability of the downstream >> CDNs to accept delegated content requests. >>=20 >> o Regarding the latter process, i.e. related to the "willingness" >> ("enables a Request Routing function in an upstream CDN to query a >> Request Routing function in a downstream CDN to determine if the >> downstream CDN (...) is willing (...)to accept the delegated >> content request"), it is to be noted that the relationship between >> a uCDN and a dCDN is always in the frame of a contractual >> agreement between the administrative entity owning the uCDN, >> acting as the customer, and the administrative entity owning the >> dCDN, acting as the service provider. Therefore, consider a case >> where >>=20 >> * the uCDN has a content request to redirect which is in full >> conformance with the terms of this contractual agreement, and >>=20 >> * the uCDN has selected this dCDN. >>=20 >> As the uCDN knows, thanks to the routing information exchanged via >> the aforementioned routing process, that the dCDN is able to >> accept this content request, the uCDN MAY redirect the content >> request to the dCDN and the dCDN MUST accept the content request. >> Exchanging over the CDNI Request Routing interface information >> about the "willingness" of the dCDN to accept the content request >> is not relevant. >>=20 >> I think you might be over thinking what we wrote in the problem statemen= t. >>=20 >> What was in the problem statement was meant to convey that an upstream C= DN could make a request to a downstream CDN to say "how do I redirect this = request to you" and the downstream CDN could reply with either "her is how = to redirect it", or "no I can't/won't take that content delivery right now"= , reasons may include the uCDN has requested a delivery of a protocol the d= CDN does not support (possibly in error) or the dCDN has no capacity right = now etc. >>=20 >> Ben >>=20 >> On 9 Jul 2012, at 18:00, wrote: >>=20 >>> Hi everyone, >>>=20 >>> We have just submitted the draft below. We are convinced that it will h= elp the WG to progress on the CDNI routing issues.=20 >>>=20 >>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >>>=20 >>> Any feedback is very welcome. >>>=20 >>> Best regards, >>>=20 >>> Gilles >>>=20 >>>=20 >>> -----Message d'origine----- >>> De : i-d-announce-bounces@ietf.org >>> [mailto:i-d-announce-bounces@ietf.org] De la part de=20 >>> internet-drafts@ietf.org Envoy=E9 : lundi 9 juillet 2012 18:55 =C0 : >>> i-d-announce@ietf.org Objet : I-D Action:=20 >>> draft-lelouedec-cdni-request-routing-00.txt >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. >>>=20 >>>=20 >>> Title : CDNI Request Routing >>> Author(s) : Yannick Le Louedec >>> Anne Marrec >>> Gilles Bertrand >>> Marcin Pilarski >>> Filename : draft-lelouedec-cdni-request-routing-00.txt >>> Pages : 30 >>> Date : 2012-07-09 >>>=20 >>> Abstract: >>> The present document proposes to clarify the CDNI Request Routing=20 >>> interface introduced in [I-D.ietf-cdni-framework] and [I-D.ietf-cdni-=20 >>> problem-statement], as well as related terminology. >>>=20 >>> In particular the present document proposes to split the CDNI=20 >>> Request Routing interface into two separate interfaces with clearer=20 >>> roles, named respectively CDNI Routing interface and CDNI Downstream=20 >>> Resource Identifier Signaling interface (CDNI DRIS interface). >>>=20 >>> This part of the CDN interconnection framework the IETF has been=20 >>> referring to so far with the term "CDNI Request Routing" is just=20 >>> another routing, signaling and forwarding problem in a long series of=20 >>> the telecommunication history. For example, one can draw a direct=20 >>> analogy between the IP/MPLS-TE framework and the CDN interconnection=20 >>> framework. >>>=20 >>> In addition, this document recommends that the specification of ALL=20 >>> CDN interconnection interfaces in the scope of the CDNI IETF WG=20 >>> relies on the equivalent concept to IP prefix for CDN=20 >>> interconnection, named 'contentRequestScope'. This highly useful and=20 >>> powerful concept SHALL be used to simplify the specification of ALL=20 >>> CDN interconnection interfaces, as well as to ensure performance and=20 >>> scalability in CDN interconnection. >>>=20 >>> All these proposals can be smoothly integrated in the WG drafts,=20 >>> especially [I-D.ietf-cdni-framework] and=20 >>> [I-D.ietf-cdni-requirements], as they essentially propose (useful)=20 >>> clarifications of the existing framework. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-routing >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> 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=20 >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>=20 >>> _____________________________________________________________________ >>> ____________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >>> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu= e les pieces jointes. Les messages electroniques etant susceptibles d'alter= ation, France Telecom - Orange decline toute responsabilite si ce message a= ete altere, deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or=20 >>> privileged information that may be protected by law; they should not be= distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and = delete this message and its attachments. >>> As emails may be altered, France Telecom - Orange is not liable for mes= sages that have been modified, changed or falsified. >>> Thank you. >>>=20 >>> _______________________________________________ >>> 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 >>=20 >> ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for mess= ages that have been modified, changed or falsified. >> Thank you. >>=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > This e-mail and its contents are subject to the DISCLAIMER at http://www.= tno.nl/emaildisclaimer >=20 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. = Les messages electroniques etant susceptibles d'alteration, France Telecom = - Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 From ray.vanbrandenburg@tno.nl Fri Jul 13 05:53:35 2012 Return-Path: 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 BF9E921F87D0 for ; Fri, 13 Jul 2012 05:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[AWL=0.855, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 oNsWXI9l1z+U for ; Fri, 13 Jul 2012 05:53:34 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1333E21F8710 for ; Fri, 13 Jul 2012 05:53:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,579,1336341600"; d="scan'208";a="72299869" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 13 Jul 2012 14:54:09 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.152]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0298.004; Fri, 13 Jul 2012 14:54:08 +0200 From: "Brandenburg, R. (Ray) van" To: "cdni@ietf.org" Thread-Topic: New Version Notification for draft-brandenburg-cdni-has-03.txt Thread-Index: AQHNYPYK69T0lDIlhEq/6KjDclDrxZcnKnyQ Date: Fri, 13 Jul 2012 12:54:07 +0000 Message-ID: References: <20120713124933.24842.92028.idtracker@ietfa.amsl.com> In-Reply-To: <20120713124933.24842.92028.idtracker@ietfa.amsl.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: [CDNi] FW: New Version Notification for draft-brandenburg-cdni-has-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 12:53:35 -0000 SGkgYWxsLA0KDQpBcyB5b3UgY2FuIHNlZSB3ZSBqdXN0IHVwbG9hZGVkIGEgbmV3IHZlcnNpb24g b2YgdGhlIEhBUy1DRE5JIGRyYWZ0LiBUaGlzIGlzIHRoZSB2ZXJzaW9uIG9mIHRoZSBkcmFmdCB0 aGF0IHdlIHdpbGwgYmUgcHJlc2VudGluZyBkdXJpbmcgdGhlIFZhbmNvdXZlciBtZWV0aW5nLiAN Cg0KSSdtIGxvb2tpbmcgZm9yd2FyZCB0byB5b3VyIGNvbW1lbnRzIGFuZCBzZWVpbmcgeW91IGFs bCBpbiBWYW5jb3V2ZXIhDQoNCkJlc3QgcmVnYXJkcywNCg0KUmF5IHZhbiBCcmFuZGVuYnVyZw0K DQoNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6 IHZyaWpkYWcgMTMganVsaSAyMDEyIDE0OjUwDQpUbzogQnJhbmRlbmJ1cmcsIFIuIChSYXkpIHZh bg0KQ2M6IGZsZWZhdWNoQGNpc2NvLmNvbTsga2xldW5nQGNpc2NvLmNvbTsgRGV2ZW50ZXIsIE0u Ty4gKE9za2FyKSB2YW4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtYnJhbmRlbmJ1cmctY2RuaS1oYXMtMDMudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LWJyYW5kZW5idXJnLWNkbmktaGFzLTAzLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IFJheSB2YW4gQnJhbmRlbmJ1cmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURiBy ZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWJyYW5kZW5idXJnLWNkbmktaGFzDQpSZXZp c2lvbjoJIDAzDQpUaXRsZToJCSBNb2RlbHMgZm9yIGFkYXB0aXZlLXN0cmVhbWluZy1hd2FyZSBD RE4gSW50ZXJjb25uZWN0aW9uDQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0wNy0xMg0KV0cgSUQ6CQkg SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDQzDQpVUkw6ICAgICAgICAg ICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWJyYW5kZW5idXJn LWNkbmktaGFzLTAzLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWJyYW5kZW5idXJnLWNkbmktaGFzDQpIdG1saXplZDogICAgICAgIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJyYW5kZW5idXJnLWNkbmktaGFzLTAzDQpE aWZmOiAgICAgICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt YnJhbmRlbmJ1cmctY2RuaS1oYXMtMDMNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50cyBw cmVzZW50cyB0aG91Z2h0cyBvbiB0aGUgcG90ZW50aWFsIGltcGFjdCBvZg0KICAgc3VwcG9ydGlu ZyBIVFRQIEFkYXB0aXZlIFN0cmVhbWluZyB0ZWNobm9sb2dpZXMgaW4gQ0RODQogICBJbnRlcmNv bm5lY3Rpb24gc2NlbmFyaW9zLiAgT3VyIGludGVudCBpcyB0byBzcHVyIGRpc2N1c3Npb24gb24g aG93DQogICB0aGUgZGlmZmVyZW50IENETkkgaW50ZXJmYWNlcyBjb3VsZCwgYW5kIHNob3VsZCwg ZGVhbCB3aXRoIGNvbnRlbnQNCiAgIGRlbGl2ZXJlZCB1c2luZyBhZGFwdGl2ZSBzdHJlYW1pbmcg dGVjaG5vbG9naWVzIGFuZCB0byBmYWNpbGl0YXRlDQogICB3b3JraW5nIGdyb3VwIGRlY2lzaW9u cy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0 DQpUaGlzIGUtbWFpbCBhbmQgaXRzIGNvbnRlbnRzIGFyZSBzdWJqZWN0IHRvIHRoZSBESVNDTEFJ TUVSIGF0IGh0dHA6Ly93d3cudG5vLm5sL2VtYWlsZGlzY2xhaW1lcgo= From wangdanhua@huawei.com Mon Jul 16 02:26:46 2012 Return-Path: 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 3A48821F86DA for ; Mon, 16 Jul 2012 02:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[AWL=3.067, 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 feVTbJEbdAoP for ; Mon, 16 Jul 2012 02:26:45 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 85BA421F86D4 for ; Mon, 16 Jul 2012 02:26:45 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIB21680; Mon, 16 Jul 2012 05:27:29 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 02:25:42 -0700 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 02:25:43 -0700 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.110]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Mon, 16 Jul 2012 17:25:40 +0800 From: Wangdanhua To: "cdni@ietf.org" Thread-Topic: Forward: New Version Notification for draft-he-cdni-routing-request-redirection-02.txt Thread-Index: AQHNYzT3/MNj6xubIEifUj4DJWQVBw== Date: Mon, 16 Jul 2012 09:25:40 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.177] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [CDNi] Forward: New Version Notification for draft-he-cdni-routing-request-redirection-02.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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 09:26:46 -0000 SGkgYWxsLA0KDQpXZSBqdXN0IHVwbG9hZGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0LWhl LWNkbmktcm91dGluZy1yZXF1ZXN0LXJlZGlyZWN0aW9uLiBBbnkgY29tbWVudHMgb3Igc3VnZ2Vz dGlvbnMgYXJlIGFwcHJlY2lhdGVkLg0KDQpCZXN0IHdpc2hlcywNCkRhbmh1YSBXYW5nDQoNCi0t LS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCuWPkemAgeaXtumXtDogMjAxMuW5 tDfmnIgxNuaXpSAxNDoxMg0K5pS25Lu25Lq6OiBXYW5nZGFuaHVhDQrmioTpgIE6IGNoZW5nQGdz dGEuY29tOyBoZXhpYW95YW4gMDAyMTU5OTc7IHpoYW5neXVuZmVpQGNoaW5hbW9iaWxlLmNvbTsg c3BlbmNlci5kYXdraW5zQHdvbmRlcm1hc3Rlci5jb207IG5pd2VpQGNoaW5hbW9iaWxlLmNvbQ0K 5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhlLWNkbmktcm91dGlu Zy1yZXF1ZXN0LXJlZGlyZWN0aW9uLTAyLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1oZS1jZG5pLXJvdXRpbmctcmVxdWVzdC1yZWRpcmVjdGlvbi0wMi50eHQNCmhhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgV2FuZyBEYW5odWEgKGVkaXRvcikgYW5kIHBvc3Rl ZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1oZS1jZG5pLXJv dXRpbmctcmVxdWVzdC1yZWRpcmVjdGlvbg0KUmV2aXNpb246CSAwMg0KVGl0bGU6CQkgUm91dGlu ZyBSZXF1ZXN0IFJlZGlyZWN0aW9uIGZvciBDRE4gSW50ZXJjb25uZWN0aW9uDQpDcmVhdGlvbiBk YXRlOgkgMjAxMi0wNy0xNg0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIg b2YgcGFnZXM6IDE1DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWhlLWNkbmktcm91dGluZy1yZXF1ZXN0LXJlZGlyZWN0aW9uLTAyLnR4 dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWhlLWNkbmktcm91dGluZy1yZXF1ZXN0LXJlZGlyZWN0aW9uDQpIdG1saXplZDogICAgICAgIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhlLWNkbmktcm91dGluZy1yZXF1ZXN0LXJl ZGlyZWN0aW9uLTAyDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtaGUtY2RuaS1yb3V0aW5nLXJlcXVlc3QtcmVkaXJlY3Rpb24tMDINCg0K QWJzdHJhY3Q6DQogICBUaGUgUmVxdWVzdCBSb3V0aW5nIEludGVyZmFjZSBjb21wcmlzZXMgb2Yg KDEpIHRoZSBhc3luY2hyb25vdXMNCiAgIGFkdmVydGlzZW1lbnQgb2YgZm9vdHByaW50IGFuZCBj YXBhYmlsaXRpZXMgYnkgYSBkQ0ROIHRoYXQgYWxsb3dzIGENCiAgIHVDRE4gdG8gZGVjaWRlIHdo ZXRoZXIgdG8gcmVkaXJlY3QgcGFydGljdWxhciB1c2VyIHJlcXVlc3RzIHRvIHRoYXQNCiAgIGRD RE47IGFuZCAoMikgdGhlIHN5bmNocm9ub3VzIG9wZXJhdGlvbiBvZiBhbiB1cHN0cmVhbSBDRE4g cmVxdWVzdGluZw0KICAgd2hldGhlciBhIGRvd25zdHJlYW0gQ0ROIGlzIHByZXBhcmVkIHRvIGFj Y2VwdCBhIHVzZXIgcmVxdWVzdCBhbmQgb2YNCiAgIGEgZG93bnN0cmVhbSBDRE4gcmVzcG9uZGlu ZyB3aXRoIGhvdyB0byBhY3R1YWxseSByZWRpcmVjdCB0aGUgdXNlcg0KICAgcmVxdWVzdC4gIFRo aXMgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIGludGVyZmFjZSBmb3IgdGhlIGxhdHRlciBwYXJ0Lg0K DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg== From haibin.song@huawei.com Mon Jul 16 03:37:17 2012 Return-Path: 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 69FFE21F87C3 for ; Mon, 16 Jul 2012 03:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.321 X-Spam-Level: X-Spam-Status: No, score=-6.321 tagged_above=-999 required=5 tests=[AWL=0.278, 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 8t+2Gff7ZF+N for ; Mon, 16 Jul 2012 03:37:16 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B6F8B21F87C5 for ; Mon, 16 Jul 2012 03:37:16 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHU31728; Mon, 16 Jul 2012 06:38:01 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 03:36:13 -0700 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 03:36:12 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.243]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Mon, 16 Jul 2012 18:36:08 +0800 From: Songhaibin To: "cdni@ietf.org" Thread-Topic: New Version Notification for draft-song-cdni-slr-based-footprint-01.txt Thread-Index: AQHNYz44APbaas3pUECadQEMtcXkoZcrtgZw Date: Mon, 16 Jul 2012 10:36:08 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.73] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [CDNi] FW: New Version Notification for draft-song-cdni-slr-based-footprint-01.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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 10:37:17 -0000 SGksDQoNCldlIGp1c3Qgc3VibWl0dGVkIGEgZHJhZnQgYWJvdXQgc2VydmljZSBsZXZlbCByZXF1 aXJlbWVudHMgYmFzZWQgZm9vdHByaW50LiBUaGlzIGRyYWZ0IGlzIG1haW5seSB1c2VkIHRvIGdl bmVyYXRlIHRoZSBkaXNjdXNzaW9uIG9uIHRoaXMgYXNwZWN0IGFuZCBpdCBpcyBzdGlsbCBvbiBh IGhpZ2ggbGV2ZWwgaWRlYSBzdGFnZS4gV2UgaGF2ZSBub3QgZ2l2ZW4gZGVlcCB0aG91Z2h0IG9u IHRoZSBkZXRhaWxzIGluIHRoaXMgZG9jdW1lbnQuIFNvIGFueSBkaXNjdXNzaW9uIGFuZCBjb21t ZW50cyBhcmUgd2VsY29tZSENCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtc29uZy1jZG5pLXNsci1iYXNlZC1mb290cHJpbnQtMDEudHh0DQoNCkJSLA0KLUhhaWJp bg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gU2VudDogTW9u ZGF5LCBKdWx5IDE2LCAyMDEyIDY6MzEgUE0NCj4gVG86IFNvbmdoYWliaW4NCj4gQ2M6IHpoYW5n eXVuZmVpQGNoaW5hbW9iaWxlLmNvbQ0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LXNvbmctY2RuaS1zbHItYmFzZWQtZm9vdHByaW50LTAxLnR4dA0KPiANCj4g DQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zb25nLWNkbmktc2xyLWJhc2VkLWZvb3Rw cmludC0wMS50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBIYWliaW4g U29uZyBhbmQgcG9zdGVkIHRvIHRoZQ0KPiBJRVRGIHJlcG9zaXRvcnkuDQo+IA0KPiBGaWxlbmFt ZToJIGRyYWZ0LXNvbmctY2RuaS1zbHItYmFzZWQtZm9vdHByaW50DQo+IFJldmlzaW9uOgkgMDEN Cj4gVGl0bGU6CQkgQSBTTFIgKFNlcnZpY2UgTGV2ZWwgUmVxdWlyZW1lbnRzKSBiYXNlZCBmb290 cHJpbnQgZm9yIENETkkNCj4gQ3JlYXRpb24gZGF0ZToJIDIwMTItMDctMTYNCj4gV0cgSUQ6CQkg SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IE51bWJlciBvZiBwYWdlczogNw0KPiBVUkw6DQo+IGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNvbmctY2RuaS1zbHItYmFz ZWQtZm9vdHByaW50LTAxLnR4dA0KPiBTdGF0dXM6DQo+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtc29uZy1jZG5pLXNsci1iYXNlZC1mb290cHJpbnQNCj4gSHRtbGl6ZWQ6 DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNvbmctY2RuaS1zbHItYmFzZWQt Zm9vdHByaW50LTAxDQo+IERpZmY6DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtc29uZy1jZG5pLXNsci1iYXNlZC1mb290cHJpbnQtMDENCj4gDQo+IEFic3RyYWN0 Og0KPiAgICBGb290cHJpbnQgYWR2ZXJ0aXNlbWVudCBpcyBhIHZlcnkgaW1wb3J0YW50IHN0ZXAg Zm9yIENETg0KPiAgICBpbnRlcmNvbm5lY3Rpb24gYW5kIGdlbmVyYXRlcyBhIGxvdCBvZiBkaXNj dXNzaW9uLiAgQWN0dWFsbHksIGVhY2gNCj4gICAgQ0ROIGNhbiBzZXJ2ZSB0aGUgd2hvbGUgd29y bGQgaWYgaXRzIHN1cnJvZ2F0ZXMgYXJlIHB1YmxpY2x5DQo+ICAgIHJlYWNoYWJsZSBieSBJUCBh ZGRyZXNzZXMuICBCdXQgaWYgYSBDRE4gZG9lcyB0aGF0LCBpdCBjYW4gbm90DQo+ICAgIHNhdGlz ZnkgdGhlIHJlcXVpcmVtZW50cyBmcm9tIHRoZSBhcHBsaWNhdGlvbnMuICBTbyBDRE5zIGRlbGl2 ZXINCj4gICAgY29udGVudHMgZm9yIGFwcGxpY2F0aW9ucywgYW5kIHRoZSBiYXNpYyByZXF1aXJl bWVudHMgc2hvdWxkIGJlIGZyb20NCj4gICAgdGhlIGFwcGxpY2F0aW9ucywgYnV0IHRoZXJlIGlz IHJhcmUgZGlzY3Vzc2lvbiBvbiBzZXJ2aWNlIGxldmVsDQo+ICAgIHJlcXVpcmVtZW50cyBiYXNl ZCBmb290cHJpbnQuICBUaGlzIGRvY3VtZW50IGlzIHVzZWQgdG8gZ2VuZXJhdGUgdGhlDQo+ICAg IGRpc2N1c3Npb24gb24gdGhpcyBhc3BlY3QuDQo+IA0KPiANCj4gDQo+IA0KPiBUaGUgSUVURiBT ZWNyZXRhcmlhdA0K From swainner@cisco.com Mon Jul 16 04:36:05 2012 Return-Path: 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 1C0D921F87D3 for ; Mon, 16 Jul 2012 04:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 fmOWC5MxIQtR for ; Mon, 16 Jul 2012 04:36:03 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 10AA621F87CD for ; Mon, 16 Jul 2012 04:36:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=9474; q=dns/txt; s=iport; t=1342438607; x=1343648207; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=q3vu0fK2m4DAkEF/RcWO6j8paPgVMQlnidoAO4seuaE=; b=JnNViCmhsczy3NkZZ5BfzKGnFdb7siOIUyUY8AXmgacmILWT+mkQy1Xn 5M82J7Sda9DyK0l79yU1I20cYzjNM8eCVbiJ2d1ZG5NS+TW5LeEGCopZZ wDMZaPRcgfGlOhy8JvqISxgQMVIbv1tdjtDssXjc7yXXL5puJXwQXEH0C w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGX7A1CtJV2d/2dsb2JhbABFuSWBB4IgAQEBBAEBAQ8BHwEFNgQGEQsYCRYIBwkDAgECARUfERMGAgEBBRmHawucBZ83i0AKhj0DlTuBEol1gxmBZoJ7gUM X-IronPort-AV: E=Sophos;i="4.77,593,1336348800"; d="scan'208";a="102169565" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 16 Jul 2012 11:36:46 +0000 Received: from rtp-swainner-8912.cisco.com (rtp-swainner-8912.cisco.com [10.116.109.195]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6GBajvv022693 for ; Mon, 16 Jul 2012 11:36:46 GMT Message-ID: <5003FCCD.4090005@cisco.com> Date: Mon, 16 Jul 2012 07:36:45 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: cdni@ietf.org References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> In-Reply-To: <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 11:36:05 -0000 I'm inclined to interpret the "able (and willing)" in two context as well. We have the general willingness of the dCDN to accept a certain class of redirects which is presumably advertised by the footprint and capabilities. This information would allow the uCDN to know a prior to the client routing request that the dCDN is a candidate for consideration. Given the dCDN is a candidate (along with many others), the uCDN may choose this particular dCDN and elect to route the request to the dCDN. The dCDN may be unable to fulfill this particular request for any number of reasons (momentary overload condition, configuration error, loss of connectivity). Of course the logging interface will record this fact; however, the uCDN needs an immediate response in the routing request such that an alternate candidate can be considered. I presume that the successful routing request of the dCDN will provide the appropriate information on how to redirect the client. Scott On 7/9/12 2:41 PM, Ben Niven-Jenkins wrote: > Colleagues, > > I started reading draft-lelouedec-cdni-request-routing-00 and this text caught my eye: > > Quoting [I-D.ietf-cdni-problem-statement > ], "The CDNI Request Routing > interface enables a Request Routing function in an upstream CDN to > query a Request Routing function in a downstream CDN to determine if > the downstream CDN is able (and willing) to accept the delegated > content request". > > The "ability" and the "willingness" of the downstream CDN to accept > the delegated content request match two fully different processes in > CDN interconnection. And the description of both these processes > should be reviewed and clarified for the following reasons: > > o Regarding the former process, i.e. related to the "ability" > ("enables a Request Routing function in an upstream CDN to query a > Request Routing function in a downstream CDN to determine if the > downstream CDN is able (...) to accept the delegated content > request"), a routing protocol is used to achieve such a process, > called routing process, in many other technologies and networks > (IP, ATM, etc.). In all these technologies, it is the downstream > entity that provides routing information to the upstream entity. > The same approach should be applied to CDN interconnection. The > reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2, > dCDN 3, and then it selects one of them based on their responses") > would suffer from latency, signaling overhead and/or lack of > reactivity to events that impact the ability of the downstream > CDNs to accept delegated content requests. > > o Regarding the latter process, i.e. related to the "willingness" > ("enables a Request Routing function in an upstream CDN to query a > Request Routing function in a downstream CDN to determine if the > downstream CDN (...) is willing (...)to accept the delegated > content request"), it is to be noted that the relationship between > a uCDN and a dCDN is always in the frame of a contractual > agreement between the administrative entity owning the uCDN, > acting as the customer, and the administrative entity owning the > dCDN, acting as the service provider. Therefore, consider a case > where > > * the uCDN has a content request to redirect which is in full > conformance with the terms of this contractual agreement, and > > * the uCDN has selected this dCDN. > > As the uCDN knows, thanks to the routing information exchanged via > the aforementioned routing process, that the dCDN is able to > accept this content request, the uCDN MAY redirect the content > request to the dCDN and the dCDN MUST accept the content request. > Exchanging over the CDNI Request Routing interface information > about the "willingness" of the dCDN to accept the content request > is not relevant. > > I think you might be over thinking what we wrote in the problem statement. > > What was in the problem statement was meant to convey that an upstream CDN could make a request to a downstream CDN to say "how do I redirect this request to you" and the downstream CDN could reply with either "her is how to redirect it", or "no I can't/won't take that content delivery right now", reasons may include the uCDN has requested a delivery of a protocol the dCDN does not support (possibly in error) or the dCDN has no capacity right now etc. > > Ben > > On 9 Jul 2012, at 18:00, wrote: > >> Hi everyone, >> >> We have just submitted the draft below. We are convinced that it will help the WG to progress on the CDNI routing issues. >> >> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >> >> Any feedback is very welcome. >> >> Best regards, >> >> Gilles >> >> >> -----Message d'origine----- >> De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] De la part de internet-drafts@ietf.org >> Envoyé : lundi 9 juillet 2012 18:55 >> À : i-d-announce@ietf.org >> Objet : I-D Action: draft-lelouedec-cdni-request-routing-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : CDNI Request Routing >> Author(s) : Yannick Le Louedec >> Anne Marrec >> Gilles Bertrand >> Marcin Pilarski >> Filename : draft-lelouedec-cdni-request-routing-00.txt >> Pages : 30 >> Date : 2012-07-09 >> >> Abstract: >> The present document proposes to clarify the CDNI Request Routing >> interface introduced in [I-D.ietf-cdni-framework] and [I-D.ietf-cdni- >> problem-statement], as well as related terminology. >> >> In particular the present document proposes to split the CDNI Request >> Routing interface into two separate interfaces with clearer roles, >> named respectively CDNI Routing interface and CDNI Downstream >> Resource Identifier Signaling interface (CDNI DRIS interface). >> >> This part of the CDN interconnection framework the IETF has been >> referring to so far with the term "CDNI Request Routing" is just >> another routing, signaling and forwarding problem in a long series of >> the telecommunication history. For example, one can draw a direct >> analogy between the IP/MPLS-TE framework and the CDN interconnection >> framework. >> >> In addition, this document recommends that the specification of ALL >> CDN interconnection interfaces in the scope of the CDNI IETF WG >> relies on the equivalent concept to IP prefix for CDN >> interconnection, named 'contentRequestScope'. This highly useful and >> powerful concept SHALL be used to simplify the specification of ALL >> CDN interconnection interfaces, as well as to ensure performance and >> scalability in CDN interconnection. >> >> All these proposals can be smoothly integrated in the WG drafts, >> especially [I-D.ietf-cdni-framework] and >> [I-D.ietf-cdni-requirements], as they essentially propose (useful) >> clarifications of the existing framework. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-routing >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 >> >> _________________________________________________________________________________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >> France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and delete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> 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 Mon Jul 16 05:22:14 2012 Return-Path: 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 709E021F87E0 for ; Mon, 16 Jul 2012 05:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 wc371ApBCCdW for ; Mon, 16 Jul 2012 05:22:11 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC4C21F87CD for ; Mon, 16 Jul 2012 05:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34104; q=dns/txt; s=iport; t=1342441375; x=1343650975; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=6NbX/MOFBJDF19FA+EHAzNMOWbtjj/MxWW1/b7C1vGA=; b=OMBxJpQuc67u+gxfZgxx1YfzZUdMAaZKLL7p4uXtCyJWSRJEHRsoPcnQ qa+8UUiBU0WC1L3R7jm6hKh36DmC5SJlcxszgU9Vehjv00IT+yuVmrYv4 MOzn+dm98pzANOBxva88fOOqTt0dJhpeD5iYJc1zu0Kz5NA6N9FHfjzJi s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwHABoHBFCtJV2b/2dsb2JhbABFuDV0gQeCIAEBAQMBAQEBDwEHARcBBQ8nBAYNBAsRBAEBAQkMCggHCQMCAQIBFR8JCBMGAgEBBRmHZQYLnAeRBY42i0ACCBCDBYMoA5U7gRKJdYMZgWaCe4E6CRo X-IronPort-AV: E=Sophos;i="4.77,594,1336348800"; d="scan'208";a="99209828" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 16 Jul 2012 12:22:54 +0000 Received: from rtp-swainner-8912.cisco.com (rtp-swainner-8912.cisco.com [10.116.109.195]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6GCMrIm002465 for ; Mon, 16 Jul 2012 12:22:53 GMT Message-ID: <5004079D.4000406@cisco.com> Date: Mon, 16 Jul 2012 08:22:53 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: cdni@ietf.org References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> <2040_1341930789_4FFC3D24_2040_2504_1_b86bff40-ae68-40c0-b8e5-060f51be6864@PEXCVZYH02.corporate.adroot.infra.ftgroup> <3A7EA7EE-F8D4-4094-83F2-12CD3826B662@tno.nl> In-Reply-To: <3A7EA7EE-F8D4-4094-83F2-12CD3826B662@tno.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 12:22:14 -0000 On 7/10/12 11:39 AM, Brandenburg, R. (Ray) van wrote: > Hi Yannick, > > We seem to be misunderstanding each other. Maybe this will help clarify my point: > >> Let me try to fully understand your point: >> Are you really meaning that in this case the dCDN has in reality absolutely no obligation with regards to the uCDN? >> Are you really meaning that in this case the dCDN decides alone, in real time, and for each content request, whether it denies or accepts to ensure delivery? > What I mean is that I would like to have a RR Interface at least support a model where for every content request the uCDN asks the dCDN whether it wants to deliver that particular content item (I believe you call this a PULL approach). And I would like to allow the dCDN to be able to say 'No' on this request (whether it is for purposes or failure, overload, or any other reason). > >> Are you really meaning that in this case the dCDN decides alone, in real time, and for each content request, whether it denies or accepts to ensure delivery, and this even if the dCDN has the capability to deliver the content? > Yes. I think we have to delineate between the iterative and recursive model. The recursive model assumes that the client request to the uCDN will be recursive and the CDN-I RR interface will be used to provide an answer for each client request. The choice to initiate the recursion would be determined by the footprint / capabilities. The ability of the dCDN to execute the specific request would provide immediate feedback to the uCDN. A dCDN that continues to advertise the footprint / capability, but frequently or continually rejects the request via CDN-I RR would be a poor candidate. The opportunity now arises where the uCDN may elect to choose an alternate dCDN because its preferred dCDN (according to footprint / capabilities) is 'under-performing'. The iterative model, the uCDN blindly redirects the client to the dCDN based on the footprint / capabilities. What the dCDN does with the request is somewhat transparent to the uCDN. With the exception of the CDN-I logging, the uCDN assumes the dCDN is properly handling the requests that were delegated to the dCDN. If you are trying to 'tighten' up the case of blind rejections, then the frequency of the footprint / capabilities advertisements would have to be accelerated. For the case where the dCDN repeatedly sees requests from the uCDN that the dCDN can't handle, it should retract its footprint / capabilities advertisement. Failing to do so would continually black-hole routing requests which would be indicated in the logging information. Either way, you need a feedback loop to avoid dumping routing requests. With any feedback loop (recursive routing request or footprint / capabilities advertisement), you have to be careful about rapid oscillations and dampening the responses. Scott > >> Are you really meaning that in this case the dCDN may possibly response negatively to all requests for content request redirection submitted by the uCDN over the CDNI request routing interface? (i.e. that possibly the uCDN will never be allowed/invited to redirect a content request to the dCDN?) > > Yes. Any negative effect this may have on the business relationship between uCDN and dCDN should be handled on the business level. > > Ray > > > On Jul 10, 2012, at 4:33 PM, > wrote: > >> Hi Ray, >> >> >> 1) Ray, quoting your mail: "The current drafts seems to assume some particular type of contractual agreement between CDNs that might not always be the case." >> >> Please quote the draft. >> Please let us know exactly to which sentence(s) of the draft you are referring to. >> Otherwise it is hard to discuss and comment on your email. >> >> >> 2) Ray, Quoting your mail: "If a dCDN does not live up to its contractual agreement, this should be something that is handled on a business level, not on a protocol level." >> >> Maybe there is a deep misunderstanding. >> So I will try to be clear again. >> We do not propose the CDNI routing interface to be used by the dCDN to send a message saying "Sorry, but I decide unilaterally to refuse this content request". >> We do not propose the CDNI routing interface to be used to handle any aspect relating to a dCDN deciding unilaterally to stop living up to its contractual agreement. >> >> Please let us know where you saw such an idea in this IETF draft "CDNI request routing". >> >> The only role of the CDNI routing interface is to be used to advertise CDNI routing information from the downstream CDN to the upstream CDN. >> And this is the description given in this IETF draft. >> >> >> 3) Ray, quoting your mail: "one example of a contractual agreement between two CDNs is one in which the uCDN and dCDN have agreed that the dCDN will deliver some content on behalf of a uCDN, but decide on a per-request basis whether it wants to do so (and is for example paid per request). In these cases, the dCDN needs to have the ability to deny delivery on a per-request basis." >> >> Let me try to fully understand your point: >> Are you really meaning that in this case the dCDN has in reality absolutely no obligation with regards to the uCDN? >> Are you really meaning that in this case the dCDN decides alone, in real time, and for each content request, whether it denies or accepts to ensure delivery? >> Are you really meaning that in this case the dCDN decides alone, in real time, and for each content request, whether it denies or accepts to ensure delivery, and this even if the dCDN has the capability to deliver the content? >> Are you really meaning that in this case the dCDN may possibly response negatively to all requests for content request redirection submitted by the uCDN over the CDNI request routing interface? (i.e. that possibly the uCDN will never be allowed/invited to redirect a content request to the dCDN?) >> >> >> 4) Ray, quoting your mail: "Every routing protocol defines the expected behavior of interconnected elements/networks on a technical level, not on a business level." >> >> Again, this is not what I have written, and this is not the idea we want to share. >> I wrote "Every routing protocol has been defined (or at least configured) so far by considering the expected behavior of the interconnected elements/networks." >> That's all. >> I can rephrase this sentence the following way: "we must know what we expect to do with a protocol to design it correctly." >> And IHMO this is an evidence; I don't know any other way to proceed. >> >> Besides, let us consider BGP (which is by the way an option proposed by some IETF members to implement this CDNI routing interface). >> In IP networks, BGP configurations in IP routers are defined as per the business relationships (valley free policy, etc.). >> Of course the business relationships determine the BGP configurations. >> And of course BGP has been designed so as to allow to configure IP interconnections adequately depending on the corresponding Customer/provider, sibling and peering contractual agreements. >> But this does not mean that BGP "defines the expected behavior of interconnected elements/networks... on a business level." >> Even if we can indeed infer quite accurately the business relationships between ISP from the BGP configuration of their IP routers (see CAIDA project), but this is another story. >> >> >> Best regards, >> >> Yannick Le Louédec. >> >> >> >> -----Message d'origine----- >> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >> Envoyé : mardi 10 juillet 2012 15:13 >> À : LE LOUEDEC Yannick RD-CORE; Ben Niven-Jenkins >> Cc : Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE >> Objet : RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt >> >> Hi Yannick, >> >> See comments inline. >> >> In general: IMO the CDNI interfaces should be abstracted from any kind of contractual/business agreement that might or might not exist between a dCDN and uCDN. The current drafts seems to assume some particular type of contractual agreement between CDNs that might not always be the case. >> >> Ray >> >> -----Original Message----- >> From: yannick.lelouedec@orange.com [mailto:yannick.lelouedec@orange.com] >> Sent: dinsdag 10 juli 2012 12:01 >> To: Brandenburg, R. (Ray) van; Ben Niven-Jenkins >> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE >> Subject: RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt >> >> Hi Ray, all, >> >> >> 1) Ray, Quoting your mail: "I don't see why the CDNI Request Routing interface should state that a dCDN MUST deliver the content if it has indicated its ability to do so earlier in either a contractual agreement or in the capability interface." >> >> This is not what we have written. >> Let me try to rephrase simply. >> >> A contractual agreement is a contractual agreement. >> It put in writings the respective obligations of the uCDN and of the dCDN. >> The uCDN may redirect any content request to the dCDN as long as it is in full conformance with the terms of this contractual agreement (the type of the content request is in full conformance, the maximum number of content requests per second is respected, etc.). >> In this case the dCDN may not say "Sorry, but I decide unilaterally to refuse this content request". >> >> [RvB]: This is where we disagree. IMHO, the type of behavior you describe (the dCDN not living up to its obligation) should not be enforced by the CDNI Interfaces. If a dCDN does not live up to its contractual agreement, this should be something that is handled on a business level, not on a protocol level. >> >> Why? Because this is the deal, a contractual agreement is a contractual agreement! >> Yet the dCDN may say "I do apologize, but at this time I cannot handle correctly a certain class of content requests specified in our contractual agreement" (for example the class of the HTTP content requests with token from French end users, because of overload situation, failure, etc.) This is the role of the CDNI routing interface to provide the uCDN with such information. >> >> (And the dCDN may be given a penalty for example if this was agreed in the terms of the contractual agreement.) >> >> >> 2) Ray, Quoting your mail: "I understand that in most cases, the contractual agreement might indeed impose this behavior on the dCDN" >> >> Please provide the description of an example where this is not the case. >> Otherwise the IETF CDNI WG shall indeed consider this is ALWAYS the case. >> >> [RvB]: I can't remember ever seeing such a discussion on the WG list. Anyway: one example of a contractual agreement between two CDNs is one in which the uCDN and dCDN have agreed that the dCDN will deliver some content on behalf of a uCDN, but decide on a per-request basis whether it wants to do so (and is for example paid per request). In these cases, the dCDN needs to have the ability to deny delivery on a per-request basis. >> >> And this is an important point to be able to progress in the CDNI interfaces' specification works. >> >> If the contractual agreement does not define clearly the obligations of the uCDN, it is impossible to dimension adequately the dCDN, neither to define correctly the CDNI contractual agreements between the dCDN and the dCDNs of this dCDN. >> If the contractual agreement does not define clearly the obligations of the dCDN, the dCDN may do what it wants... even to put in the trash can any content request it accepted to handle. >> >> [RvB]: Exactly, this is something that needs to be discussed on a business/contractual level and not on a technical level. That is way IMHO the CDNI Interfaces should not make ANY assumptions on what was agreed on a contractual level. >> >> In both situations it is impossible to ensure any quality of experience to the end user. >> >> >> 3) Ray, Quoting your mail: "I don't think this type of behavior should be imposed by the protocol we're developing here." >> >> I do not sure I understand this sentence. >> Every routing protocol has been defined (or at least configured) so far by considering the expected behavior of the interconnected elements/networks. >> >> [RvB]: Every routing protocol defines the expected behavior of interconnected elements/networks on a technical level, not on a business level. Having a dCDN say 'I'm not willing to deliver this content' is perfectly fine from a technical perspective, although it could be problematic from a contractual perspective. >> >> But maybe I will understand if you provide an example on the point 2 above. >> >> >> Best regards, >> >> Yannick Le Louédec. >> >> >> >> -----Message d'origine----- >> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >> Envoyé : mardi 10 juillet 2012 09:20 >> À : Ben Niven-Jenkins; LE LOUEDEC Yannick RD-CORE Cc : Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt >> >> Hi Yannick, Ben, >> >> I tend to agree with Ben here. When reading the draft, I got the feeling that the draft seems to assume a lot about the relationship between the uCDN and dCDN. For example, I don't see why the CDNI Request Routing interface should state that a dCDN MUST deliver the content if it has indicated its ability to do so earlier in either a contractual agreement or in the capability interface. I understand that in most cases, the contractual agreement might indeed impose this behavior on the dCDN, but I don't think this type of behavior should be imposed by the protocol we're developing here. >> >> It was always my assumption that the Request Routing Interface would at least include the option of allowing the uCDN to query the dCDN for every content request whether the dCDN is willing to deliver that particular request. >> >> I will send my full review of the draft later. >> >> Ray >> >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins >> Sent: dinsdag 10 juli 2012 7:38 >> To: yannick.lelouedec@orange.com >> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE >> Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt >> >> Yannick, >> >> Please see inline. >> >> On 9 Jul 2012, at 20:05, wrote: >> >>> Hi Ben, all, >>> >>> Ben, quoting you mail below, "... the downstream CDN could reply with >>> either "here is how to redirect it"", >>> >>> => This is the role of the CDNI DRIS interface to provide the uCDN with this information, and we target to make its specification public before Vancouver meeting so that everyone may read it before the meeting and get full knowledge of our proposal about this part of CDNI request routing. >>> >>> Ben, quoting you mail below, "... or "no I can't/won't take that content delivery right now", reasons may include the uCDN has requested a delivery of a protocol the dCDN does not support (possibly in error). >>> >>> => This is the role of the CDNI logging interface to provide the uCDN with this information. >> I agree this information should be logged but the Request Routing interface (what you call the DRIS) also needs to be able to indicate a failure. >> >> Otherwise the uCDN will 'blindly' redirect the the dCDN and the delivery will fail leading to poor end user experience. >> >>> Ben, quoting you mail below, "... or "no I can't/won't take that content delivery right now", reasons may include ... the dCDN has no capacity right now etc." >>> >>> => This is the role of the CDNI routing interface to provide the uCDN with this information. >> It is the role of the CDN capability/routing interface to advertise broad capabilities etc not to give extremely fine grained real-time information on exactly the state of the dCDN. >> >> Even if the capability/routing interface is real-time there are likely to still be race conditions where we need the dCDN to be about to indicate a failure to accept a redirect through the request routing/DRIS interface >> >>> So we may conclude we are in line basically, which is a good point. >>> We just aimed at checking there was a common understanding on this point. >>> >>> The key point for us here is that we don't want this sentence extracted from draft-ietf-cdni-problem-statement be interpreted as: ". and the dCDN MUST accept the content request except when it has not the "ability" to do so." >> Why not? IMO that is a valid scenario for some use cases. >> >>> The fact that the dCDN is temporary unable to handle content request correctly is not a valid reason for the dCDN to be discharged of its obligations to the uCDN. >>> The contract set between the uCDN and the dCDN remains valid anyway, and the obligations of the dCDN as well. >> Correct, but that contract may not be the same for all uCDNs & dCDNs, for example a uCDN may not have a guarantee that a dCDN can handle everything it is requested to handle but the contract may only be that the dCDN guarantees to handle up to a certain volume of traffic. >> >>> The dCDN must announce to the uCDN that it is temporary unable, as soon as possible, via the CDNI routing interface. >>> And the uCDN must take this information into account in its CDN selection process as soon as possible. >>> Then if the uCDN decides to continue to redirect content requests to the dCDN, the uCDN MAY perfectly do it, but the uCDN knows these content requests will be lost. >> What happens in the period between the dCDN being unable to handle requests and the time it takes to advertise that to the uCDN and for the uCDN to process & incorporate that new knowledge? Are requests blindly forwarded to the dCDN which is unable to handle them leading to poor user experience? >> >>> We could even imagine the situation where the uCDN continues to do it intentionally, because it has no better option and the content request will be lost anyway. For example in the case where neither the uCDN nor the other downstream CDNs of the uCDN cannot manage correctly the content request, the uCDN could do it intentionally so as to be able to clearly prove (with CDNI logging information) that it is the dCDN, not the uCDN, who is at fault. >>> But, of course, if there are alternative backup options, the normal reaction of the uCDN is to stop as soon as possible to redirect content requests to the dCDN when the uCDN knows that the dCDN is unable to handle them correctly. >>> >>> So, to be clear, we would prefer the sentence to be understood as: >>> ". and the dCDN MUST accept the content request. >>> And if it cannot handle correctly the redirected content request it receives, the content request is lost. >> What about scenarios where the uCDN has a choice of dCDNs (e.g. two national-wide CDNs offering services at different costs), the uCDN may elect to query both dCDNs and decide based on their responses which one to choose. If the dCDN is unable to satisfy the request the uCDN needs to know that so that it can fallback to the (more expensive in this example) dCDN. >> >>> For example the dCDN generates a response to the content request with an error message, or no response at all. And in parallel the CDNI logging interface may be used to exchange logs corresponding to this problem. Anyway the dCDN MAY NOT redirect that content request back towards the uCDN." >>> >>> Exactly as in IP networks: IP packets are not sent back towards the origin by a downstream router under failure or congestion. >> In a routed IP network, there is often a small packet loss while the network re-converges, by enabling the dCDN to refuse a redirection at CDNI Request Routing/DRIS query time we can reduce that window by giving the uCDN the option to take an alternative action (e.g. try another dCDN) while the routing/capability information re-converges. >> >>> In both networks (IP and CDN), the reason is the same. >>> If the dCDN redirects back a content request to the uCDN, this generates a loop. >> Loop avoidance is a separate issue IMO to whether we should allow a dCDN to be able to communicate "I am unable/unwilling to take that content delivery at this time". >> >> Regards >> Ben >> >>> To manage this would introduce a very high complexity. >>> And this would be just to try to save the content requests redirected by the uCDN to the dCDN in the timeslot between the time the dCDN gets down and the time the uCDN takes this failure into account in its CDN selection process. >>> It is much better to try to reduce this timeslot as much as possible, with routing optimizations (we will propose as soon as possible). >>> Rather than introducing additional complexities (to manage redirection to the uCDN) in the framework. >>> >>> >>> By the way, as you know, the IESG has just approved today the 'Content Distribution Network Interconnection (CDNI) Problem Statement' draft as informational RFC. This is a good point. >>> And, as you may see in the draft "CDNI request routing", we do not propose to modify this problem statement draft. >>> We want know to focus now on getting the specifications of all CDNI interfaces ready as soon as possible. >>> >>> Best regards, >>> >>> Yannick Le Louédec. >>> >>> >>> -----Message d'origine----- >>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part >>> de Ben Niven-Jenkins Envoyé : lundi 9 juillet 2012 20:41 À : BERTRAND >>> Gilles RD-CORE Cc : cdni@ietf.org; Pilarski Marcin - Korpo TP; MARREC >>> Anne RD-CORE Objet : Re: [CDNi] TR: I-D Action: >>> draft-lelouedec-cdni-request-routing-00.txt >>> >>> Colleagues, >>> >>> I started reading draft-lelouedec-cdni-request-routing-00 and this text caught my eye: >>> >>> Quoting [I-D.ietf-cdni-problem-statement ], "The CDNI Request >>> Routing >>> interface enables a Request Routing function in an upstream CDN to >>> query a Request Routing function in a downstream CDN to determine if >>> the downstream CDN is able (and willing) to accept the delegated >>> content request". >>> >>> The "ability" and the "willingness" of the downstream CDN to accept >>> the delegated content request match two fully different processes in >>> CDN interconnection. And the description of both these processes >>> should be reviewed and clarified for the following reasons: >>> >>> o Regarding the former process, i.e. related to the "ability" >>> ("enables a Request Routing function in an upstream CDN to query a >>> Request Routing function in a downstream CDN to determine if the >>> downstream CDN is able (...) to accept the delegated content >>> request"), a routing protocol is used to achieve such a process, >>> called routing process, in many other technologies and networks >>> (IP, ATM, etc.). In all these technologies, it is the downstream >>> entity that provides routing information to the upstream entity. >>> The same approach should be applied to CDN interconnection. The >>> reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2, >>> dCDN 3, and then it selects one of them based on their responses") >>> would suffer from latency, signaling overhead and/or lack of >>> reactivity to events that impact the ability of the downstream >>> CDNs to accept delegated content requests. >>> >>> o Regarding the latter process, i.e. related to the "willingness" >>> ("enables a Request Routing function in an upstream CDN to query a >>> Request Routing function in a downstream CDN to determine if the >>> downstream CDN (...) is willing (...)to accept the delegated >>> content request"), it is to be noted that the relationship between >>> a uCDN and a dCDN is always in the frame of a contractual >>> agreement between the administrative entity owning the uCDN, >>> acting as the customer, and the administrative entity owning the >>> dCDN, acting as the service provider. Therefore, consider a case >>> where >>> >>> * the uCDN has a content request to redirect which is in full >>> conformance with the terms of this contractual agreement, and >>> >>> * the uCDN has selected this dCDN. >>> >>> As the uCDN knows, thanks to the routing information exchanged via >>> the aforementioned routing process, that the dCDN is able to >>> accept this content request, the uCDN MAY redirect the content >>> request to the dCDN and the dCDN MUST accept the content request. >>> Exchanging over the CDNI Request Routing interface information >>> about the "willingness" of the dCDN to accept the content request >>> is not relevant. >>> >>> I think you might be over thinking what we wrote in the problem statement. >>> >>> What was in the problem statement was meant to convey that an upstream CDN could make a request to a downstream CDN to say "how do I redirect this request to you" and the downstream CDN could reply with either "her is how to redirect it", or "no I can't/won't take that content delivery right now", reasons may include the uCDN has requested a delivery of a protocol the dCDN does not support (possibly in error) or the dCDN has no capacity right now etc. >>> >>> Ben >>> >>> On 9 Jul 2012, at 18:00, wrote: >>> >>>> Hi everyone, >>>> >>>> We have just submitted the draft below. We are convinced that it will help the WG to progress on the CDNI routing issues. >>>> >>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >>>> >>>> Any feedback is very welcome. >>>> >>>> Best regards, >>>> >>>> Gilles >>>> >>>> >>>> -----Message d'origine----- >>>> De : i-d-announce-bounces@ietf.org >>>> [mailto:i-d-announce-bounces@ietf.org] De la part de >>>> internet-drafts@ietf.org Envoyé : lundi 9 juillet 2012 18:55 À : >>>> i-d-announce@ietf.org Objet : I-D Action: >>>> draft-lelouedec-cdni-request-routing-00.txt >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> >>>> >>>> Title : CDNI Request Routing >>>> Author(s) : Yannick Le Louedec >>>> Anne Marrec >>>> Gilles Bertrand >>>> Marcin Pilarski >>>> Filename : draft-lelouedec-cdni-request-routing-00.txt >>>> Pages : 30 >>>> Date : 2012-07-09 >>>> >>>> Abstract: >>>> The present document proposes to clarify the CDNI Request Routing >>>> interface introduced in [I-D.ietf-cdni-framework] and [I-D.ietf-cdni- >>>> problem-statement], as well as related terminology. >>>> >>>> In particular the present document proposes to split the CDNI >>>> Request Routing interface into two separate interfaces with clearer >>>> roles, named respectively CDNI Routing interface and CDNI Downstream >>>> Resource Identifier Signaling interface (CDNI DRIS interface). >>>> >>>> This part of the CDN interconnection framework the IETF has been >>>> referring to so far with the term "CDNI Request Routing" is just >>>> another routing, signaling and forwarding problem in a long series of >>>> the telecommunication history. For example, one can draw a direct >>>> analogy between the IP/MPLS-TE framework and the CDN interconnection >>>> framework. >>>> >>>> In addition, this document recommends that the specification of ALL >>>> CDN interconnection interfaces in the scope of the CDNI IETF WG >>>> relies on the equivalent concept to IP prefix for CDN >>>> interconnection, named 'contentRequestScope'. This highly useful and >>>> powerful concept SHALL be used to simplify the specification of ALL >>>> CDN interconnection interfaces, as well as to ensure performance and >>>> scalability in CDN interconnection. >>>> >>>> All these proposals can be smoothly integrated in the WG drafts, >>>> especially [I-D.ietf-cdni-framework] and >>>> [I-D.ietf-cdni-requirements], as they essentially propose (useful) >>>> clarifications of the existing framework. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-routing >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> 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 >>>> >>>> _____________________________________________________________________ >>>> ____________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>>> exploites ou copies sans autorisation. Si vous avez recu ce message >>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>> >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender and delete this message and its attachments. >>>> As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >>>> Thank you. >>>> >>>> _______________________________________________ >>>> 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 >>> >>> ______________________________________________________________________ >>> ___________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce message >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and delete this message and its attachments. >>> As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >>> Thank you. >>> >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >> This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer >> >> >> _________________________________________________________________________________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and delete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >> Thank you. >> >> >> _________________________________________________________________________________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >> France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and delete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >> Thank you. >> > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > . > From yannick.lelouedec@orange.com Mon Jul 16 07:34:28 2012 Return-Path: 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 D3DA121F85E6 for ; Mon, 16 Jul 2012 07:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=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 bbF4LiI0zYIJ for ; Mon, 16 Jul 2012 07:34:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id C582221F85E4 for ; Mon, 16 Jul 2012 07:34:27 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 84B9018C1A7; Mon, 16 Jul 2012 16:35:11 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 64BD84C015; Mon, 16 Jul 2012 16:35:11 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Mon, 16 Jul 2012 16:35:07 +0200 From: To: Scott Wainner , Ben Niven-Jenkins , "Brandenburg, R. (Ray) van" , "cdni@ietf.org" Thread-Topic: IETF #84 - Proposal for a side meeting on the CDNI request routing interface Thread-Index: AQHNY2AxE9cOJtuYIkGZsocUwBZTOQ== Date: Mon, 16 Jul 2012 14:35:05 +0000 Message-ID: <20625_1342449311_5004269F_20625_735_1_e5fd8c10-b453-4cfa-8821-c05811f6324f@PEXCVZYH02.corporate.adroot.infra.ftgroup> References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> <2040_1341930789_4FFC3D24_2040_2504_1_b86bff40-ae68-40c0-b8e5-060f51be6864@PEXCVZYH02.corporate.adroot.infra.ftgroup> <3A7EA7EE-F8D4-4094-83F2-12CD3826B662@tno.nl> <5004079D.4000406@cisco.com> In-Reply-To: <5004079D.4000406@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Subject: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI request routing 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 14:34:29 -0000 Dear all, We propose to arrange a side meeting on Sunday evening during IETF #84 (i.e= . on July 29th) on the CDNI request routing interface. The objective is to clear the discussion we had these last days via the IET= F CDNI mailing list, and to ease an efficient meeting on Tuesday 31. If everybody agrees that this is a good idea, we will set up a doodle. Best regards, Yannick Le Lou=E9dec, Orange OLNC. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From ray.vanbrandenburg@tno.nl Mon Jul 16 07:42:21 2012 Return-Path: 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 CC25021F867B for ; Mon, 16 Jul 2012 07:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.244 X-Spam-Level: X-Spam-Status: No, score=0.244 tagged_above=-999 required=5 tests=[AWL=0.748, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 9HZVTygWV+nC for ; Mon, 16 Jul 2012 07:42:21 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id C6CFE21F8616 for ; Mon, 16 Jul 2012 07:42:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,594,1336341600"; d="scan'208";a="72431724" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1a.tno.nl with ESMTP; 16 Jul 2012 16:43:02 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.152]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.02.0298.004; Mon, 16 Jul 2012 16:43:01 +0200 From: "Brandenburg, R. (Ray) van" To: "yannick.lelouedec@orange.com" , "Scott Wainner" , Ben Niven-Jenkins , "cdni@ietf.org" Thread-Topic: IETF #84 - Proposal for a side meeting on the CDNI request routing interface Thread-Index: AQHNY2BZ57Stz0lLxUGXC65wgUK9qpcr+6Mg Date: Mon, 16 Jul 2012 14:42:59 +0000 Message-ID: References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> <2040_1341930789_4FFC3D24_2040_2504_1_b86bff40-ae68-40c0-b8e5-060f51be6864@PEXCVZYH02.corporate.adroot.infra.ftgroup> <3A7EA7EE-F8D4-4094-83F2-12CD3826B662@tno.nl> <5004079D.4000406@cisco.com> <20625_1342449311_5004269F_20625_735_1_e5fd8c10-b453-4cfa-8821-c05811f6324f@PEXCVZYH02.corporate.adroot.infra.ftgroup> In-Reply-To: <20625_1342449311_5004269F_20625_735_1_e5fd8c10-b453-4cfa-8821-c05811f6324f@PEXCVZYH02.corporate.adroot.infra.ftgroup> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI request routing 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 14:42:21 -0000 I think that is a very good idea, and I would like to attend. = Ray -----Original Message----- From: yannick.lelouedec@orange.com [mailto:yannick.lelouedec@orange.com] = Sent: maandag 16 juli 2012 16:35 To: Scott Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.= org Cc: BERTRAND Gilles RD-CORE; STEPHAN Emile RD-CORE Subject: IETF #84 - Proposal for a side meeting on the CDNI request routing= interface Dear all, We propose to arrange a side meeting on Sunday evening during IETF #84 (i.e= . on July 29th) on the CDNI request routing interface. The objective is to clear the discussion we had these last days via the IET= F CDNI mailing list, and to ease an efficient meeting on Tuesday 31. If everybody agrees that this is a good idea, we will set up a doodle. Best regards, Yannick Le Lou=E9dec, Orange OLNC. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, France Telecom - = Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From Jan.Seedorf@neclab.eu Mon Jul 16 08:09:56 2012 Return-Path: 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 7C32E21F866E; Mon, 16 Jul 2012 08:09:56 -0700 (PDT) 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 eOjamGOkUtA8; Mon, 16 Jul 2012 08:09:52 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id F2FB821F84B2; Mon, 16 Jul 2012 08:09:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 96DF210185B; Mon, 16 Jul 2012 17:13:31 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+ssd0UehYGy; Mon, 16 Jul 2012 17:13:31 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 7E4B010185A; Mon, 16 Jul 2012 17:13:21 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.121]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 16 Jul 2012 17:11:14 +0200 From: Jan Seedorf To: "cdni@ietf.org" Thread-Topic: New Version Notification for draft-seedorf-cdni-request-routing-alto-02.txt Thread-Index: AQHNY15wovoZxXUnakaSGgdYe+9n4ZcsAo0A Date: Mon, 16 Jul 2012 15:11:12 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE32CBC581@Polydeuces.office.hd> References: <20120716142050.3763.72206.idtracker@ietfa.amsl.com> In-Reply-To: <20120716142050.3763.72206.idtracker@ietfa.amsl.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "alto@ietf.org" Subject: [CDNi] FW: New Version Notification for draft-seedorf-cdni-request-routing-alto-02.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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 15:09:56 -0000 RGVhciBhbGwsDQoNCkkgaGF2ZSBqdXN0IHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0 LXNlZWRvcmYtY2RuaS1yZXF1ZXN0LXJvdXRpbmctYWx0by4gQXMgYmVmb3JlLCB0aGUgZHJhZnQg b3V0bGluZXMgaG93IEFMVE8gY291bGQgYmUgdXNlZCBmb3IgQ0ROSSByZXF1ZXN0IHJvdXRpbmcs IGluIHBhcnRpY3VsYXIgZm9yIGRvd25zdHJlYW0gQ0ROIHNlbGVjdGlvbi4gVGhlIG5ldyB2ZXJz aW9uIGNsYXJpZmllcyBzb21lIGFkZGl0aW9uYWwgYXNzdW1wdGlvbnMsIHJlZmVycyB0byBzb21l IG9mIHRoZSBsYXRlc3QgZGlzY3Vzc2lvbnMgd2UgaGF2ZSBoYWQgaW4gdGhlIGZvb3RwcmludC9j YXBhYmlsaXRpZXMgZGVzaWduIHRlYW0sIGFuZCBhbHNvIGdpdmVzIHNvbWUgbW9yZSBjb25jcmV0 ZSBleGFtcGxlcyBvbiBob3cgQUxUTyBuZXR3b3JrIGFuZCBjb3N0IG1hcHMgd291bGQgbG9vayBs aWtlIGFuZCB3aGF0IHRoZSBkZXNpZ24gY2hvaWNlcyBoZXJlIGFyZS4NCg0KQ29tbWVudHMgYXJl IHdlbGNvbWUuDQoNClNlZSB5b3UgaW4gVmFuY291dmVyLA0KDQogLSBKYW4NCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIEp1bHkgMTYsIDIwMTIg NDoyMSBQTQ0KVG86IEphbiBTZWVkb3JmDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LXNlZWRvcmYtY2RuaS1yZXF1ZXN0LXJvdXRpbmctYWx0by0wMi50eHQNCg0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtc2VlZG9yZi1jZG5pLXJlcXVlc3Qtcm91dGlu Zy1hbHRvLTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKYW4gU2Vl ZG9yZiBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRy YWZ0LXNlZWRvcmYtY2RuaS1yZXF1ZXN0LXJvdXRpbmctYWx0bw0KUmV2aXNpb246CSAwMg0KVGl0 bGU6CQkgQ0ROSSBSZXF1ZXN0IFJvdXRpbmcgd2l0aCBBTFRPDQpDcmVhdGlvbiBkYXRlOgkgMjAx Mi0wNy0xNg0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6 IDIwDQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LXNlZWRvcmYtY2RuaS1yZXF1ZXN0LXJvdXRpbmctYWx0by0wMi50eHQNClN0YXR1czog ICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zZWVkb3JmLWNk bmktcmVxdWVzdC1yb3V0aW5nLWFsdG8NCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtc2VlZG9yZi1jZG5pLXJlcXVlc3Qtcm91dGluZy1hbHRvLTAyDQpE aWZmOiAgICAgICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt c2VlZG9yZi1jZG5pLXJlcXVlc3Qtcm91dGluZy1hbHRvLTAyDQoNCkFic3RyYWN0Og0KICAgTmV0 d29yayBTZXJ2aWNlIFByb3ZpZGVycyAoTlNQcykgYXJlIGN1cnJlbnRseSBjb25zaWRlcmluZyB0 byBkZXBsb3kNCiAgIENvbnRlbnQgRGVsaXZlcnkgTmV0d29ya3MgKENETnMpIHdpdGhpbiB0aGVp ciBuZXR3b3Jrcy4gIEFzIGENCiAgIGNvbnNlcXVlbmNlIG9mIHRoaXMgZGV2ZWxvcG1lbnQsIHRo ZXJlIGlzIGEgbmVlZCBmb3IgaW50ZXJjb25uZWN0aW5nDQogICB0aGVzZSBsb2NhbCBDRE5zLiAg VGhlIG5lY2Vzc2FyeSBpbnRlcmZhY2VzIGZvciBpbnRlci1jb25uZWN0aW5nIENETnMNCiAgIGFy ZSBjdXJyZW50bHkgYmVpbmcgZGVmaW5lZCBpbiB0aGUgQ29udGVudCBEZWxpdmVyeSBOZXR3b3Jr cw0KICAgSW50ZXJjb25uZWN0aW9uIChDRE5JKSBXRy4gIFRoaXMgZG9jdW1lbnQgZm9jdXNzZXMg b24gdGhlIFJlcXVlc3QNCiAgIFJvdXRpbmcgSW50ZXJmYWNlIG9mIENETkksIGFuZCBtb3JlIHNw ZWNpZmljYWxseSBvbiBob3cgdGhlIHNvbHV0aW9ucw0KICAgY3VycmVudGx5IGJlaW5nIGRlZmlu ZWQgaW4gdGhlIEFwcGxpY2F0aW9uIExheWVyIFRyYWZmaWMgT3B0aW1pemF0aW9uDQogICAoQUxU TykgV0cgY2FuIGltcHJvdmUgQ0ROSSByZXF1ZXN0IHJvdXRpbmcuICBUaGUgb3ZlcmFsbCBpbnRl bnRpb24NCiAgIGJlaGluZCB0aGlzIGRvY3VtZW50IGlzIHRvIGZvc3RlciBkaXNjdXNzaW9ucyAo aW4gdGhlIENETkkgYXMgd2VsbCBhcw0KICAgaW4gdGhlIEFMVE8gV0cpIHJlZ2FyZGluZyBpZiwg aG93LCBhbmQgdW5kZXIgd2hhdCBjb25kaXRpb25zIEFMVE8gY2FuDQogICBiZSB1c2VmdWwgdG8g b3B0aW1pemUgQ0ROSSByZXF1ZXN0IHJvdXRpbmcuICBBcyBiYXNpcyBmb3IgdGhpcw0KICAgZGlz Y3Vzc2lvbiwgdGhpcyBkb2N1bWVudCBwcm92aWRlcyBjb25jcmV0ZSBleGFtcGxlcyBvZiBob3cg QUxUTyBjYW4NCiAgIGJlIGludGVncmF0ZWQgd2l0aGluIENETkkgcmVxdWVzdCByb3V0aW5nIGFu ZCBpbiBwYXJ0aWN1bGFyIGluIHRoZQ0KICAgcHJvY2VzcyBvZiBzZWxlY3RpbmcgYSBkb3duc3Ry ZWFtIENETi4gIFRoZSBleGFtcGxlcyBpbiB0aGlzIGRvY3VtZW50DQogICBhcmUgYmFzZWQgb24g dGhlIHVzZSBjYXNlcyBhbmQgZXhhbXBsZXMgY3VycmVudGx5IGJlaW5nIGRpc2N1c3NlZCBpbg0K ICAgdGhlIENETkkgV0cuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVU RiBTZWNyZXRhcmlhdA0K From Jan.Seedorf@neclab.eu Mon Jul 16 08:17:36 2012 Return-Path: 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 1C2DB21F869F for ; Mon, 16 Jul 2012 08:17:36 -0700 (PDT) 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 mEhhOEr8CBjb for ; Mon, 16 Jul 2012 08:17:35 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 03B8B21F8742 for ; Mon, 16 Jul 2012 08:17:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id A5BCD10185B; Mon, 16 Jul 2012 17:21:14 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwSzce-M01qb; Mon, 16 Jul 2012 17:21:14 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 886F810185A; Mon, 16 Jul 2012 17:20:59 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.121]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 16 Jul 2012 17:18:52 +0200 From: Jan Seedorf To: "cdni@ietf.org" Thread-Topic: New Version Notification for draft-spp-cdni-rr-foot-cap-semantics-01.txt Thread-Index: AQHNY2PTG3KRr8Tqs0uR/PQ7sHpa6pcsA3sg Date: Mon, 16 Jul 2012 15:18:50 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE32CBC59A@Polydeuces.office.hd> References: <20120716145924.2709.4649.idtracker@ietfa.amsl.com> In-Reply-To: <20120716145924.2709.4649.idtracker@ietfa.amsl.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [CDNi] FW: New Version Notification for draft-spp-cdni-rr-foot-cap-semantics-01.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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 15:17:36 -0000 RGVhciBhbGwsDQoNCldlIGhhdmUganVzdCBzdWJtaXR0ZWQgYW4gdXBkYXRlIG9mIGRyYWZ0LXNw cC1jZG5pLXJyLWZvb3QtY2FwLXNlbWFudGljcyAobm93IHZlcnNpb24gLTAxKS4gVGhpcyBuZXcg dmVyc2lvbiBhZGRyZXNzZXMgKGhvcGVmdWxseSkgYWxsIHRoZSBjb21tZW50cyB3ZSByZWNlaXZl ZCAobWFpbmx5IGZyb20gRnJhbmNvaXMsIHRoYW5rcyEpIG9uIHRoZSBwcmV2aW91cyB2ZXJzaW9u LiBBcyBwYXJ0IG9mIHRoZXNlIGNvbW1lbnRzLCB0aGUgZHJhZnQgbm93IGxpc3QgbW9yZSByZXF1 aXJlbWVudHMgYW5kIHRleHQgZnJvbSB0aGUgQ0ROSSByZXF1aXJlbWVudHMgZG9jdW1lbnQgdGhh dCBhcmUgcmVsZXZhbnQgZm9yIHRoZSBkaXNjdXNzaW9uLiBBbHNvLCB0aGUgbmV3IHZlcnNpb24g aGFzIHNvbWUgYWRkaXRpb25zIHRoYXQgdHJ5IHRvIGNhcHR1cmUgdGhlIGRpc2N1c3Npb25zIHdl IGhhdmUgaGFkIHdpdGhpbiB0aGUgQ0ROSSBmb290cHJpbnQvY2FwYWJpbGl0aWVzIGRlc2lnbiB0 ZWFtIHNpbmNlIHRoZSBsYXN0IElFVEYgbWVldGluZzogZS5nLiB3aGF0IGFib3V0IGNoZWF0aW5n IGRvd25zdHJlYW0gQ0ROcz87IGlzIGl0IHJlYXNvbmFibGUgdG8gYXNzdW1lIHRoYXQgdGhlIHVD RE4gbWFrZXMgdGhlIGRlY2lzaW9uPywgY2FuIHdlIHNpbXBsaWZ5IHNvbWUgYXNzdW1wdGlvbiB0 byBtYWtlIHByb2dyZXNzIHdpdGggdGhlIHRlcm1pbm9sb2d5PzsgIndpbGxpbmduZXNzIHRvIHNl cnZlIiBpcyBhIGJhc2lzIHRvIGRlZmluZSBmb290cHJpbnQsIGJ1dCBpdCBpcyBwcm9iYWJseSBu b3QgZW5vdWdoIHRvIGRlZmluZSBhIGRDRE4gZm9vdHByaW50LCBzb21lIGFkZGl0aW9uYWwgaW5m b3JtYXRpb24gbmVlZHMgdG8gYmUgdGFnZ2VkIGFsb25nIHRvIGVuYWJsZSB0aGUgdUNETiB0byBq dWRnZS9hc3Nlc3MgdGhlIGRlbGl2ZXJ5IHF1YWxpdHkgYXNzb2NpYXRlZCB3aXRoIGEgZ2l2ZW4g ZENETiBjb3ZlcmFnZSBmb290cHJpbnQuDQoNCkNvbW1lbnRzIGFyZSBvZiBjb3Vyc2Ugd2VsY29t ZSwNCg0KU2VlIHlvdSBpbiBWYW5jb3V2ZXIsDQoNCiAtIEphbg0KDQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIEp1bHkgMTYsIDIwMTIgNDo1 OSBQTQ0KVG86IHNlZWRvcmZAbmVjbGFiLmV1DQpDYzogc3ByZXZpZGlAY2lzY28uY29tOyBqb24u cGV0ZXJzb25AbmV1c3Rhci5iaXoNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtc3BwLWNkbmktcnItZm9vdC1jYXAtc2VtYW50aWNzLTAxLnR4dA0KDQoNCkEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zcHAtY2RuaS1yci1mb290LWNhcC1zZW1hbnRpY3MtMDEu dHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEphbiBTZWVkb3JmIGFuZCBw b3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtc3BwLWNk bmktcnItZm9vdC1jYXAtc2VtYW50aWNzDQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBDRE5JIFJl cXVlc3QgUm91dGluZzogRm9vdHByaW50IGFuZCBDYXBhYmlsaXRpZXMgU2VtYW50aWNzDQpDcmVh dGlvbiBkYXRlOgkgMjAxMi0wNy0xNg0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpO dW1iZXIgb2YgcGFnZXM6IDE5DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNwcC1jZG5pLXJyLWZvb3QtY2FwLXNlbWFudGljcy0wMS50 eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1zcHAtY2RuaS1yci1mb290LWNhcC1zZW1hbnRpY3MNCkh0bWxpemVkOiAgICAgICAgaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc3BwLWNkbmktcnItZm9vdC1jYXAtc2VtYW50aWNz LTAxDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtc3BwLWNkbmktcnItZm9vdC1jYXAtc2VtYW50aWNzLTAxDQoNCkFic3RyYWN0Og0KICAg VGhpcyBkb2N1bWVudCB0cmllcyB0byBjYXB0dXJlIHRoZSBzZW1hbnRpY3Mgb2YgdGhlICJGb290 cHJpbnQgYW5kDQogICBDYXBhYmlsaXRpZXMgQWR2ZXJ0aXNlbWVudCIgcGFydCBvZiB0aGUgQ0RO SSBSZXF1ZXN0IFJvdXRpbmcNCiAgIGludGVyZmFjZSwgaS5lLiB0aGUgZGVzaXJlZCBtZWFuaW5n IGFuZCB3aGF0ICJGb290cHJpbnQgYW5kDQogICBDYXBhYmlsaXRpZXMgQWR2ZXJ0aXNlbWVudCIg aXMgZXhwZWN0ZWQgdG8gb2ZmZXIgd2l0aGluIENETkkuICBUaGUNCiAgIGRpc2N1c3Npb24gaW4g dGhpcyBkb2N1bWVudCBoYXMgdGhlIGdvYWwgdG8gZmFjaWxpdGF0ZSB0aGUgY2hvb3NpbmcNCiAg IG9mIG9uZSBvciBtb3JlIHN1aXRhYmxlIHByb3RvY29scyBmb3IgIkZvb3RwcmludCBhbmQgQ2Fw YWJpbGl0aWVzDQogICBBZHZlcnRpc2VtZW50IiB3aXRoaW4gQ0ROSSBSZXF1ZXN0IFJvdXRpbmcu DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From kevin.ma@azukisystems.com Mon Jul 16 13:42:35 2012 Return-Path: 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 1058311E80F0 for ; Mon, 16 Jul 2012 13:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 0W+3ceEhn9EY for ; Mon, 16 Jul 2012 13:42:33 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id EBEE711E8291 for ; Mon, 16 Jul 2012 13:42:32 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 277F95548A2; Mon, 16 Jul 2012 16:43:18 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 2F86A556EAD; Mon, 16 Jul 2012 16:40:26 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Mon, 16 Jul 2012 16:40:21 -0400 From: Kevin J Ma To: "Matt Caulfield (mcaulfie)" , "cdni@ietf.org" Date: Mon, 16 Jul 2012 16:40:24 -0400 Thread-Topic: New Metadata Interface Draft (draft-cjlmw-cdni-metadata-00) Thread-Index: Ac1eC0YVScB5jeVWTF6OpuGDrKcS+gFg0Grw Message-ID: <291CC3F9E50E7641901A54E85D0977C65326E2AA7F@MAILR002.mail.lan> References: <166EBB70C264A9479E459B01B1BA6C9201B060@xmb-aln-x03.cisco.com> In-Reply-To: <166EBB70C264A9479E459B01B1BA6C9201B060@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_291CC3F9E50E7641901A54E85D0977C65326E2AA7FMAILR002maill_" MIME-Version: 1.0 Cc: "Ben Niven-Jenkins \(ben@velocix.com\)" Subject: Re: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni-metadata-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 20:42:35 -0000 --_000_291CC3F9E50E7641901A54E85D0977C65326E2AA7FMAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Matt, A couple of initial comments/questions about the merged draft: - I do not understand the need for a heirarchical separation of the Acquisition and Delivery objects? Why is the property "key" not sufficient for designating the function of the metadata? Though it could be argued that these are logically different functions, the extra layer seems unnecessary, and introduces some complexity to the inheritance model? With inheritance-based override, can a lower level PathMetadata object override just an Auth List, or does it have to replace the entire Delivery object? Does it have to place the Auth List inside a lower level Delivery object, or can it just define a new Auth List with no Delivery object wrapper? Is there a concept of leaf vs. branch objects for override purposes? In general, if there are an arbitrary number of levels below each object, and an arbitrary number of levels of PathMetadata which may contain objects with arbitrary levels of metadata which may override previous levels, is there a need to check that duplicate Metadata do not exist within a given subtree, and/or should that restriction be stated explicity? - I see that the PathMetadata defines some restrictions to what it may contain, however, this does not seem like a scalable method of managing object restrictions. As we move forward and more vendor specific metadata are defined, managing metadata collisions using the such a method seems complex, in that the CDNI Metadata RFC could need to be continuously updated to add more restrictions. It would be nice if there was a general set of rules for how and where to define new metadata, rather than creating highly customized objects which have complex modification restrictions? - I assume that the inheritance model requires that PathMatch objects must match the path of all PathMatch objects above it in the hierarchy? i.e., I cannot add a PathMatch for "/bar/baz" inside a PathMetadata whose PathMatch was for "/foo"? It is probably worth stating explicitly? How are ambiguous patterns (e.g., "/*/foo/*") handled? Are there defined restrictions on the PathMatch objects to guarantee that all lookups will be deterministic? - In the ACLRule object, if you can only have either an allow or a deny Property but not both, and the ACLRule list can only have either Location or TimeWindow properties but not both, it is not clear that much is gained by combining them into the same ACL and ACLRule objects? In the future, if new types of ACLs are added, would we modify these existing objects (and rev the CDNI Metadata RFC), or just add separate object definitions? The reuse of object definitions, in this case, does not seem to buy us anything? Defining separate LocationACL/LocationACLRule objects and TimeWindowACL/TimeWindowACLRule objects, where allow/deny is just an attribute/property would result in essentially the same implementation, but without the interdependendies, which would simplify future revisions? - In the Property definitions, I assume that the "key" is the term that follows the "Property:" tag, and that the "Description:" and "Type:" indented below describe the "value"? It was not clear to me what the "Mandatory:" tag implied? Mandatory to specify the Property in every object? Mandatory to implement support for the Property? or Mandatory to enforce the Property? It might be useful to explicitly define Mandatory? - In the HostMatch object, the hostname Property is defined as a String? Should there be Pattern support for hostnames? Also, does hostnames support both IP and DNS values? Also, does the hostname support a URI prefix that should be matched as part of the hostname, and not be included in the PathMatch? - For Lists of objects, I did not see a specific ordering defined? Is there a way to enforce ordering? - With respect to extensibility, can an "x-" object be added to any other object, or are there restrictions on where a new custom object may be added into the hierarchy? Can I add a new ACL type? Can I add a new pattern matching option to the HostMatch and/or PathMatch objects (fundamentally changing the way hosts and paths are matched)? Can I add new types of location algorithms (e.g., GPS coordinates or zip code) to the Location object? Or is it intended more for just creating a new hierarchy under the Delivery object? - With respect to the "ignorable" Property, does that affect the entire parent object to which it is added? If it is a Property itself (rather than an attribute of a Property), then does that require a wrapper object around the actual Property and the "ingnorable" Property, for all new Properties? Should it be a standard attribute like Mandatory? - Is there a way for the client to request metadata for a given URI, rather than recursively checking and requesting PathMetadata? Doesn't this lead to alot of lookups (even local cache lookups) for each request, to find all of the applicable PathMetadata? Are there optimizations for local cache lookup? Note: I have also uploaded an updated version of my draft: http://tools.ietf.org/html/draft-ma-cdni-metadata-03 thanx. -- Kevin J. Ma From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Mat= t Caulfield (mcaulfie) Sent: Monday, July 09, 2012 3:45 PM To: cdni@ietf.org Cc: Ben Niven-Jenkins (ben@velocix.com) Subject: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni-metadata-00) Hi everyone, As we announced in April, a group of us (Ben Niven-Jenkins, Kent Leung, Rob= Murray, Grant Watson, and I) have been working on a merge of two of the CD= NI metadata interface proposals: - draft-caulfield-cdni-metadata-core-00 - draft-jenkins-cdni-metadata-00 The merged draft has now been submitted: http://tools.ietf.org/html/draft-c= jlmw-cdni-metadata-00 We will be presenting on this draft in Vancouver. Any feedback on the list = is also appreciated. Thanks, Matt --_000_291CC3F9E50E7641901A54E85D0977C65326E2AA7FMAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Matt,

  A couple of initial comments/que= stions about the merged draft:

 <= /span>

  - I do not understand the need for a heirarchical sep= aration of the

    Acquisition and= Delivery objects?  Why is the property "key" not=

    sufficient for designating the function = of the metadata?

 

    Though it could be argued that these are logically diff= erent

    functions, the extra lay= er seems unnecessary, and introduces some

 &= nbsp;  complexity to the inheritance model?

=  

    With inheritance-based = override, can a lower level PathMetadata

 &n= bsp;  object override just an Auth List, or does it have to replace th= e

    entire Delivery object? = ; Does it have to place the Auth List

  = ;  inside a lower level Delivery object, or can it just define a new

    Auth List with no Delivery obje= ct wrapper?  Is there a concept of

 &nb= sp;  leaf vs. branch objects for override purposes?<= /p>

 

    In general, if = there are an arbitrary number of levels below each

    may contain objects = with arbitrary levels of metadata which may

&nb= sp;   override previous levels, is there a need to check that dup= licate

    Metadata do not e= xist within a given subtree, and/or should that

&= nbsp;   restriction be stated explicity?

  - I see that the PathMetadata def= ines some restrictions to what it

  &nb= sp; may contain, however, this does not seem like a scalable method of=

    managing object restrictions. = ; As we move forward and more vendor

  =   specific metadata are defined, managing metadata collisions using

    the such a method seems complex,= in that the CDNI Metadata RFC

   = could need to be continuously updated to add more restrictions.=

    It would be nice if there was a general = set of rules for how and

    where= to define new metadata, rather than creating highly

<= p class=3DMsoNormal>    customized objects which have complex modification r= estrictions?

 

&nb= sp; - I assume that the inheritance model requires that PathMatch

    objects must match the path of all Path= Match objects above it in

    the = hierarchy?  i.e., I cannot add a PathMatch for "/bar/baz"

    inside a PathMetadata whose Path= Match was for "/foo"?  It is

&nb= sp;   probably worth stating explicitly?

    How are ambiguous pat= terns (e.g., "/*/foo/*") handled?  Are there

    defined restrictions on the PathMatch objects= to guarantee that

    all lookups= will be deterministic?

 <= /p>

  - In the ACLRule object, if you can only have either an allo= w or a

    deny Property but not b= oth, and the ACLRule list can only have

 &nb= sp;  either Location or TimeWindow properties but not both, it is not<= o:p>

    clear that much is gained by c= ombining them into the same ACL and

  &= nbsp; ACLRule objects?  In the future, if new types of ACLs are added,=

    would we modify these existin= g objects (and rev the CDNI Metadata

  =   RFC), or just add separate object definitions?

=

 

    The reuse of objec= t definitions, in this case, does not seem to

&nb= sp;   buy us anything?  Defining separate LocationACL/Locati= onACLRule

    objects and TimeWind= owACL/TimeWindowACLRule objects, where

 &nbs= p;  allow/deny is just an attribute/property would result in

    essentially the same implementation, bu= t without the

    interdependendie= s, which would simplify future revisions?

&n= bsp;

  - In the Property definitions, I assume th= at the "key" is the term

  &n= bsp; that follows the "Property:" tag, and that the "Descrip= tion:" and

    "Type:&qu= ot; indented below describe the "value"?

    It was not clear to m= e what the "Mandatory:" tag implied?

&n= bsp;   Mandatory to specify the Property in every object?  M= andatory to

    implement support = for the Property?  or Mandatory to enforce the

 

&n= bsp; - In the HostMatch object, the hostname Property is defined as a<= /o:p>

    String?  Should there be Patte= rn support for hostnames?  Also,

  = ;  does hostnames support both IP and DNS values?  Also, does the=

    hostname support a URI prefix= that should be matched as part of

  &n= bsp; the hostname, and not be included in the PathMatch?<= /p>

 

  - For Lists of objects, I d= id not see a specific ordering defined?

 &nb= sp;  Is there a way to enforce ordering?

 

  - With respect to extensibility, can a= n "x-" object be added to any

 &nb= sp;  other object, or are there restrictions on where a new custom

    object may be added into the hier= archy?

 

 &nb= sp;  Can I add a new ACL type?  Can I add a new pattern matching = option

    to the HostMatch and/or= PathMatch objects (fundamentally changing

 =    the way hosts and paths are matched)?  Can I add new type= s of

    location algorithms (e.g.= , GPS coordinates or zip code) to the

  = ;  Location object?  Or is it intended more for just creating a n= ew

    hierarchy under the Deliver= y object?

 

 = - With respect to the "ignorable" Property, does that affect the=

    entire parent object to which= it is added?  If it is a Property

 &nb= sp;  itself (rather than an attribute of a Property), then does that

    require a wrapper object around= the actual Property and the

    &= quot;ingnorable" Property, for all new Properties?  Should it be = a

    standard attribute like Mand= atory?

 

  - = Is there a way for the client to request metadata for a given URI,

    rather than recursively checking and r= equesting PathMetadata?

    Doesn'= t this lead to alot of lookups (even local cache lookups)=

    for each request, to find all of the applicable= PathMetadata?

    Are there optim= izations for local cache lookup?

=  

  Note: I have also uploaded an updated version of my= draft:

       = ; http://tools.ietf.org/html/draft-ma-cdni-metadata-03 

 

thanx.

 

--  Kevin J. Ma

 

 

From: cdni-bounces@ietf.org [mailto:cd= ni-bounces@ietf.org] On Behalf Of Matt Caulfield (mcaulfie)
Se= nt: Monday, July 09, 2012 3:45 PM
To: cdni@ietf.org
Cc:= Ben Niven-Jenkins (ben@velocix.com)
Subject: [CDNi] New Meta= data Interface Draft (draft-cjlmw-cdni-metadata-00)

 

Hi everyone= ,

 

= As we announced in April, a group of us (Ben Niven-Jenkins, Kent Leung, Rob= Murray, Grant Watson, and I) have been working on a merge of two of the CD= NI metadata interface proposals:

-=        draft-caulfield-= cdni-metadata-core-00

-  = ;     draft-jenkins-cdni-metadata= -00

 

The merged draft has now been submitted: http://tools.ietf.org/html/dra= ft-cjlmw-cdni-metadata-00

 = ;

We will be presenting on this draft in Vancouver. An= y feedback on the list is also appreciated.

 

Thanks,

Matt

 

 

   &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;           

= --_000_291CC3F9E50E7641901A54E85D0977C65326E2AA7FMAILR002maill_-- From internet-drafts@ietf.org Mon Jul 16 13:45:41 2012 Return-Path: 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 D4BC611E82D7; Mon, 16 Jul 2012 13:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 MfdUuUoXsJOP; Mon, 16 Jul 2012 13:45:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CA811E82BB; Mon, 16 Jul 2012 13:45:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716204541.4354.35565.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 13:45:41 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-framework-01.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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 20:45:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : Framework for CDN Interconnection Author(s) : Larry Peterson Bruce Davie Filename : draft-ietf-cdni-framework-01.txt Pages : 55 Date : 2012-07-16 Abstract: This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDN Interconnection requires the specification of several interfaces and mechanisms to address issues such as request routing, metadata exchange, and the acquisition of content by one CDN from another. The intent of this document is to outline what each interface needs to accomplish, and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. It obsoletes RFC 3466. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-framework-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-framework-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mcaulfie@cisco.com Tue Jul 17 13:01:07 2012 Return-Path: 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 F0E2811E8095 for ; Tue, 17 Jul 2012 13:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[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 A+jerGg5hmUJ for ; Tue, 17 Jul 2012 13:01:00 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB1B21F86F5 for ; Tue, 17 Jul 2012 13:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcaulfie@cisco.com; l=50092; q=dns/txt; s=iport; t=1342555309; x=1343764909; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SVbfEQmZG1oTGHmNyqnzrBcWIu4vuGXU+/xGj0wjSbs=; b=ZDQ1PM6YBBYe4T6RtfyuNStLRtX/5b1yVkvtKg614EBh6wyCXR5ka5Eo 0vpPFFMjBusR17w0ywd6p7eTt3YIduczMz4oz7ewhu76Vxwly+gylkYYP IwYqfxjy7xl42pGbIqWYImD8tlC+zYANfBoe6t2iuatfOw9FfPUSERYH4 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAETEBVCtJXG+/2dsb2JhbABFgkqtQAGIeYEHgiABAQEEEgEaPw0QAgEIEQQBAQsWAQYHMhQJCAEBBAENBQgah2sLnRCgMItAFYVaYAORDIVDjRCBZoJfgVc X-IronPort-AV: E=Sophos;i="4.77,604,1336348800"; d="scan'208,217";a="102751299" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 17 Jul 2012 20:01:47 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6HK1llV019420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Jul 2012 20:01:47 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Tue, 17 Jul 2012 15:01:47 -0500 From: "Matt Caulfield (mcaulfie)" To: Kevin J Ma , "cdni@ietf.org" Thread-Topic: New Metadata Interface Draft (draft-cjlmw-cdni-metadata-00) Thread-Index: Ac1eC0YVScB5jeVWTF6OpuGDrKcS+gFg0GrwAC74lzA= Date: Tue, 17 Jul 2012 20:01:46 +0000 Message-ID: <166EBB70C264A9479E459B01B1BA6C9201F7B3@xmb-aln-x03.cisco.com> References: <166EBB70C264A9479E459B01B1BA6C9201B060@xmb-aln-x03.cisco.com> <291CC3F9E50E7641901A54E85D0977C65326E2AA7F@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C65326E2AA7F@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.173.128] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19046.004 x-tm-as-result: No--37.341100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_166EBB70C264A9479E459B01B1BA6C9201F7B3xmbalnx03ciscocom_" MIME-Version: 1.0 Cc: "Ben Niven-Jenkins \(ben@velocix.com\)" Subject: Re: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni-metadata-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 20:01:07 -0000 --_000_166EBB70C264A9479E459B01B1BA6C9201F7B3xmbalnx03ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kevin, Thank you for the comments, please see my responses inline below. Regards, Matt From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] Sent: Monday, July 16, 2012 4:40 PM To: Matt Caulfield (mcaulfie); cdni@ietf.org Cc: Ben Niven-Jenkins (ben@velocix.com) Subject: RE: New Metadata Interface Draft (draft-cjlmw-cdni-metadata-00) Hi Matt, A couple of initial comments/questions about the merged draft: - I do not understand the need for a heirarchical separation of the Acquisition and Delivery objects? Why is the property "key" not sufficient for designating the function of the metadata? [Matt>] The separation was created to categorize metadata properties. It's = not essential. It may be useful if one server in a CDN is delivery a piece = of content and another server is acquiring. The acquisition server could li= mit itself to looking at the acquisition metadata while the delivery server= could limit itself to looking at the delivery metadata. Would you suggest = removing this distinction? Though it could be argued that these are logically different functions, the extra layer seems unnecessary, and introduces some complexity to the inheritance model? [Matt>] I don't think that the extra layer introduces any additional comple= xity. In our model, objects can contain objects which can contain objects, = the delivery/acquisition objects aren't a special case. With inheritance-based override, can a lower level PathMetadata object override just an Auth List, or does it have to replace the entire Delivery object? Does it have to place the Auth List inside a lower level Delivery object, or can it just define a new Auth List with no Delivery object wrapper? Is there a concept of leaf vs. branch objects for override purposes? [Matt>] Any object at any level can be overridden. So yes, just the Auth li= st could be overridden, there is no need to override the entire delivery ob= ject. Yes, the schema must be preserved - so to override the auth list it w= ould be wrapped by a delivery object. No, there is no concept of leaf vs. b= ranch. Based on your comment, I think we could spend more time on the descr= iption of inheritance. In general, if there are an arbitrary number of levels below each object, and an arbitrary number of levels of PathMetadata which may contain objects with arbitrary levels of metadata which may override previous levels, is there a need to check that duplicate Metadata do not exist within a given subtree, and/or should that restriction be stated explicity? [Matt>] I'm not sure what you mean by duplicate metadata. Each PathMetadata= object defines a bunch of metadata properties, each one is unique. Each Pa= thMetadata object either inherits or overrides the metadata properties of i= ts parent. - I see that the PathMetadata defines some restrictions to what it may contain, however, this does not seem like a scalable method of managing object restrictions. As we move forward and more vendor specific metadata are defined, managing metadata collisions using the such a method seems complex, in that the CDNI Metadata RFC could need to be continuously updated to add more restrictions. It would be nice if there was a general set of rules for how and where to define new metadata, rather than creating highly customized objects which have complex modification restrictions? [Matt>] I agree, this approach is not scalable. The general rule is that fo= r DNS-redirection, only the HostMetadata object can be referenced by a requ= est router. Any metadata properties which are added and need to be availabl= e at request-routing time should be restricted to the HostMetadata object. = I think we could consider relaxing the restrictions on the PathMetadata obj= ect and allow the operator to choose which properties to place in each obje= ct. Will look into this further. - I assume that the inheritance model requires that PathMatch objects must match the path of all PathMatch objects above it in the hierarchy? i.e., I cannot add a PathMatch for "/bar/baz" inside a PathMetadata whose PathMatch was for "/foo"? It is probably worth stating explicitly? [Matt>] I don't think this is a requirement. The interface doesn't break if= someone adds what is effectively an unreachable child node. In practice it= should be avoided and we could add a note stating so. How are ambiguous patterns (e.g., "/*/foo/*") handled? Are there defined restrictions on the PathMatch objects to guarantee that all lookups will be deterministic? [Matt>] I don't think we've specified the exact behavior of the regex. This= will need to be added. - In the ACLRule object, if you can only have either an allow or a deny Property but not both, and the ACLRule list can only have either Location or TimeWindow properties but not both, it is not clear that much is gained by combining them into the same ACL and ACLRule objects? In the future, if new types of ACLs are added, would we modify these existing objects (and rev the CDNI Metadata RFC), or just add separate object definitions? [Matt>] Using a common ACL and ACLRule definitions only avoids redundancy i= n the draft. A better description may have kept the TimeWindow ACL complete= ly separate from the Location ACL (separate object definitions). If more me= tadata properties fit the "ACL" model, then they should be added alongside = TimeWindow and Location. The reuse of object definitions, in this case, does not seem to buy us anything? Defining separate LocationACL/LocationACLRule objects and TimeWindowACL/TimeWindowACLRule objects, where allow/deny is just an attribute/property would result in essentially the same implementation, but without the interdependendies, which would simplify future revisions? [Matt>] Agree. - In the Property definitions, I assume that the "key" is the term that follows the "Property:" tag, and that the "Description:" and "Type:" indented below describe the "value"? [Matt>] Correct. It was not clear to me what the "Mandatory:" tag implied? Mandatory to specify the Property in every object? Mandatory to implement support for the Property? or Mandatory to enforce the Property? It might be useful to explicitly define Mandatory? [Matt>] Will need to add some definition of Mandatory to the text before we= start using it. Mandatory means that that property must be defined in the = metadata for a piece of content - there is no default value. - In the HostMatch object, the hostname Property is defined as a String? Should there be Pattern support for hostnames? Also, does hostnames support both IP and DNS values? Also, does the hostname support a URI prefix that should be matched as part of the hostname, and not be included in the PathMatch? [Matt>] We debated whether or not to allow patterns in hostnames and decide= d against it. Ben can provide some of the background there. Yes, the hostna= me should support both IP an DNS values. No, the hostname does not include = any other part of the URI. Will need to add some clarification on the hostn= ame to the draft. - For Lists of objects, I did not see a specific ordering defined? Is there a way to enforce ordering? [Matt>] I'm not sure I understand your question. All lists are ordered. Can= you clarify? - With respect to extensibility, can an "x-" object be added to any other object, or are there restrictions on where a new custom object may be added into the hierarchy? [Matt>] An "x-" object can be added anywhere. Can I add a new ACL type? Can I add a new pattern matching option to the HostMatch and/or PathMatch objects (fundamentally changing the way hosts and paths are matched)? Can I add new types of location algorithms (e.g., GPS coordinates or zip code) to the Location object? Or is it intended more for just creating a new hierarchy under the Delivery object? [Matt>] It is intended for adding new metadata properties, however it could= be used for changing the structure of the metadata tree or changing how we= do path matches as you suggest. - With respect to the "ignorable" Property, does that affect the entire parent object to which it is added? If it is a Property itself (rather than an attribute of a Property), then does that require a wrapper object around the actual Property and the "ingnorable" Property, for all new Properties? Should it be a standard attribute like Mandatory? [Matt>] Yes, the ignorable property affects the entire object and all the o= bjects it contains. The "ignorable" property can be thought of as an attrib= ute. In the XML encoding, it would likely be an attribute (and not an eleme= nt). In JSON, yes, it can lead to wrapper object. - Is there a way for the client to request metadata for a given URI, rather than recursively checking and requesting PathMetadata? Doesn't this lead to alot of lookups (even local cache lookups) for each request, to find all of the applicable PathMetadata? Are there optimizations for local cache lookup? [Matt>] No, there's no way to get the metadata for a specific URL without t= raversing the tree. This approach enforces cacheability. As for local looku= ps, it's up to the CDN how it store metadata internally. The local lookup s= peed is independent of the metadata interface speed. Note: I have also uploaded an updated version of my draft: http://tools.ietf.org/html/draft-ma-cdni-metadata-03 [Matt>] Thanks, I will check it out. thanx. -- Kevin J. Ma From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Matt Caul= field (mcaulfie) Sent: Monday, July 09, 2012 3:45 PM To: cdni@ietf.org Cc: Ben Niven-Jenkins (ben@velocix.com) Subject: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni-metadata-00) Hi everyone, As we announced in April, a group of us (Ben Niven-Jenkins, Kent Leung, Rob= Murray, Grant Watson, and I) have been working on a merge of two of the CD= NI metadata interface proposals: - draft-caulfield-cdni-metadata-core-00 - draft-jenkins-cdni-metadata-00 The merged draft has now been submitted: http://tools.ietf.org/html/draft-c= jlmw-cdni-metadata-00 We will be presenting on this draft in Vancouver. Any feedback on the list = is also appreciated. Thanks, Matt --_000_166EBB70C264A9479E459B01B1BA6C9201F7B3xmbalnx03ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kevin,

 

Thank you for the comments, please see= my responses inline below.

 

Regards,

Matt

 

From: Kevin J = Ma [mailto:kevin.ma@azukisystems.com]
Sent: Monday, July 16, 2012 4:40 PM
To: Matt Caulfield (mcaulfie); cdni@ietf.org
Cc: Ben Niven-Jenkins (ben@velocix.com)
Subject: RE: New Metadata Interface Draft (draft-cjlmw-cdni-metadata= -00)

 

Hi Matt,

 

  A couple of initial comments/questions about the me= rged draft:

 

  - I do not understand the need for a heirarchical s= eparation of the

    Acquisition and Delivery objects? = Why is the property "key" not

    sufficient for designating the function= of the metadata?

[Matt>] The separation w= as created to categorize metadata properties. It’s not essential. It = may be useful if one server in a CDN is delivery a piece of content and another server is acquiring. The acquisition server could limit itself= to looking at the acquisition metadata while the delivery server could lim= it itself to looking at the delivery metadata. Would you suggest removing t= his distinction?

 

    Though it could be argued that these ar= e logically different

    functions, the extra layer seems unnece= ssary, and introduces some

    complexity to the inheritance model?

[Matt>] I don’t th= ink that the extra layer introduces any additional complexity. In our model= , objects can contain objects which can contain objects, the delivery/acqui= sition objects aren’t a special case.

 

    With inheritance-based override, can a = lower level PathMetadata

    object override just an Auth List, or d= oes it have to replace the

    entire Delivery object?  Does it h= ave to place the Auth List

    inside a lower level Delivery object, o= r can it just define a new

    Auth List with no Delivery object wrapp= er?  Is there a concept of

    leaf vs. branch objects for override pu= rposes?

[Matt>] Any object at an= y level can be overridden. So yes, just the Auth list could be overridden, = there is no need to override the entire delivery object. Yes, the schema must be preserved – so to override the auth list it would= be wrapped by a delivery object. No, there is no concept of leaf vs. branc= h. Based on your comment, I think we could spend more time on the descripti= on of inheritance.

 

    In general, if there are an arbitrary n= umber of levels below each

    object, and an arbitrary number of leve= ls of PathMetadata which

    may contain objects with arbitrary leve= ls of metadata which may

    override previous levels, is there a ne= ed to check that duplicate

    Metadata do not exist within a giv= en subtree, and/or should that

    restriction be stated explicity?

[Matt>] I’m not su= re what you mean by duplicate metadata. Each PathMetadata object defines a = bunch of metadata properties, each one is unique. Each PathMetadata object either inherits or overrides the metadata properties of its parent.=

 

  - I see that the PathMetadata defines some restrict= ions to what it

    may contain, however, this does not see= m like a scalable method of

    managing object restrictions.  As = we move forward and more vendor

    specific metadata are defined, managing= metadata collisions using

    the such a method seems complex, in tha= t the CDNI Metadata RFC

    could need to be continuously updated t= o add more restrictions.

    It would be nice if there was a general= set of rules for how and

    where to define new metadata, rather th= an creating highly

    customized objects which have complex m= odification restrictions?

[Matt>] I agree, this ap= proach is not scalable. The general rule is that for DNS-redirection, only = the HostMetadata object can be referenced by a request router. Any metadata properties which are added and need to be available at reques= t-routing time should be restricted to the HostMetadata object. I think we = could consider relaxing the restrictions on the PathMetadata object and all= ow the operator to choose which properties to place in each object. Will look into this further.

 

  - I assume that the inheritance model requires that= PathMatch

    objects must match the path of all Path= Match objects above it in

    the hierarchy?  i.e., I cannot add= a PathMatch for "/bar/baz"

    inside a PathMetadata whose PathMatch w= as for "/foo"?  It is

    probably worth stating explicitly?=

[Matt>] I don’t th= ink this is a requirement. The interface doesn’t break if someone add= s what is effectively an unreachable child node. In practice it should be avoided and we could add a note stating so.

 

    How are ambiguous patterns (e.g., "= ;/*/foo/*") handled?  Are there

    defined restrictions on the PathMatch o= bjects to guarantee that

    all lookups will be deterministic?=

[Matt>] I don’t th= ink we’ve specified the exact behavior of the regex. This will need t= o be added.

 

  - In the ACLRule object, if you can only have eithe= r an allow or a

    deny Property but not both, and the ACL= Rule list can only have

    either Location or TimeWindow propertie= s but not both, it is not

    clear that much is gained by combining = them into the same ACL and

    ACLRule objects?  In the future, i= f new types of ACLs are added,

    would we modify these existing objects = (and rev the CDNI Metadata

    RFC), or just add separate object defin= itions?

[Matt>] Using a common A= CL and ACLRule definitions only avoids redundancy in the draft. A better de= scription may have kept the TimeWindow ACL completely separate from the Location ACL (separate object definitions). If more metadata prop= erties fit the “ACL” model, then they should be added alongside= TimeWindow and Location.

 

    The reuse of object definitions, in thi= s case, does not seem to

    buy us anything?  Defining separat= e LocationACL/LocationACLRule

    objects and TimeWindowACL/TimeWindowACL= Rule objects, where

    allow/deny is just an attribute/propert= y would result in

    essentially the same implementation, bu= t without the

    interdependendies, which would simplify= future revisions?

[Matt>] Agree.

 

  - In the Property definitions, I assume that the &q= uot;key" is the term

    that follows the "Property:" = tag, and that the "Description:" and

    "Type:" indented below descri= be the "value"?

[Matt>] Correct.

 

    It was not clear to me what the "M= andatory:" tag implied?

    Mandatory to specify the Property in ev= ery object?  Mandatory to

    implement support for the Property?&nbs= p; or Mandatory to enforce the

    Property?  It might be useful to e= xplicitly define Mandatory?

[Matt>] Will need to add= some definition of Mandatory to the text before we start using it. Mandato= ry means that that property must be defined in the metadata for a piece of content – there is no default value.

 

  - In the HostMatch object, the hostname Property is= defined as a

    String?  Should there be Pattern s= upport for hostnames?  Also,

    does hostnames support both IP and DNS = values?  Also, does the

    hostname support a URI prefix that shou= ld be matched as part of

    the hostname, and not be included in th= e PathMatch?

[Matt>] We debated wheth= er or not to allow patterns in hostnames and decided against it. Ben can pr= ovide some of the background there. Yes, the hostname should support both IP an DNS values. No, the hostname does not include any other= part of the URI. Will need to add some clarification on the hostname to th= e draft.

 

  - For Lists of objects, I did not see a specific or= dering defined?

    Is there a way to enforce ordering?

[Matt>] I’m not su= re I understand your question. All lists are ordered. Can you clarify?=

 

  - With respect to extensibility, can an "x-&qu= ot; object be added to any

    other object, or are there restrictions= on where a new custom

    object may be added into the hierarchy?=

[Matt>] An “x-R= 20; object can be added anywhere.

 

    Can I add a new ACL type?  Can I a= dd a new pattern matching option

    to the HostMatch and/or PathMatch objec= ts (fundamentally changing

    the way hosts and paths are matched)?&n= bsp; Can I add new types of

    location algorithms (e.g., GPS coordina= tes or zip code) to the

    Location object?  Or is it intende= d more for just creating a new

    hierarchy under the Delivery object?

[Matt>] It is intended f= or adding new metadata properties, however it could be used for changing th= e structure of the metadata tree or changing how we do path matches as you suggest.

 

  - With respect to the "ignorable" Propert= y, does that affect the

    entire parent object to which it is add= ed?  If it is a Property

    itself (rather than an attribute of a P= roperty), then does that

    require a wrapper object around the act= ual Property and the

    "ingnorable" Property, for al= l new Properties?  Should it be a

    standard attribute like Mandatory?=

[Matt>] Yes, the ignorab= le property affects the entire object and all the objects it contains. The = “ignorable” property can be thought of as an attribute. In the XML encoding, it would likely be an attribute (and not an element). In= JSON, yes, it can lead to wrapper object.

 

  - Is there a way for the client to request metadata= for a given URI,

    rather than recursively checking and re= questing PathMetadata?

    Doesn't this lead to alot of lookups (e= ven local cache lookups)

    for each request, to find all of the ap= plicable PathMetadata?

    Are there optimizations for local cache= lookup?

[Matt>] No, there’= s no way to get the metadata for a specific URL without traversing the tree= . This approach enforces cacheability. As for local lookups, it’s up to the CDN how it store metadata internally. The local lookup speed is = independent of the metadata interface speed.

 

  Note: I have also uploaded an updated version of my= draft:

        http://too= ls.ietf.org/html/draft-ma-cdni-metadata-03 

[Matt>] Thanks, I will c= heck it out.

 

thanx.

 

--  Kevin J. Ma

 

 

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Matt Caulfield (mcau= lfie)
Sent: Monday, July 09, 2012 3:45 PM
To: cdni@ietf.org
Cc: Ben Niven-Jenkins (ben@veloci= x.com)
Subject: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni-metad= ata-00)

 

Hi everyone,

 

As we announced in April, a group of us (= Ben Niven-Jenkins, Kent Leung, Rob Murray, Grant Watson, and I) have been w= orking on a merge of two of the CDNI metadata interface proposals:

-   &nbs= p;   draft-caulfield-cdni-metadata-cor= e-00

-   &nbs= p;   draft-jenkins-cdni-metadata-00

 

The merged draft has now been submitted: = http://tools.ietf.org/html/draft-cjlmw-cdni-metadata-00

 

We will be presenting on this draft in Va= ncouver. Any feedback on the list is also appreciated.

 

Thanks,

Matt

 

 

       = ;            &n= bsp;            = ;            &n= bsp;            = ;        

--_000_166EBB70C264A9479E459B01B1BA6C9201F7B3xmbalnx03ciscocom_-- From ben@niven-jenkins.co.uk Tue Jul 17 13:05:45 2012 Return-Path: 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 354DC11E8087 for ; Tue, 17 Jul 2012 13:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.326 X-Spam-Level: X-Spam-Status: No, score=-102.326 tagged_above=-999 required=5 tests=[AWL=0.273, 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 WDhDI6zhYDfO for ; Tue, 17 Jul 2012 13:05:43 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3DA21F85FD for ; Tue, 17 Jul 2012 13:05:43 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginmedia.com ([86.14.227.47] helo=[192.168.0.3]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SrE2P-0005b5-IC; Tue, 17 Jul 2012 21:06:30 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <291CC3F9E50E7641901A54E85D0977C65326E2AA7F@MAILR002.mail.lan> Date: Tue, 17 Jul 2012 21:06:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <166EBB70C264A9479E459B01B1BA6C9201B060@xmb-aln-x03.cisco.com> <291CC3F9E50E7641901A54E85D0977C65326E2AA7F@MAILR002.mail.lan> To: Kevin J Ma X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "Ben Niven-Jenkins \(ben@velocix.com\)" , "cdni@ietf.org" Subject: Re: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni-metadata-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 20:05:45 -0000 Hi Kevin, Thanks for reading the draft, some good questions. My opinion inline. On 16 Jul 2012, at 21:40, Kevin J Ma wrote: > Hi Matt, > =20 > A couple of initial comments/questions about the merged draft: > =20 > - I do not understand the need for a heirarchical separation of the > Acquisition and Delivery objects? Why is the property "key" not > sufficient for designating the function of the metadata? This is a good question and something we discussed at length amongst the = authors but probably don't really talk about in the draft. We discussed a lot the trade offs between embedding all CDNI metadata = properties together versus splitting some out into different object that = could be independently cached/retrieved. We decided not to try to optimise too early so we took an approach of = allowing any object to be embedded or independently addressable. This = leads to the data model being slightly more convoluted and it can = certainly be optimised a bit IMO. But we decided on an approach where we = first had a stable/agreed model with the WG and then we could revisit it = see what optimisations make sense. > =20 > Though it could be argued that these are logically different > functions, the extra layer seems unnecessary, and introduces some > complexity to the inheritance model? > =20 > With inheritance-based override, can a lower level PathMetadata > object override just an Auth List, or does it have to replace the > entire Delivery object? This is an area where we need to flesh out the specification and not one = we've fully fleshed out yet. My current thinking is to only have to specify those properties which = you want to override compared to the parent PathMetadata object.=20 > Does it have to place the Auth List > inside a lower level Delivery object, or can it just define a new > Auth List with no Delivery object wrapper? Currently yes but when we revisit the data model to look for = optimisations this is a good candidate. > Is there a concept of > leaf vs. branch objects for override purposes? I'm not exactly sure what you mean by leaf vs branch > =20 > In general, if there are an arbitrary number of levels below each > object, and an arbitrary number of levels of PathMetadata which > may contain objects with arbitrary levels of metadata which may > override previous levels, is there a need to check that duplicate > Metadata do not exist within a given subtree, and/or should that > restriction be stated explicity? I don't think there's a need to check for duplicates explicitly as they = represent different content items/paths/hosts but a uCDN may want to do = so as part of optimising it's representation of the metadata but that's = an implementation decision. > =20 > - I see that the PathMetadata defines some restrictions to what it > may contain, however, this does not seem like a scalable method of > managing object restrictions. I disagree. It is an editorial device to avoid repeating definitions for = the same properties with identical text in multiple places in the = document. > As we move forward and more vendor > specific metadata are defined, managing metadata collisions using > the such a method seems complex, in that the CDNI Metadata RFC > could need to be continuously updated to add more restrictions. > It would be nice if there was a general set of rules for how and > where to define new metadata, rather than creating highly > customized objects which have complex modification restrictions? We're not defining complex modification restrictions we're ruling out of = scope those properties which simply do not make sense to include in a = PathMetadata object. How we handle vendor extensions is a separate issue, that I will admit = needs some more work and the ideas in the current draft need refinement. However both HostMetadata & PathMetadata objects would allow vendor = extensions and it is up to the specification for those extensions to = decide whether the appropriate place to place their extension is within = the HostMetdata, PathMetadata, or both objects. > =20 > - I assume that the inheritance model requires that PathMatch > objects must match the path of all PathMatch objects above it in > the hierarchy? i.e., I cannot add a PathMatch for "/bar/baz" > inside a PathMetadata whose PathMatch was for "/foo"? It is > probably worth stating explicitly? Yes. In your example there would not be a URL a client could request = that would ever match both path patterns and so the CDNI Metdata = associated with the /foo path would never get applied. I have no problem = stating that more explicitly in the next version. =20 > =20 > How are ambiguous patterns (e.g., "/*/foo/*") handled? Are there > defined restrictions on the PathMatch objects to guarantee that > all lookups will be deterministic? IMO The PathMatches are ordered and the first match wins, so in the case = of ambiguous/overlapping patterns the uCDN needs to ensure it has = ordered the PathMatches appropriately to get the desired deterministic = behaviour. =20 > =20 > - In the ACLRule object, if you can only have either an allow or a > deny Property but not both, and the ACLRule list can only have > either Location or TimeWindow properties but not both, it is not > clear that much is gained by combining them into the same ACL and > ACLRule objects? In the future, if new types of ACLs are added, > would we modify these existing objects (and rev the CDNI Metadata > RFC), or just add separate object definitions? I think this is an example of where in trying to explain the concept of = ACLs earlier on in the document we carried that abstract model maybe a = little too far into the encoding. We should re-look at that part to see = if we can clean it up along the lines you propose. =20 > =20 > The reuse of object definitions, in this case, does not seem to > buy us anything? Defining separate LocationACL/LocationACLRule > objects and TimeWindowACL/TimeWindowACLRule objects, where > allow/deny is just an attribute/property would result in > essentially the same implementation, but without the > interdependendies, which would simplify future revisions? > =20 > - In the Property definitions, I assume that the "key" is the term > that follows the "Property:" tag, and that the "Description:" and > "Type:" indented below describe the "value"? Correct. > =20 > It was not clear to me what the "Mandatory:" tag implied? > Mandatory to specify the Property in every object? Mandatory to > implement support for the Property? or Mandatory to enforce the > Property? It might be useful to explicitly define Mandatory? Mandatory to specify the property in every object. My thinking is that for a given delivery protocol there will be a = mandatory set of properties/capabilities a dCDN is expected to have. If = the dCDN cannot support the required "flavour" of the delivery protocol, = it cannot perform the delivery (and would advertise that as part of its = capabilities etc.).=20 Generally in the CDNI Metadata specification, if a property is mandatory = to specify in an object it is because it is essential for the delivery = of that delivery protocol. For a given delivery protocol there would need to be a separate = specification (IMO) that specified the mandatory to implement/understand = CDNI Metadata properties in order for a dCDN to claim "compliance" with = a given delivery protocol. > =20 > - In the HostMatch object, the hostname Property is defined as a > String? Should there be Pattern support for hostnames? I'd need to think about that a bit more first but I think there might be = some value to that. > Also, > does hostnames support both IP and DNS values? I'm not sure of the use case for IP values as clients connecting to CDNs = aren't typically given a URL with an IP address as a hostname. > Also, does the > hostname support a URI prefix that should be matched as part of > the hostname, and not be included in the PathMatch? No, the hostname is essentially the HTTP Host: header. All URL prefixes = are via PathMetadata. > =20 > - For Lists of objects, I did not see a specific ordering defined? > Is there a way to enforce ordering? Lists are ordered. In JSON they would be an array with N entries, with = index[0] being first and index[N-1] being last. > =20 > - With respect to extensibility, can an "x-" object be added to any > other object, or are there restrictions on where a new custom > object may be added into the hierarchy? It's up to whoever specifies the "x-" property to define which objects = it applies to and what restrictions apply to it. I think this is an area of the draft that isn't fully fleshed out and = needs more thought and your input is welcome. My current thinking is to split extensions clearly into "mandatory" and = "optional" categories which could for example be expressed by having a = property of "mandatory" which contained a dictionary of 'mandatory' = extensions and likewise for optional extensions. The basic rule would be if there is a property in the "mandatory" = category that you don't understand then you cannot perform the content = delivery. You can still perform the delivery if there are "optional" = extensions you don't understand. But like I say it's an area I think we definitely need to do some more = thinking, refinement etc of. > =20 > Can I add a new ACL type? Can I add a new pattern matching option > to the HostMatch and/or PathMatch objects (fundamentally changing > the way hosts and paths are matched)? Can I add new types of > location algorithms (e.g., GPS coordinates or zip code) to the > Location object? Or is it intended more for just creating a new > hierarchy under the Delivery object? IMO you can potentially do all those things. I think if you had lots of = them as mandatory extensions you might be better off minting a vendor = specific delivery protocol identifier to give dCDNs a heads-up that they = needed to support a lot of vendor/extension-specific capabilities, but = there are certainly other ways to do that too (depending how the = capabilities advertisement interface evolves). > =20 > - With respect to the "ignorable" Property, does that affect the > entire parent object to which it is added? If it is a Property > itself (rather than an attribute of a Property), then does that > require a wrapper object around the actual Property and the > "ingnorable" Property, for all new Properties? Should it be a > standard attribute like Mandatory? > =20 > - Is there a way for the client to request metadata for a given URI, > rather than recursively checking and requesting PathMetadata? > Doesn't this lead to alot of lookups (even local cache lookups) > for each request, to find all of the applicable PathMetadata? > Are there optimizations for local cache lookup? This partly goes back to optimising the data model once we have it = stable. But also in reality I don't expect the layers of hierarchical = metadata to extend to that many and if a dCDN is being selected one = would hope that it is doing a fairly decent amount of delivery for that = domain/uCDN and so it would need most of that portion of the metadata = tree anyway. So the initial lookup from the "root" of the CDNI Metadata tree to the = PathMetadata for the domain/site is non optimal but the results are = highly cacheable and so any penalty (assuming the dCDN doesn't prefetch = the top couple of tiers of objects anyway) is only on first retrieval = (from that point there's nothing to stop the dCDN pre-validating cache = freshness for objects to make sure it always has a fresh version in it's = cache). > =20 > Note: I have also uploaded an updated version of my draft: > http://tools.ietf.org/html/draft-ma-cdni-metadata-03=20 Thanks. I'll give it a read when I get a chance. Ben > =20 > thanx. > =20 > -- Kevin J. Ma > =20 > =20 > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Matt Caulfield (mcaulfie) > Sent: Monday, July 09, 2012 3:45 PM > To: cdni@ietf.org > Cc: Ben Niven-Jenkins (ben@velocix.com) > Subject: [CDNi] New Metadata Interface Draft = (draft-cjlmw-cdni-metadata-00) > =20 > Hi everyone, > =20 > As we announced in April, a group of us (Ben Niven-Jenkins, Kent = Leung, Rob Murray, Grant Watson, and I) have been working on a merge of = two of the CDNI metadata interface proposals: > - draft-caulfield-cdni-metadata-core-00 > - draft-jenkins-cdni-metadata-00 > =20 > The merged draft has now been submitted: = http://tools.ietf.org/html/draft-cjlmw-cdni-metadata-00 > =20 > We will be presenting on this draft in Vancouver. Any feedback on the = list is also appreciated. > =20 > Thanks, > Matt > =20 > =20 > =20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From ben@niven-jenkins.co.uk Tue Jul 17 13:20:41 2012 Return-Path: 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 D2C5321F86A2 for ; Tue, 17 Jul 2012 13:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.38 X-Spam-Level: X-Spam-Status: No, score=-102.38 tagged_above=-999 required=5 tests=[AWL=0.219, 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 xRR-NGxLfNVR for ; Tue, 17 Jul 2012 13:20:41 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id CFC1721F8663 for ; Tue, 17 Jul 2012 13:20:40 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginmedia.com ([86.14.227.47] helo=[192.168.0.3]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SrEGu-0003UI-EB; Tue, 17 Jul 2012 21:21:28 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <166EBB70C264A9479E459B01B1BA6C9201F7B3@xmb-aln-x03.cisco.com> Date: Tue, 17 Jul 2012 21:21:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2806A716-8B71-4939-9C85-9BE6EBD81315@niven-jenkins.co.uk> References: <166EBB70C264A9479E459B01B1BA6C9201B060@xmb-aln-x03.cisco.com> <291CC3F9E50E7641901A54E85D0977C65326E2AA7F@MAILR002.mail.lan> <166EBB70C264A9479E459B01B1BA6C9201F7B3@xmb-aln-x03.cisco.com> To: "Matt Caulfield (mcaulfie)" X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "Ben Niven-Jenkins \(ben@velocix.com\)" , "cdni@ietf.org" Subject: [CDNi] Host pattern matches in CDNI Metadata (was Re: New Metadata Interface Draft (draft-cjlmw-cdni-metadata-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 20:20:41 -0000 Kevin, Matt, Just zoning in on one comment On 17 Jul 2012, at 21:01, Matt Caulfield (mcaulfie) wrote: > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]=20 > - In the HostMatch object, the hostname Property is defined as a > String? Should there be Pattern support for hostnames? Also, > does hostnames support both IP and DNS values? Also, does the > hostname support a URI prefix that should be matched as part of > the hostname, and not be included in the PathMatch? > [Matt>] We debated whether or not to allow patterns in hostnames and = decided against it. Ben can provide some of the background there. Yes, = the hostname should support both IP an DNS values. No, the hostname does = not include any other part of the URI. Will need to add some = clarification on the hostname to the draft. Off hand I can't remember the obviously good reasons I used to convince = Matt it was a bad idea. I remember we discussed whether to allow a list of hosts in a = HostMetadata and what occurs to me with that is that it doesn't buy you = much over having multiple HostMetadata objects linking to the same = PathMetadata objects but I'm sure I had other reasons for not doing it. Having a special pattern to say all subdomains of this host might be = useful but I need to think about it more in case it's ruled out by one = of the previous reasons that I can't remember right now. Ben From RMurray@velocix.com Wed Jul 18 01:36:06 2012 Return-Path: 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 8B54521F8766 for ; Wed, 18 Jul 2012 01:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 ms8j5xHG8u+m for ; Wed, 18 Jul 2012 01:36:05 -0700 (PDT) Received: from owa.velocix.com (mail-out2.velocix.com [81.134.152.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3E07021F8760 for ; Wed, 18 Jul 2012 01:36:05 -0700 (PDT) Received: from EXB04CAM.corp.velocix.com ([169.254.1.40]) by exc01cam.corp.velocix.com ([172.18.4.76]) with mapi id 14.02.0247.003; Wed, 18 Jul 2012 09:36:43 +0100 From: Rob Murray To: Ben Niven-Jenkins , "Matt Caulfield (mcaulfie)" Thread-Topic: [CDNi] Host pattern matches in CDNI Metadata (was Re: New Metadata Interface Draft (draft-cjlmw-cdni-metadata-00)) Thread-Index: AQHNZMB1Veutwzbc1UKt2u1mamYhlg== Date: Wed, 18 Jul 2012 08:36:53 +0000 Message-ID: In-Reply-To: <2806A716-8B71-4939-9C85-9BE6EBD81315@niven-jenkins.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.18.0.168] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Host pattern matches in CDNI Metadata (was Re: New Metadata Interface Draft (draft-cjlmw-cdni-metadata-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 08:36:06 -0000 On 17/07/2012 21:21, "Ben Niven-Jenkins" wrote: >Kevin, Matt, > >Just zoning in on one comment > >On 17 Jul 2012, at 21:01, Matt Caulfield (mcaulfie) wrote: >> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >> - In the HostMatch object, the hostname Property is defined as a >> String? Should there be Pattern support for hostnames? Also, >> does hostnames support both IP and DNS values? Also, does the >> hostname support a URI prefix that should be matched as part of >> the hostname, and not be included in the PathMatch? >> [Matt>] We debated whether or not to allow patterns in hostnames and >>decided against it. Ben can provide some of the background there. Yes, >>the hostname should support both IP an DNS values. No, the hostname does >>not include any other part of the URI. Will need to add some >>clarification on the hostname to the draft. > >Off hand I can't remember the obviously good reasons I used to convince >Matt it was a bad idea. I think there were a couple of reasons, neither of them killer arguments but they leant us towards the current position... - the HostIndex isn't ordered between CDNs, any given downstream request-router or surrogate may have a HostIndex assembled from several upstreams. If patterns aren't allowed in the HostMatch, either two CDNs are advertising the same host or not. There's no need for any more complicated disambiguation. - in an implementation, if patterns aren't allowed, the requested hostname can be hashed to do the HostIndex lookup, there's no need to do a linear search matching patterns across all known sites for every request. (I'm sure there are ways to make the search more efficient, but this keeps it simple.) Another thought was that domains tend to be split for a reason - it seems likely that different subdomains will have different metadata properties, though we have no data to support that. Rob. > >I remember we discussed whether to allow a list of hosts in a >HostMetadata and what occurs to me with that is that it doesn't buy you >much over having multiple HostMetadata objects linking to the same >PathMetadata objects but I'm sure I had other reasons for not doing it. > >Having a special pattern to say all subdomains of this host might be >useful but I need to think about it more in case it's ruled out by one of >the previous reasons that I can't remember right now. > >Ben > > >_______________________________________________ >CDNi mailing list >CDNi@ietf.org >https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Wed Jul 18 06:13:25 2012 Return-Path: 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 60E2321F858E for ; Wed, 18 Jul 2012 06:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 YHFy9pIgzgUY for ; Wed, 18 Jul 2012 06:13:23 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 880AA21F8629 for ; Wed, 18 Jul 2012 06:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=4114; q=dns/txt; s=iport; t=1342617254; x=1343826854; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=DPc1qF+58KOvG7GtyYbump/jhGw1EboAh2lGfXyCt+Y=; b=gqIRHZD2bSWDoQI1fldLv0c7Z2G+oUG9wZTZfRrA0tOE3D4mO8XjKct5 sjzCq2JPAD60KZUyjkogqCSj8j/ZxUbx81nQyATETey8IixIYJP4L4oXc V+UbyBfmOYzjYln9R+DtX4bOiE26upkWUxSTFkfNgpSlpyV+V4P04PFGw A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAIK1BlCtJV2a/2dsb2JhbABFuTqBB4IgAQEBAwEBAQEPASc0GwIBCDYQJwslAgQTCRmHZQYLnV+gHYtAChCFVWADlUSBE4l3gxmBZoJfgV8 X-IronPort-AV: E=Sophos;i="4.77,610,1336348800"; d="scan'208";a="102804993" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 18 Jul 2012 13:14:12 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6IDECa3001380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 18 Jul 2012 13:14:12 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.17]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Wed, 18 Jul 2012 08:14:11 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: I-D Action: draft-lelouedec-cdni-request-routing-00.txt Thread-Index: AQHNZOc4lDL9eO+7BkC/VTJJ7ud0wg== Date: Wed, 18 Jul 2012 13:14:11 +0000 Message-ID: <3FBC9023-91C7-4F14-AFA8-C57B27301012@cisco.com> References: <20120709165434.9858.81618.idtracker@ietfa.amsl.com> In-Reply-To: <20120709165434.9858.81618.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.198] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19048.005 x-tm-as-result: No--47.925800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <503583244E4D1F4297230C13CE777D7C@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 13:13:25 -0000 Authors, This document spends a lot of time proposing to split the "Request Routing"= interface into two interfaces. In particular, its conclusions include: " We also recommend to review the charter of the CDNI WG, in particular to replace the following objective: o "WG Creation + 18 months: Submit specification of the CDNI Request Routing protocol to IESG as Proposed Standard" by the two following objectives: o "WG Creation + 18 months: Submit specification of the CDNI Routing interface to IESG as Proposed Standard" o "WG Creation + 18 months: Submit specification of the CDNI Downstream Resource Identifier Signaling (DRIS) Interface to IESG as Proposed Standard" " Can you guys consider the fact that the charter has already been updated tw= o months ago (http://www.ietf.org/mail-archive/web/cdni/current/msg00989.ht= ml) to split the Request Routing into 2 interfaces and already reads: " o Dec 2012 - Submit specification of the CDNI Request Routing/Redirection = interface to IESG as Proposed Standard ... o Jun 2013 - Submit specification of the CDNI Request Routing/Footprint & = Capabilities Advertisement interface to IESG as Proposed Standard " Does this not basically already address your point? Cheers Francois On 9 Jul 2012, at 18:54, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : CDNI Request Routing > Author(s) : Yannick Le Louedec > Anne Marrec > Gilles Bertrand > Marcin Pilarski > Filename : draft-lelouedec-cdni-request-routing-00.txt > Pages : 30 > Date : 2012-07-09 >=20 > Abstract: > The present document proposes to clarify the CDNI Request Routing > interface introduced in [I-D.ietf-cdni-framework] and [I-D.ietf-cdni- > problem-statement], as well as related terminology. >=20 > In particular the present document proposes to split the CDNI Request > Routing interface into two separate interfaces with clearer roles, > named respectively CDNI Routing interface and CDNI Downstream > Resource Identifier Signaling interface (CDNI DRIS interface). >=20 > This part of the CDN interconnection framework the IETF has been > referring to so far with the term "CDNI Request Routing" is just > another routing, signaling and forwarding problem in a long series of > the telecommunication history. For example, one can draw a direct > analogy between the IP/MPLS-TE framework and the CDN interconnection > framework. >=20 > In addition, this document recommends that the specification of ALL > CDN interconnection interfaces in the scope of the CDNI IETF WG > relies on the equivalent concept to IP prefix for CDN > interconnection, named 'contentRequestScope'. This highly useful and > powerful concept SHALL be used to simplify the specification of ALL > CDN interconnection interfaces, as well as to ensure performance and > scalability in CDN interconnection. >=20 > All these proposals can be smoothly integrated in the WG drafts, > especially [I-D.ietf-cdni-framework] and > [I-D.ietf-cdni-requirements], as they essentially propose (useful) > clarifications of the existing framework. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-routing >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 flefauch@cisco.com Wed Jul 18 09:51:33 2012 Return-Path: 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 3760121F86DC for ; Wed, 18 Jul 2012 09:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.411 X-Spam-Level: X-Spam-Status: No, score=-10.411 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 CKxT250em5zX for ; Wed, 18 Jul 2012 09:51:32 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0D16D21F86D6 for ; Wed, 18 Jul 2012 09:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=4632; q=dns/txt; s=iport; t=1342630343; x=1343839943; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=N7Xfnrol8b3Xp8CxLnOngGwn4qeFm4dVob4B+LSkOAI=; b=gl20MLoGAPfEZKkmZC7i3GN/ijFjzaS76e4prg4dZN+5P83l5QnF+tlN 13BTrHAGyIJ6l6o6GwQ7ErCfNQ+2NwquTu6ldKqLZ7hcGky46LamHlDX9 LZ5HsDS7biYkYlqk5UoRFByOjCIKmgbctJVIDhWpmcG3ZIQIoM0xam4dB U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKvoBlCtJV2b/2dsb2JhbABFhWqyMYEZgQeCIAEBAQQSARARRQwEAgEGEwQBAQMCIwMCAgIwFAEICAIEDgUJGYdrC512jRmTDoEgiiCFPTJgA5VEgRONEIFmgl8 X-IronPort-AV: E=Sophos;i="4.77,610,1336348800"; d="scan'208";a="103081736" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 18 Jul 2012 16:52:22 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6IGqM5K020281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Jul 2012 16:52:22 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.17]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Wed, 18 Jul 2012 11:52:22 -0500 From: "Francois Le Faucheur (flefauch)" To: =?utf-8?B?7LWc7YOc7IOB?= Thread-Topic: draft-choi-cdni-req-routing-redir-loop-prevention-00.txt Thread-Index: AQHNZQWyLUvS1S4KmUi9RTGzAxcReA== Date: Wed, 18 Jul 2012 16:52:21 +0000 Message-ID: <0CC51B43-4A45-4D66-A146-E5D0023E7216@cisco.com> References: <20120705135807.11011.78218.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.198] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19048.005 x-tm-as-result: No--50.456900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-ID: <877C5465A0A23643B8F4B6601736A899@cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] draft-choi-cdni-req-routing-redir-loop-prevention-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 16:51:33 -0000 SGVsbG8gVGFlc2FuZywNCg0KSnVzdCBoYWQgYSBxdWljayBsb29rIGF0IHlvdXIgZG9jdW1lbnQu IEhlcmUgYXJlIGEgZmV3IGVhcmx5IHF1ZXN0aW9ucyBhbmQgY29tbWVudHMuDQoNCjEpIEkgdGhp bmsgd2hhdCB5b3UgY2FsbCAiQ0ROLVByb3ZpZGVyLUlEIiBpcyBhY3R1YWxseSAoaSkgYSBkeW5h bWljIHJlY29yZCBvZiB0aGUgQ0ROcyBpbiB0aGUgQ0ROIHBhdGggKyBhICJUVEwiIGV4cHJlc3Nl ZCBpbiBudW1iZXIgb2YgcmVkaXJlY3Rpb24gaG9wcy4NCkknZCBzdWdnZXN0IHlvdSBnaXZlIGl0 IGFub3RoZXIgbmFtZSB0aGFuICJDRE4tUHJvdmlkZXItSUQiIGFzIHRoaXMgdGVuZCB0byBzdWdn ZXN0IGFuIGlkZW50aWZpZXIgZm9yIGEgc2luZ2xlIENETi4gUGVyaGFwcyB5b3UgY291bGQgY2Fs bCB0aGlzIHNvbWV0aGluZyBsaWtlIGEgIkNETiBQYXRoIFJlY29yZCIgb3IgIkNETiBwYXRoIuKA pg0KV2hlbiB5b3UgZ2l2ZSBhbiBleGFtcGxlIG9mICJDRE4gUGF0aCBSZWNvcmQiLCBJIHN1Z2dl c3QgeW91IHByb3ZpZGUgYW4gZXhhbXBsZSB0aGF0IGNvbnRhaW5zIG1vcmUgdGhhbiAxIENETiwg anVzdCB0byBtYWtlIGl0IGNsZWFyZXIuDQoNCjIpIEluIHRoZSBjYXNlIG9mIEhUVFAgSSBhbSB1 bmNsZWFyIGFzIHRvIHdoZXRoZXIgeXUgYXJlIHByb3Bvc2luZyB0byBoYXZlIHRoZSAiQ0ROIFBh dGggUmVjb3JkIiBjb252ZWV5ZWQgOg0KCShpKSBpbiBhIFRCRCBIVFRQIGhlYWRlciwgDQoJKGlp KSBpbnNpZGUgdGhlIFVSSSBob3N0bmFtZSwgb3INCgkoaWlpKSBpbnNpZGUgdGhlIFVSSSBxdWVy eSBzdHJpbmcNCg0KVGhlIHRleHQgOiAiRm9yIEhUVFAtIGJhc2VkIHJlZGlyZWN0aW9uLCB3ZSBk ZWZpbmUgYSBIVFRQIHJlcXVlc3Qgcm91dGluZyByZWRpcmVjdGlvbiBoZWFkZXIgIkNETi1Qcm92 aWRlci1JRCIgc3VnZ2VzdHMgKGkpLg0KVGhlIHRleHQgIkZvciBlYWNoIHN0ZXAgb2YgcmVkaXJl Y3Rpb24sIGl0IGlzIGF0dGFjaGVkIHRvIHRoZSBiZWdpbm5pbmcgb2YgdGhlIHByb3ZpZGVyIGRv bWFpbiBVUkwuIiBzdWdnZXN0cyAoaWkpLg0KVGhlIHRleHQgOiAicGVlci11Q0ROLmRDRE4xLm5l dC9jZG4uY3NwLmNvbT91Q0ROLVByb3ZpZGVyLUlEIiBzdWdnZXN0cyAoaWlpKS4NCg0KCQ0KMykg YWxnb3JpdGhtIGluIGNhc2Ugb2YgbG9vcCBkZXRlY3Rpb24uDQpZb3Ugc2F5Og0KIklmIGEgbG9v cCBpcyBkZXRlY3RlZCBhbmQgbXlzZWxmIGNhbiBzZXJ2ZSB0aGUgcmVxdWVzdCwgdGhlIHJlcXVl c3QNCiAgIGlzIHByb2Nlc3NlZCBpbiBteSBDRE4uICBGb3Igc29tZSByZWFzb24sIGlmIG15c2Vs ZiBjYW5ub3QgcHJvY2Vzcw0KICAgdGhlIHJlcXVlc3QsIGl0IGZpcnN0IGNoZWNrcyBhdmFpbGFi aWxpdHkgb2YgaXRzIHBhcmVudCBhbmQgdGhlbg0KICAgdUNETi4gIElmIG5vbmUgb2YgdGhlbSBz dWNjZWVkLCB0aGVuIHJlcXVlc3QgaXMgZGVuaWVkLg0KIg0KSWYgYSBsb29wIGlzIGRldGVjdGVk LCB0aGUgQ0ROIGRldGVjdGluZyB0aGUgbG9vcCBjYW4gZGVjaWRlIHRvIHNlcnZlIHRoZSByZXF1 ZXN0IGFzIHlvdSBzdWdnZXN0LCBvciBhcmd1YWJseSBjb3VsZCBkZWNpZGUgdG8gcGljayBhbiBh bHRlcm5hdGl2ZSBkQ0ROLiBJcyB0aGVyZSBhIHJlYXNvbiB5b3Ugc2VlbSB0byBleGNsdWRlIHRo YXQgb3B0aW9uPw0KDQoNCkNoZWVycw0KDQpGcmFuY29pcw0KDQo+IA0KPiANCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog7LWc7YOc7IOBIA0KPiBTZW50OiBUdWVzZGF5LCBK dWx5IDE3LCAyMDEyIDEyOjUwIEFNDQo+IFRvOiAnY2RuaUBpZXRmLm9yZycNCj4gU3ViamVjdDog Rlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtY2hvaS1jZG5pLXJlcS1yb3V0 aW5nLXJlZGlyLWxvb3AtcHJldmVudGlvbi0wMC50eHQNCj4gDQo+IERlYXIgYWxsLCAgDQo+IA0K PiBXZSBoYXZlIHVwbG9hZGVkIGEgbmV3IEktRCByZWxhdGVkIHRvICdDRE5JIFJlcXVlc3QgUm91 dGluZyBSZWRpcmVjdGlvbiB3aXRoIExvb3AgUHJldmVudGlvbicgYXMgYmVsb3cuICBXZSByZXF1 ZXN0IHlvdXIgcmV2aWV3IGFuZCBjb21tZW50cw0KPiANCj4gVGhhbmtzLCANCj4gVGFlc2FuZyBD aG9pDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KPiBTZW50 OiBUaHVyc2RheSwgSnVseSAwNSwgMjAxMiAxMDo1OCBQTQ0KPiBUbzog7LWc7YOc7IOBDQo+IENj OiBkai5raW1Aa3QuY29tDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtY2hvaS1jZG5pLXJlcS1yb3V0aW5nLXJlZGlyLWxvb3AtcHJldmVudGlvbi0wMC50eHQN Cj4gDQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWNob2ktY2RuaS1yZXEt cm91dGluZy1yZWRpci1sb29wLXByZXZlbnRpb24tMDAudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgVGFlc2FuZyBDaG9pIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVw b3NpdG9yeS4NCj4gDQo+IEZpbGVuYW1lOgkgZHJhZnQtY2hvaS1jZG5pLXJlcS1yb3V0aW5nLXJl ZGlyLWxvb3AtcHJldmVudGlvbg0KPiBSZXZpc2lvbjoJIDAwDQo+IFRpdGxlOgkJIENETmkgUmVx dWVzdCBSb3V0aW5nIFJlZGlyZWN0aW9uIHdpdGggTG9vcCBQcmV2ZW50aW9uDQo+IENyZWF0aW9u IGRhdGU6CSAyMDEyLTA3LTA0DQo+IFdHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBO dW1iZXIgb2YgcGFnZXM6IDIwDQo+IFVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtY2hvaS1jZG5pLXJlcS1yb3V0aW5nLXJlZGlyLWxvb3At cHJldmVudGlvbi0wMC50eHQNCj4gU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWNob2ktY2RuaS1yZXEtcm91dGluZy1yZWRpci1sb29wLXByZXZl bnRpb24NCj4gSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1jaG9pLWNkbmktcmVxLXJvdXRpbmctcmVkaXItbG9vcC1wcmV2ZW50aW9uLTAwDQo+IA0KPiAN Cj4gQWJzdHJhY3Q6DQo+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgcmVxdWVzdCByb3V0aW5n IHJlZGlyZWN0aW9uIHByb2NlZHVyZXMsIGxvb3ANCj4gICBwcmV2ZW50aW9uIG1lY2hhbmlzbXMs IGFuZCBvdGhlciBvcGVyYXRpb25hbCBjb25zaWRlcmF0aW9ucyB3aGljaCBhcmUNCj4gICBhc3Nv Y2lhdGVkIHdpdGggcmVkaXJlY3Rpb24uDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IFRoZSBJ RVRGIFNlY3JldGFyaWF0DQoNCg== From kevin.ma@azukisystems.com Wed Jul 18 12:09:43 2012 Return-Path: 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 1982A11E817F for ; Wed, 18 Jul 2012 12:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 UO9kiRjlzcbg for ; Wed, 18 Jul 2012 12:09:42 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 91F5D11E816F for ; Wed, 18 Jul 2012 12:09:41 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 6E5E3416A4B; Wed, 18 Jul 2012 14:49:52 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB027.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id BD8584168EB; Wed, 18 Jul 2012 14:49:47 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB027.mail.lan ([10.110.17.27]) with mapi; Wed, 18 Jul 2012 15:10:27 -0400 From: Kevin J Ma To: "Matt Caulfield (mcaulfie)" , "cdni@ietf.org" Date: Wed, 18 Jul 2012 15:10:24 -0400 Thread-Topic: New Metadata Interface Draft (draft-cjlmw-cdni-metadata-00) Thread-Index: Ac1eC0YVScB5jeVWTF6OpuGDrKcS+gFg0GrwAC74lzAALbM/IAAABjzw Message-ID: <291CC3F9E50E7641901A54E85D0977C65326E2B2FF@MAILR002.mail.lan> References: <166EBB70C264A9479E459B01B1BA6C9201B060@xmb-aln-x03.cisco.com> <291CC3F9E50E7641901A54E85D0977C65326E2AA7F@MAILR002.mail.lan> <166EBB70C264A9479E459B01B1BA6C9201F7B3@xmb-aln-x03.cisco.com> <291CC3F9E50E7641901A54E85D0977C65326E2B1C4@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C65326E2B1C4@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Ben Niven-Jenkins \(ben@velocix.com\)" Subject: Re: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni-metadata-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 19:09:43 -0000 Hi Matt, thanx for the reponse. comments inline: > From: Matt Caulfield (mcaulfie) [mailto:mcaulfie@cisco.com] > Sent: Tuesday, July 17, 2012 4:02 PM > To: Kevin J Ma; cdni@ietf.org > Cc: Ben Niven-Jenkins (ben@velocix.com) > Subject: RE: New Metadata Interface Draft (draft-cjlmw-cdni-metadata-00) >=20 > Hi Kevin, >=20 > Thank you for the comments, please see my responses inline below. >=20 > Regards, > Matt >=20 > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Monday, July 16, 2012 4:40 PM > To: Matt Caulfield (mcaulfie); cdni@ietf.org > Cc: Ben Niven-Jenkins (ben@velocix.com) > Subject: RE: New Metadata Interface Draft (draft-cjlmw-cdni-metadata-00) >=20 > Hi Matt, >=20 > =A0 A couple of initial comments/questions about the merged draft: >=20 > =A0 - I do not understand the need for a heirarchical separation of the > =A0=A0=A0 Acquisition and Delivery objects?=A0 Why is the property "key" = not > =A0=A0=A0 sufficient for designating the function of the metadata? > [Matt>] The separation was created to categorize metadata properties. It'= s > not essential. It may be useful if one server in a CDN is delivery a piec= e > of content and another server is acquiring. The acquisition server could > limit itself to looking at the acquisition metadata while the delivery > server could limit itself to looking at the delivery metadata. Would you > suggest removing this distinction? It raises question in my mind about how override works (see response to Ben= ). > =A0=A0=A0 Though it could be argued that these are logically different > =A0=A0=A0 functions, the extra layer seems unnecessary, and introduces so= me > =A0=A0=A0 complexity to the inheritance model? > [Matt>] I don't think that the extra layer introduces any additional > complexity. In our model, objects can contain objects which can contain > objects, the delivery/acquisition objects aren't a special case. >=20 > =A0=A0=A0 With inheritance-based override, can a lower level PathMetadata > =A0=A0=A0 object override just an Auth List, or does it have to replace t= he > =A0=A0=A0 entire Delivery object?=A0 Does it have to place the Auth List > =A0=A0=A0 inside a lower level Delivery object, or can it just define a n= ew > =A0=A0=A0 Auth List with no Delivery object wrapper?=A0 Is there a concep= t of > =A0=A0=A0 leaf vs. branch objects for override purposes? > [Matt>] Any object at any level can be overridden. So yes, just the Auth > list could be overridden, there is no need to override the entire deliver= y > object. Yes, the schema must be preserved - so to override the auth list > it would be wrapped by a delivery object. No, there is no concept of leaf > vs. branch. Based on your comment, I think we could spend more time on th= e > description of inheritance. >=20 > =A0=A0=A0 In general, if there are an arbitrary number of levels below ea= ch > =A0=A0=A0 object, and an arbitrary number of levels of PathMetadata which > =A0=A0=A0 may contain objects with arbitrary levels of metadata which may > =A0=A0=A0 override previous levels, is there a need to check that duplica= te > =A0=A0=A0=A0Metadata do not exist within a given subtree, and/or should t= hat > =A0=A0=A0 restriction be stated explicity? > [Matt>] I'm not sure what you mean by duplicate metadata. Each > PathMetadata object defines a bunch of metadata properties, each one is > unique. Each PathMetadata object either inherits or overrides the metadat= a > properties of its parent. I guess I was thinking more about scope, not across multiple PathMetadata objects, but within a single one, e.g.: Delivery has an auth property. If someone add a new x-azuki property to the Delivery property and the x-azuki property has its own auth property. Is there a conflict? Presumably the delivery/x-azuki/auth property is distinct from the delivery/auth property? And the precedence of the two auth properties would be defined by the x-azuki/auth property? If there was also a delivery/x-cisco/auth property and a delivery/x-velocix/auth it gets a little more complex. Should there be restrictions on naming and/or overriding existing metadata object functions, or is it just left up to the implementors to do the right thing? > =A0 - For Lists of objects, I did not see a specific ordering defined? > =A0=A0=A0 Is there a way to enforce ordering? > [Matt>] I'm not sure I understand your question. All lists are ordered. > Can you clarify? I do not see any text in the draft which defines what a "List" is, or how they are ordered? JSON arrays have inherent ordering, but XML lists do not. Also, JSON and XML may only be an on-the-wire encoding. The data model should specify an order from which to generate the JSON/XML? > =A0 - With respect to extensibility, can an "x-" object be added to any > =A0=A0=A0 other object, or are there restrictions on where a new custom > =A0=A0=A0 object may be added into the hierarchy? > [Matt>] An "x-" object can be added anywhere. >=20 > =A0=A0=A0 Can I add a new ACL type?=A0 Can I add a new pattern matching o= ption > =A0=A0=A0 to the HostMatch and/or PathMatch objects (fundamentally changi= ng > =A0=A0=A0 the way hosts and paths are matched)?=A0 Can I add new types of > =A0=A0=A0 location algorithms (e.g., GPS coordinates or zip code) to the > =A0=A0=A0 Location object?=A0 Or is it intended more for just creating a = new > =A0=A0=A0 hierarchy under the Delivery object? > [Matt>] It is intended for adding new metadata properties, however it > could be used for changing the structure of the metadata tree or changing > how we do path matches as you suggest. >=20 > =A0 - With respect to the "ignorable" Property, does that affect the > =A0=A0=A0 entire parent object to which it is added?=A0 If it is a Proper= ty > =A0=A0=A0 itself (rather than an attribute of a Property), then does that > =A0=A0=A0 require a wrapper object around the actual Property and the > =A0=A0=A0 "ingnorable" Property, for all new Properties?=A0 Should it be = a > =A0=A0=A0 standard attribute like Mandatory? > [Matt>] Yes, the ignorable property affects the entire object and all the > objects it contains. The "ignorable" property can be thought of as an > attribute. In the XML encoding, it would likely be an attribute (and not > an element). In JSON, yes, it can lead to wrapper object. So, would "ignorable" affect all children as well? Or only the objects in the current level, not including other objects referenced through a PathMatch object? > =A0 - Is there a way for the client to request metadata for a given URI, > =A0=A0=A0 rather than recursively checking and requesting PathMetadata? > =A0 =A0=A0Doesn't this lead to alot of lookups (even local cache lookups) > =A0=A0=A0 for each request, to find all of the applicable PathMetadata? > =A0=A0=A0 Are there optimizations for local cache lookup? > [Matt>] No, there's no way to get the metadata for a specific URL without > traversing the tree. This approach enforces cacheability. As for local > lookups, it's up to the CDN how it store metadata internally. The local > lookup speed is independent of the metadata interface speed. I'm not sure that cacheability is really affected. I understand the desire to be able to individually reference and store objects. The recursive tree structure does not really enhance that. Having all the PathMatch objects i= n a flat single layer structure would not change cacheability (or increase th= e storage requirements), but it might make it easier to natively support look= up for given URIs? Though compacted representations could be generated for faster local lookup= s, the un-compacted representation is still needed to be able to determine how to refresh metadata or get more specific (additional PathMatch) metadata. thanx. -- Kevin J. Ma > =A0 Note: I have also uploaded an updated version of my draft: > =A0=A0=A0=A0=A0=A0=A0 http://tools.ietf.org/html/draft-ma-cdni-metadata-0= 3 > [Matt>] Thanks, I will check it out. >=20 > thanx. >=20 > --=A0 Kevin J. Ma >=20 >=20 > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Matt Caulfield (mcaulfie) > Sent: Monday, July 09, 2012 3:45 PM > To: cdni@ietf.org > Cc: Ben Niven-Jenkins (ben@velocix.com) > Subject: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni-metadata- > 00) >=20 > Hi everyone, >=20 > As we announced in April, a group of us (Ben Niven-Jenkins, Kent Leung, > Rob Murray, Grant Watson, and I) have been working on a merge of two of > the CDNI metadata interface proposals: > - draft-caulfield-cdni-metadata-core-00 > - draft-jenkins-cdni-metadata-00 >=20 > The merged draft has now been submitted: http://tools.ietf.org/html/draft= - > cjlmw-cdni-metadata-00 >=20 > We will be presenting on this draft in Vancouver. Any feedback on the lis= t > is also appreciated. >=20 > Thanks, > Matt >=20 >=20 >=20 From kevin.ma@azukisystems.com Wed Jul 18 12:11:07 2012 Return-Path: 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 F341611E816F for ; Wed, 18 Jul 2012 12:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 5221es20ySqm for ; Wed, 18 Jul 2012 12:10:55 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 2F99911E8150 for ; Wed, 18 Jul 2012 12:10:55 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id B5CB38FB2AF; Wed, 18 Jul 2012 14:51:06 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id A83BF8FAC7D; Wed, 18 Jul 2012 14:51:05 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Wed, 18 Jul 2012 15:11:44 -0400 From: Kevin J Ma To: Ben Niven-Jenkins Date: Wed, 18 Jul 2012 15:11:43 -0400 Thread-Topic: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni-metadata-00) Thread-Index: Ac1kV6dfGlSeGyobTyKFuzOd9IaQFgAqWfig Message-ID: <291CC3F9E50E7641901A54E85D0977C65326E2B302@MAILR002.mail.lan> References: <166EBB70C264A9479E459B01B1BA6C9201B060@xmb-aln-x03.cisco.com> <291CC3F9E50E7641901A54E85D0977C65326E2AA7F@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Ben Niven-Jenkins \(ben@velocix.com\)" , "cdni@ietf.org" Subject: Re: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni-metadata-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 19:11:07 -0000 Hi Ben, thanx for the response. comments inline: > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Tuesday, July 17, 2012 4:06 PM > To: Kevin J Ma > Cc: Matt Caulfield (mcaulfie); cdni@ietf.org; Ben Niven-Jenkins > (ben@velocix.com) > Subject: Re: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni- > metadata-00) >=20 > Hi Kevin, >=20 > Thanks for reading the draft, some good questions. My opinion inline. >=20 >=20 > On 16 Jul 2012, at 21:40, Kevin J Ma wrote: >=20 > > Hi Matt, > > > > A couple of initial comments/questions about the merged draft: > > > > - I do not understand the need for a heirarchical separation of the > > Acquisition and Delivery objects? Why is the property "key" not > > sufficient for designating the function of the metadata? >=20 > This is a good question and something we discussed at length amongst the > authors but probably don't really talk about in the draft. >=20 > We discussed a lot the trade offs between embedding all CDNI metadata > properties together versus splitting some out into different object that > could be independently cached/retrieved. >=20 > We decided not to try to optimise too early so we took an approach of > allowing any object to be embedded or independently addressable. This > leads to the data model being slightly more convoluted and it can > certainly be optimised a bit IMO. But we decided on an approach where we > first had a stable/agreed model with the WG and then we could revisit it > see what optimisations make sense. Understood. My specific concerns were with: a) how extra levels might impact local cache implementations, i.e., which objects can be compacted locally vs. how much the structure must be maintained, in order to understand how to update individual objects without traversing the entire recursion tree, and b) how error prone inheritance-based override might be if there are alot of levels at which errant overrides could be applied. > > Though it could be argued that these are logically different > > functions, the extra layer seems unnecessary, and introduces some > > complexity to the inheritance model? > > > > With inheritance-based override, can a lower level PathMetadata > > object override just an Auth List, or does it have to replace the > > entire Delivery object? >=20 > This is an area where we need to flesh out the specification and not one > we've fully fleshed out yet. >=20 > My current thinking is to only have to specify those properties which you > want to override compared to the parent PathMetadata object. > > > Does it have to place the Auth List > > inside a lower level Delivery object, or can it just define a new > > Auth List with no Delivery object wrapper? >=20 > Currently yes but when we revisit the data model to look for optimisation= s > this is a good candidate. >=20 > > Is there a concept of > > leaf vs. branch objects for override purposes? >=20 > I'm not exactly sure what you mean by leaf vs branch My confusion comes from whether or not a Delivery object with an Auth List inside it overrides the Delivery object or just the Auth object. It could be that the Delivery object is just a logical/organizational object that is never overriden in its entirety, in which case it could be considered a "branch", but the Auth List is a metadata object that requires actions, which could classify it as a "leaf". If my root Delivery object has a protocol, location ACL, and auth list, and a Delivery object further down only specifies a location ACL: a) is it valid, since it does not have a protocol? b) does it only override the location ACL? or does it imply that no auth list should be used? i.e., do you have to re-specify every field? if not are there rules for what falls through? c) if it only overrides the location ACL, if one wanted to not have an auth list at the lower level, does that require specifying an empty auth list to override the root level auth list? As has been noted, we probably need to expand the discussion of the inheritance rules. [snip] > > > > - In the HostMatch object, the hostname Property is defined as a > > String? Should there be Pattern support for hostnames? >=20 > I'd need to think about that a bit more first but I think there might be > some value to that. >=20 > > Also, > > does hostnames support both IP and DNS values? >=20 > I'm not sure of the use case for IP values as clients connecting to CDNs > aren't typically given a URL with an IP address as a hostname. For the public Internet I would agree, however, there are cases where MSOs building internal CDNs prefer (for whatever reason) IP addresses. > > Also, does the > > hostname support a URI prefix that should be matched as part of > > the hostname, and not be included in the PathMatch? >=20 > No, the hostname is essentially the HTTP Host: header. All URL prefixes > are via PathMetadata. So, in a case where a given CDN requires some type of URI path prefix, would the CDN specific URI path prefix live in the PathMatch, or would it be up to the local CDN to recognize the URI path prefix, and then match against the remainder of the URL? e.g., client requests cdn1.com/cdn1_prefix/video/x.m3u8 cdn1 redirects to cdn2.com/cdn2_prefix/video/x.m3u8 Do we think this a valid use case? If so, should the PathMatch have a URI of "video/*.m3u8" or "cdnN_prefix/video/*.m3u8"? If the latter, whose responsibility is it to properly construct that PathMatch and what information would need to be passed between CDNs to do that? > > - For Lists of objects, I did not see a specific ordering defined? > > Is there a way to enforce ordering? >=20 > Lists are ordered. In JSON they would be an array with N entries, with > index[0] being first and index[N-1] being last. XML is a little more problematic with unordered lists. For this to work, the list itself must be cached as an object, as it contains the explicit ordering? It is not just the objects which it references that need to be cached and refreshed, i.e., the list order could change even if none of the objects in the list have changed? If using the native JSON directly, it is probably implied, but as a generic model for other implementations it might be worth explicitly defining the properties of a list? [snip] > > Can I add a new ACL type? Can I add a new pattern matching option > > to the HostMatch and/or PathMatch objects (fundamentally changing > > the way hosts and paths are matched)? Can I add new types of > > location algorithms (e.g., GPS coordinates or zip code) to the > > Location object? Or is it intended more for just creating a new > > hierarchy under the Delivery object? >=20 > IMO you can potentially do all those things. I think if you had lots of > them as mandatory extensions you might be better off minting a vendor > specific delivery protocol identifier to give dCDNs a heads-up that they > needed to support a lot of vendor/extension-specific capabilities, but > there are certainly other ways to do that too (depending how the > capabilities advertisement interface evolves). Agreed. Being overly flexible here could open up some interesting issues wrt being able to fundamentally change the way mandatory properties behave. But it does come down to how well the capabilities are advertised. thanx. -- Kevin J. Ma > > Note: I have also uploaded an updated version of my draft: > > http://tools.ietf.org/html/draft-ma-cdni-metadata-03 >=20 > Thanks. I'll give it a read when I get a chance. >=20 > Ben >=20 > > > > thanx. > > > > -- Kevin J. Ma > > > > > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Matt Caulfield (mcaulfie) > > Sent: Monday, July 09, 2012 3:45 PM > > To: cdni@ietf.org > > Cc: Ben Niven-Jenkins (ben@velocix.com) > > Subject: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni-metadata= - > 00) > > > > Hi everyone, > > > > As we announced in April, a group of us (Ben Niven-Jenkins, Kent Leung, > Rob Murray, Grant Watson, and I) have been working on a merge of two of > the CDNI metadata interface proposals: > > - draft-caulfield-cdni-metadata-core-00 > > - draft-jenkins-cdni-metadata-00 > > > > The merged draft has now been submitted: > http://tools.ietf.org/html/draft-cjlmw-cdni-metadata-00 > > > > We will be presenting on this draft in Vancouver. Any feedback on the > list is also appreciated. > > > > Thanks, > > Matt > > > > > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From gilles.bertrand@orange.com Thu Jul 19 01:35:14 2012 Return-Path: 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 3503221F8691 for ; Thu, 19 Jul 2012 01:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=0.789, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 yeK4Oi+3ehLQ for ; Thu, 19 Jul 2012 01:35:13 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 097C421F8685 for ; Thu, 19 Jul 2012 01:35:12 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 89C8B3B4479; Thu, 19 Jul 2012 10:36:04 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 58D6D238059; Thu, 19 Jul 2012 10:36:04 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 19 Jul 2012 10:36:00 +0200 From: To: "Francois Le Faucheur (flefauch)" Thread-Topic: I-D Action: draft-lelouedec-cdni-request-routing-00.txt Thread-Index: AQHNXfOnkNbM7QU0fkCX0/bmdVoXZ5cu8QKAgAFdWEA= Date: Thu, 19 Jul 2012 08:35:43 +0000 Message-ID: <12783_1342686964_5007C6F4_12783_1364_2_2AC63C9F27AF8446B0C064C50FC0A89304BD59@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <20120709165434.9858.81618.idtracker@ietfa.amsl.com> <3FBC9023-91C7-4F14-AFA8-C57B27301012@cisco.com> In-Reply-To: <3FBC9023-91C7-4F14-AFA8-C57B27301012@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 08:35:14 -0000 Fran=E7ois, Our draft proposes a constructive approach to help the working group progre= ss on CDNI the request routing and signaling aspects. We therefore propose = clarifications of the fundamental routing concepts in CDNI as we think that= these concepts were not yet defined clearly enough. The new charter indeed introduces a splitting of the request routing interf= ace. We consider this as a good progress towards refining the interface rol= es and this move is consistent the spirit of our propositions, even if we a= re not fully satisfied with the current terminology, as explained in http:/= /tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00.=20 We could live along with the current charter text and consider that: - "Redirection interface" interface is close to what we call the "Downstrea= m Resource Identifier Signaling interface" - "Footprint & Capabilities Advertisement" is close to what we call the "CD= NI Routing interface" with the clarifications provided in http://tools.ietf.org/html/draft-leloue= dec-cdni-request-routing-00. We could start discussing this issue in the informal gathering on request r= outing proposed by Yannick on Sunday evening. Best regards, -- Gilles -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de F= rancois Le Faucheur (flefauch) Envoy=E9=A0: mercredi 18 juillet 2012 15:14 =C0=A0: cdni@ietf.org Objet=A0: Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.txt Authors, This document spends a lot of time proposing to split the "Request Routing"= interface into two interfaces. In particular, its conclusions include: " We also recommend to review the charter of the CDNI WG, in particular to replace the following objective: o "WG Creation + 18 months: Submit specification of the CDNI Request Routing protocol to IESG as Proposed Standard" by the two following objectives: o "WG Creation + 18 months: Submit specification of the CDNI Routing interface to IESG as Proposed Standard" o "WG Creation + 18 months: Submit specification of the CDNI Downstream Resource Identifier Signaling (DRIS) Interface to IESG as Proposed Standard" " Can you guys consider the fact that the charter has already been updated tw= o months ago (http://www.ietf.org/mail-archive/web/cdni/current/msg00989.ht= ml) to split the Request Routing into 2 interfaces and already reads: " o Dec 2012 - Submit specification of the CDNI Request Routing/Redirection = interface to IESG as Proposed Standard ... o Jun 2013 - Submit specification of the CDNI Request Routing/Footprint & = Capabilities Advertisement interface to IESG as Proposed Standard " Does this not basically already address your point? Cheers Francois On 9 Jul 2012, at 18:54, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : CDNI Request Routing > Author(s) : Yannick Le Louedec > Anne Marrec > Gilles Bertrand > Marcin Pilarski > Filename : draft-lelouedec-cdni-request-routing-00.txt > Pages : 30 > Date : 2012-07-09 >=20 > Abstract: > The present document proposes to clarify the CDNI Request Routing > interface introduced in [I-D.ietf-cdni-framework] and [I-D.ietf-cdni- > problem-statement], as well as related terminology. >=20 > In particular the present document proposes to split the CDNI Request > Routing interface into two separate interfaces with clearer roles, > named respectively CDNI Routing interface and CDNI Downstream > Resource Identifier Signaling interface (CDNI DRIS interface). >=20 > This part of the CDN interconnection framework the IETF has been > referring to so far with the term "CDNI Request Routing" is just > another routing, signaling and forwarding problem in a long series of > the telecommunication history. For example, one can draw a direct > analogy between the IP/MPLS-TE framework and the CDN interconnection > framework. >=20 > In addition, this document recommends that the specification of ALL > CDN interconnection interfaces in the scope of the CDNI IETF WG > relies on the equivalent concept to IP prefix for CDN > interconnection, named 'contentRequestScope'. This highly useful and > powerful concept SHALL be used to simplify the specification of ALL > CDN interconnection interfaces, as well as to ensure performance and > scalability in CDN interconnection. >=20 > All these proposals can be smoothly integrated in the WG drafts, > especially [I-D.ietf-cdni-framework] and > [I-D.ietf-cdni-requirements], as they essentially propose (useful) > clarifications of the existing framework. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-routing >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From flefauch@cisco.com Thu Jul 19 02:00:20 2012 Return-Path: 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 61E2921F86F1 for ; Thu, 19 Jul 2012 02:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 Wxbo4cb+bGAW for ; Thu, 19 Jul 2012 02:00:19 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF4B21F86C9 for ; Thu, 19 Jul 2012 02:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4046; q=dns/txt; s=iport; t=1342688472; x=1343898072; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=F9RuTP00svCg7EyZrbDYWSc1AiUk9KKiObLAk9TKn/A=; b=PGkjCQkzeqY89OLk46P0/rI2EMp8zDD7js76OgFDGFbiKk5zkcRbQkYg w30kC/pYwza/3LTXiqM8OTy9+XujwGpvBrPb3ahhHkuM5arCspT7OkiLP nzrl3c1LZkR36RGeYS414xYJK0ptf7/mg0VNv4pKoHDwZPHo6NE2bTtgG o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAI/LB1CtJV2a/2dsb2JhbABFuUWBB4IgAQEBAwEBAQEPASc0CxACAT4QJwslAgQBDQUJGYdlBguePo8WkHWLQIYwYAOVRIETiXeDGYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,615,1336348800"; d="scan'208";a="100347584" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 19 Jul 2012 09:01:11 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6J91BZo032633 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jul 2012 09:01:11 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.17]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Thu, 19 Jul 2012 04:01:11 -0500 From: "Francois Le Faucheur (flefauch)" To: "niwei@chinamobile.com" , "biyana@chinamobile.com" , zhangyunfei Thread-Topic: Comments re Re: I-D Action: draft-ni-cdni-criteria-metadata-extension-00.txt Thread-Index: AQHNZY0KLmuTfJiwLEazqbouHDgZYg== Date: Thu, 19 Jul 2012 09:01:10 +0000 Message-ID: <8B1F02A4-88E6-444D-87A9-97819F54D2A3@cisco.com> References: <20120709174141.2670.59592.idtracker@ietfa.amsl.com> In-Reply-To: <20120709174141.2670.59592.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.198] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19050.003 x-tm-as-result: No--44.945900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-cjlmw-cdni-metadata@tools.ietf.org" , "cdni@ietf.org" , "draft-ma-cdni-metadata@tools.ietf.org" Subject: [CDNi] Comments re Re: I-D Action: draft-ni-cdni-criteria-metadata-extension-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 09:00:20 -0000 Hello Wei, Yana, Yunfei, The I-D says: " The object includes the following fields: O country - a string containing the country code for the region. O bgpAs - a number containing the BGP AS identifier of the region. O subnet - a string containing a dotted decimal IP address and subnet mask, here the IP address is the source IP address in IP layer. O msdnPrefix - a few digits in MSISDN specifying user's home area information in mobile network. MSISDN should be extracted from HTTP Header by the surrogate of downstream CDN. O subnet2 - a string containing a dotted decimal IP address extracted from the HTTP x-forwarded-for header and the corresponding subnet mask, which specifies the real IP address of mobile devices assigned by mobile core network. The IP address should be extracted from HTTP Header by the surrogate of downstream CDN. " The Location object of cjlmw-cdni-metadata is described as: " | Location | Geographic or network location identified by | | | country code, BGP AS number, or subnet to which = | | | content may (or may not) be delivered.=20 " Can you confirm that your first three criteria ("Country", "BGP AS" and "Su= bnet") are addressed as you see needed? Regarding the last 2 criteria, I would like to encourage you to work (ideal= ly before Vancouver) with the authors of the current CDNI Metadata proposal= s (e.g. cjlmw-cdni-metadata and ma-cdni-metadata) to discuss whether/how th= ose could be integrated in the current metadata proposals. On that, my pers= onal input is: * I can see the rationale for extending the geoblocking based on the IP ad= dress allocated based on current location (ie your "Subnet2"). * I am somewhat skeptical on the requirements to control distribution base= d on ranges of the Mobile number (ie your "msdnPrefix"), particularly consi= dering number portability. I would be interested in hearing other opinions = on that. Regardless of which document the discussion of "subnet2" ends up in the fut= ure, I suggest an editor's note be incorporate to remind us to check the st= atus of "draft-petersson-forwarded-for" (unless someone can update us on th= at) to decide whether we ought to extend the description to cover the propo= sed "Forwarded" header, in addition to the X-Forwarded-For header. Cheers Francois On 9 Jul 2012, at 19:41, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : CDNI Delivery Criteria Metadata Extension for Mobile N= etwork > Author(s) : Wei Ni > Yana Bi > Yunfei Zhang > Filename : draft-ni-cdni-criteria-metadata-extension-00.txt > Pages : 11 > Date : 2012-07-09 >=20 > Abstract: > In CDNI deployment, the downstream CDN may probably delivers > content to mobile devices, which is served by cellular networks > (e.g., 2G, 3G). The purpose of this document is to provide some > complement to the delivery criteria in current Metadata Interface > with a more precise criteria model, which is in consideration of > content delivery service to mobile devices. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ni-cdni-criteria-metadata-extensio= n >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ni-cdni-criteria-metadata-extension-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 flefauch@cisco.com Thu Jul 19 02:18:44 2012 Return-Path: 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 0D91B21F867B for ; Thu, 19 Jul 2012 02:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.553 X-Spam-Level: X-Spam-Status: No, score=-10.553 tagged_above=-999 required=5 tests=[AWL=0.045, 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 myu7rgJMsNcD for ; Thu, 19 Jul 2012 02:18:43 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C532E21F8609 for ; Thu, 19 Jul 2012 02:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9601; q=dns/txt; s=iport; t=1342689575; x=1343899175; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2zaZvIK7g1G471BESzKVBKyMTup21tPEz6O/tMV8G3Y=; b=jMm2EQF0BAa11+ZD8Uj1KjM6/F0oAig8JMLAIugtBC+yjzrBdzv0Gq56 P3+7BQZLUEY/RY8i6J81lj1Kaw6TNMeAKU0wEGhIxjwEdvRFTkxmlYz2y FnfND+TbBnDT0Vr/Ho1b9gt3FXonIRniO4mohlfcE9p5PJWG6hUOVOzTc g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngGAKHQB1CtJXG//2dsb2JhbABFiE2gD4dnAYkBgQeCIQEBBAEBAQ8BWwsQAgEIPwcnCxQRAgQBDQUJGYdrC545oAiLQIYwYAOVRIETiXeDGYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,615,1336348800"; d="scan'208,217";a="100354281" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 19 Jul 2012 09:19:35 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6J9JZqc031398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jul 2012 09:19:35 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.17]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0298.004; Thu, 19 Jul 2012 04:19:34 -0500 From: "Francois Le Faucheur (flefauch)" To: "niwei@chinamobile.com" , "biyana@chinamobile.com" , zhangyunfei Thread-Topic: [CDNi] Comments re Re: I-D Action: draft-ni-cdni-criteria-metadata-extension-00.txt Thread-Index: AQHNZY+cBWadX3xEbECFDWSS2/iOMA== Date: Thu, 19 Jul 2012 09:19:33 +0000 Message-ID: <9F4392D9-C4C9-428A-89A4-5FF2F41E9F1C@cisco.com> References: <20120709174141.2670.59592.idtracker@ietfa.amsl.com> <8B1F02A4-88E6-444D-87A9-97819F54D2A3@cisco.com> In-Reply-To: <8B1F02A4-88E6-444D-87A9-97819F54D2A3@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.198] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19050.003 x-tm-as-result: No--40.984500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_9F4392D9C4C9428A89A45FF2F41E9F1Cciscocom_" MIME-Version: 1.0 Cc: "draft-ma-cdni-metadata@tools.ietf.org" , "cdni@ietf.org" , "draft-cjlmw-cdni-metadata@tools.ietf.org" Subject: Re: [CDNi] Comments re Re: I-D Action: draft-ni-cdni-criteria-metadata-extension-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 09:18:44 -0000 --_000_9F4392D9C4C9428A89A45FF2F41E9F1Cciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 19 Jul 2012, at 11:01, Francois Le Faucheur (flefauch) wrote: Regardless of which document the discussion of "subnet2" ends up in the fut= ure, I suggest an editor's note be incorporate to remind us to check the st= atus of "draft-petersson-forwarded-for" (unless someone can update us on th= at) to decide whether we ought to extend the description to cover the propo= sed "Forwarded" header, in addition to the X-Forwarded-For header. Here is some update from the horse's mouth: On 19 Jul 2012, at 11:12, Andreas Petersson wrote: Hi, The name has changed to draft-ietf-appsawg-http-forwarded, version -06 is the latest version. It is currently in IETF Last Call. See http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ Regards, Andreas Petersson Francois Cheers Francois On 9 Jul 2012, at 19:41, > > wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : CDNI Delivery Criteria Metadata Extension for Mobile Netw= ork Author(s) : Wei Ni Yana Bi Yunfei Zhang Filename : draft-ni-cdni-criteria-metadata-extension-00.txt Pages : 11 Date : 2012-07-09 Abstract: In CDNI deployment, the downstream CDN may probably delivers content to mobile devices, which is served by cellular networks (e.g., 2G, 3G). The purpose of this document is to provide some complement to the delivery criteria in current Metadata Interface with a more precise criteria model, which is in consideration of content delivery service to mobile devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ni-cdni-criteria-metadata-extension There's also a htmlized version available at: http://tools.ietf.org/html/draft-ni-cdni-criteria-metadata-extension-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_9F4392D9C4C9428A89A45FF2F41E9F1Cciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4F00891251DE7040AB5731392A79B469@cisco.com> Content-Transfer-Encoding: quoted-printable


On 19 Jul 2012, at 11:01, Francois Le Faucheur (flefauch) wrote:


Regardless of which document the discussion of "subnet2" ends up = in the future, I suggest an editor's note be incorporate to remind us to ch= eck the status of "draft-petersson-forwarded-for" (unless someone= can update us on that) to decide whether we ought to extend the description to cover the proposed "Forwarded" header,= in addition to the X-Forwarded-For header.

Here is some update from the horse's mouth:

On 19 Jul 2012, at 11:12, Andreas Petersson wrote:

Hi,

The name has changed to draft-ietf-appsawg-http-forwarded, version -06
is the latest version. It is currently in IETF Last Call.
See http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/


Regards,
Andreas Petersson


Francois





Cheers

Francois


On 9 Jul 2012, at 19:41, <in= ternet-drafts@ietf.org>
<internet-drafts@ietf.org> wrote:


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


Title          =  : CDNI Delivery Criteria Metadata Extension for Mobile Network
Author(s)       : Wei Ni
        &= nbsp;           &nbs= p;   Yana Bi
        &= nbsp;           &nbs= p;   Yunfei Zhang
Filename        : draft-n= i-cdni-criteria-metadata-extension-00.txt
Pages          =  : 11
Date          &= nbsp; : 2012-07-09

Abstract:
 In CDNI deployment, the downstream  CD= N may probably delivers
 content to mobile devices, which is served = by cellular networks
 (e.g., 2G, 3G). The purpose of this documen= t is to provide some
 complement to the delivery criteria in curr= ent Metadata Interface
 with a more precise criteria model, which i= s in consideration of
 content delivery service to mobile devices.=



The IETF datatracker status page for this draft i= s:
https://datatracker.ietf.org/doc/draf= t-ni-cdni-criteria-metadata-extension

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ni-cdni= -criteria-metadata-extension-00


Internet-Drafts are also available by anonymous F= TP at:
f= tp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Anno= unce@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

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

--_000_9F4392D9C4C9428A89A45FF2F41E9F1Cciscocom_-- From flefauch@cisco.com Thu Jul 19 05:36:03 2012 Return-Path: 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 830A321F8724 for ; Thu, 19 Jul 2012 05:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.448 X-Spam-Level: X-Spam-Status: No, score=-9.448 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SARE_HEXOCTDWORD=2, WEIRD_PORT=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 O6VpJRlYKFMy for ; Thu, 19 Jul 2012 05:36:02 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3971A21F8720 for ; Thu, 19 Jul 2012 05:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=10396; q=dns/txt; s=iport; t=1342701415; x=1343911015; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ikOumgQw4bjLb+ZBDYLQQETaydy82W4Tbj3z3WF1K8I=; b=EAC7IKcG81ZK1yaxUP+IDqRpG/RcvnacqMojQWxz9hwxbh9+sYvllxOI hggv/5eOvzaSj2S/iznXvkYwa2pBGqtCrmiQPURJuwTrxWg7i0Tdv89Ma EZ5p4engtZqHTFAFGRd4Ir+FnaG/3ifT58dZxqABZXZaqVTXIJDbSciq3 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwFAPv9B1CtJV2Z/2dsb2JhbABFhW2sDoYrgRqBB4IgAQEBAwESARAEDTMSBQcEAgEGAhEEAQEDAiMDAgICMBQBCAgCBA4FCRmHZQYLnhSNGZJugSCKLIV+MmADlUSBE40QgWaCXw X-IronPort-AV: E=Sophos;i="4.77,615,1336348800"; d="scan'208";a="103423602" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 19 Jul 2012 12:36:55 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6JCasOm020754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jul 2012 12:36:54 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.17]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Thu, 19 Jul 2012 07:35:40 -0500 From: "Francois Le Faucheur (flefauch)" To: =?utf-8?B?7LWc7YOc7IOB?= Thread-Topic: draft-choi-cdni-req-routing-redir-loop-prevention-00.txt Thread-Index: AQHNZaPpRda4jhxaR0GROx7Y9V1J95cw3uiA Date: Thu, 19 Jul 2012 12:36:54 +0000 Message-ID: References: <20120705135807.11011.78218.idtracker@ietfa.amsl.com> <0CC51B43-4A45-4D66-A146-E5D0023E7216@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.198] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19050.003 x-tm-as-result: No--68.848700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-ID: <864A9027B7038749A8726AEBB8B67585@cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "cdni@ietf.org" , "cdni.kaist@kaist.ac.kr" Subject: Re: [CDNi] draft-choi-cdni-req-routing-redir-loop-prevention-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 12:36:03 -0000 SGkgVGFlc2FuZywNCg0KUGxlYXNlIHNlZSBiZWxvdzoNCg0KT24gMTkgSnVsIDIwMTIsIGF0IDEz OjQ0LCDstZztg5zsg4Egd3JvdGU6DQoNCj4gRGVhciBGcmFuY29pcywNCj4gDQo+IFRoYW5rcyBm b3IgeW91ciBjb21tZW50cy4gIE15IGluLWxpbmUgcmVzcG9uc2UgaXMgYXMgZm9sbG93czoNCj4g DQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBGcmFuY29pcyBMZSBG YXVjaGV1ciAoZmxlZmF1Y2gpIFttYWlsdG86ZmxlZmF1Y2hAY2lzY28uY29tXSANCj4gU2VudDog VGh1cnNkYXksIEp1bHkgMTksIDIwMTIgMTo1MiBBTQ0KPiBUbzog7LWc7YOc7IOBDQo+IENjOiBj ZG5pQGlldGYub3JnDQo+IFN1YmplY3Q6IGRyYWZ0LWNob2ktY2RuaS1yZXEtcm91dGluZy1yZWRp ci1sb29wLXByZXZlbnRpb24tMDAudHh0DQo+IA0KPiBIZWxsbyBUYWVzYW5nLA0KPiANCj4gSnVz dCBoYWQgYSBxdWljayBsb29rIGF0IHlvdXIgZG9jdW1lbnQuIEhlcmUgYXJlIGEgZmV3IGVhcmx5 IHF1ZXN0aW9ucyBhbmQgY29tbWVudHMuDQo+IA0KPiAxKSBJIHRoaW5rIHdoYXQgeW91IGNhbGwg IkNETi1Qcm92aWRlci1JRCIgaXMgYWN0dWFsbHkgKGkpIGEgZHluYW1pYyByZWNvcmQgb2YgdGhl IENETnMgaW4gdGhlIENETiBwYXRoICsgYSAiVFRMIiBleHByZXNzZWQgaW4gbnVtYmVyIG9mIHJl ZGlyZWN0aW9uIGhvcHMuDQo+IEknZCBzdWdnZXN0IHlvdSBnaXZlIGl0IGFub3RoZXIgbmFtZSB0 aGFuICJDRE4tUHJvdmlkZXItSUQiIGFzIHRoaXMgdGVuZCB0byBzdWdnZXN0IGFuIGlkZW50aWZp ZXIgZm9yIGEgc2luZ2xlIENETi4gUGVyaGFwcyB5b3UgY291bGQgY2FsbCB0aGlzIHNvbWV0aGlu ZyBsaWtlIGEgIkNETiBQYXRoIFJlY29yZCIgb3IgIkNETiBwYXRoIuKApiBXaGVuIHlvdSBnaXZl IGFuIGV4YW1wbGUgb2YgIkNETiBQYXRoIFJlY29yZCIsIEkgc3VnZ2VzdCB5b3UgcHJvdmlkZSBh biBleGFtcGxlIHRoYXQgY29udGFpbnMgbW9yZSB0aGFuIDEgQ0ROLCBqdXN0IHRvIG1ha2UgaXQg Y2xlYXJlci4NCj4gDQo+ID09PiBNeSBpbnRlbnRpb24gd2FzIHRvIG1ha2UgQ0ROLVByb3ZpZGVy LUlEIHVuaXF1ZSB0byBhIHBhcnRpY3VsYXIgQ0ROIHByb3ZpZGVyLiAgQXMgZGVzY3JpYmVkLCBp dCBjb25zaXN0cyBvZiBDRE4gcHJvdmlkZXIgTmFtZSBhbmQgVFRMLiAgDQoNCldlbGwgdGhlIHRl eHQgYWN0dWFsbHkgc2F5czoNCiINCkl0IGNvbnNpc3RzIG9mICJDRE4gcHJvdmlkZXIgbGlzdCIg YW5kICJNYXhOdW1SZWRIb3BzIi4gIFRoZSBDRE4gcHJvdmlkZXIgbGlzdCBpcyBhIHNldCBvZiB1 bmlxdWVseSBpZGVudGlmaWFibGUgQ0ROIHByb3ZpZGVyIG5hbWVzLg0KIg0KU28gdGhlIHRleHQg ZG9lcyBub3QgcXVpdGUgY29udmV5IHdoYXQgeW91IGludGVuZGVkLg0KDQpCdXQgYW55d2F5cywg SSB0aGluayB0aGVyZSBpcyBhZ3JlZW1lbnQgdGhhdCB3aGF0IGlzIG5lZWRlZCBpcyB0byBzb21l aG93IHJlY29yZCB0aGUgIkNETi1QYXRoIiBidWlsdCBhcyBhIHNlcmllcyBvZiBDRE4gaWRlbnRp ZmllcnMuDQoNCg0KPiBVbmlxdWVuZXNzIGlzIGd1YXJhbnRlZWQgYmVjYXVzZSBDRE4gUHJvdmlk ZXIgTmFtZSBpcyBiYXNlZCBvbiBBUyBudW1iZXIuICBNYWluIHJlYXNvbnMgZm9yIHN1Y2ggYSBw cm9wb3NhbCBhcmUgdHdvLWZvbGQ6ICBvbmUgaXMgZm9yIHVuaXF1ZW5lc3MgYW5kIHRoZSBvdGhl ciBpcyBmb3Igc2F2aW5nIHNwYWNlIGluIHRoZSBVUkwuICBJZiB3ZSB1c2UgZXh0ZW5zaW9uIG9m IGRvbWFpbiBuYW1lIGZvciBzdWNoIHB1cnBvc2VzIGFzIGRlc2NyaWJlZCBpbiB0aGUgZnJhbWV3 b3JrIGRyYWZ0LCBzcGFjZSBhdmFpbGFibGUgaW4gVVJJIGhvc3RuYW1lIG1heSBub3QgYmUgZW5v dWdoIGlmIHRoZSBkZXB0aCBvZiBjYXNjYWRlZCByZWRpcmVjdGlvbiBiZWNvbWVzIGxhcmdlLiAg QWxzbyBnbG9iYWwgdW5pcXVlbmVzcyBtYXkgbm90IGJlIGd1YXJhbnRlZWQgc2luY2UgZHVwbGlj YXRlZCBleHRlbmRlZCBkb21haW4gbmFtZXMgY2FuIGJlIHVzZWQgYWNjaWRlbnRhbGx5LiAgVGh1 cywgdGhlIG5hbWUgQ0ROLVByb3ZpZGVyLUlEIHNlcnZlcyBvdXIgaW50ZW5kZWQgcHVycG9zZS4N Cj4gIEhvd2V2ZXIsIGl0IGlzIG9rIHdpdGggdXMgdG8gdXNlIHRoZSBwcm9wb3NlZCBuYW1lLCBp LmUuLCBDRE4gUGF0aCBSZWNvcmQgY2hhbmdlIGFueSBpbnRlbmRlZCBzZW1hbnRpY3MuICBIb3cg aXQgaXMgY2FycmllZCBpbiBVUkwgaXMgc2hvd24gYmVsb3cgd2l0aCBhbiBleGFtcGxlLg0KPiAN Cj4gMikgSW4gdGhlIGNhc2Ugb2YgSFRUUCBJIGFtIHVuY2xlYXIgYXMgdG8gd2hldGhlciB5dSBh cmUgcHJvcG9zaW5nIHRvIGhhdmUgdGhlICJDRE4gUGF0aCBSZWNvcmQiIGNvbnZlZXllZCA6DQo+ IAkoaSkgaW4gYSBUQkQgSFRUUCBoZWFkZXIsIA0KPiAJKGlpKSBpbnNpZGUgdGhlIFVSSSBob3N0 bmFtZSwgb3INCj4gCShpaWkpIGluc2lkZSB0aGUgVVJJIHF1ZXJ5IHN0cmluZw0KPiANCj4gVGhl IHRleHQgOiAiRm9yIEhUVFAtIGJhc2VkIHJlZGlyZWN0aW9uLCB3ZSBkZWZpbmUgYSBIVFRQIHJl cXVlc3Qgcm91dGluZyByZWRpcmVjdGlvbiBoZWFkZXIgIkNETi1Qcm92aWRlci1JRCIgc3VnZ2Vz dHMgKGkpLg0KPiBUaGUgdGV4dCAiRm9yIGVhY2ggc3RlcCBvZiByZWRpcmVjdGlvbiwgaXQgaXMg YXR0YWNoZWQgdG8gdGhlIGJlZ2lubmluZyBvZiB0aGUgcHJvdmlkZXIgZG9tYWluIFVSTC4iIHN1 Z2dlc3RzIChpaSkuDQo+IFRoZSB0ZXh0IDogInBlZXItdUNETi5kQ0ROMS5uZXQvY2RuLmNzcC5j b20/dUNETi1Qcm92aWRlci1JRCIgc3VnZ2VzdHMgKGlpaSkuDQo+IA0KPiA9PT4gIFRoYW5rcyBm b3IgcGluLXBvaW50aW5nIGluY29uc2lzdGVuY3kgaW4gdGhlIGRyYWZ0cy4gIFRoZXJlIHdlcmUg c29tZSB1bmludGVudGlvbmFsbHkgbWlzdGFrZXMgZHVyaW5nIGRyYWZ0IHByZXBhcmF0aW9uLiAg T3VyIGludGVudGlvbiB0byBjYXJyeSBDRE4tUHJvdmlkZXItSUQgaW4gVVJMIGlzIGluc2lkZSBV UkkgcXVlcnkgc3RyaW5nLiAgT25lIGV4YW1wbGUgZm9yIHRoZSBjYXNlIHRoYXQgcmVkaXJlY3Rp b24gaXMgY2FzY2FkZWQgdGhyZWUgdGltZXMsICh1Q0ROIC0+IGRDRE4xIC0+IGRDRE4yKSBkQ0RO MiBjYXJyaWVzIFVSTCBhcyBnaXZlbiBiZWxvdyB0byBhbm90aGVyIGRDRE4gaWYgZnVydGhlciBy ZWRpcmVjdGlvbiBpcyBuZWVkZWQuDQo+IA0KPiBodHRwOi8vY2RuLmNzcC5jb20/dUNETi1Qcm92 aWRlci1JRD0xMDA6MDoxMCZkQ0ROMS1Qcm92aWRlci1JRD0yMDA6MTo5JmRDRE4yLVByb3ZpZGVy LUlEPTMwMDowOjgNCg0KVGhpcyBleGFtcGxlIGFzc3VtZXMgdGhhdCBhIFRUTCB2YWx1ZSBpcyBz aWduYWxlZCBmb3IgZWFjaCBsZXZlbCAoMTAsIDkgYW5kIDgpLiBEbyB5b3Ugc2VlIGEgbmVlZCB0 byBjb252ZXkgdGhlIFRUTCBvZiBlYWNoIENETiBsZXZlbCBhcyBvcHBvc2VkIHRvIG9ubHkgdGhl IGxhdGVzdCBUVEwgdmFsdWU/IA0KZWc6IGh0dHA6Ly9jZG4uY3NwLmNvbT9DRE5JLUNJRDA9MTAw OjAmQ0ROSS1DSUQxPTIwMDoxJkNETkktQ0lEMj0zMDA6MCZDRE5JLVRUTD04DQoNCg0KPiANCj4g SW4gdGhlIHNlY3Rpb24gMi4xIG9mIG15IGRyYWZ0IGdpdmVzIG9uZSBleGFtcGxlIGFzICJodHRw Oi8vMTAwOjA6MTAuY2RuLmNzcC5jb20iLiAgSXQgaXMgdXNlZCB0byBkZXNjcmliZSBhYnN0cmFj dCBmb3JtIHRvIGNvdmVyIGJvdGggSFRUUC1iYXNlZCBhbmQgRE5TLWJhc2VkIGNhc2VzLiAgRm9y IGNsYXJpdHksIHRoZSB0ZXh0IG5lZWRzIHRvIGJlIGZpeGVkIHRvIGRlc2NyaWJlIGJvdGggY2Fz ZXMgc2VwYXJhdGVseS4NCj4gDQo+IAkNCj4gMykgYWxnb3JpdGhtIGluIGNhc2Ugb2YgbG9vcCBk ZXRlY3Rpb24uDQo+IFlvdSBzYXk6DQo+ICJJZiBhIGxvb3AgaXMgZGV0ZWN0ZWQgYW5kIG15c2Vs ZiBjYW4gc2VydmUgdGhlIHJlcXVlc3QsIHRoZSByZXF1ZXN0DQo+ICAgaXMgcHJvY2Vzc2VkIGlu IG15IENETi4gIEZvciBzb21lIHJlYXNvbiwgaWYgbXlzZWxmIGNhbm5vdCBwcm9jZXNzDQo+ICAg dGhlIHJlcXVlc3QsIGl0IGZpcnN0IGNoZWNrcyBhdmFpbGFiaWxpdHkgb2YgaXRzIHBhcmVudCBh bmQgdGhlbg0KPiAgIHVDRE4uICBJZiBub25lIG9mIHRoZW0gc3VjY2VlZCwgdGhlbiByZXF1ZXN0 IGlzIGRlbmllZC4NCj4gIg0KPiBJZiBhIGxvb3AgaXMgZGV0ZWN0ZWQsIHRoZSBDRE4gZGV0ZWN0 aW5nIHRoZSBsb29wIGNhbiBkZWNpZGUgdG8gc2VydmUgdGhlIHJlcXVlc3QgYXMgeW91IHN1Z2dl c3QsIG9yIGFyZ3VhYmx5IGNvdWxkIGRlY2lkZSB0byBwaWNrIGFuIGFsdGVybmF0aXZlIGRDRE4u IElzIHRoZXJlIGEgcmVhc29uIHlvdSBzZWVtIHRvIGV4Y2x1ZGUgdGhhdCBvcHRpb24/DQo+IA0K PiA9PT4gVGhlIHByb3Bvc2VkIGFsZ29yaXRobSBzaG93cyBvbmUgcG9zc2libGUgYnV0IG1vc3Qg Z2VuZXJhbCBvcHRpb24gZm9yIHBvc3QtcHJvY2Vzc2luZyBvZiBsb29wIGRldGVjdGlvbi4gIFRo YXQgaXMsIGl0IGFzc3VtZXMgcmVzb3VyY2UgYXZhaWxhYmlsaXR5IG9mIGl0cyBvd24gcGFyZW50 IHVudGlsIGl0IHJlYWNoZXMgdUNETiBwcm92aWRlci4gIEhvd2V2ZXIsIHRoZXJlIGFyZSBvdGhl ciBwb3N0LXByb2Nlc3NpbmcgYWx0ZXJuYXRpdmVzIHdoaWNoIHdlcmVuJ3QgZGVzY3JpYmVkIGlu IHRoZSBkcmFmdC4gIFRoZXkgYXJlOg0KPiANCj4gMS4gV2hlbiBhIGxvb3AgZGV0ZWN0ZWQsIGRl bnkgdGhlIHNlcnZpY2UuICBUaGlzIGlzIG1vc3Qgc3RyaWN0IGNhc2UuDQo+IDIuIFRoZSBzZWNv bmQgbWV0aG9kIGlzIHRoZSBvbmUgZGVzY3JpYmVkIGluIHRoZSBkcmFmdC4gIEl0IGlzIGdlbmVy YWwgYW5kIHJlYXNvbmFibGUgcG9zdC1wcm9jZXNzaW5nIGNhc2UuDQo+IDMuIFRoZSB0aGlyZCBt ZXRob2QgaXMgdG8gYWxsb3cgcGFyZW50IGRDRE4gdG8gcmVkaXJlY3QgYW5vdGhlciBkQ0ROIGFz IHlvdSBjb21tZW50ZWQgYWJvdmUuDQo+IDQuIFRoZSBmb3VydGggbWV0aG9kIGlzIHRvIGNoZWNr IHRoZSByZXNvdXJjZSBhdmFpbGFiaWxpdHkgdXAgdW50aWwgdUNETi4gIElmIHVDRE4gc3RpbGwg Y2Fubm90IHNlcnZlLCB0aGVuIGl0IGNhbiBzdGFydCByZWRpcmVjdGlvbiBwcm9jZXNzIGFnYWlu IGV4Y2VwdCB0aGUgcGF0aCBpdCBqdXN0IHRyaWVkLiAgVGhpcyBtZXRob2QgaXMgdGhlIG1vc3Qg Z2VuZXJhbCBidXQgcmF0aGVyIGluLWVmZmljaWVudCBjYXNlLiAgSXQgbWF5IGhhdmUgdG8gY29u c3VtZSBhbGwgdGhlIFRUTCB2YWx1ZS4gQWx0aG91Z2ggd2UganVzdCByZWNvbW1lbmRlZCBvbmUg bWV0aG9kLCBpdCBjYW4gZGVzY3JpYmUgYWxsIHBvc3NpYmxlIG1ldGhvZHMgaW4gdGhlIGRyYWZ0 IGFzIHdlbGwuDQoNClNvIEkgdGhpbmsgd2UgYWdyZWUgdGhlcmUgYXJlIG90aGVyIGFsZ29yaXRo bS4NClBlcnNvbmFsbHkgSSBkb24ndCB0aGlvbmsgd2UgbmVlZCB0byBzcGVjaWZ5IHRoZSBhbGdv cml0aG0uIFdlIG9ubHkgbmVlZCB0byBzcGVjaWZ5Og0KCShpKSBhIG1lY2hhbmlzbSB0byBhbGxv dyBsb29wIGRldGVjdGlvbg0KCShpaSkgd2hvIGlzIHJlc3BvbnNpYmxlIGZvciBkZXRlY3Rpbmcg YW5kIHJlc29sdmluZyB0aGUgc2l0dWF0aW9uIChhbmQgbWFrZSBzdXJlIHRoYXQgdGhlIGxvb3Ag ZGV0ZWN0aW9uIGFsZ29yaXRobSBjYW4gYXBwbHkgcmVjdXJzaXZlbHkgc28gdGhhdCBpZiBhIHN1 YnNlcXVlbnQgbG9vcCBoYXBwZW5zIGl0IGlzIGFnYWluIGRldGVjdGVkIGFuZCBzb2x2ZWQpLg0K V291bGQgeW91IGFncmVlPw0KDQpDaGVlcnMNCg0KRnJhbmNvaXMNCg0KDQo+IA0KPiBDaGVlcnMN Cj4gDQo+IEZyYW5jb2lzDQo+IA0KPj4gDQo+PiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+PiBGcm9tOiDstZztg5zsg4ENCj4+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMTcsIDIwMTIg MTI6NTAgQU0NCj4+IFRvOiAnY2RuaUBpZXRmLm9yZycNCj4+IFN1YmplY3Q6IEZXOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIA0KPj4gZHJhZnQtY2hvaS1jZG5pLXJlcS1yb3V0aW5nLXJl ZGlyLWxvb3AtcHJldmVudGlvbi0wMC50eHQNCj4+IA0KPj4gRGVhciBhbGwsDQo+PiANCj4+IFdl IGhhdmUgdXBsb2FkZWQgYSBuZXcgSS1EIHJlbGF0ZWQgdG8gJ0NETkkgUmVxdWVzdCBSb3V0aW5n IA0KPj4gUmVkaXJlY3Rpb24gd2l0aCBMb29wIFByZXZlbnRpb24nIGFzIGJlbG93LiAgV2UgcmVx dWVzdCB5b3VyIHJldmlldyANCj4+IGFuZCBjb21tZW50cw0KPj4gDQo+PiBUaGFua3MsDQo+PiBU YWVzYW5nIENob2kNCj4+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206 IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y Z10NCj4+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDA1LCAyMDEyIDEwOjU4IFBNDQo+PiBUbzog7LWc 7YOc7IOBDQo+PiBDYzogZGoua2ltQGt0LmNvbQ0KPj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciANCj4+IGRyYWZ0LWNob2ktY2RuaS1yZXEtcm91dGluZy1yZWRpci1sb29w LXByZXZlbnRpb24tMDAudHh0DQo+PiANCj4+IA0KPj4gDQo+PiBBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgDQo+PiBkcmFmdC1jaG9pLWNkbmktcmVxLXJvdXRpbmctcmVkaXItbG9vcC1wcmV2ZW50aW9u LTAwLnR4dA0KPj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUYWVzYW5nIENo b2kgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KPj4gDQo+PiBGaWxlbmFtZToJ IGRyYWZ0LWNob2ktY2RuaS1yZXEtcm91dGluZy1yZWRpci1sb29wLXByZXZlbnRpb24NCj4+IFJl dmlzaW9uOgkgMDANCj4+IFRpdGxlOgkJIENETmkgUmVxdWVzdCBSb3V0aW5nIFJlZGlyZWN0aW9u IHdpdGggTG9vcCBQcmV2ZW50aW9uDQo+PiBDcmVhdGlvbiBkYXRlOgkgMjAxMi0wNy0wNA0KPj4g V0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+PiBOdW1iZXIgb2YgcGFnZXM6IDIwDQo+ PiBVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWNob2ktY2RuaS1yZXEtcm91dGluZy1yZWRpci1sb29wLXByZXZlbnRpb24tMDAudHh0DQo+ PiBTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt Y2hvaS1jZG5pLXJlcS1yb3V0aW5nLXJlZGlyLWxvb3AtcHJldmVudGlvbg0KPj4gSHRtbGl6ZWQ6 ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaG9pLWNkbmktcmVxLXJv dXRpbmctcmVkaXItbG9vcC1wcmV2ZW50aW9uLTAwDQo+PiANCj4+IA0KPj4gQWJzdHJhY3Q6DQo+ PiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgcmVxdWVzdCByb3V0aW5nIHJlZGlyZWN0aW9uIHBy b2NlZHVyZXMsIGxvb3ANCj4+ICBwcmV2ZW50aW9uIG1lY2hhbmlzbXMsIGFuZCBvdGhlciBvcGVy YXRpb25hbCBjb25zaWRlcmF0aW9ucyB3aGljaCBhcmUNCj4+ICBhc3NvY2lhdGVkIHdpdGggcmVk aXJlY3Rpb24uDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiBUaGUgSUVURiBTZWNy ZXRhcmlhdA0KPiANCg0K From ben@niven-jenkins.co.uk Thu Jul 19 11:16:34 2012 Return-Path: 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 C563421F8625 for ; Thu, 19 Jul 2012 11:16:34 -0700 (PDT) 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 KmkByH+9CrCk for ; Thu, 19 Jul 2012 11:16:34 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 1280521F861D for ; Thu, 19 Jul 2012 11:16:34 -0700 (PDT) Received: from 52.red-80-25-156.staticip.rima-tde.net ([80.25.156.52] helo=[192.168.11.169]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SrvHy-00056d-I0; Thu, 19 Jul 2012 19:17:27 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Thu, 19 Jul 2012 19:17:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0F70E030-DAE1-48D1-80C6-3B48CDC41FD8@niven-jenkins.co.uk> References: To: Rob Murray X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: Ben Niven-Jenkins , "cdni@ietf.org" Subject: Re: [CDNi] Host pattern matches in CDNI Metadata (was Re: New Metadata Interface Draft (draft-cjlmw-cdni-metadata-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 18:16:34 -0000 On 18 Jul 2012, at 09:36, Rob Murray wrote: > On 17/07/2012 21:21, "Ben Niven-Jenkins" = wrote: >> On 17 Jul 2012, at 21:01, Matt Caulfield (mcaulfie) wrote: >>> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>> - In the HostMatch object, the hostname Property is defined as a >>> String? Should there be Pattern support for hostnames? Also, >>> does hostnames support both IP and DNS values? Also, does the >>> hostname support a URI prefix that should be matched as part of >>> the hostname, and not be included in the PathMatch? >>> [Matt>] We debated whether or not to allow patterns in hostnames and >>> decided against it. Ben can provide some of the background there. = Yes, >>> the hostname should support both IP an DNS values. No, the hostname = does >>> not include any other part of the URI. Will need to add some >>> clarification on the hostname to the draft. >>=20 >> Off hand I can't remember the obviously good reasons I used to = convince >> Matt it was a bad idea. >=20 > I think there were a couple of reasons, neither of them killer = arguments > but they leant us towards the current position... >=20 > - the HostIndex isn't ordered between CDNs, any given downstream > request-router or surrogate may have a HostIndex assembled from = several > upstreams. If patterns aren't allowed in the HostMatch, either two = CDNs > are advertising the same host or not. There's no need for any more > complicated disambiguation. Ah yes, that was the primary reason I didn't like wildcarded hosts in = HostIndex/HostMetdata. It leads to non-determinism in dCDNs if they have = multiple uCDNs advertising CDNI Metadata for the same host wildcard. Ben >=20 > - in an implementation, if patterns aren't allowed, the requested > hostname can be hashed to do the HostIndex lookup, there's no need to = do a > linear search matching patterns across all known sites for every = request. > (I'm sure there are ways to make the search more efficient, but this = keeps > it simple.) >=20 > Another thought was that domains tend to be split for a reason - it = seems > likely that different subdomains will have different metadata = properties, > though we have no data to support that. >=20 >=20 > Rob. >=20 >>=20 >> I remember we discussed whether to allow a list of hosts in a >> HostMetadata and what occurs to me with that is that it doesn't buy = you >> much over having multiple HostMetadata objects linking to the same >> PathMetadata objects but I'm sure I had other reasons for not doing = it. >>=20 >> Having a special pattern to say all subdomains of this host might be >> useful but I need to think about it more in case it's ruled out by = one of >> the previous reasons that I can't remember right now. >>=20 >> Ben >>=20 >>=20 >> _______________________________________________ >> 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 kevin.ma@azukisystems.com Thu Jul 19 12:27:26 2012 Return-Path: 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 36AC321F8777 for ; Thu, 19 Jul 2012 12:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] 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 3hnCiXAs7vua for ; Thu, 19 Jul 2012 12:27:25 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 4D61821F8775 for ; Thu, 19 Jul 2012 12:27:25 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id A8300556F01; Thu, 19 Jul 2012 15:28:18 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id BEA3E556E8C; Thu, 19 Jul 2012 15:28:17 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Thu, 19 Jul 2012 15:28:05 -0400 From: Kevin J Ma To: Ben Niven-Jenkins , Rob Murray Date: Thu, 19 Jul 2012 15:28:15 -0400 Thread-Topic: [CDNi] Host pattern matches in CDNI Metadata (was Re: New Metadata Interface Draft (draft-cjlmw-cdni-metadata-00)) Thread-Index: Ac1l2r16h44pepFmTS+77Z4PN5XIdgACcvlw Message-ID: <291CC3F9E50E7641901A54E85D0977C65326E2B772@MAILR002.mail.lan> References: <0F70E030-DAE1-48D1-80C6-3B48CDC41FD8@niven-jenkins.co.uk> In-Reply-To: <0F70E030-DAE1-48D1-80C6-3B48CDC41FD8@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ben Niven-Jenkins , "cdni@ietf.org" Subject: Re: [CDNi] Host pattern matches in CDNI Metadata (was Re: New Metadata Interface Draft (draft-cjlmw-cdni-metadata-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 19:27:26 -0000 Could be worth a note in the draft, for future reference... > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Ben Niven-Jenkins > Sent: Thursday, July 19, 2012 2:17 PM > To: Rob Murray > Cc: Ben Niven-Jenkins; cdni@ietf.org > Subject: Re: [CDNi] Host pattern matches in CDNI Metadata (was Re: New > Metadata Interface Draft (draft-cjlmw-cdni-metadata-00)) >=20 >=20 >=20 > On 18 Jul 2012, at 09:36, Rob Murray wrote: >=20 > > On 17/07/2012 21:21, "Ben Niven-Jenkins" > wrote: > >> On 17 Jul 2012, at 21:01, Matt Caulfield (mcaulfie) wrote: > >>> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > >>> - In the HostMatch object, the hostname Property is defined as a > >>> String? Should there be Pattern support for hostnames? Also, > >>> does hostnames support both IP and DNS values? Also, does the > >>> hostname support a URI prefix that should be matched as part of > >>> the hostname, and not be included in the PathMatch? > >>> [Matt>] We debated whether or not to allow patterns in hostnames and > >>> decided against it. Ben can provide some of the background there. Yes= , > >>> the hostname should support both IP an DNS values. No, the hostname > does > >>> not include any other part of the URI. Will need to add some > >>> clarification on the hostname to the draft. > >> > >> Off hand I can't remember the obviously good reasons I used to convinc= e > >> Matt it was a bad idea. > > > > I think there were a couple of reasons, neither of them killer argument= s > > but they leant us towards the current position... > > > > - the HostIndex isn't ordered between CDNs, any given downstream > > request-router or surrogate may have a HostIndex assembled from several > > upstreams. If patterns aren't allowed in the HostMatch, either two CDNs > > are advertising the same host or not. There's no need for any more > > complicated disambiguation. >=20 > Ah yes, that was the primary reason I didn't like wildcarded hosts in > HostIndex/HostMetdata. It leads to non-determinism in dCDNs if they have > multiple uCDNs advertising CDNI Metadata for the same host wildcard. >=20 > Ben >=20 > > > > - in an implementation, if patterns aren't allowed, the requested > > hostname can be hashed to do the HostIndex lookup, there's no need to d= o > a > > linear search matching patterns across all known sites for every > request. > > (I'm sure there are ways to make the search more efficient, but this > keeps > > it simple.) > > > > Another thought was that domains tend to be split for a reason - it > seems > > likely that different subdomains will have different metadata > properties, > > though we have no data to support that. > > > > > > Rob. > > > >> > >> I remember we discussed whether to allow a list of hosts in a > >> HostMetadata and what occurs to me with that is that it doesn't buy yo= u > >> much over having multiple HostMetadata objects linking to the same > >> PathMetadata objects but I'm sure I had other reasons for not doing it= . > >> > >> Having a special pattern to say all subdomains of this host might be > >> useful but I need to think about it more in case it's ruled out by one > of > >> the previous reasons that I can't remember right now. > >> > >> Ben > >> > >> > >> _______________________________________________ > >> 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 ben@niven-jenkins.co.uk Thu Jul 19 13:17:50 2012 Return-Path: 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 67AD711E80A1 for ; Thu, 19 Jul 2012 13:17:50 -0700 (PDT) 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 Z4fVyYCuVODu for ; Thu, 19 Jul 2012 13:17:46 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id C0C9B11E8086 for ; Thu, 19 Jul 2012 13:17:45 -0700 (PDT) Received: from 52.red-80-25-156.staticip.rima-tde.net ([80.25.156.52] helo=[192.168.11.169]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SrxB9-0006Is-Km; Thu, 19 Jul 2012 21:18:39 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <291CC3F9E50E7641901A54E85D0977C65326E2B302@MAILR002.mail.lan> Date: Thu, 19 Jul 2012 21:18:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <166EBB70C264A9479E459B01B1BA6C9201B060@xmb-aln-x03.cisco.com> <291CC3F9E50E7641901A54E85D0977C65326E2AA7F@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C65326E2B302@MAILR002.mail.lan> To: Kevin J Ma X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "Ben Niven-Jenkins \(ben@velocix.com\)" , "cdni@ietf.org" Subject: Re: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni-metadata-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 20:17:50 -0000 Kevin, More responses inline. On 18 Jul 2012, at 20:11, Kevin J Ma wrote: >> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] >> On 16 Jul 2012, at 21:40, Kevin J Ma wrote: >>=20 >>> Hi Matt, >>>=20 >>> A couple of initial comments/questions about the merged draft: >>>=20 >>> - I do not understand the need for a heirarchical separation of the >>> Acquisition and Delivery objects? Why is the property "key" not >>> sufficient for designating the function of the metadata? >>=20 >> This is a good question and something we discussed at length amongst = the >> authors but probably don't really talk about in the draft. >>=20 >> We discussed a lot the trade offs between embedding all CDNI metadata >> properties together versus splitting some out into different object = that >> could be independently cached/retrieved. >>=20 >> We decided not to try to optimise too early so we took an approach of >> allowing any object to be embedded or independently addressable. This >> leads to the data model being slightly more convoluted and it can >> certainly be optimised a bit IMO. But we decided on an approach where = we >> first had a stable/agreed model with the WG and then we could revisit = it >> see what optimisations make sense. >=20 > Understood. My specific concerns were with: > a) how extra levels might impact local cache implementations, i.e., > which objects can be compacted locally vs. how much the structure > must be maintained, in order to understand how to update individual > objects without traversing the entire recursion tree, and If an implementation wants to maintain a local CDNI metadata cache and = compact/fold the multiple levels into a single "resource" in that local = cache it is free to do so and allowing arbitrary levels Vs a fixed = number of levels doesn't affect that. The main impact to the local cache implementation is that = compacting/folding hurts cacheability & may result in the size of the = local cache having to be larger than the total size of all the = individual resources (if individual resources are referenced by multiple = other resources). The local cache must use the most conservative = Expiry/TTL of all the compacted/folded resources. If the individual = resources being compacted/folded have significantly different TTLs (e.g. = I could imagine the TTLs for Location objects could be significantly = longer than for HostMetadata/SiteMetadata objects) then some resources = will need to be re-validated more often than would be necessary if the = local cache was not performing compacting/folding. > b) how error prone inheritance-based override might be if there are > alot of levels at which errant overrides could be applied. Error prone in what way? I don't see that dCDN implementations become more error prone because we = allow multiple levels as they will just reuse the same processing code = for each level. I can see that it might make it more likely that the "content provider = user" configuring the CDN/CDNI Metadata in the first place may be more = likely to make an error and forget to override a property but I don't = see that as much as a problem as in reality I don't expect there to be = that many levels actually used. I have a design principle that once you go past requiring 2 of = something, you may as well design for allowing an arbitrary number of = those things rather than choosing an artificial fixed value as a = maximum. >>> Is there a concept of >>> leaf vs. branch objects for override purposes? >>=20 >> I'm not exactly sure what you mean by leaf vs branch >=20 > My confusion comes from whether or not a Delivery object with an Auth = List > inside it overrides the Delivery object or just the Auth object. IMO it would just override the Auth object. > It could > be that the Delivery object is just a logical/organizational object = that is > never overriden in its entirety, in which case it could be considered = a > "branch", but the Auth List is a metadata object that requires = actions, > which could classify it as a "leaf". >=20 > If my root Delivery object has a protocol, location ACL, and auth = list, > and a Delivery object further down only specifies a location ACL: > a) is it valid, since it does not have a protocol? Yes it is valid. > b) does it only override the location ACL? > or does it imply that no auth list should be used? It just overrides the Location ACL. > i.e., do you have to re-specify every field? > if not are there rules for what falls through? Everything falls through unless it is overridden by the child object. > c) if it only overrides the location ACL, if one wanted to not have an > auth list at the lower level, does that require specifying an empty > auth list to override the root level auth list? It would require specifying an empty Auth list. >=20 > As has been noted, we probably need to expand the discussion of the > inheritance rules. Agreed. >>> Also, >>> does hostnames support both IP and DNS values? >>=20 >> I'm not sure of the use case for IP values as clients connecting to = CDNs >> aren't typically given a URL with an IP address as a hostname. >=20 > For the public Internet I would agree, however, there are cases where = MSOs > building internal CDNs prefer (for whatever reason) IP addresses. Let me understand this use case a bit more. Is it that the MSO/CDN operator prefers that redirects are performed to = IP addresses? or That the value of the Host: header the client presents in its GET = request is an IP address? I'm aware of the former, I'm not aware of the latter. >>> Also, does the >>> hostname support a URI prefix that should be matched as part of >>> the hostname, and not be included in the PathMatch? >>=20 >> No, the hostname is essentially the HTTP Host: header. All URL = prefixes >> are via PathMetadata. >=20 > So, in a case where a given CDN requires some type of URI path prefix, > would the CDN specific URI path prefix live in the PathMatch, or would > it be up to the local CDN to recognize the URI path prefix, and then > match against the remainder of the URL? e.g., >=20 > client requests cdn1.com/cdn1_prefix/video/x.m3u8 > cdn1 redirects to cdn2.com/cdn2_prefix/video/x.m3u8 >=20 > Do we think this a valid use case? If so, should the PathMatch have > a URI of "video/*.m3u8" or "cdnN_prefix/video/*.m3u8"? If the latter, > whose responsibility is it to properly construct that PathMatch and > what information would need to be passed between CDNs to do that? CDNI Metadata is expressed by the uCDN to the dCDN. If the dCDN needs to = use additional path prefixes material so that it can understand incoming = requests that have been redirected to it from another CDN then it may = need to tranform the CDNI Metadata it received from the uCDN when = expressing that CDNI Metadata to other dCDNs in the chain. It may also = be able to do the same through a mechanical conversion that doesn't = require transforming the CDNI Metadata it receives from the uCDN. So in the case you have above, if you took a CDNI Metadata feed from = both CDN1 & CDN2 the PatternMatch they each advertise for the same = content /video/x.m3u8 would be different (tailored to their own = requirements for path_prefixing to enable them to remap to the original = content request) but the delivery properties associated with those = different PatternMatches would be the same (assuming dCDNs are not = allowed to change/override the original delivery properties). >>> - For Lists of objects, I did not see a specific ordering defined? >>> Is there a way to enforce ordering? >>=20 >> Lists are ordered. In JSON they would be an array with N entries, = with >> index[0] being first and index[N-1] being last. >=20 > XML is a little more problematic with unordered lists. Good job my preference is that we use a JSON encoding then :-) (we put both in the draft as we couldn't reach consensus among the = authors whether to use JSON or XML) > For this to work, the list itself must be cached as an object, as it > contains the explicit ordering? It is not just the objects which it > references that need to be cached and refreshed, i.e., the list order > could change even if none of the objects in the list have changed? >=20 > If using the native JSON directly, it is probably implied, but as a > generic model for other implementations it might be worth explicitly > defining the properties of a list? Sure we can do that. Ben From ben@niven-jenkins.co.uk Thu Jul 19 14:00:45 2012 Return-Path: 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 58DBC11E80AD for ; Thu, 19 Jul 2012 14:00:45 -0700 (PDT) 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 Z+pc05xtCS+l for ; Thu, 19 Jul 2012 14:00:44 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 84B7B11E80A5 for ; Thu, 19 Jul 2012 14:00:44 -0700 (PDT) Received: from 52.red-80-25-156.staticip.rima-tde.net ([80.25.156.52] helo=[192.168.11.169]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Srxqr-0004TZ-Kl; Thu, 19 Jul 2012 22:01:38 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <291CC3F9E50E7641901A54E85D0977C65326E2B2FF@MAILR002.mail.lan> Date: Thu, 19 Jul 2012 22:01:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <818C8FBD-F5F5-4557-923B-3C0AECBBBF2E@niven-jenkins.co.uk> References: <166EBB70C264A9479E459B01B1BA6C9201B060@xmb-aln-x03.cisco.com> <291CC3F9E50E7641901A54E85D0977C65326E2AA7F@MAILR002.mail.lan> <166EBB70C264A9479E459B01B1BA6C9201F7B3@xmb-aln-x03.cisco.com> <291CC3F9E50E7641901A54E85D0977C65326E2B1C4@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C65326E2B2FF@MAILR002.mail.lan> To: Kevin J Ma X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "Ben Niven-Jenkins \(ben@velocix.com\)" , "cdni@ietf.org" Subject: Re: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni-metadata-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 21:00:45 -0000 Kevin, Matt, Jumping in on one point below. On 18 Jul 2012, at 20:10, Kevin J Ma wrote: >> From: Matt Caulfield (mcaulfie) [mailto:mcaulfie@cisco.com] >> In general, if there are an arbitrary number of levels below each >> object, and an arbitrary number of levels of PathMetadata which >> may contain objects with arbitrary levels of metadata which may >> override previous levels, is there a need to check that duplicate >> Metadata do not exist within a given subtree, and/or should that >> restriction be stated explicity? >> [Matt>] I'm not sure what you mean by duplicate metadata. Each >> PathMetadata object defines a bunch of metadata properties, each one = is >> unique. Each PathMetadata object either inherits or overrides the = metadata >> properties of its parent. >=20 > I guess I was thinking more about scope, not across multiple = PathMetadata > objects, but within a single one, e.g.: >=20 > Delivery has an auth property. If someone add a new x-azuki property = to > the Delivery property and the x-azuki property has its own auth = property. > Is there a conflict? IMO it should be up to the specification of the x-azuki property to = define what it's behaviour is where there is an interaction between its = presence and the presence of another property. > Presumably the delivery/x-azuki/auth property is distinct from the > delivery/auth property? And the precedence of the two auth properties > would be defined by the x-azuki/auth property? If there was also a > delivery/x-cisco/auth property and a delivery/x-velocix/auth it gets > a little more complex. Not really unless someone is expecting to use the delivery/x-azuki/auth = property alongside the delivery/x-velocix/auth property to get a = different behaviour than if they'd only included one or the other of the = two properties. But that's what you get if you try to use two vendor-specific extensions = from different vendors at the same time in the hope that the presence of = them both will give you a behaviour that neither by themselves would = give you. It'll be the same situation regardless of how we represent = vendor specific extensions IMO. Ben > Should there be restrictions on naming and/or > overriding existing metadata object functions, or is it just left up > to the implementors to do the right thing? From kevin.ma@azukisystems.com Thu Jul 19 14:27:30 2012 Return-Path: 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 C711921F8683 for ; Thu, 19 Jul 2012 14:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] 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 9fZyxoiGyOWS for ; Thu, 19 Jul 2012 14:27:26 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE4021F85F8 for ; Thu, 19 Jul 2012 14:27:26 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 945DE416B44; Thu, 19 Jul 2012 17:07:39 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB012.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 5F7BD416BC2; Thu, 19 Jul 2012 17:07:31 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Thu, 19 Jul 2012 17:27:21 -0400 From: Kevin J Ma To: Ben Niven-Jenkins Date: Thu, 19 Jul 2012 17:27:23 -0400 Thread-Topic: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni-metadata-00) Thread-Index: Ac1l66ndk0BpZc4cQgmoc2dqOshVRAAAXq2A Message-ID: <291CC3F9E50E7641901A54E85D0977C65326EC6EE7@MAILR002.mail.lan> References: <166EBB70C264A9479E459B01B1BA6C9201B060@xmb-aln-x03.cisco.com> <291CC3F9E50E7641901A54E85D0977C65326E2AA7F@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C65326E2B302@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Ben Niven-Jenkins \(ben@velocix.com\)" , "cdni@ietf.org" Subject: Re: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni-metadata-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 21:27:30 -0000 Hi Ben, comments inline: > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Thursday, July 19, 2012 4:18 PM > To: Kevin J Ma > Cc: Matt Caulfield (mcaulfie); cdni@ietf.org; Ben Niven-Jenkins > (ben@velocix.com) > Subject: Re: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni- > metadata-00) >=20 > Kevin, >=20 > More responses inline. >=20 > On 18 Jul 2012, at 20:11, Kevin J Ma wrote: >=20 > >> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > >> On 16 Jul 2012, at 21:40, Kevin J Ma wrote: > >> [snip] > > b) how error prone inheritance-based override might be if there are > > alot of levels at which errant overrides could be applied. >=20 > Error prone in what way? Error prone in the definition and resolution of object names/hierarchies going forward, especially wrt overrides. I personally prefer separation of metadata definitions (e.g., how do you construct an ACL list) from the metadata concept (i.e., we need a location ACL list). Please see the continued discussion below... [snip] > >>> Is there a concept of > >>> leaf vs. branch objects for override purposes? > >> > >> I'm not exactly sure what you mean by leaf vs branch > > > > My confusion comes from whether or not a Delivery object with an Auth > List > > inside it overrides the Delivery object or just the Auth object. >=20 > IMO it would just override the Auth object. >=20 > > It could > > be that the Delivery object is just a logical/organizational object tha= t > is > > never overriden in its entirety, in which case it could be considered a > > "branch", but the Auth List is a metadata object that requires actions, > > which could classify it as a "leaf". > > > > If my root Delivery object has a protocol, location ACL, and auth list, > > and a Delivery object further down only specifies a location ACL: > > a) is it valid, since it does not have a protocol? >=20 > Yes it is valid. >=20 > > b) does it only override the location ACL? > > or does it imply that no auth list should be used? >=20 > It just overrides the Location ACL. >=20 > > i.e., do you have to re-specify every field? > > if not are there rules for what falls through? >=20 > Everything falls through unless it is overridden by the child object. So, the child is a leaf in my terms? And only leaf objects are overridable= . But the Location ACL is actualy made up of other objects (i.e., ACL and ACLRule objects, and Location/TimeWindow objects below that), so it's not actually a leaf object in the data model defined in the draft, but it is a leaf object in what I see as the CDNI metadata model abstraction, which has the distinction between CDNI metadata properties (i.e., the concept), and the ancillary objects that make up the value (i.e., the definition). The Location ACL may be an object, and that object may be serializable into the JSON just as it is currently defined, but it's not clear to me that we would want to allow individual portions of that object to be overridden? The current model doesn't specify which objects can and cannot be overridde= n. If we want certain objects (and all their children) to be treated as atomic units, then I think that needs to be represented in the data model. [snip] > >>> Also, > >>> does hostnames support both IP and DNS values? > >> > >> I'm not sure of the use case for IP values as clients connecting to > CDNs > >> aren't typically given a URL with an IP address as a hostname. > > > > For the public Internet I would agree, however, there are cases where > MSOs > > building internal CDNs prefer (for whatever reason) IP addresses. >=20 > Let me understand this use case a bit more. >=20 > Is it that the MSO/CDN operator prefers that redirects are performed to I= P > addresses? >=20 > or >=20 > That the value of the Host: header the client presents in its GET request > is an IP address? >=20 > I'm aware of the former, I'm not aware of the latter. We have seen cases where there is no DNS in the network and the client is only presented with an IP address. I don't know how prevalent it is, but it should not really be an issue to support, should it? > >>> Also, does the > >>> hostname support a URI prefix that should be matched as part of > >>> the hostname, and not be included in the PathMatch? > >> > >> No, the hostname is essentially the HTTP Host: header. All URL prefixe= s > >> are via PathMetadata. > > > > So, in a case where a given CDN requires some type of URI path prefix, > > would the CDN specific URI path prefix live in the PathMatch, or would > > it be up to the local CDN to recognize the URI path prefix, and then > > match against the remainder of the URL? e.g., > > > > client requests cdn1.com/cdn1_prefix/video/x.m3u8 > > cdn1 redirects to cdn2.com/cdn2_prefix/video/x.m3u8 > > > > Do we think this a valid use case? If so, should the PathMatch have > > a URI of "video/*.m3u8" or "cdnN_prefix/video/*.m3u8"? If the latter, > > whose responsibility is it to properly construct that PathMatch and > > what information would need to be passed between CDNs to do that? >=20 > CDNI Metadata is expressed by the uCDN to the dCDN. If the dCDN needs to > use additional path prefixes material so that it can understand incoming > requests that have been redirected to it from another CDN then it may nee= d > to tranform the CDNI Metadata it received from the uCDN when expressing > that CDNI Metadata to other dCDNs in the chain. It may also be able to do > the same through a mechanical conversion that doesn't require transformin= g > the CDNI Metadata it receives from the uCDN. >=20 > So in the case you have above, if you took a CDNI Metadata feed from both > CDN1 & CDN2 the PatternMatch they each advertise for the same content > /video/x.m3u8 would be different (tailored to their own requirements for > path_prefixing to enable them to remap to the original content request) > but the delivery properties associated with those different PatternMatche= s > would be the same (assuming dCDNs are not allowed to change/override the > original delivery properties). So, CDN1 would receive /video/*.m3u8 (from either a uCDN or CP), and add in the /cdn1_prefix to its local PathMatch objects resulting in local PathMatc= h objects with /cdn1_prefix/video/*.m3u8. When CDN2 requested the metadata, CDN1 would provide /cdn1_prefix/video/x.m3u8 to CDN2, rather than stripping off the /cdn1_prefix and providing /video/*.m3u8? CDN2 would then need to know to strip off the /cdn1_prefix, before adding its own /cdn2_prefix to its PathMatch objects? (Presumably the request routing already knows about the required rewrite between CDN1 and CDN2.) thanx. -- Kevin J. Ma > >>> - For Lists of objects, I did not see a specific ordering defined? > >>> Is there a way to enforce ordering? > >> > >> Lists are ordered. In JSON they would be an array with N entries, with > >> index[0] being first and index[N-1] being last. > > > > XML is a little more problematic with unordered lists. >=20 > Good job my preference is that we use a JSON encoding then :-) >=20 > (we put both in the draft as we couldn't reach consensus among the author= s > whether to use JSON or XML) >=20 > > For this to work, the list itself must be cached as an object, as it > > contains the explicit ordering? It is not just the objects which it > > references that need to be cached and refreshed, i.e., the list order > > could change even if none of the objects in the list have changed? > > > > If using the native JSON directly, it is probably implied, but as a > > generic model for other implementations it might be worth explicitly > > defining the properties of a list? >=20 > Sure we can do that. >=20 > Ben From kevin.ma@azukisystems.com Thu Jul 19 14:36:43 2012 Return-Path: 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 0C11D11E80EB for ; Thu, 19 Jul 2012 14:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] 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 DOyNv69UzUBA for ; Thu, 19 Jul 2012 14:36:42 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 853DF11E80EE for ; Thu, 19 Jul 2012 14:36:40 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 79F538BE8A1; Thu, 19 Jul 2012 17:37:34 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 152488BE89E; Thu, 19 Jul 2012 17:37:34 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Thu, 19 Jul 2012 17:37:33 -0400 From: Kevin J Ma To: Ben Niven-Jenkins Date: Thu, 19 Jul 2012 17:37:32 -0400 Thread-Topic: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni-metadata-00) Thread-Index: Ac1l8cfDQ7uId3TrTwOXAFIXEOJkywABFRQw Message-ID: <291CC3F9E50E7641901A54E85D0977C65326EC6EF1@MAILR002.mail.lan> References: <166EBB70C264A9479E459B01B1BA6C9201B060@xmb-aln-x03.cisco.com> <291CC3F9E50E7641901A54E85D0977C65326E2AA7F@MAILR002.mail.lan> <166EBB70C264A9479E459B01B1BA6C9201F7B3@xmb-aln-x03.cisco.com> <291CC3F9E50E7641901A54E85D0977C65326E2B1C4@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C65326E2B2FF@MAILR002.mail.lan> <818C8FBD-F5F5-4557-923B-3C0AECBBBF2E@niven-jenkins.co.uk> In-Reply-To: <818C8FBD-F5F5-4557-923B-3C0AECBBBF2E@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Ben Niven-Jenkins \(ben@velocix.com\)" , "cdni@ietf.org" Subject: Re: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni-metadata-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 21:36:43 -0000 Hi Ben, inline: > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Thursday, July 19, 2012 5:02 PM > To: Kevin J Ma > Cc: Matt Caulfield (mcaulfie); cdni@ietf.org; Ben Niven-Jenkins > (ben@velocix.com) > Subject: Re: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni- > metadata-00) >=20 > Kevin, Matt, >=20 > Jumping in on one point below. >=20 > On 18 Jul 2012, at 20:10, Kevin J Ma wrote: > >> From: Matt Caulfield (mcaulfie) [mailto:mcaulfie@cisco.com] > >> In general, if there are an arbitrary number of levels below each > >> object, and an arbitrary number of levels of PathMetadata which > >> may contain objects with arbitrary levels of metadata which may > >> override previous levels, is there a need to check that duplicate > >> Metadata do not exist within a given subtree, and/or should that > >> restriction be stated explicity? > >> [Matt>] I'm not sure what you mean by duplicate metadata. Each > >> PathMetadata object defines a bunch of metadata properties, each one i= s > >> unique. Each PathMetadata object either inherits or overrides the > metadata > >> properties of its parent. > > > > I guess I was thinking more about scope, not across multiple > PathMetadata > > objects, but within a single one, e.g.: > > > > Delivery has an auth property. If someone add a new x-azuki property t= o > > the Delivery property and the x-azuki property has its own auth > property. > > Is there a conflict? >=20 > IMO it should be up to the specification of the x-azuki property to defin= e > what it's behaviour is where there is an interaction between its presence > and the presence of another property. Fair enough. thanx. -- Kevin J. Ma > > Presumably the delivery/x-azuki/auth property is distinct from the > > delivery/auth property? And the precedence of the two auth properties > > would be defined by the x-azuki/auth property? If there was also a > > delivery/x-cisco/auth property and a delivery/x-velocix/auth it gets > > a little more complex. >=20 > Not really unless someone is expecting to use the delivery/x-azuki/auth > property alongside the delivery/x-velocix/auth property to get a differen= t > behaviour than if they'd only included one or the other of the two > properties. >=20 > But that's what you get if you try to use two vendor-specific extensions > from different vendors at the same time in the hope that the presence of > them both will give you a behaviour that neither by themselves would give > you. It'll be the same situation regardless of how we represent vendor > specific extensions IMO. >=20 > Ben >=20 > > Should there be restrictions on naming and/or > > overriding existing metadata object functions, or is it just left up > > to the implementors to do the right thing? >=20 From flefauch@cisco.com Fri Jul 20 02:09:00 2012 Return-Path: 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 1409321F8505 for ; Fri, 20 Jul 2012 02:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.558 X-Spam-Level: X-Spam-Status: No, score=-10.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 RAyH8cTaKG+C for ; Fri, 20 Jul 2012 02:08:59 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id AD56421F8503 for ; Fri, 20 Jul 2012 02:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=7873; q=dns/txt; s=iport; t=1342775394; x=1343984994; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mE5WREFUHwudfRncSUwKDakEvTslYffbuOdby8xu0vg=; b=QasUzyiKTAkZk5Q3BqPtx2iKrgIlPC/ngpr6uUsX9nPBpfZGBgiT2V0f j+QNOJaP9nItMTjOs0fTfOINshoLLPlrgWqnhhuYtNZs9UDDOpVrht1rZ TYQD3shaW7CQW0SgXBZ8Dr/i6pQ45GvlGPnX5bRDYKYuimPl0n8ZbRMWq M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACcgCVCtJV2a/2dsb2JhbAA7Crk+gQeCIAEBAQMBAQEBDwFbCwULAgEIGCcHJwsUEQIEDgUJGYdlBgueVKAii0wKBgqFZmADiBiNLIETiXeDGYFmgl+BXw X-IronPort-AV: E=Sophos;i="4.77,621,1336348800"; d="scan'208";a="103755422" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 20 Jul 2012 09:09:53 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6K99rSO032348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Jul 2012 09:09:53 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.17]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Fri, 20 Jul 2012 04:09:53 -0500 From: "Francois Le Faucheur (flefauch)" To: " " Thread-Topic: I-D Action: draft-lelouedec-cdni-request-routing-00.txt Thread-Index: AQHNZOc4lDL9eO+7BkC/VTJJ7ud0wpcwnPuAgAGb6QA= Date: Fri, 20 Jul 2012 09:09:52 +0000 Message-ID: <52A7DC4F-D5F1-40FB-A8D9-4E9C424A710A@cisco.com> References: <20120709165434.9858.81618.idtracker@ietfa.amsl.com> <3FBC9023-91C7-4F14-AFA8-C57B27301012@cisco.com> <12783_1342686964_5007C6F4_12783_1364_2_2AC63C9F27AF8446B0C064C50FC0A89304BD59@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <12783_1342686964_5007C6F4_12783_1364_2_2AC63C9F27AF8446B0C064C50FC0A89304BD59@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.199] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19052.005 x-tm-as-result: No--57.302200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <72B08EB655477C46B7657C1E5CD7AD0B@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 09:09:00 -0000 Hello Gilles, On 19 Jul 2012, at 10:35, wrote: > Fran=E7ois, >=20 > Our draft proposes a constructive approach to help the working group prog= ress on CDNI the request routing and signaling aspects. We therefore propos= e clarifications of the fundamental routing concepts in CDNI as we think th= at these concepts were not yet defined clearly enough. >=20 > The new charter indeed introduces a splitting of the request routing inte= rface. We consider this as a good progress towards refining the interface r= oles and this move is consistent the spirit of our propositions, even if we= are not fully satisfied with the current terminology, as explained in http= ://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00.=20 >=20 > We could live along with the current charter text and consider that: > - "Redirection interface" interface is close to what we call the "Downstr= eam Resource Identifier Signaling interface" > - "Footprint & Capabilities Advertisement" is close to what we call the "= CDNI Routing interface" > with the clarifications provided in http://tools.ietf.org/html/draft-lelo= uedec-cdni-request-routing-00. >=20 > We could start discussing this issue in the informal gathering on request= routing proposed by Yannick on Sunday evening. Right. My suggestion is that, after this discussion, you identify the incremental = changes/clarification you still want to propose - given the current definit= ion/description of the RR/Redirection interface and the RR/Footprint & Capa= bilities Advertisement interface (for example, consider also the descriptio= n of these interfaces in the problem-statement) - and then structure those = as: * proposed changes to the Framewok * proposed input into the work of the RR/Footprint & Advertisement Design = Team=20 * proposed input into a RR/Redirection interface spec This is just a suggestion aiming at making your input effective for the WG. Cheers Francois >=20 > Best regards, > -- > Gilles >=20 >=20 > -----Message d'origine----- > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de F= rancois Le Faucheur (flefauch) > Envoy=E9 : mercredi 18 juillet 2012 15:14 > =C0 : cdni@ietf.org > Objet : Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.tx= t >=20 > Authors, >=20 > This document spends a lot of time proposing to split the "Request Routin= g" interface into two interfaces. In particular, its conclusions include: >=20 > " > We also recommend to review the charter of the CDNI WG, in particular > to replace the following objective: >=20 > o "WG Creation + 18 months: Submit specification of the CDNI Request > Routing protocol to IESG as Proposed Standard" >=20 > by the two following objectives: >=20 > o "WG Creation + 18 months: Submit specification of the CDNI Routing > interface to IESG as Proposed Standard" >=20 > o "WG Creation + 18 months: Submit specification of the CDNI > Downstream Resource Identifier Signaling (DRIS) Interface to IESG > as Proposed Standard" > " >=20 > Can you guys consider the fact that the charter has already been updated = two months ago (http://www.ietf.org/mail-archive/web/cdni/current/msg00989.= html) to split the Request Routing into 2 interfaces and already reads: > " > o Dec 2012 - Submit specification of the CDNI Request Routing/Redirectio= n interface to IESG as Proposed Standard ... > o Jun 2013 - Submit specification of the CDNI Request Routing/Footprint = & Capabilities Advertisement interface to IESG as Proposed Standard " >=20 > Does this not basically already address your point? >=20 > Cheers >=20 > Francois >=20 >=20 > On 9 Jul 2012, at 18:54, wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >>=20 >>=20 >> Title : CDNI Request Routing >> Author(s) : Yannick Le Louedec >> Anne Marrec >> Gilles Bertrand >> Marcin Pilarski >> Filename : draft-lelouedec-cdni-request-routing-00.txt >> Pages : 30 >> Date : 2012-07-09 >>=20 >> Abstract: >> The present document proposes to clarify the CDNI Request Routing >> interface introduced in [I-D.ietf-cdni-framework] and [I-D.ietf-cdni- >> problem-statement], as well as related terminology. >>=20 >> In particular the present document proposes to split the CDNI Request >> Routing interface into two separate interfaces with clearer roles, >> named respectively CDNI Routing interface and CDNI Downstream >> Resource Identifier Signaling interface (CDNI DRIS interface). >>=20 >> This part of the CDN interconnection framework the IETF has been >> referring to so far with the term "CDNI Request Routing" is just >> another routing, signaling and forwarding problem in a long series of >> the telecommunication history. For example, one can draw a direct >> analogy between the IP/MPLS-TE framework and the CDN interconnection >> framework. >>=20 >> In addition, this document recommends that the specification of ALL >> CDN interconnection interfaces in the scope of the CDNI IETF WG >> relies on the equivalent concept to IP prefix for CDN >> interconnection, named 'contentRequestScope'. This highly useful and >> powerful concept SHALL be used to simplify the specification of ALL >> CDN interconnection interfaces, as well as to ensure performance and >> scalability in CDN interconnection. >>=20 >> All these proposals can be smoothly integrated in the WG drafts, >> especially [I-D.ietf-cdni-framework] and >> [I-D.ietf-cdni-requirements], as they essentially propose (useful) >> clarifications of the existing framework. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-routing >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> 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=20 >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 From yannick.lelouedec@orange.com Fri Jul 20 05:27:17 2012 Return-Path: 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 3FFEA21F85D7 for ; Fri, 20 Jul 2012 05:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=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 tfcaNDZhw8Gl for ; Fri, 20 Jul 2012 05:27:16 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B76AA21F85D3 for ; Fri, 20 Jul 2012 05:27:15 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 5A79C22C527; Fri, 20 Jul 2012 14:28:10 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 36CBA35C058; Fri, 20 Jul 2012 14:28:10 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Fri, 20 Jul 2012 14:28:06 +0200 From: To: "Woundy, Richard" , "Francois Le Faucheur (flefauch@cisco.com)" , Scott Wainner , Ben Niven-Jenkins , "Brandenburg, R. (Ray) van" , "cdni@ietf.org" Thread-Topic: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI request routing interface Thread-Index: AQHNY2A5fo4MVwP740iQcVbJGEbAwJcyGMnQ Date: Fri, 20 Jul 2012 12:28:05 +0000 Message-ID: <6600_1342787290_50094EDA_6600_4066_1_d3cac703-4dbd-435d-b762-cf9ea6296b54@PEXCVZYH02.corporate.adroot.infra.ftgroup> References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> <2040_1341930789_4FFC3D24_2040_2504_1_b86bff40-ae68-40c0-b8e5-060f51be6864@PEXCVZYH02.corporate.adroot.infra.ftgroup> <3A7EA7EE-F8D4-4094-83F2-12CD3826B662@tno.nl> <5004079D.4000406@cisco.com> <20625_1342449311_5004269F_20625_735_1_e5fd8c10-b453-4cfa-8821-c05811f6324f@PEXCVZYH02.corporate.adroot.infra.ftgroup> In-Reply-To: <20625_1342449311_5004269F_20625_735_1_e5fd8c10-b453-4cfa-8821-c05811f6324f@PEXCVZYH02.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.20.112417 Subject: Re: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI request routing 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 12:27:17 -0000 Dear all, The doodle for the side meeting in Vancouver on CDNI request routing is her= e: http://www.doodle.com/n552qchpurfcpckn=20 Please fill it in as soon as possible if you intend to attend. Ideally we would like to arrange this meeting at Hyatt Regency Hotel, on Mo= nday evening, after the welcoming session. Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de y= annick.lelouedec@orange.com Envoy=E9=A0: lundi 16 juillet 2012 16:35 =C0=A0: Scott Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@i= etf.org Objet=A0: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI request= routing interface Dear all, We propose to arrange a side meeting on Sunday evening during IETF #84 (i.e= . on July 29th) on the CDNI request routing interface. The objective is to clear the discussion we had these last days via the IET= F CDNI mailing list, and to ease an efficient meeting on Tuesday 31. If everybody agrees that this is a good idea, we will set up a doodle. Best regards, Yannick Le Lou=E9dec, Orange OLNC. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, France Telecom - = Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From gilles.bertrand@orange.com Mon Jul 23 00:53:52 2012 Return-Path: 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 2C92621F8697 for ; Mon, 23 Jul 2012 00:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.658, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 vYKhp-PJ0Y5K for ; Mon, 23 Jul 2012 00:53:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id DE29B21F8505 for ; Mon, 23 Jul 2012 00:53:50 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 98F0022C365; Mon, 23 Jul 2012 09:53:49 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 75F69238059; Mon, 23 Jul 2012 09:53:49 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Mon, 23 Jul 2012 09:53:42 +0200 From: To: LE LOUEDEC Yannick RD-CORE , "Woundy, Richard" , "Francois Le Faucheur (flefauch@cisco.com)" , Scott Wainner , Ben Niven-Jenkins , "Brandenburg, R. (Ray) van" , "cdni@ietf.org" Thread-Topic: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI request routing interface Thread-Index: AQHNY2A5fo4MVwP740iQcVbJGEbAwJcyGMnQgARwy5A= Date: Mon, 23 Jul 2012 07:53:22 +0000 Message-ID: <7236_1343030029_500D030D_7236_3596_1_43f35d19-f090-4315-a880-5046bc0c63d6@PEXCVZYH02.corporate.adroot.infra.ftgroup> References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> <2040_1341930789_4FFC3D24_2040_2504_1_b86bff40-ae68-40c0-b8e5-060f51be6864@PEXCVZYH02.corporate.adroot.infra.ftgroup> <3A7EA7EE-F8D4-4094-83F2-12CD3826B662@tno.nl> <5004079D.4000406@cisco.com> <20625_1342449311_5004269F_20625_735_1_e5fd8c10-b453-4cfa-8821-c05811f6324f@PEXCVZYH02.corporate.adroot.infra.ftgroup> <457F4B94DBADF743B61D350B3E7929FE020572@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <457F4B94DBADF743B61D350B3E7929FE020572@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.21.123318 Subject: Re: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI request routing 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 07:53:52 -0000 Yannick,=20 You probably mean on "Sunday" evening after the welcoming session?=20 Best regards, -- Gilles -----Message d'origine----- De=A0: LE LOUEDEC Yannick RD-CORE=20 Envoy=E9=A0: vendredi 20 juillet 2012 14:28 =C0=A0: Woundy, Richard; Francois Le Faucheur (flefauch@cisco.com); Scott W= ainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.org Cc=A0: STEPHAN Emile RD-CORE; BERTRAND Gilles RD-CORE Objet=A0: RE: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI req= uest routing interface Dear all, The doodle for the side meeting in Vancouver on CDNI request routing is her= e: http://www.doodle.com/n552qchpurfcpckn Please fill it in as soon as possible if you intend to attend. Ideally we would like to arrange this meeting at Hyatt Regency Hotel, on Mo= nday evening, after the welcoming session. Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de y= annick.lelouedec@orange.com Envoy=E9=A0: lundi 16 juillet 2012 16:35 =C0=A0= : Scott Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.or= g Objet=A0: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI reque= st routing interface Dear all, We propose to arrange a side meeting on Sunday evening during IETF #84 (i.e= . on July 29th) on the CDNI request routing interface. The objective is to clear the discussion we had these last days via the IET= F CDNI mailing list, and to ease an efficient meeting on Tuesday 31. If everybody agrees that this is a good idea, we will set up a doodle. Best regards, Yannick Le Lou=E9dec, Orange OLNC. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, France Telecom - = Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From yannick.lelouedec@orange.com Mon Jul 23 01:07:38 2012 Return-Path: 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 1214621F86D3 for ; Mon, 23 Jul 2012 01:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=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 JEWxXmP8W2hs for ; Mon, 23 Jul 2012 01:07:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C41A721F86D1 for ; Mon, 23 Jul 2012 01:07:36 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 305593B42A4; Mon, 23 Jul 2012 10:07:36 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 0C33635C048; Mon, 23 Jul 2012 10:07:36 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Mon, 23 Jul 2012 10:07:33 +0200 From: To: BERTRAND Gilles RD-CORE , "Woundy, Richard" , "Francois Le Faucheur (flefauch@cisco.com)" , Scott Wainner , Ben Niven-Jenkins , "Brandenburg, R. (Ray) van" , "cdni@ietf.org" Thread-Topic: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI request routing interface Thread-Index: AQHNY2A5fo4MVwP740iQcVbJGEbAwJcyGMnQgARwy5CAAAIAIA== Date: Mon, 23 Jul 2012 08:07:32 +0000 Message-ID: <19575_1343030856_500D0648_19575_7867_1_32076722-70e1-40b8-951d-d02e511b336c@PEXCVZYH01.corporate.adroot.infra.ftgroup> References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> <2040_1341930789_4FFC3D24_2040_2504_1_b86bff40-ae68-40c0-b8e5-060f51be6864@PEXCVZYH02.corporate.adroot.infra.ftgroup> <3A7EA7EE-F8D4-4094-83F2-12CD3826B662@tno.nl> <5004079D.4000406@cisco.com> <20625_1342449311_5004269F_20625_735_1_e5fd8c10-b453-4cfa-8821-c05811f6324f@PEXCVZYH02.corporate.adroot.infra.ftgroup> <457F4B94DBADF743B61D350B3E7929FE020572@PEXCVZYM11.corporate.adroot.infra.ftgroup> <2AC63C9F27AF8446B0C064C50FC0A89304D027@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <2AC63C9F27AF8446B0C064C50FC0A89304D027@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.23.63919 Subject: Re: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI request routing 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 08:07:38 -0000 Dear Gilles, All, I mean on Monday, After the welcome session in case the representatives from the CDNIW G must= attend it (Extract from Monday's agenda : "1730 - 1800 Welcome, 1. Welcome= - Bernard Aboba..."). Otherwise (if the representatives must not attend this welcome session), we= could even possibly arrange it at the same time if it appears that most pe= ople are available at that time. Our initial plan was indeed to arrange it rather on Sunday, but some people= will be available from Monday on only. Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: BERTRAND Gilles RD-CORE=20 Envoy=E9=A0: lundi 23 juillet 2012 09:53 =C0=A0: LE LOUEDEC Yannick RD-CORE; Woundy, Richard; Francois Le Faucheur (= flefauch@cisco.com); Scott Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray= ) van; cdni@ietf.org Cc=A0: STEPHAN Emile RD-CORE Objet=A0: RE: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI req= uest routing interface Yannick,=20 You probably mean on "Sunday" evening after the welcoming session?=20 Best regards, -- Gilles -----Message d'origine----- De=A0: LE LOUEDEC Yannick RD-CORE Envoy=E9=A0: vendredi 20 juillet 2012 14:28 =C0=A0: Woundy, Richard; Francois Le Faucheur (flefauch@cisco.com); Scott W= ainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.org Cc=A0: = STEPHAN Emile RD-CORE; BERTRAND Gilles RD-CORE Objet=A0: RE: [CDNi] IETF #8= 4 - Proposal for a side meeting on the CDNI request routing interface Dear all, The doodle for the side meeting in Vancouver on CDNI request routing is her= e: http://www.doodle.com/n552qchpurfcpckn Please fill it in as soon as possible if you intend to attend. Ideally we would like to arrange this meeting at Hyatt Regency Hotel, on Mo= nday evening, after the welcoming session. Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de y= annick.lelouedec@orange.com Envoy=E9=A0: lundi 16 juillet 2012 16:35 =C0=A0= : Scott Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.or= g Objet=A0: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI reque= st routing interface Dear all, We propose to arrange a side meeting on Sunday evening during IETF #84 (i.e= . on July 29th) on the CDNI request routing interface. The objective is to clear the discussion we had these last days via the IET= F CDNI mailing list, and to ease an efficient meeting on Tuesday 31. If everybody agrees that this is a good idea, we will set up a doodle. Best regards, Yannick Le Lou=E9dec, Orange OLNC. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, France Telecom - = Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From flefauch@cisco.com Mon Jul 23 01:23:37 2012 Return-Path: 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 371FB21F86A4 for ; Mon, 23 Jul 2012 01:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 zeJs85cgECrD for ; Mon, 23 Jul 2012 01:23:36 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE8021F86C3 for ; Mon, 23 Jul 2012 01:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=244; q=dns/txt; s=iport; t=1343031816; x=1344241416; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=dPJboxWkIrndr1CLYJtDum79OlDaf/5my9BLZbyPH7U=; b=e8qxkj7EWd0w/VhDyKDojXxqXsycj4buEuHrvr8zbT62tmQnBKRsDJHL f4r5SgXpHrhYJ5zuQwVA6AdFf4amPbF4dZNcs6KQy/NyoOLYH295vnGiy c2oEJ/rlG9SSqkFO0SCd4bbyuNt0pqyPnSUwsFxlFNiM5XtoKiUE6lnWu g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggGACUJDVCtJXG9/2dsb2JhbABEgyuCALQJgQeCJxIBJ1EBPkInBBwZh2sLnRyBKJ8TkUBgA5VJjieBZoJf X-IronPort-AV: E=Sophos;i="4.77,638,1336348800"; d="scan'208";a="104335448" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 23 Jul 2012 08:23:36 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6N8NaIv009315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 23 Jul 2012 08:23:36 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.17]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Mon, 23 Jul 2012 03:23:35 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: IETF-84 CDNI WG draft agenda posted Thread-Index: AQHNaKxz3BolPZpr9Eu1PO34MwcKFw== Date: Mon, 23 Jul 2012 08:23:35 +0000 Message-ID: <8F3AD620-73BA-44C6-866D-FFF52F23E699@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19058.004 x-tm-as-result: No--25.208500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <7060D3FA86D28F43AFD12129283655A0@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] IETF-84 CDNI WG draft agenda posted 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 08:23:37 -0000 Folks, The draft CDNI WG agenda is posted at: http://www.ietf.org/proceedings/84/agenda/agenda-84-cdni Please let us know if we have missed some presentation requests or if you h= ave general comments/suggestions. Francois & Rich= From flefauch@cisco.com Mon Jul 23 04:15:01 2012 Return-Path: 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 2DE0F21F84C9 for ; Mon, 23 Jul 2012 04:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.407 X-Spam-Level: X-Spam-Status: No, score=-10.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 MeXtoi40-hOT for ; Mon, 23 Jul 2012 04:15:00 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 01A6C21F846A for ; Mon, 23 Jul 2012 04:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=4583; q=dns/txt; s=iport; t=1343042100; x=1344251700; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=/Dwl0MZHi91THIr/9cnv2id/4Wq0hEqAL7QfRghFq0A=; b=YS+2IObUTbNemAHnkb/i95kgKx8ycb5X+DVdIx7RYxtjSVFjtcikxVLH zHaOLW9daR48p3w1pTa2h7qppIu+lyLNB0QYz5ZyULDvqNn0CColfs2yP BnYyDFy+6iD6H7O6l+OXG7xRifyOl6xffpCiaIZVjhnenV3/w8oo3PWmQ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPYxDVCtJXG8/2dsb2JhbABFuTWBB4IgAQEBAwEBAQEPASc0EAsCARkDAQIfECcLFAkIAgQTCRIHh2UGC54mnyeLTRWFXmADlUmBFIl5gxqBZoJfgVc X-IronPort-AV: E=Sophos;i="4.77,638,1336348800"; d="scan'208";a="104341467" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 23 Jul 2012 11:14:49 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6NBEmAC014171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 23 Jul 2012 11:14:48 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.17]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Mon, 23 Jul 2012 06:14:48 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Vancouver discussions on CDNI and HTTP Adaptive Bitrate Streaming Thread-Index: AQHNaMReJzBNMpPPekeRQ55PMVcekQ== Date: Mon, 23 Jul 2012 11:14:47 +0000 Message-ID: <14907C1F-86BA-48D9-BB58-3157B42CF01B@cisco.com> References: <20120713124933.24842.61000.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19058.005 x-tm-as-result: No--39.342800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <50F7BED56CAFFB4A8B03CC836D67CA6E@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Vancouver discussions on CDNI and HTTP Adaptive Bitrate Streaming 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 11:15:01 -0000 Folks, In line with the approach agreed in Paris, a lot of work has gone since int= o analysing the options for how the different CDNI interfaces could/should = handle HTTP Adaptive Bitrate Streaming (HAS) and in documenting this analys= is as well as recommendations to facilitate WG decisions. This includes the= work of the extended design team that held three virtual meetings since Pa= ris, as well as the work from Ray (and co-authors) in revving up draft-bran= denburg-cdni-has multiple times accordingly. Our objective for Vancouver is to reach tentative agreement on how the diff= erent CDNI interfaces are to handle HAS. To maximise our chances of success= , we'd like to request that people who want to contribute into that discuss= ion do read draft-brandenburg-cdni-has-03 before Vancouver, and engage into= as much clarification/discussion as possible on the list before Vancouver. In Vancouver, Ray and co-authors will give a brief recap of the options, th= eir pros-and-cons and of the recommendations, in order to try bring everyon= e up to speed. But it is a complex topic, with a lot of subtle ramification= s, and we feel the only way to have a constructive discussion in a constrai= n timeslot is if everyone shares a similar base level of terminology/unders= tanding. This is why we request that people be familar with the latest vers= ion of draft-brandenburg-cdni-has (ie -03). Note that for each of the dimensions analysed in draft-brandenburg-cdni-has= , there is a subsection highlighing the recommendations for that dimension = (specifically sections 3.1.3, 3.2.3, 3.3.3 , 3.4.3 and 3.5.9). In the context of that discussion, I would also like everyone to keep in mi= nd the following statement from our charter: " The CDNI WG aims at delivering a targeted, deployable solution in a short t= imeframe (18-24 months) as needed by the industry. " and the related guiding principle followed by the extended design team: " we have a strong motivation to develop first what is REQUIRED to make HAS w= ork. We need to focus on fundamentals to make HAS work vs how to use CDN-I = to make things work better. " Remember also that, once it has delivered a first set of CDNI interfaces, i= t is possible for the CDNI WG to propose to recharter in order to develop e= xtensions for more advanced functionality. So the HAS decisions that the WG= will make now only conditions what is to be included in the deliverables a= gainst the initial charter, it does not limit what might be supported by CD= NI interfaces in the future. Looking forward to discussing CDNI support for HAS in Vancouver or on the l= ist before. Cheers Francois & Rich Begin forwarded message: > From: > Subject: I-D Action: draft-brandenburg-cdni-has-03.txt > Date: 13 July 2012 14:49:33 CEST > To: > Reply-To: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : Models for adaptive-streaming-aware CDN Interconnectio= n > Author(s) : Ray van Brandenburg > Oskar van Deventer > Francois Le Faucheur > Kent Leung > Filename : draft-brandenburg-cdni-has-03.txt > Pages : 43 > Date : 2012-07-13 >=20 > Abstract: > This documents presents thoughts 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 could, and should, deal with content > delivered using adaptive streaming technologies and to facilitate > working group decisions. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-brandenburg-cdni-has >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-brandenburg-cdni-has-03 >=20 > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-brandenburg-cdni-has-03 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 flefauch@cisco.com Mon Jul 23 04:32:41 2012 Return-Path: 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 3098E21F8702 for ; Mon, 23 Jul 2012 04:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.564 X-Spam-Level: X-Spam-Status: No, score=-10.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 MT4dTV9zB3Qm for ; Mon, 23 Jul 2012 04:32:40 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFC221F86FF for ; Mon, 23 Jul 2012 04:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5238; q=dns/txt; s=iport; t=1343043160; x=1344252760; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ykwPjvHVQwwqaW/LvidLXN3QF/MRodBDo6KubLlqKAE=; b=XBmxP+sSBsmsP0VrOCE+a20MK3VVLxzUkcqSTuuTEibi4EUCow3h9QOb ck3wIRjo0X3bFYwOoLAER8jDUVQne7DVPcg5rG1ESSpnHHnIFabXci1o8 2CzPxU3XaxMeT9R+64qWBEdYwPmQVyaQy5qTYiymApVeAbQbwwaMoBYo7 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABc1DVCtJXG+/2dsb2JhbABFuTWBB4IgAQEBAwEBAQEPASc0EAsCAQgRAwECHxAnCxQJCAIEEwkSB4dlBgueH58oi00VhV5gA5VJgRSJeYMagWaCX4FX X-IronPort-AV: E=Sophos;i="4.77,638,1336348800"; d="scan'208";a="101360293" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 23 Jul 2012 11:32:39 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6NBWd2N000898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 23 Jul 2012 11:32:39 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.17]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0298.004; Mon, 23 Jul 2012 06:32:39 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: [CDNi] Vancouver discussions on CDNI and HTTP Adaptive Bitrate Streaming Thread-Index: AQHNaMbdvr13hR/Irk654Q7IOqlYwg== Date: Mon, 23 Jul 2012 11:32:39 +0000 Message-ID: <37F4FFC2-91FB-43B6-BA55-A72F28172081@cisco.com> References: <20120713124933.24842.61000.idtracker@ietfa.amsl.com> <14907C1F-86BA-48D9-BB58-3157B42CF01B@cisco.com> In-Reply-To: <14907C1F-86BA-48D9-BB58-3157B42CF01B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19058.005 x-tm-as-result: No--40.330700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <696E19D9E5187640A92D2E52A8394CE5@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Vancouver discussions on CDNI and HTTP Adaptive Bitrate Streaming 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 11:32:41 -0000 On 23 Jul 2012, at 13:14, Francois Le Faucheur (flefauch) wrote: > Folks, >=20 > In line with the approach agreed in Paris, a lot of work has gone since i= nto analysing the options for how the different CDNI interfaces could/shoul= d handle HTTP Adaptive Bitrate Streaming (HAS) and in documenting this anal= ysis as well as recommendations to facilitate WG decisions. This includes t= he work of the extended design team that held three virtual meetings since = Paris, as well as the work from Ray (and co-authors) in revving up draft-br= andenburg-cdni-has multiple times accordingly. >=20 > Our objective for Vancouver is to reach tentative agreement on how the di= fferent CDNI interfaces are to handle HAS. To maximise our chances of succe= ss, we'd like to request that people who want to contribute into that discu= ssion do read draft-brandenburg-cdni-has-03 before Vancouver, and engage in= to as much clarification/discussion as possible on the list before Vancouve= r. If someone would like some other proposals, or other options, to be conside= red for HAS handling, but missed the I-D posting deadline, we request they = document those on the list asap and before end of Wed 25 Jul (to give a cha= nce to others to look into it before Vancouver). Cheers Francois & Rich >=20 > In Vancouver, Ray and co-authors will give a brief recap of the options, = their pros-and-cons and of the recommendations, in order to try bring every= one up to speed. But it is a complex topic, with a lot of subtle ramificati= ons, and we feel the only way to have a constructive discussion in a constr= ain timeslot is if everyone shares a similar base level of terminology/unde= rstanding. This is why we request that people be familar with the latest ve= rsion of draft-brandenburg-cdni-has (ie -03). >=20 > Note that for each of the dimensions analysed in draft-brandenburg-cdni-h= as, there is a subsection highlighing the recommendations for that dimensio= n (specifically sections 3.1.3, 3.2.3, 3.3.3 , 3.4.3 and 3.5.9). >=20 > In the context of that discussion, I would also like everyone to keep in = mind the following statement from our charter: > " > The CDNI WG aims at delivering a targeted, deployable solution in a short= timeframe (18-24 months) as needed by the industry. > " > and the related guiding principle followed by the extended design team: > " > we have a strong motivation to develop first what is REQUIRED to make HAS= work. We need to focus on fundamentals to make HAS work vs how to use CDN-= I to make things work better. > " >=20 > Remember also that, once it has delivered a first set of CDNI interfaces,= it is possible for the CDNI WG to propose to recharter in order to develop= extensions for more advanced functionality. So the HAS decisions that the = WG will make now only conditions what is to be included in the deliverables= against the initial charter, it does not limit what might be supported by = CDNI interfaces in the future. >=20 > Looking forward to discussing CDNI support for HAS in Vancouver or on the= list before. >=20 > Cheers >=20 > Francois & Rich >=20 >=20 > Begin forwarded message: >=20 >> From: >> Subject: I-D Action: draft-brandenburg-cdni-has-03.txt >> Date: 13 July 2012 14:49:33 CEST >> To: >> Reply-To: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >>=20 >>=20 >> Title : Models for adaptive-streaming-aware CDN Interconnecti= on >> Author(s) : Ray van Brandenburg >> Oskar van Deventer >> Francois Le Faucheur >> Kent Leung >> Filename : draft-brandenburg-cdni-has-03.txt >> Pages : 43 >> Date : 2012-07-13 >>=20 >> Abstract: >> This documents presents thoughts 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 could, and should, deal with content >> delivered using adaptive streaming technologies and to facilitate >> working group decisions. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-brandenburg-cdni-has >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-brandenburg-cdni-has-03 >>=20 >> A diff from previous version is available at: >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-brandenburg-cdni-has-03 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> 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 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From swainner@cisco.com Mon Jul 23 07:33:15 2012 Return-Path: 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 18CCC11E8086 for ; Mon, 23 Jul 2012 07:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 O1C7kCE8DXJe for ; Mon, 23 Jul 2012 07:33:14 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6F211E807F for ; Mon, 23 Jul 2012 07:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=3274; q=dns/txt; s=iport; t=1343053994; x=1344263594; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=hq8fZ4xk4Ntd4RNp8CHSogSSL3fuAo4bn3y+/cwZYP8=; b=HqymkgpDW20HgYlBEQRD7/e6UhKM0ceJX1DZDN/cE8BGyovOlyEgJDZ2 U2WX/b1lefeJKdQFlxtGE5rTezvgUHJlthTR0G45W6QntVrsuPaG4BO/e DoIk3tgjZKMpZ2YtL//Ai7+9rcOXnhkM71KVzfgOYvoFkTcNqVdJmT+u9 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFVfDVCtJV2c/2dsb2JhbABFuTaBB4IgAQEBBAEBAQ8BJTYJAQ0ECxEEAQEBCRYIBwkDAgECARUfCAEIEwYCAQEFGYdrC51Hn0iLTRqGOQOVSYEUjROBZoJ7gUM X-IronPort-AV: E=Sophos;i="4.77,639,1336348800"; d="scan'208";a="104404205" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 23 Jul 2012 14:33:13 +0000 Received: from rtp-swainner-89110.cisco.com (rtp-swainner-89110.cisco.com [10.116.109.203]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6NEXDL6016028 for ; Mon, 23 Jul 2012 14:33:13 GMT Message-ID: <500D60A9.1050909@cisco.com> Date: Mon, 23 Jul 2012 10:33:13 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: cdni@ietf.org References: <20120713124933.24842.92028.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [CDNi] FW: New Version Notification for draft-brandenburg-cdni-has-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 14:33:15 -0000 Ray, Question on Section 3.5.4 Option 5.2.1: Flexible URL Signing by CSP Fourth Paragraph: "However, instead of signing the entire URL, the CSP signs the Relative URL (i.e. invariant portion of the URL) and conveys the protected portion in the authorization parameters embedded in the chunk URL." Are we proposing query string semantics in the URL that define what portion of the URL elements are protected and the method? In doing so, the CSP, uCDN, surrogates, and delivery nodes must support the query string semantics and methods. The uCDN must be made aware of the dCDN's capabilities to support this method of authorization prior to dCDN selection. I think this is noted in the section ... "Effect on CDN Interfaces: o Requires the ability to exclude the variant portion of URL in the signing process (NOTE: Issue is specific to URL Signing support for HAS content and not CDNI?)" I think this issue is relevant not only for HAS and needs to be address in CDNI capabilities advertisement if we're recommending Flexible URL Signing. Scott On 7/13/12 8:54 AM, Brandenburg, R. (Ray) van wrote: > Hi all, > > As you can see we just uploaded a new version of the HAS-CDNI draft. This is the version of the draft that we will be presenting during the Vancouver meeting. > > I'm looking forward to your comments and seeing you all in Vancouver! > > Best regards, > > Ray van Brandenburg > > > > > > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: vrijdag 13 juli 2012 14:50 > To: Brandenburg, R. (Ray) van > Cc: flefauch@cisco.com; kleung@cisco.com; Deventer, M.O. (Oskar) van > Subject: New Version Notification for draft-brandenburg-cdni-has-03.txt > > > A new version of I-D, draft-brandenburg-cdni-has-03.txt has been successfully submitted by Ray van Brandenburg and posted to the IETF repository. > > Filename: draft-brandenburg-cdni-has > Revision: 03 > Title: Models for adaptive-streaming-aware CDN Interconnection > Creation date: 2012-07-12 > WG ID: Individual Submission > Number of pages: 43 > URL: http://www.ietf.org/internet-drafts/draft-brandenburg-cdni-has-03.txt > Status: http://datatracker.ietf.org/doc/draft-brandenburg-cdni-has > Htmlized: http://tools.ietf.org/html/draft-brandenburg-cdni-has-03 > Diff: http://tools.ietf.org/rfcdiff?url2=draft-brandenburg-cdni-has-03 > > Abstract: > This documents presents thoughts 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 could, and should, deal with content > delivered using adaptive streaming technologies and to facilitate > working group decisions. > > > > > 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 > . > From ray.vanbrandenburg@tno.nl Mon Jul 23 08:00:36 2012 Return-Path: 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 8650E11E809B for ; Mon, 23 Jul 2012 08:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.34 X-Spam-Level: X-Spam-Status: No, score=0.34 tagged_above=-999 required=5 tests=[AWL=0.844, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 amkjPGM27hn9 for ; Mon, 23 Jul 2012 08:00:35 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 38B1211E80AD for ; Mon, 23 Jul 2012 08:00:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,639,1336341600"; d="scan'208";a="15848632" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 23 Jul 2012 17:00:30 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.152]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.02.0298.004; Mon, 23 Jul 2012 17:00:30 +0200 From: "Brandenburg, R. (Ray) van" To: Scott Wainner , "cdni@ietf.org" , "Kent (kleung) Leung (kleung@cisco.com)" Thread-Topic: [CDNi] FW: New Version Notification for draft-brandenburg-cdni-has-03.txt Thread-Index: AQHNaOAbO17MwZanF0WmuzGxcAHB6Zc28+Mw Date: Mon, 23 Jul 2012 15:00:30 +0000 Message-ID: References: <20120713124933.24842.92028.idtracker@ietfa.amsl.com> <500D60A9.1050909@cisco.com> In-Reply-To: <500D60A9.1050909@cisco.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] FW: New Version Notification for draft-brandenburg-cdni-has-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 15:00:36 -0000 Hi Scott, Good point.=20 Kent is the main author of URL signing section, so he's best suited to answ= er your question, but I think you have a point regarding the capability exc= hange this behavior would probably require.=20 @Kent, what do you think? BTW, now that we're talking about URL signing, I think the CDNI interfaces = would require some document that describes URL signing in general anyway, a= nd I'm not sure which document would be best suited for this. The obvious p= lace would be the Request Routing draft, although URL signing might also ha= ve some repercussions on the Metadata interface. Any ideas on that? Or have= I missed something and has this already been discussed on the list earlier= ?=20 Ray -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Sco= tt Wainner Sent: maandag 23 juli 2012 16:33 To: cdni@ietf.org Subject: Re: [CDNi] FW: New Version Notification for draft-brandenburg-cdni= -has-03.txt Ray, Question on Section 3.5.4 Option 5.2.1: Flexible URL Signing by CSP Fourth Paragraph: "However, instead of signing the entire URL, the CSP signs the Relative URL (i.e. invariant portion of the URL) and conveys the protected portion in the authorization parameters embedded in the chunk URL." Are we proposing query string semantics in the URL that define what portion= of the URL elements are protected and the method? In doing so, the CSP, uCDN, surrogates, and delivery nodes must support the= query string semantics and methods. The uCDN must be made aware of the dC= DN's capabilities to support this method of authorization prior to dCDN sel= ection. I think this is noted in the section ... "Effect on CDN Interfaces: o Requires the ability to exclude the variant portion of URL in the signing process (NOTE: Issue is specific to URL Signing support for HAS content and not CDNI?)" I think this issue is relevant not only for HAS and needs to be address in = CDNI capabilities advertisement if we're recommending Flexible URL Signing. Scott On 7/13/12 8:54 AM, Brandenburg, R. (Ray) van wrote: > Hi all, > > As you can see we just uploaded a new version of the HAS-CDNI draft. This= is the version of the draft that we will be presenting during the Vancouve= r meeting. > > I'm looking forward to your comments and seeing you all in Vancouver! > > Best regards, > > Ray van Brandenburg > > > > > > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: vrijdag 13 juli 2012 14:50 > To: Brandenburg, R. (Ray) van > Cc: flefauch@cisco.com; kleung@cisco.com; Deventer, M.O. (Oskar) van > Subject: New Version Notification for=20 > draft-brandenburg-cdni-has-03.txt > > > A new version of I-D, draft-brandenburg-cdni-has-03.txt has been successf= ully submitted by Ray van Brandenburg and posted to the IETF repository. > > Filename: draft-brandenburg-cdni-has > Revision: 03 > Title: Models for adaptive-streaming-aware CDN Interconnection > Creation date: 2012-07-12 > WG ID: Individual Submission > Number of pages: 43 > URL: http://www.ietf.org/internet-drafts/draft-brandenburg-cd= ni-has-03.txt > Status: http://datatracker.ietf.org/doc/draft-brandenburg-cdni-h= as > Htmlized: http://tools.ietf.org/html/draft-brandenburg-cdni-has-03 > Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-brandenburg-c= dni-has-03 > > Abstract: > This documents presents thoughts 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 could, and should, deal with content > delivered using adaptive streaming technologies and to facilitate > working group decisions. > > = =20 > > > The IETF Secretariat > This e-mail and its contents are subject to the DISCLAIMER at=20 > http://www.tno.nl/emaildisclaimer=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 mcaulfie@cisco.com Mon Jul 23 08:26:03 2012 Return-Path: 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 51A3111E808E for ; Mon, 23 Jul 2012 08:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 kSInhnXbF79C for ; Mon, 23 Jul 2012 08:26:02 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id DFD4D11E808D for ; Mon, 23 Jul 2012 08:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcaulfie@cisco.com; l=11620; q=dns/txt; s=iport; t=1343057162; x=1344266762; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=05cs03tEFaQnYQuehj9Qo0fI/GBT/q3fczvhULbjabQ=; b=X/2uSfEv1apjO8JZ32iMAJwLpJn8GDjWknPV25oPFnHbC1pfS/gi0dQj pYXxWK2O1IpeSZfIyYCo6AaXceNp7bgeptoUlj3ij9yI95KtYQWkdU1Ge A/CC+NSNpgBodOjkk6ooPwo6nvW0wg4KOO3JU01QDBM8JII7hdqVOUElO Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOZsDVCtJXG9/2dsb2JhbABFuTiBB4IgAQEBAwESAWYFBwQCAQgRBAEBCx0HMhQJCAEBBAENBQgah2UGC50Zn12LTRULhVNgA4gZiHuFSY0TgWaCX4FX X-IronPort-AV: E=Sophos;i="4.77,639,1336348800"; d="scan'208";a="104219178" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 23 Jul 2012 15:25:42 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6NFPgWu031874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Jul 2012 15:25:42 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0298.004; Mon, 23 Jul 2012 10:25:42 -0500 From: "Matt Caulfield (mcaulfie)" To: Kevin J Ma , "cdni@ietf.org" Thread-Topic: New Metadata Interface Draft (draft-cjlmw-cdni-metadata-00) Thread-Index: Ac1eC0YVScB5jeVWTF6OpuGDrKcS+gFg0GrwAC74lzAALbM/IAAABjzwAPePb3A= Date: Mon, 23 Jul 2012 15:25:41 +0000 Message-ID: <166EBB70C264A9479E459B01B1BA6C92021EAD@xmb-aln-x03.cisco.com> References: <166EBB70C264A9479E459B01B1BA6C9201B060@xmb-aln-x03.cisco.com> <291CC3F9E50E7641901A54E85D0977C65326E2AA7F@MAILR002.mail.lan> <166EBB70C264A9479E459B01B1BA6C9201F7B3@xmb-aln-x03.cisco.com> <291CC3F9E50E7641901A54E85D0977C65326E2B1C4@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C65326E2B2FF@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C65326E2B2FF@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.182.158] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19058.005 x-tm-as-result: No--39.959000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Ben Niven-Jenkins \(ben@velocix.com\)" Subject: Re: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni-metadata-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 15:26:03 -0000 Hi Kevin, Your feedback is very helpful. My responses inline. Thanks, Matt -----Original Message----- From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]=20 Sent: Wednesday, July 18, 2012 3:10 PM To: Matt Caulfield (mcaulfie); cdni@ietf.org Cc: Ben Niven-Jenkins (ben@velocix.com) Subject: RE: New Metadata Interface Draft (draft-cjlmw-cdni-metadata-00) Hi Matt, thanx for the reponse. comments inline: > From: Matt Caulfield (mcaulfie) [mailto:mcaulfie@cisco.com] > Sent: Tuesday, July 17, 2012 4:02 PM > To: Kevin J Ma; cdni@ietf.org > Cc: Ben Niven-Jenkins (ben@velocix.com) > Subject: RE: New Metadata Interface Draft=20 > (draft-cjlmw-cdni-metadata-00) >=20 > Hi Kevin, >=20 > Thank you for the comments, please see my responses inline below. >=20 > Regards, > Matt >=20 > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Monday, July 16, 2012 4:40 PM > To: Matt Caulfield (mcaulfie); cdni@ietf.org > Cc: Ben Niven-Jenkins (ben@velocix.com) > Subject: RE: New Metadata Interface Draft=20 > (draft-cjlmw-cdni-metadata-00) >=20 > Hi Matt, >=20 > =A0 A couple of initial comments/questions about the merged draft: >=20 > =A0 - I do not understand the need for a heirarchical separation of the > =A0=A0=A0 Acquisition and Delivery objects?=A0 Why is the property "key" = not > =A0=A0=A0 sufficient for designating the function of the metadata? > [Matt>] The separation was created to categorize metadata properties.=20 > It's not essential. It may be useful if one server in a CDN is=20 > delivery a piece of content and another server is acquiring. The=20 > acquisition server could limit itself to looking at the acquisition=20 > metadata while the delivery server could limit itself to looking at=20 > the delivery metadata. Would you suggest removing this distinction? It raises question in my mind about how override works (see response to Ben= ). [Matt>] I think I understand your confusion. The best way to think about th= e inheritance rules is not by what overrides what. Instead, imagine that th= e dCDN needs to know the value of parameter X. The dCDN has already found t= he branch of HostMetadata and PathMetadata which apply to the request. To f= ind the value of parameter X, the dCDN first looks for that parameter in th= e leaf PathMetadata. If the value is not found, it looks in the parent, and= if it's not found, looks in the parent's parent, all the way up. If the pa= rameter value is not found, it takes on the default value.=20 > =A0=A0=A0 Though it could be argued that these are logically different > =A0=A0=A0 functions, the extra layer seems unnecessary, and introduces so= me > =A0=A0=A0 complexity to the inheritance model? > [Matt>] I don't think that the extra layer introduces any additional=20 > complexity. In our model, objects can contain objects which can=20 > contain objects, the delivery/acquisition objects aren't a special case. >=20 > =A0=A0=A0 With inheritance-based override, can a lower level PathMetadata > =A0=A0=A0 object override just an Auth List, or does it have to replace t= he > =A0=A0=A0 entire Delivery object?=A0 Does it have to place the Auth List > =A0=A0=A0 inside a lower level Delivery object, or can it just define a n= ew > =A0=A0=A0 Auth List with no Delivery object wrapper?=A0 Is there a concep= t of > =A0=A0=A0 leaf vs. branch objects for override purposes? > [Matt>] Any object at any level can be overridden. So yes, just the=20 > Auth list could be overridden, there is no need to override the entire=20 > delivery object. Yes, the schema must be preserved - so to override=20 > the auth list it would be wrapped by a delivery object. No, there is=20 > no concept of leaf vs. branch. Based on your comment, I think we could=20 > spend more time on the description of inheritance. >=20 > =A0=A0=A0 In general, if there are an arbitrary number of levels below ea= ch > =A0=A0=A0 object, and an arbitrary number of levels of PathMetadata which > =A0=A0=A0 may contain objects with arbitrary levels of metadata which may > =A0=A0=A0 override previous levels, is there a need to check that duplica= te > =A0=A0=A0=A0Metadata do not exist within a given subtree, and/or should t= hat > =A0=A0=A0 restriction be stated explicity? > [Matt>] I'm not sure what you mean by duplicate metadata. Each=20 > PathMetadata object defines a bunch of metadata properties, each one=20 > is unique. Each PathMetadata object either inherits or overrides the=20 > metadata properties of its parent. I guess I was thinking more about scope, not across multiple PathMetadata o= bjects, but within a single one, e.g.: Delivery has an auth property. If someone add a new x-azuki property to th= e Delivery property and the x-azuki property has its own auth property. Is there a conflict? Presumably the delivery/x-azuki/auth property is distinct from the delivery= /auth property? And the precedence of the two auth properties would be def= ined by the x-azuki/auth property? If there was also a delivery/x-cisco/au= th property and a delivery/x-velocix/auth it gets a little more complex. S= hould there be restrictions on naming and/or overriding existing metadata o= bject functions, or is it just left up to the implementors to do the right = thing? [Matt>] I think Ben supplied a good answer to this question. > =A0 - For Lists of objects, I did not see a specific ordering defined? > =A0=A0=A0 Is there a way to enforce ordering? > [Matt>] I'm not sure I understand your question. All lists are ordered. > Can you clarify? I do not see any text in the draft which defines what a "List" is, or how t= hey are ordered? JSON arrays have inherent ordering, but XML lists do not.= Also, JSON and XML may only be an on-the-wire encoding. The data model s= hould specify an order from which to generate the JSON/XML? [Matt>] Noted, we will need to add a description of Lists to the next revis= ion in the data model section. In XML encoding, we'll need to add an attrib= ute which provides the list index (this was an oversight). > =A0 - With respect to extensibility, can an "x-" object be added to any > =A0=A0=A0 other object, or are there restrictions on where a new custom > =A0=A0=A0 object may be added into the hierarchy? > [Matt>] An "x-" object can be added anywhere. >=20 > =A0=A0=A0 Can I add a new ACL type?=A0 Can I add a new pattern matching o= ption > =A0=A0=A0 to the HostMatch and/or PathMatch objects (fundamentally changi= ng > =A0=A0=A0 the way hosts and paths are matched)?=A0 Can I add new types of > =A0=A0=A0 location algorithms (e.g., GPS coordinates or zip code) to the > =A0=A0=A0 Location object?=A0 Or is it intended more for just creating a = new > =A0=A0=A0 hierarchy under the Delivery object? > [Matt>] It is intended for adding new metadata properties, however it=20 > could be used for changing the structure of the metadata tree or=20 > changing how we do path matches as you suggest. >=20 > =A0 - With respect to the "ignorable" Property, does that affect the > =A0=A0=A0 entire parent object to which it is added?=A0 If it is a Proper= ty > =A0=A0=A0 itself (rather than an attribute of a Property), then does that > =A0=A0=A0 require a wrapper object around the actual Property and the > =A0=A0=A0 "ingnorable" Property, for all new Properties?=A0 Should it be = a > =A0=A0=A0 standard attribute like Mandatory? > [Matt>] Yes, the ignorable property affects the entire object and all=20 > the objects it contains. The "ignorable" property can be thought of as=20 > an attribute. In the XML encoding, it would likely be an attribute=20 > (and not an element). In JSON, yes, it can lead to wrapper object. So, would "ignorable" affect all children as well? Or only the objects in = the current level, not including other objects referenced through a PathMat= ch object? [Matt>] "ignorable" affects all children as well. Will need to clarify this= in the next revision when we improve the extensibility section. > =A0 - Is there a way for the client to request metadata for a given URI, > =A0=A0=A0 rather than recursively checking and requesting PathMetadata? > =A0 =A0=A0Doesn't this lead to alot of lookups (even local cache lookups) > =A0=A0=A0 for each request, to find all of the applicable PathMetadata? > =A0=A0=A0 Are there optimizations for local cache lookup? > [Matt>] No, there's no way to get the metadata for a specific URL=20 > without traversing the tree. This approach enforces cacheability. As=20 > for local lookups, it's up to the CDN how it store metadata=20 > internally. The local lookup speed is independent of the metadata interfa= ce speed. I'm not sure that cacheability is really affected. I understand the desire= to be able to individually reference and store objects. The recursive tre= e structure does not really enhance that. Having all the PathMatch objects= in a flat single layer structure would not change cacheability (or increas= e the storage requirements), but it might make it easier to natively suppor= t lookup for given URIs? =20 [Matt>] With respect to cacheability, I was referring to the idea of reques= ting metadata for a given URI. Assume that we form a request for a metadata= object by putting the content request URL in the query string to the metad= ata server. If this is the approach, then I don't think that HTTP caching c= an help us.=20 [Matt>] With respect to flat vs tall tree, I think you're right - cacheabil= ity is not affected. However, I think that the multi-level tree provides be= tter space efficiency for a few reasons. 1) With the flat tree there could = be redundancy between siblings. In a multi-level model, any redundant metad= ata would be kept in a single parent node. 2) In a flat tree, the root node= would be much larger than the multi-level tree. 3) In a multi-level tree, = the cache TTL of each node could be proportional to its tree level (the roo= t could have a long TTL). Though compacted representations could be generated for faster local lookup= s, the un-compacted representation is still needed to be able to determine = how to refresh metadata or get more specific (additional PathMatch) metadat= a. [Matt>] This information could be stored in whatever format is most reasona= ble to the dCDN. It need not be "un-compacted".=20 thanx. -- Kevin J. Ma > =A0 Note: I have also uploaded an updated version of my draft: > =A0=A0=A0=A0=A0=A0=A0 http://tools.ietf.org/html/draft-ma-cdni-metadata-0= 3 > [Matt>] Thanks, I will check it out. >=20 > thanx. >=20 > --=A0 Kevin J. Ma >=20 >=20 > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf=20 > Of Matt Caulfield (mcaulfie) > Sent: Monday, July 09, 2012 3:45 PM > To: cdni@ietf.org > Cc: Ben Niven-Jenkins (ben@velocix.com) > Subject: [CDNi] New Metadata Interface Draft=20 > (draft-cjlmw-cdni-metadata- > 00) >=20 > Hi everyone, >=20 > As we announced in April, a group of us (Ben Niven-Jenkins, Kent=20 > Leung, Rob Murray, Grant Watson, and I) have been working on a merge=20 > of two of the CDNI metadata interface proposals: > - draft-caulfield-cdni-metadata-core-00 > - draft-jenkins-cdni-metadata-00 >=20 > The merged draft has now been submitted:=20 > http://tools.ietf.org/html/draft- > cjlmw-cdni-metadata-00 >=20 > We will be presenting on this draft in Vancouver. Any feedback on the=20 > list is also appreciated. >=20 > Thanks, > Matt >=20 >=20 >=20 From flefauch@cisco.com Mon Jul 23 08:45:42 2012 Return-Path: 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 0CA1021F8505 for ; Mon, 23 Jul 2012 08:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.571 X-Spam-Level: X-Spam-Status: No, score=-10.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 dncq7VXLZ4z2 for ; Mon, 23 Jul 2012 08:45:41 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 527C621F8501 for ; Mon, 23 Jul 2012 08:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=126; q=dns/txt; s=iport; t=1343058341; x=1344267941; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=i6NMkh+rmejd2+/LOTY3DCJgSzTOnXl4c9PKlp8SzbY=; b=JH0BT+L/5kLNFFTDWdKSGqwF+jVeGWK4eK5DFjSwij2D7Qzk0gdsGfnp AqdWEzxg7ewmR8ET67O4QYDSYUlimiGzx7Z4ZUhWIL5Aq0BHm0ofyKKY2 EMClOSEdOKaEfEDxD1uGCWHQgoundFnGlbT8hHmC8U8PNq0run/cJEOWg 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHtwDVCtJV2c/2dsb2JhbABFuTiBB4InEgEnUQE+QicENYdrm36BKJ9ekUBgA5VJjieBZoJf X-IronPort-AV: E=Sophos;i="4.77,639,1336348800"; d="scan'208";a="101444703" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 23 Jul 2012 15:45:41 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6NFjecK001312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 23 Jul 2012 15:45:40 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.17]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0298.004; Mon, 23 Jul 2012 10:45:40 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: draft slides for Vancouver presentations Thread-Index: AQHNaOo0Zo3Q3vdNo067fXJlw9a+cg== Date: Mon, 23 Jul 2012 15:45:38 +0000 Message-ID: <5DB88CC7-F3A5-4721-A38B-69D59C2A54FF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19058.005 x-tm-as-result: No--25.137700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <0DF0A8A4333EF341B48B1B6BC3A87EE5@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] draft slides for Vancouver presentations 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 15:45:42 -0000 Hello, Please provide Rich and me with your draft slides by Close of Business on T= hursday 26 Jul. Thanks Francois= From flefauch@cisco.com Mon Jul 23 09:15:49 2012 Return-Path: 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 CA5D721F867B for ; Mon, 23 Jul 2012 09:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.454 X-Spam-Level: X-Spam-Status: No, score=-10.454 tagged_above=-999 required=5 tests=[AWL=0.144, 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 T38Io9OhbJXJ for ; Mon, 23 Jul 2012 09:15:48 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C87C921F8650 for ; Mon, 23 Jul 2012 09:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=15243; q=dns/txt; s=iport; t=1343060148; x=1344269748; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IKpJ2ho0DiUkOTj56PR8RSOhhc3EVwBq7j113hVtwks=; b=QJVHHZbnAoQmxY11cK0/E+KV0xgUubkzPgODIZNXPyp8VV7OUvIbeDSx 8Y+I1cgoTcxNWqD64o2pBOEg1cCf3JxYc87RnadzgAJf/7ka8UNqgxshY JTjhqAelqZ+jxH7nsFN9cRCb6KFVHsqalb28imXTzSn5hHqL1b8SeeUPw w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgFAC94DVCtJXG9/2dsb2JhbAA7CqhOh3MBiHaBB4IgAQEBBAEBAQ8BWwkCDAQCAQgRBAEBKAcnCxQJCAIEDgUJGYdrC50bn1+LTRAKhVlgA5VJgRSNE4Fmgl+BWAcc X-IronPort-AV: E=Sophos;i="4.77,639,1336348800"; d="scan'208,217";a="104474449" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 23 Jul 2012 16:15:47 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6NGFlZ4006348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Jul 2012 16:15:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.17]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0298.004; Mon, 23 Jul 2012 11:15:46 -0500 From: "Francois Le Faucheur (flefauch)" To: "Brandenburg, R. (Ray) van" Thread-Topic: [CDNi] New Version Notification for draft-brandenburg-cdni-has-03.txt Thread-Index: AQHNaO5qU8T4yPZRuEiwQ2y8lhbJ3A== Date: Mon, 23 Jul 2012 16:15:46 +0000 Message-ID: <7DFB8AF3-6E68-4876-BAF8-8800DBA6B4D6@cisco.com> References: <20120713124933.24842.92028.idtracker@ietfa.amsl.com> <500D60A9.1050909@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19058.005 x-tm-as-result: No--35.266600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_7DFB8AF36E684876BAF88800DBA6B4D6ciscocom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] New Version Notification for draft-brandenburg-cdni-has-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 16:15:50 -0000 --_000_7DFB8AF36E684876BAF88800DBA6B4D6ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 23 Jul 2012, at 17:00, Brandenburg, R. (Ray) van wrote: BTW, now that we're talking about URL signing, I think the CDNI interfaces = would require some document that describes URL signing in general anyway, and also describes it quite specifically (i.e. how exactly to locate the si= gnature in URI, how to identify the fields in scope and parameters, and how= to validate the signature). and I'm not sure which document would be best suited for this. The obvious = place would be the Request Routing draft, although URL signing might also h= ave some repercussions on the Metadata interface. I would picture: * Request Routing Interface/Redirection specifies the URI Signing mechanism= (algorithm, fields, parameters, encoding in URI,...) * Metadata Interface specifies the CDNI Metadata object that needs to be ex= changed across CDNs to allow signature validation by dCDN. Cheers Francois Any ideas on that? Or have I missed something and has this already been dis= cussed on the list earlier? Ray -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Scott Wainner Sent: maandag 23 juli 2012 16:33 To: cdni@ietf.org Subject: Re: [CDNi] FW: New Version Notification for draft-brandenburg-cdni= -has-03.txt Ray, Question on Section 3.5.4 Option 5.2.1: Flexible URL Signing by CSP Fourth Paragraph: "However, instead of signing the entire URL, the CSP signs the Relative URL (i.e. invariant portion of the URL) and conveys the protected portion in the authorization parameters embedded in the chunk URL." Are we proposing query string semantics in the URL that define what portion= of the URL elements are protected and the method? In doing so, the CSP, uCDN, surrogates, and delivery nodes must support the= query string semantics and methods. The uCDN must be made aware of the dC= DN's capabilities to support this method of authorization prior to dCDN sel= ection. I think this is noted in the section ... "Effect on CDN Interfaces: o Requires the ability to exclude the variant portion of URL in the signing process (NOTE: Issue is specific to URL Signing support for HAS content and not CDNI?)" I think this issue is relevant not only for HAS and needs to be address in = CDNI capabilities advertisement if we're recommending Flexible URL Signing. Scott On 7/13/12 8:54 AM, Brandenburg, R. (Ray) van wrote: Hi all, As you can see we just uploaded a new version of the HAS-CDNI draft. This i= s the version of the draft that we will be presenting during the Vancouver = meeting. I'm looking forward to your comments and seeing you all in Vancouver! Best regards, Ray van Brandenburg -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: vrijdag 13 juli 2012 14:50 To: Brandenburg, R. (Ray) van Cc: flefauch@cisco.com; kleung@cisco.com; Deventer, M.O. (Oskar) van Subject: New Version Notification for draft-brandenburg-cdni-has-03.txt A new version of I-D, draft-brandenburg-cdni-has-03.txt has been successful= ly submitted by Ray van Brandenburg and posted to the IETF repository. Filename: draft-brandenburg-cdni-has Revision: 03 Title: Models for adaptive-streaming-aware CDN Interconnection Creation date: 2012-07-12 WG ID: Individual Submission Number of pages: 43 URL: http://www.ietf.org/internet-drafts/draft-brandenburg-cdni= -has-03.txt Status: http://datatracker.ietf.org/doc/draft-brandenburg-cdni-has Htmlized: http://tools.ietf.org/html/draft-brandenburg-cdni-has-03 Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-brandenburg-cdn= i-has-03 Abstract: This documents presents thoughts 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 could, and should, deal with content delivered using adaptive streaming technologies and to facilitate working group decisions. 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 . _______________________________________________ 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 --_000_7DFB8AF36E684876BAF88800DBA6B4D6ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On 23 Jul 2012, at 17:00, Brandenburg, R. (Ray) van wrote:

BTW, now that we're talking about URL signing, I think the CDNI inte= rfaces would require some document that describes URL signing in general an= yway,

and also describes it quite specifically (i.e. how exactly to locate t= he signature in URI, how to identify the fields in scope and parameters, an= d how to validate the signature).

and I'm not sure which document would be best suited for this. The obv= ious place would be the Request Routing draft, although URL signing might a= lso have some repercussions on the Metadata interface.

I would picture:
* Requ= est Routing Interface/Redirection specifies the URI Signing mechanism (algo= rithm, fields, parameters, encoding in URI,...)
* Meta= data Interface specifies the CDNI Metadata object that needs to be exchange= d across CDNs to allow signature validation by dCDN.

Cheers

Francois


Any ideas on that? Or have I missed something and has this already bee= n discussed on the list earlier?

Ray



-----Original Message-----
From: cdni-bounces@ietf.org [m= ailto:cdni-bounces@ietf.org] On Behalf Of Scott Wainner
Sent: maandag 23 juli 2012 16:33
To: cdni@ietf.org
Subject: Re: [CDNi] FW: New Version Notification for draft-brandenburg-cdni= -has-03.txt

Ray,

Question on Section 3.5.4 Option 5.2.1: Flexible URL Signing by CSP

Fourth Paragraph:

"However, instead of signing the entire URL, the CSP signs
   the Relative URL (i.e. invariant portion of the URL) and = conveys the
   protected portion in the authorization parameters embedde= d in the
   chunk URL."

Are we proposing query string semantics in the URL that define what portion= of the URL elements are protected and the method?

In doing so, the CSP, uCDN, surrogates, and delivery nodes must support the= query string semantics and methods.  The uCDN must be made aware of t= he dCDN's capabilities to support this method of authorization prior to dCD= N selection.

I think this is noted in the section ...

"Effect on CDN Interfaces:

 o  Requires the ability to exclude the variant portion of URL in= the
      signing process (NOTE: Issue is specifi= c to URL Signing support
      for HAS content and not CDNI?)"
I think this issue is relevant not only for HAS and needs to be address in = CDNI capabilities advertisement if we're recommending Flexible URL Signing.=

Scott

On 7/13/12 8:54 AM, Brandenburg, R. (Ray) van wrote:
Hi all,

As you can see we just uploaded a new version of = the HAS-CDNI draft. This is the version of the draft that we will be presen= ting during the Vancouver meeting.

I'm looking forward to your comments and seeing y= ou all in Vancouver!

Best regards,

Ray van Brandenburg







-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: vrijdag 13 juli 2012 14:50
To: Brandenburg, R. (Ray) van
Cc: flefauc= h@cisco.com; kleung@cisco.com; Deventer, M.O. (O= skar) van
Subject: New Version Notification for
draft-brandenburg-cdni-has-03.txt


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

Filename: draft-brandenburg-cdni-has
Revision: 03
Title: Mode= ls for adaptive-streaming-aware CDN Interconnection
Creation date: 2012-07-12
WG ID: Indi= vidual Submission
Number of pages: 43
URL:        &n= bsp;    http://www.ietf.org/internet-drafts/draf= t-brandenburg-cdni-has-03.txt
Status:        = ;  http://datatracker.ietf.org/doc/draft-brandenburg-cdni-has
Htmlized:       &nb= sp;htt= p://tools.ietf.org/html/draft-brandenburg-cdni-has-03
Diff:        &= nbsp;   http://tools.ietf.org/rfcdiff?url2=3Ddraft-brand= enburg-cdni-has-03

Abstract:
   This documents presents thought= s on the potential impact of
   supporting HTTP Adaptive Stream= ing technologies in CDN
   Interconnection scenarios. &nbs= p;Our intent is to spur discussion on how
   the different CDNI interfaces c= ould, and should, deal with content
   delivered using adaptive stream= ing technologies and to facilitate
   working group decisions.




The IETF Secretariat
This e-mail and its contents are subject to the D= ISCLAIMER at
htt= p://www.tno.nl/emaildisclaimer
_______________________________________________
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

--_000_7DFB8AF36E684876BAF88800DBA6B4D6ciscocom_-- From kleung@cisco.com Mon Jul 23 10:26:40 2012 Return-Path: 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 BBBE021F864F for ; Mon, 23 Jul 2012 10:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 NAiG+U-GifLD for ; Mon, 23 Jul 2012 10:26:39 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 92B1221F847C for ; Mon, 23 Jul 2012 10:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=5605; q=dns/txt; s=iport; t=1343064399; x=1344273999; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CfTk0o9YLdgCB5EyO5WjZdmSx7Brt/goUdtxnMGWLC4=; b=ARLpz/depdF/cXrEZE47FMQJwVQ9JWDzLmdXC1vfE1kgB9lG3Sv1T2qn RHEdWYrnnBAUeYpW1xebCsqDXD3tdL7FUklqMfkzd4elT8MmIUuORgd4f ucuvNUV/ncvrXHJufDnhxhV8Iz6A9uNAtej+8rpj5rXeWhaDql5dTlB0g 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFiIDVCtJXG9/2dsb2JhbABFuV+BB4IgAQEBBAEBAQ8BJzQJAgwEAgEIEQQBAQEKFAkHJwsUCAEIAgQBDQUIARmHawuceJ9ti00ahVlgA5ZdjROBZoJfgV8 X-IronPort-AV: E=Sophos;i="4.77,639,1336348800"; d="scan'208";a="104498496" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 23 Jul 2012 17:26:39 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6NHQchc031663 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Jul 2012 17:26:39 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Mon, 23 Jul 2012 12:26:38 -0500 From: "Kent Leung (kleung)" To: "Brandenburg, R. (Ray) van" , "Scott Wainner (swainner)" , "cdni@ietf.org" Thread-Topic: [CDNi] FW: New Version Notification for draft-brandenburg-cdni-has-03.txt Thread-Index: AQHNaOAcr0PYTeMb2kq0nAY9iwTsWpc3Sd4A//+9gJA= Date: Mon, 23 Jul 2012 17:26:38 +0000 Message-ID: References: <20120713124933.24842.92028.idtracker@ietfa.amsl.com> <500D60A9.1050909@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.78.42] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19058.005 x-tm-as-result: No--48.685400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] FW: New Version Notification for draft-brandenburg-cdni-has-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 17:26:41 -0000 Hi Ray and Scott. Thanks for the comments. Flexible URL Signing needs to be defined further. = I'm planning to publish on URL Signing before the following IETF after Vanc= ouver. This should cover some of the details for Flexible URL Signing such = as protected query string in the URL used to specify the invariant portion. I agree that this would require support in the CDNI's Request Routing Inter= face for capabilities advertisement. As for CDNI document that covers URL Signing in a general way, should this = be in the Framework doc? Currently, that draft does mention URI Signing for= the CDNI Metadata Interface. The implications to the CDNI interfaces are c= overed in the last paragraph of the CDNI Considerations section. Probably s= hould be incorporated into the Framework doc? Larry, what do you think? Kent -----Original Message----- From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl]=20 Sent: Monday, July 23, 2012 8:01 AM To: Scott Wainner (swainner); cdni@ietf.org; Kent Leung (kleung) Subject: RE: [CDNi] FW: New Version Notification for draft-brandenburg-cdni= -has-03.txt Hi Scott, Good point.=20 Kent is the main author of URL signing section, so he's best suited to answ= er your question, but I think you have a point regarding the capability exc= hange this behavior would probably require.=20 @Kent, what do you think? BTW, now that we're talking about URL signing, I think the CDNI interfaces = would require some document that describes URL signing in general anyway, a= nd I'm not sure which document would be best suited for this. The obvious p= lace would be the Request Routing draft, although URL signing might also ha= ve some repercussions on the Metadata interface. Any ideas on that? Or have= I missed something and has this already been discussed on the list earlier= ?=20 Ray -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Sco= tt Wainner Sent: maandag 23 juli 2012 16:33 To: cdni@ietf.org Subject: Re: [CDNi] FW: New Version Notification for draft-brandenburg-cdni= -has-03.txt Ray, Question on Section 3.5.4 Option 5.2.1: Flexible URL Signing by CSP Fourth Paragraph: "However, instead of signing the entire URL, the CSP signs the Relative URL (i.e. invariant portion of the URL) and conveys the protected portion in the authorization parameters embedded in the chunk URL." Are we proposing query string semantics in the URL that define what portion= of the URL elements are protected and the method? In doing so, the CSP, uCDN, surrogates, and delivery nodes must support the= query string semantics and methods. The uCDN must be made aware of the dC= DN's capabilities to support this method of authorization prior to dCDN sel= ection. I think this is noted in the section ... "Effect on CDN Interfaces: o Requires the ability to exclude the variant portion of URL in the signing process (NOTE: Issue is specific to URL Signing support for HAS content and not CDNI?)" I think this issue is relevant not only for HAS and needs to be address in = CDNI capabilities advertisement if we're recommending Flexible URL Signing. Scott On 7/13/12 8:54 AM, Brandenburg, R. (Ray) van wrote: > Hi all, > > As you can see we just uploaded a new version of the HAS-CDNI draft. This= is the version of the draft that we will be presenting during the Vancouve= r meeting. > > I'm looking forward to your comments and seeing you all in Vancouver! > > Best regards, > > Ray van Brandenburg > > > > > > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: vrijdag 13 juli 2012 14:50 > To: Brandenburg, R. (Ray) van > Cc: flefauch@cisco.com; kleung@cisco.com; Deventer, M.O. (Oskar) van > Subject: New Version Notification for=20 > draft-brandenburg-cdni-has-03.txt > > > A new version of I-D, draft-brandenburg-cdni-has-03.txt has been successf= ully submitted by Ray van Brandenburg and posted to the IETF repository. > > Filename: draft-brandenburg-cdni-has > Revision: 03 > Title: Models for adaptive-streaming-aware CDN Interconnection > Creation date: 2012-07-12 > WG ID: Individual Submission > Number of pages: 43 > URL: http://www.ietf.org/internet-drafts/draft-brandenburg-cd= ni-has-03.txt > Status: http://datatracker.ietf.org/doc/draft-brandenburg-cdni-h= as > Htmlized: http://tools.ietf.org/html/draft-brandenburg-cdni-has-03 > Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-brandenburg-c= dni-has-03 > > Abstract: > This documents presents thoughts 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 could, and should, deal with content > delivered using adaptive streaming technologies and to facilitate > working group decisions. > > = =20 > > > The IETF Secretariat > This e-mail and its contents are subject to the DISCLAIMER at=20 > http://www.tno.nl/emaildisclaimer=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 ben@niven-jenkins.co.uk Mon Jul 23 14:06:54 2012 Return-Path: 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 3DC7711E809B for ; Mon, 23 Jul 2012 14:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.417 X-Spam-Level: X-Spam-Status: No, score=-102.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 ZObrgmqiju9Y for ; Mon, 23 Jul 2012 14:06:53 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0E60911E809A for ; Mon, 23 Jul 2012 14:06:53 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginmedia.com ([86.14.227.47] helo=[192.168.0.4]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1StPq7-0003Pi-9J; Mon, 23 Jul 2012 22:06:51 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <8B1F02A4-88E6-444D-87A9-97819F54D2A3@cisco.com> Date: Mon, 23 Jul 2012 22:06:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120709174141.2670.59592.idtracker@ietfa.amsl.com> <8B1F02A4-88E6-444D-87A9-97819F54D2A3@cisco.com> To: Francois Le Faucheur (flefauch) X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "draft-cjlmw-cdni-metadata@tools.ietf.org" , "draft-ma-cdni-metadata@tools.ietf.org" , "biyana@chinamobile.com" , "cdni@ietf.org" , "niwei@chinamobile.com" Subject: Re: [CDNi] Comments re Re: I-D Action: draft-ni-cdni-criteria-metadata-extension-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 21:06:54 -0000 Francois, Wei, Yana, Yunfei, My thoughts inline. On 19 Jul 2012, at 10:01, Francois Le Faucheur (flefauch) wrote: > Hello Wei, Yana, Yunfei, >=20 > The I-D says: > " > The object includes the following fields: > O country - a string containing the country code for the region. > O bgpAs - a number containing the BGP AS identifier of the region. > O subnet - a string containing a dotted decimal IP address and > subnet mask, here the IP address is the source IP address in IP > layer. > O msdnPrefix - a few digits in MSISDN specifying user's home area > information in mobile network. MSISDN should be extracted from HTTP > Header by the surrogate of downstream CDN. > O subnet2 - a string containing a dotted decimal IP address > extracted from the HTTP x-forwarded-for header and the corresponding > subnet mask, which specifies the real IP address of mobile devices > assigned by mobile core network. The IP address should be extracted > from HTTP Header by the surrogate of downstream CDN. > " >=20 > The Location object of cjlmw-cdni-metadata is described as: > " > | Location | Geographic or network location identified by = | > | | country code, BGP AS number, or subnet to which = | > | | content may (or may not) be delivered.=20 > " > Can you confirm that your first three criteria ("Country", "BGP AS" = and "Subnet") are addressed as you see needed? >=20 >=20 > Regarding the last 2 criteria, I would like to encourage you to work = (ideally before Vancouver) with the authors of the current CDNI Metadata = proposals (e.g. cjlmw-cdni-metadata and ma-cdni-metadata) to discuss = whether/how those could be integrated in the current metadata proposals. = On that, my personal input is: > * I can see the rationale for extending the geoblocking based on = the IP address allocated based on current location (ie your "Subnet2"). As I understand it the situation/use case described in = draft-ni-cdni-criteria-metadata-extension is this: - The client is sat behind some kind of gateway device (WAP gateway, = CG-NAT, etc.) so that the CDN's request router/surrogate does not see = the client's IP address but instead it sees the IP address of the = gateway device. - Geo-blocking must continue to work in this scenario and the specific = worry is that the CDN may block access based on the gateway's IP address = where it would have allowed access had it seen the client's actual IP = address. My first comment is that this scenario/use case exists today and the = solution taken is to ensure the gateway's IP address is included in the = allowed geo-blocking policy. So the scenario/use case by itself doesn't = raise any specific additional requirements on CDNI. However, in some scenarios it may be useful for the CDN request = router/surrogate to factor in the client's actual IP address, e.g. = because the gateway is aggregating for multiple network = regions/provinces and you'd like the request router to be able to do a = finer grained cache selection, and in some cases (e.g. HTTP redirection) = the X-Forwarded-For can expose that information to the CDN's request = router. For that sort of scenario I'd suggest that we don't try to overload = geo-blocking by having another category of Location which means "a list = of IP addresses to extract/compare from the X-FF header". Instead one = ensures that the gateway's IP address is allowed by the normal = geo-blocking policy (as today) and we have a CDNI Metadata property/flag = that indicates a dCDN should use the client IP address from the X-FF = header for certain (defined) decisions. However, the X-FF header is not a secure header and can be subject to = modification by intermediaries and therefore blindly trusting it is a = security risk for CDNs. So a dCDN should only use the X-FF header when = it knows (somehow, probably out of band) that that particular gateway is = to be trusted. Additionally, it would seem that the only entity to be 'harmed' by not = using the X-FF header is the dCDN because they dCDN may make a less = efficient surrogate selection.=20 That leads me to think that use of X-FF from trusted gateways is = primarily an implementation optimisation for the dCDN. We could add a = property to explicitly allow/disallow the dCDN to use X-FF to cover = cases of a paranoid uCDN that doesn't trust the dCDN's choice of trusted = gateways. Ben > * I am somewhat skeptical on the requirements to control = distribution based on ranges of the Mobile number (ie your = "msdnPrefix"), particularly considering number portability. I would be = interested in hearing other opinions on that. >=20 >=20 > Regardless of which document the discussion of "subnet2" ends up in = the future, I suggest an editor's note be incorporate to remind us to = check the status of "draft-petersson-forwarded-for" (unless someone can = update us on that) to decide whether we ought to extend the description = to cover the proposed "Forwarded" header, in addition to the = X-Forwarded-For header. >=20 > Cheers >=20 > Francois >=20 >=20 > On 9 Jul 2012, at 19:41, > wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >>=20 >> Title : CDNI Delivery Criteria Metadata Extension for = Mobile Network >> Author(s) : Wei Ni >> Yana Bi >> Yunfei Zhang >> Filename : = draft-ni-cdni-criteria-metadata-extension-00.txt >> Pages : 11 >> Date : 2012-07-09 >>=20 >> Abstract: >> In CDNI deployment, the downstream CDN may probably delivers >> content to mobile devices, which is served by cellular networks >> (e.g., 2G, 3G). The purpose of this document is to provide some >> complement to the delivery criteria in current Metadata Interface >> with a more precise criteria model, which is in consideration of >> content delivery service to mobile devices. >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ni-cdni-criteria-metadata-extension= >>=20 >> There's also a htmlized version available at: >> = http://tools.ietf.org/html/draft-ni-cdni-criteria-metadata-extension-00 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> 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 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From yannick.lelouedec@orange.com Tue Jul 24 06:16:01 2012 Return-Path: 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 F373A21F8642 for ; Tue, 24 Jul 2012 06:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 F2dNVa5soM5i for ; Tue, 24 Jul 2012 06:15:59 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7C621F85EA for ; Tue, 24 Jul 2012 06:15:59 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 707D52641C8; Tue, 24 Jul 2012 15:15:52 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 4E69B35C045; Tue, 24 Jul 2012 15:15:52 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Tue, 24 Jul 2012 15:15:48 +0200 From: To: "Woundy, Richard" , "Francois Le Faucheur (flefauch@cisco.com)" , Scott Wainner , Ben Niven-Jenkins , "Brandenburg, R. (Ray) van" , "cdni@ietf.org" Thread-Topic: IETF #84 - Side meeting on the CDNI request routing interface - Monday 30 from 20:30 to 22:00 @ Hyatt Regency Hotel. Thread-Index: Ac1pnlTFYUDY04KNQqK7R9tnzQASSA== Date: Tue, 24 Jul 2012 13:15:48 +0000 Message-ID: <1807_1343135752_500EA008_1807_3514_1_fcedeaf3-ddb1-4f28-a60e-740d9c29d263@PEXCVZYH02.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.24.113315 Subject: [CDNi] IETF #84 - Side meeting on the CDNI request routing interface - Monday 30 from 20:30 to 22:00 @ Hyatt Regency Hotel. 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 13:16:01 -0000 Dear all, We propose to arrange the side meeting on CDNI request routing on Monday 30= from 20:30 to 22:00 at Hyatt Regency Hotel. The "footprint / capabilities advertisement" design team meeting will be he= ld just before, the same day, from 18:00 to 20:00. These slots seemed to be the ones that suit most people who wish to attend. Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: LE LOUEDEC Yannick RD-CORE=20 Envoy=E9=A0: vendredi 20 juillet 2012 14:28 =C0=A0: 'Woundy, Richard'; Francois Le Faucheur (flefauch@cisco.com); Scott= Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.org Cc=A0: STEPHAN Emile RD-CORE; BERTRAND Gilles RD-CORE Objet=A0: RE: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI req= uest routing interface Dear all, The doodle for the side meeting in Vancouver on CDNI request routing is her= e: http://www.doodle.com/n552qchpurfcpckn Please fill it in as soon as possible if you intend to attend. Ideally we would like to arrange this meeting at Hyatt Regency Hotel, on Mo= nday evening, after the welcoming session. Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de y= annick.lelouedec@orange.com Envoy=E9=A0: lundi 16 juillet 2012 16:35 =C0=A0= : Scott Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.or= g Objet=A0: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI reque= st routing interface Dear all, We propose to arrange a side meeting on Sunday evening during IETF #84 (i.e= . on July 29th) on the CDNI request routing interface. The objective is to clear the discussion we had these last days via the IET= F CDNI mailing list, and to ease an efficient meeting on Tuesday 31. If everybody agrees that this is a good idea, we will set up a doodle. Best regards, Yannick Le Lou=E9dec, Orange OLNC. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, France Telecom - = Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From yannick.lelouedec@orange.com Tue Jul 24 07:04:05 2012 Return-Path: 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 64F5021F8642 for ; Tue, 24 Jul 2012 07:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=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 OjVIybi3On+q for ; Tue, 24 Jul 2012 07:04:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id E689821F8645 for ; Tue, 24 Jul 2012 07:04:03 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 2FD6E2643A4; Tue, 24 Jul 2012 16:04:03 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 0A92135C04E; Tue, 24 Jul 2012 16:04:03 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Tue, 24 Jul 2012 16:03:57 +0200 From: To: "Woundy, Richard" , "Francois Le Faucheur (flefauch@cisco.com)" , Scott Wainner , Ben Niven-Jenkins , "Brandenburg, R. (Ray) van" , "cdni@ietf.org" Thread-Topic: IETF #84 - Side meeting on the CDNI request routing interface - Monday 30 from 20:30 to 22:00 @ Hyatt Regency Hotel. Thread-Index: Ac1pnlTFYUDY04KNQqK7R9tnzQASSAABq6hw Date: Tue, 24 Jul 2012 14:03:56 +0000 Message-ID: <1807_1343138643_500EAB53_1807_7236_1_2e6394ca-9617-42a9-8264-6009c8b6563d@PEXCVZYH02.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.24.130318 Subject: Re: [CDNi] IETF #84 - Side meeting on the CDNI request routing interface - Monday 30 from 20:30 to 22:00 @ Hyatt Regency Hotel. 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 14:04:05 -0000 Dear all, The Meeting Point will be at the IETF Registration desk. Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: LE LOUEDEC Yannick RD-CORE=20 Envoy=E9=A0: mardi 24 juillet 2012 15:16 =C0=A0: 'Woundy, Richard'; 'Francois Le Faucheur (flefauch@cisco.com)'; 'Sc= ott Wainner'; 'Ben Niven-Jenkins'; 'Brandenburg, R. (Ray) van'; 'cdni@ietf.= org' Cc=A0: STEPHAN Emile RD-CORE; BERTRAND Gilles RD-CORE Objet=A0: IETF #84 - Side meeting on the CDNI request routing interface - M= onday 30 from 20:30 to 22:00 @ Hyatt Regency Hotel. Dear all, We propose to arrange the side meeting on CDNI request routing on Monday 30= from 20:30 to 22:00 at Hyatt Regency Hotel. The "footprint / capabilities advertisement" design team meeting will be he= ld just before, the same day, from 18:00 to 20:00. These slots seemed to be the ones that suit most people who wish to attend. Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: LE LOUEDEC Yannick RD-CORE Envoy=E9=A0: vendredi 20 juillet 2012 14:28 =C0=A0: 'Woundy, Richard'; Francois Le Faucheur (flefauch@cisco.com); Scott= Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.org Cc=A0= : STEPHAN Emile RD-CORE; BERTRAND Gilles RD-CORE Objet=A0: RE: [CDNi] IETF = #84 - Proposal for a side meeting on the CDNI request routing interface Dear all, The doodle for the side meeting in Vancouver on CDNI request routing is her= e: http://www.doodle.com/n552qchpurfcpckn Please fill it in as soon as possible if you intend to attend. Ideally we would like to arrange this meeting at Hyatt Regency Hotel, on Mo= nday evening, after the welcoming session. Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de y= annick.lelouedec@orange.com Envoy=E9=A0: lundi 16 juillet 2012 16:35 =C0=A0= : Scott Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.or= g Objet=A0: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI reque= st routing interface Dear all, We propose to arrange a side meeting on Sunday evening during IETF #84 (i.e= . on July 29th) on the CDNI request routing interface. The objective is to clear the discussion we had these last days via the IET= F CDNI mailing list, and to ease an efficient meeting on Tuesday 31. If everybody agrees that this is a good idea, we will set up a doodle. Best regards, Yannick Le Lou=E9dec, Orange OLNC. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, France Telecom - = Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From flefauch@cisco.com Tue Jul 24 07:29:06 2012 Return-Path: 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 9B0CE21F85F8 for ; Tue, 24 Jul 2012 07:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.572 X-Spam-Level: X-Spam-Status: No, score=-10.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 yCZF6Ps+gw0M for ; Tue, 24 Jul 2012 07:29:06 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C5E5421F8668 for ; Tue, 24 Jul 2012 07:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3845; q=dns/txt; s=iport; t=1343140145; x=1344349745; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=F7xWEPzTzg57tIebFbSDduANd4cjUQwHK1WtMup6DxU=; b=MrT1u3ZIEOTQmkLAM9F6mjJdOEuRbcTSlObFV4pBO3KcLU6+gyH2LuQn Z5Y6qtOHhuzrRLwJC4UHXrImdy1LdQ+0QI7lTCSLHBA9QS7VZLgwG9DnV aQByeovLZzygQM1hU03SaHS1WSJ03IpmXkR7jJvlzEp/I0yZmvHtF0eUI k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACOwDlCtJXG9/2dsb2JhbABFuXKBB4IgAQEBAwEBAQEPASc0CxACAT4QJwslAgQOBQkSB4dlBgubEKBGi0sghXRgA5VJgRSJeYMagWaCX4FX X-IronPort-AV: E=Sophos;i="4.77,646,1336348800"; d="scan'208";a="101797311" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 24 Jul 2012 14:29:05 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6OET5lq000406 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Jul 2012 14:29:05 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.17]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0298.004; Tue, 24 Jul 2012 09:29:04 -0500 From: "Francois Le Faucheur (flefauch)" To: "draft-jin-cdni-content-deduplication-optimization@tools.ietf.org" Thread-Topic: Comments on draft-jin-cdni-content-deduplication-optimization-01.txt Thread-Index: AQHNaait3Gc1+4IGl02+P6acQaTrGQ== Date: Tue, 24 Jul 2012 14:29:04 +0000 Message-ID: References: <20120619031711.19694.7090.idtracker@ietfa.amsl.com> In-Reply-To: <20120619031711.19694.7090.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19060.006 x-tm-as-result: No--37.693600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <1565C29A2D533C4BB296D70D3C586103@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] Comments on draft-jin-cdni-content-deduplication-optimization-01.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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 14:29:06 -0000 Hi, A few comments on draft-jin-cdni-content-deduplication-optimization below. * in several places, the document discusses separately pre-position versus = dynamic acquisition. I don't think there needs to be any difference in the = problem or the solution for the two cases.=20 The issue is: when a dCDN needs to get a content (whether for pre-position = or for dynamic acquisition): 1) can it avoid re-storing a 2nd copy of same content 2) can it avoid requesting that 2nd copy. You may want to consider discussing the problem/solution independently of t= he acquisition method. * section 4.3.3 discusses content removal but does not seem to discuss one = interesting aspect of content reduplication: when a dCDN ends up storing a = given content on behalf of two uCDNs, and then one uCDN triggers content re= moval but the other one does not, do you remove the content or not? Can you discuss that topic? * I was picturing that the Content-ID would be associated to a given conten= t request through the CDNI metadata. In other words, we could define an opt= ional Metadata object containing the Content-ID. Then whenever an action is= needed (e.g. content acquisition) for a resource URI, the CDN would first = acquire the metadata (as usual) and then get the Content-ID. It can then ma= ke the determination on whether the content is already stored. Is this what you have in mind also? I got a little confused by this text: "Receiving the message, the dCDN uses= the Content Identifier to look up target metadata." This suggests that the= metadata are hanging off the Content ID. I think you need to have the meta= data hanging off the resource URL, in particular because you need separate = metadata per uCDN (even for the same content). And I think the Content-ID i= s then conveyed inside the content metadata, Does that make sense ? =20 Cheers Francois On 19 Jun 2012, at 05:17, Internet-Drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : Content De-duplication for CDNi Optimization > Author(s) : WeiYi Jin > Mian Li > Bhumip Khasnabish > Filename : draft-jin-cdni-content-deduplication-optimization-01.t= xt > Pages : 17 > Date : 2012-06-18 >=20 > Abstract: > Recent explosive growth of content delivery/distribution networks > (CDNs) and their interconnection are causing unintended repetition of > content storage in the same dCDN. This can be avoided by using a > suitable de-duplication mechanism. This document explores the > scenarios which create the problems, and then discusses the > approaches to eliminate the duplicated transmission of the same > content from uCDN(s) to dCDN in CDNi networks. To implement the > optimization, some enhancements to the CDNi metadata model and > interface are required. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-jin-cdni-content-deduplication-opt= imization >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-jin-cdni-content-deduplication-optimizat= ion-01 >=20 > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-jin-cdni-content-deduplication= -optimization-01 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 flefauch@cisco.com Wed Jul 25 00:53:04 2012 Return-Path: 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 24CD121F84D1 for ; Wed, 25 Jul 2012 00:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.574 X-Spam-Level: X-Spam-Status: No, score=-10.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 t7DXCh0amYvl for ; Wed, 25 Jul 2012 00:53:03 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB1721F84EB for ; Wed, 25 Jul 2012 00:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=2772; q=dns/txt; s=iport; t=1343202783; x=1344412383; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xDxvAckCLe/3rWvNNQCi1ZuZUtcKUP1FGrKAJLsuIi0=; b=ZPaUMHjCEjYWXSeDng1Lyg6BFwc1o8PpWwrh3eqchi9EZoHoLJ/awxqY XMv3hVaeBZWYSOhrYDqEv2yNCpRiUq2HdBQAkCp2DB2kv3rz5GuprNwMO MDRjjyNVN7yxJoh02EKOx3VboE23KsOgbxWv+eQcpW8amkFkOlLZQQmBz E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEelD1CtJV2a/2dsb2JhbABFuWaBB4IgAQEBAwEBAQEPASc0BgMCBQcEAgEIEQQBAR8JBycLFAkIAgQOBQkZh2UGC5sloESLS4YUYAOVSYEUjROBZoJf X-IronPort-AV: E=Sophos;i="4.77,652,1336348800"; d="scan'208";a="104863581" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 25 Jul 2012 07:53:03 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6P7r2kP014870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Jul 2012 07:53:02 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.17]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0298.004; Wed, 25 Jul 2012 02:53:02 -0500 From: "Francois Le Faucheur (flefauch)" To: Songhaibin Thread-Topic: [CDNi] New Version Notification for draft-song-cdni-slr-based-footprint-01.txt Thread-Index: AQHNajqDgGWH62XWikmLQmQYvguKKA== Date: Wed, 25 Jul 2012 07:53:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19062.003 x-tm-as-result: No--34.946600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <39DD19432D10D54B87A4C81B9CCF5BCD@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] New Version Notification for draft-song-cdni-slr-based-footprint-01.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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 07:53:04 -0000 Hello Haibin, As per your request, you'll have a 5 min slot in Vancouver to introduce thi= s notion of service level requirements based footprint.=20 Moving forward, I strongly recommend you input your ideas directly into the= work of the "CDNI Footprint and Capabilities Advertisement" Design Team th= at is chartered with defining the semantics of the information that is to b= e advertised. Thanks Francois On 16 Jul 2012, at 12:36, Songhaibin wrote: > Hi, >=20 > We just submitted a draft about service level requirements based footprin= t. This draft is mainly used to generate the discussion on this aspect and = it is still on a high level idea stage. We have not given deep thought on t= he details in this document. So any discussion and comments are welcome! >=20 > http://www.ietf.org/internet-drafts/draft-song-cdni-slr-based-footprint-0= 1.txt >=20 > BR, > -Haibin >=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Monday, July 16, 2012 6:31 PM >> To: Songhaibin >> Cc: zhangyunfei@chinamobile.com >> Subject: New Version Notification for draft-song-cdni-slr-based-footprin= t-01.txt >>=20 >>=20 >> A new version of I-D, draft-song-cdni-slr-based-footprint-01.txt >> has been successfully submitted by Haibin Song and posted to the >> IETF repository. >>=20 >> Filename: draft-song-cdni-slr-based-footprint >> Revision: 01 >> Title: A SLR (Service Level Requirements) based footprint for CDNI >> Creation date: 2012-07-16 >> WG ID: Individual Submission >> Number of pages: 7 >> URL: >> http://www.ietf.org/internet-drafts/draft-song-cdni-slr-based-footprint-= 01.txt >> Status: >> http://datatracker.ietf.org/doc/draft-song-cdni-slr-based-footprint >> Htmlized: >> http://tools.ietf.org/html/draft-song-cdni-slr-based-footprint-01 >> Diff: >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-song-cdni-slr-based-footprint= -01 >>=20 >> Abstract: >> Footprint advertisement is a very important step for CDN >> interconnection and generates a lot of discussion. Actually, each >> CDN can serve the whole world if its surrogates are publicly >> reachable by IP addresses. But if a CDN does that, it can not >> satisfy the requirements from the applications. So CDNs deliver >> contents for applications, and the basic requirements should be from >> the applications, but there is rare discussion on service level >> requirements based footprint. This document is used to generate the >> discussion on this aspect. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From ray.vanbrandenburg@tno.nl Wed Jul 25 00:56:59 2012 Return-Path: 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 4E50A21F84F2 for ; Wed, 25 Jul 2012 00:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.309 X-Spam-Level: X-Spam-Status: No, score=0.309 tagged_above=-999 required=5 tests=[AWL=0.812, 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 u+xGQsz8CFU6 for ; Wed, 25 Jul 2012 00:56:56 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8B17621F84B5 for ; Wed, 25 Jul 2012 00:56:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,652,1336341600"; d="scan'208,217";a="72946420" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 25 Jul 2012 09:56:53 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.152]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0298.004; Wed, 25 Jul 2012 09:56:52 +0200 From: "Brandenburg, R. (Ray) van" To: "cdni@ietf.org" Thread-Topic: Summary of recommendations regarding CDNI and HAS Thread-Index: Ac1qOvmRw4vzxV5nTkemOaUkogVG3A== Date: Wed, 25 Jul 2012 07:56:51 +0000 Message-ID: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1581C655B05EXCMBX03tsntnon_" MIME-Version: 1.0 Cc: "draft-brandenburg-cdni-has@tools.ietf.org" Subject: [CDNi] Summary of recommendations regarding CDNI and HAS 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 07:56:59 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA1581C655B05EXCMBX03tsntnon_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi all, In order to spur some online discussion before the Vancouver meeting next w= eek, I've summarized here the main recommendations from the CDNI & HTTP Ada= ptive Streaming work we've been doing over the past months (see http://tool= s.ietf.org/html/draft-brandenburg-cdni-has-03). Content Acquisition & File Management - The recommendation made in the draft is to not do anything specific= for HAS regarding Content Acquisition and File Management. This means that= the dCDN is not explicitly made aware of any relationship between differen= t chunks and the dCDN handles each chunk as if it were an individual and in= dependent content item. The result is that content acquisition between uCDN= and dCDN also happens on a per-chunk basis. The draft does identify some p= otential improvements in this area which might be taken up after a possible= re-chartering of the WG once the initial CDNI specification is complete. Request Routing & Manifest Files - The recommendation made in the draft regarding request routing cons= ists of a mandatory and an optional part. The mandatory part, which each CD= N should support, is to perform request routing on a per-chunk basis. This = means that, depending on the type of manifest file that is used, there migh= t be an individual inter-CDN request routing operation taking place for eac= h individual chunk. As an optional feature, the draft describes a method wh= erein the uCDN rewrites the manifest file so that it points directly to the= dCDN, reducing request routing overhead. Since the process of manifest fil= e rewriting is a uCDN-internal process, this does not require standardizati= on beyond the existing request routing interface. Logging - The recommendation made in the draft regarding logging also consist= s of a mandatory and an optional part. As a mandatory requirement, the draf= t recommends that CDNs support per-chunk logging (e.g. logging each chunk r= equest as if it were an independent content request). As an optional featur= e, the draft recommends to have a system where the dCDN can include a Conte= nt Collection Identifier (CCID) and/or Session Identifier as part of the lo= gging fields, thereby providing the option for a CDN to do per-session logg= ing of HAS content. URL Signing - For CDNs that want to do URL signing, the draft recommends that CDN= s support either Flexible URL Signing by the Content Provider or by the uCD= N. Both scenarios result in a system where the dCDN can remain unaware of H= AS, with either the Content Provider or the uCDN signing the URLs in the ma= nifest file. Other topics - Regarding Content Purge, the draft does not yet include a recommend= ation but describes two options for dealing with the purge of large numbers= of related files from a dCDN. A recommendation for this topic will be adde= d to the next iteration of the draft. - The draft recommends that the CDNI Capability Advertisement method = includes some way for CDNs to indicate whether they support the HAS-specifi= c optional features recommended in the draft (such as the ability to log CC= IDs). Furthermore, the draft recommends that there is some way for dCDNs to= indicate whether they require access to manifest in order to be able to pe= rform the delivery of HAS content. I would like to invite anyone who is interested in the topic and wishes to = discuss some of these recommendations in Vancouver, to read the draft (http= ://tools.ietf.org/html/draft-brandenburg-cdni-has-03) before the meeting, s= o that we can have a fruitful discussion in Vancouver. Best regards, Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_FCC100FC8D6B034CB88CD8173B2DA1581C655B05EXCMBX03tsntnon_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
Hi all,
 
In order to spur some online discussion before the Vancouver meeting n= ext week, I’ve summarized here the main recommendations from the CDNI= & HTTP Adaptive Streaming work we’ve been doing over the past mo= nths (see http://tools.ietf.org/html/draft-brandenburg-cd= ni-has-03).
 
Content Acquisition & File Management
  • The recommendation made in the draft is to not do anything specific for= HAS regarding Content Acquisition and File Management. This means that the= dCDN is not explicitly made aware of any relationship between different ch= unks and the dCDN handles each chunk as if it were an individual and independent content item. The result is tha= t content acquisition between uCDN and dCDN also happens on a per-chunk bas= is. The draft does identify some potential improvements in this area which = might be taken up after a possible re-chartering of the WG once the initial CDNI specification is complete.
 
Request Routing & Manifest Files
  • The recommendation made in the draft regarding request routing consists= of a mandatory and an optional part. The mandatory part, which each CDN sh= ould support, is to perform request routing on a per-chunk basis. This mean= s that, depending on the type of manifest file that is used, there might be an individual inter-CDN request = routing operation taking place for each individual chunk. As an optional fe= ature, the draft describes a method wherein the uCDN rewrites the manifest = file so that it points directly to the dCDN, reducing request routing overhead. Since the process of manife= st file rewriting is a uCDN-internal process, this does not require standar= dization beyond the existing request routing interface.
 
Logging
  • The recommendation made in the draft regarding logging also consists of= a mandatory and an optional part. As a mandatory requirement, the draft re= commends that CDNs support per-chunk logging (e.g. logging each chunk reque= st as if it were an independent content request). As an optional feature, the draft recommends to have a sy= stem where the dCDN can include a Content Collection Identifier (CCID) and/= or Session Identifier as part of the logging fields, thereby providing the = option for a CDN to do per-session logging of HAS content.
 
URL Signing
  • For CDNs that want to do URL signing, the draft recommends that CDNs su= pport either Flexible URL Signing by the Content Provider or by the uCDN. B= oth scenarios result in a system where the dCDN can remain unaware of HAS, = with either the Content Provider or the uCDN signing the URLs in the manifest file.
 
Other topics
  • Regarding Content Purge, the draft does not yet include a recommendatio= n but describes two options for dealing with the purge of large numbers of = related files from a dCDN. A recommendation for this topic will be added to= the next iteration of the draft.
  • The draft recommends that the CDN= I Capability Advertisement method includes some way for CDNs to indicate wh= ether they support the HAS-specific optional features recommended in the dr= aft (such as the ability to log CCIDs). Furthermore, the draft recommends that there is some way for dCDNs to indicate whether they require access to= manifest in order to be able to perform the delivery of HAS content.
    • <= /ul>
     
    I would like to invite anyone who is interested in the topic and wishe= s to discuss some of these recommendations in Vancouver, to read the draft = (http://tools.ietf.org/html/draft-brandenburg-cdni-has-03= ) before the meeting, so that we can have a fruitful discussion in Vancouver.=
     
    Best regards,
     
    Ray
     
     
     
     

    This e-mail and its contents are subject to the DISCLAIMER at http://www= .tno.nl/emaildisclaimer

    --_000_FCC100FC8D6B034CB88CD8173B2DA1581C655B05EXCMBX03tsntnon_-- From Jan.Seedorf@neclab.eu Wed Jul 25 02:05:32 2012 Return-Path: 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 629F521F852E for ; Wed, 25 Jul 2012 02:05:32 -0700 (PDT) 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 Tp5DmUYhDIdK for ; Wed, 25 Jul 2012 02:05:31 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0D20B21F850D for ; Wed, 25 Jul 2012 02:05:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 6662110194D; Wed, 25 Jul 2012 11:09:46 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgN0rQ-VGa2O; Wed, 25 Jul 2012 11:09:46 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 46D7B101863; Wed, 25 Jul 2012 11:09:06 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.252]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 25 Jul 2012 11:05:39 +0200 From: Jan Seedorf To: "yannick.lelouedec@orange.com" , BERTRAND Gilles RD-CORE , "Woundy, Richard" , "Francois Le Faucheur (flefauch@cisco.com)" , Scott Wainner , Ben Niven-Jenkins , "Brandenburg, R. (Ray) van" , "cdni@ietf.org" Thread-Topic: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI request routing interface Thread-Index: AQHNY2A5Rhio/sr8TUGWakt2VLCaAZcyGMnQgARwy5CAAAIAIIADNlvQ Date: Wed, 25 Jul 2012 09:05:38 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE32CD8AC7@PALLENE.office.hd> References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> <2040_1341930789_4FFC3D24_2040_2504_1_b86bff40-ae68-40c0-b8e5-060f51be6864@PEXCVZYH02.corporate.adroot.infra.ftgroup> <3A7EA7EE-F8D4-4094-83F2-12CD3826B662@tno.nl> <5004079D.4000406@cisco.com> <20625_1342449311_5004269F_20625_735_1_e5fd8c10-b453-4cfa-8821-c05811f6324f@PEXCVZYH02.corporate.adroot.infra.ftgroup> <457F4B94DBADF743B61D350B3E7929FE020572@PEXCVZYM11.corporate.adroot.infra.ftgroup> <2AC63C9F27AF8446B0C064C50FC0A89304D027@PEXCVZYM13.corporate.adroot.infra.ftgroup> <19575_1343030856_500D0648_19575_7867_1_32076722-70e1-40b8-951d-d02e511b336c@PEXCVZYH01.corporate.adroot.infra.ftgroup> In-Reply-To: <19575_1343030856_500D0648_19575_7867_1_32076722-70e1-40b8-951d-d02e511b336c@PEXCVZYH01.corporate.adroot.infra.ftgroup> 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] IETF #84 - Proposal for a side meeting on the CDNI request routing 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 09:05:32 -0000 Hi Yannick, I just entered the doodle; also for me Monday evening after the technical p= lenary is the best time. - Jan > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > yannick.lelouedec@orange.com > Sent: Monday, July 23, 2012 10:08 AM > To: BERTRAND Gilles RD-CORE; Woundy, Richard; Francois Le Faucheur > (flefauch@cisco.com); Scott Wainner; Ben Niven-Jenkins; Brandenburg, R. > (Ray) van; cdni@ietf.org > Subject: Re: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI > request routing interface >=20 > Dear Gilles, All, >=20 > I mean on Monday, > After the welcome session in case the representatives from the CDNIW G > must attend it (Extract from Monday's agenda : "1730 - 1800 Welcome, 1. > Welcome - Bernard Aboba..."). > Otherwise (if the representatives must not attend this welcome session), = we > could even possibly arrange it at the same time if it appears that most p= eople > are available at that time. >=20 > Our initial plan was indeed to arrange it rather on Sunday, but some peop= le > will be available from Monday on only. >=20 > Best regards, >=20 > Yannick Le Lou=E9dec. >=20 >=20 > -----Message d'origine----- > De=A0: BERTRAND Gilles RD-CORE > Envoy=E9=A0: lundi 23 juillet 2012 09:53 > =C0=A0: LE LOUEDEC Yannick RD-CORE; Woundy, Richard; Francois Le Faucheur > (flefauch@cisco.com); Scott Wainner; Ben Niven-Jenkins; Brandenburg, R. > (Ray) van; cdni@ietf.org > Cc=A0: STEPHAN Emile RD-CORE > Objet=A0: RE: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI r= equest > routing interface >=20 > Yannick, >=20 > You probably mean on "Sunday" evening after the welcoming session? >=20 > Best regards, > -- > Gilles >=20 > -----Message d'origine----- > De=A0: LE LOUEDEC Yannick RD-CORE > Envoy=E9=A0: vendredi 20 juillet 2012 14:28 > =C0=A0: Woundy, Richard; Francois Le Faucheur (flefauch@cisco.com); Scott > Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.org Cc= =A0: > STEPHAN Emile RD-CORE; BERTRAND Gilles RD-CORE Objet=A0: RE: [CDNi] IETF > #84 - Proposal for a side meeting on the CDNI request routing interface >=20 > Dear all, >=20 > The doodle for the side meeting in Vancouver on CDNI request routing is > here: http://www.doodle.com/n552qchpurfcpckn > Please fill it in as soon as possible if you intend to attend. >=20 > Ideally we would like to arrange this meeting at Hyatt Regency Hotel, on > Monday evening, after the welcoming session. >=20 > Best regards, >=20 > Yannick Le Lou=E9dec. >=20 > -----Message d'origine----- > De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de > yannick.lelouedec@orange.com Envoy=E9=A0: lundi 16 juillet 2012 16:35 =C0= =A0: Scott > Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.org > Objet=A0: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI reque= st > routing interface >=20 > Dear all, >=20 > We propose to arrange a side meeting on Sunday evening during IETF #84 > (i.e. on July 29th) on the CDNI request routing interface. > The objective is to clear the discussion we had these last days via the I= ETF > CDNI mailing list, and to ease an efficient meeting on Tuesday 31. > If everybody agrees that this is a good idea, we will set up a doodle. >=20 > Best regards, >=20 > Yannick Le Lou=E9dec, > Orange OLNC. >=20 >=20 > __________________________________________________________ > __________________________________________________________ > _____ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veu= illez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. L= es > messages electroniques etant susceptibles d'alteration, France Telecom - > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete > this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges > that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 > __________________________________________________________ > __________________________________________________________ > _____ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce > message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete > this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges > that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From Jan.Seedorf@neclab.eu Wed Jul 25 02:13:02 2012 Return-Path: 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 F159021F858F for ; Wed, 25 Jul 2012 02:13:01 -0700 (PDT) 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 Qju568usFPVi for ; Wed, 25 Jul 2012 02:13:00 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 81EFD21F8566 for ; Wed, 25 Jul 2012 02:13:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 9A5F710192D; Wed, 25 Jul 2012 11:17:18 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oI0l-vJMfz-b; Wed, 25 Jul 2012 11:17:18 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 7C578101863; Wed, 25 Jul 2012 11:16:43 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.252]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 25 Jul 2012 11:13:16 +0200 From: Jan Seedorf To: "yannick.lelouedec@orange.com" , "Woundy, Richard" , "Francois Le Faucheur (flefauch@cisco.com)" , Scott Wainner , Ben Niven-Jenkins , "Brandenburg, R. (Ray) van" , "cdni@ietf.org" Thread-Topic: [CDNi] IETF #84 - Side meeting on the CDNI request routing interface - Monday 30 from 20:30 to 22:00 @ Hyatt Regency Hotel. Thread-Index: Ac1pnlTFYUDY04KNQqK7R9tnzQASSAABq6hwACgVm1A= Date: Wed, 25 Jul 2012 09:13:15 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE32CD8B1B@PALLENE.office.hd> References: <1807_1343138643_500EAB53_1807_7236_1_2e6394ca-9617-42a9-8264-6009c8b6563d@PEXCVZYH02.corporate.adroot.infra.ftgroup> In-Reply-To: <1807_1343138643_500EAB53_1807_7236_1_2e6394ca-9617-42a9-8264-6009c8b6563d@PEXCVZYH02.corporate.adroot.infra.ftgroup> 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] IETF #84 - Side meeting on the CDNI request routing interface - Monday 30 from 20:30 to 22:00 @ Hyatt Regency Hotel. 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 09:13:02 -0000 > The "footprint / capabilities advertisement" design team meeting will be = held > just before, the same day, from 18:00 to 20:00. > These slots seemed to be the ones that suit most people who wish to > attend. I want to attend the technical plenary. The doodle suggests that Monday 9:0= 0-11:00 is the best slot. I just sent a mail asking Enrico and Ray their pr= eference. Hopefully by today we can clarify if the "footprint / capabilitie= s advertisement" design team meeting will be=20 -- ** Monday 9:00-11:00 ** Or -- ** Monday 11:30-13:00 **=20 - Jan > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > yannick.lelouedec@orange.com > Sent: Tuesday, July 24, 2012 4:04 PM > To: Woundy, Richard; Francois Le Faucheur (flefauch@cisco.com); Scott > Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.org > Subject: Re: [CDNi] IETF #84 - Side meeting on the CDNI request routing > interface - Monday 30 from 20:30 to 22:00 @ Hyatt Regency Hotel. >=20 > Dear all, >=20 > The Meeting Point will be at the IETF Registration desk. >=20 > Best regards, >=20 > Yannick Le Lou=E9dec. >=20 > -----Message d'origine----- > De=A0: LE LOUEDEC Yannick RD-CORE > Envoy=E9=A0: mardi 24 juillet 2012 15:16 > =C0=A0: 'Woundy, Richard'; 'Francois Le Faucheur (flefauch@cisco.com)'; '= Scott > Wainner'; 'Ben Niven-Jenkins'; 'Brandenburg, R. (Ray) van'; 'cdni@ietf.or= g' > Cc=A0: STEPHAN Emile RD-CORE; BERTRAND Gilles RD-CORE > Objet=A0: IETF #84 - Side meeting on the CDNI request routing interface - > Monday 30 from 20:30 to 22:00 @ Hyatt Regency Hotel. >=20 > Dear all, >=20 > We propose to arrange the side meeting on CDNI request routing on > Monday 30 from 20:30 to 22:00 at Hyatt Regency Hotel. > The "footprint / capabilities advertisement" design team meeting will be = held > just before, the same day, from 18:00 to 20:00. > These slots seemed to be the ones that suit most people who wish to > attend. >=20 > Best regards, >=20 > Yannick Le Lou=E9dec. >=20 > -----Message d'origine----- > De=A0: LE LOUEDEC Yannick RD-CORE > Envoy=E9=A0: vendredi 20 juillet 2012 14:28 > =C0=A0: 'Woundy, Richard'; Francois Le Faucheur (flefauch@cisco.com); Sco= tt > Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.org Cc= =A0: > STEPHAN Emile RD-CORE; BERTRAND Gilles RD-CORE Objet=A0: RE: [CDNi] IETF > #84 - Proposal for a side meeting on the CDNI request routing interface >=20 > Dear all, >=20 > The doodle for the side meeting in Vancouver on CDNI request routing is > here: http://www.doodle.com/n552qchpurfcpckn > Please fill it in as soon as possible if you intend to attend. >=20 > Ideally we would like to arrange this meeting at Hyatt Regency Hotel, on > Monday evening, after the welcoming session. >=20 > Best regards, >=20 > Yannick Le Lou=E9dec. >=20 > -----Message d'origine----- > De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de > yannick.lelouedec@orange.com Envoy=E9=A0: lundi 16 juillet 2012 16:35 =C0= =A0: Scott > Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.org > Objet=A0: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI reque= st > routing interface >=20 > Dear all, >=20 > We propose to arrange a side meeting on Sunday evening during IETF #84 > (i.e. on July 29th) on the CDNI request routing interface. > The objective is to clear the discussion we had these last days via the I= ETF > CDNI mailing list, and to ease an efficient meeting on Tuesday 31. > If everybody agrees that this is a good idea, we will set up a doodle. >=20 > Best regards, >=20 > Yannick Le Lou=E9dec, > Orange OLNC. >=20 >=20 > __________________________________________________________ > __________________________________________________________ > _____ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veu= illez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. L= es > messages electroniques etant susceptibles d'alteration, France Telecom - > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete > this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges > that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 > __________________________________________________________ > __________________________________________________________ > _____ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce > message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete > this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges > that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Wed Jul 25 02:24:48 2012 Return-Path: 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 399F521F859B for ; Wed, 25 Jul 2012 02:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.575 X-Spam-Level: X-Spam-Status: No, score=-10.575 tagged_above=-999 required=5 tests=[AWL=0.023, 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 3XIMxHpF71Ud for ; Wed, 25 Jul 2012 02:24:46 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 962F721F858D for ; Wed, 25 Jul 2012 02:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=14911; q=dns/txt; s=iport; t=1343208286; x=1344417886; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WsENLwis4/aecexIWGteHv3uO0A26lvsfXM1iRBgrsA=; b=ATMuG79sG3gJH0j6ARBGGRkY1X8lvTew7ZMVN7MmGmAEwnvKT2Uk3N0V OE1y3sg67nwNoNdSnljgYYRYBk8tFHe3ltCDOUYoEOI3LyzOu8dIosOhc OL3SUPd9HagDKOd9E2PCTEcctNmlOAsPOYXFznXSBdkUpYYzePEDC39i4 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAGy6D1CtJV2c/2dsb2JhbAA7CoJKrhEBiQeBB4IhAQEEAQEBDwFbBAcQAgEIPwcnCxQRAQEEDgUihW+BfAubJKBMi00QCoV6YAOVSYEUjROBZoJfgV8 X-IronPort-AV: E=Sophos;i="4.77,652,1336348800"; d="scan'208,217";a="105124915" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 25 Jul 2012 09:24:46 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6P9OjIS001585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Jul 2012 09:24:46 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.17]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0298.004; Wed, 25 Jul 2012 04:24:45 -0500 From: "Francois Le Faucheur (flefauch)" To: "Brandenburg, R. (Ray) van" Thread-Topic: [CDNi] Summary of recommendations regarding CDNI and HAS Thread-Index: Ac1qOvmRw4vzxV5nTkemOaUkogVG3AANjw6A Date: Wed, 25 Jul 2012 09:24:45 +0000 Message-ID: <09C4CD02-9A87-4E5F-81F4-27800D0FD33E@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19062.004 x-tm-as-result: No--49.769000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_09C4CD029A874E5F81F427800D0FD33Eciscocom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" , "draft-brandenburg-cdni-has@tools.ietf.org" Subject: Re: [CDNi] Summary of recommendations regarding CDNI and HAS 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 09:24:48 -0000 --_000_09C4CD029A874E5F81F427800D0FD33Eciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Ray, Thanks much for this great summary. All, two small clarifications embedded (for those who did not follow the discus= sions as closely): On 25 Jul 2012, at 09:56, Brandenburg, R. (Ray) van wrote: Hi all, In order to spur some online discussion before the Vancouver meeting next w= eek, I=92ve summarized here the main recommendations from the CDNI & HTTP A= daptive Streaming work we=92ve been doing over the past months (see http://= tools.ietf.org/html/draft-brandenburg-cdni-has-03). Content Acquisition & File Management * The recommendation made in the draft is to not do anything specific f= or HAS regarding Content Acquisition and File Management. This means that t= he dCDN is not explicitly made aware of any relationship between different = chunks and the dCDN handles each chunk as if it were an individual and inde= pendent content item. The result is that content acquisition between uCDN a= nd dCDN also happens on a per-chunk basis. The draft does identify some pot= ential improvements in this area which might be taken up after a possible r= e-chartering of the WG once the initial CDNI specification is complete. Request Routing & Manifest Files * The recommendation made in the draft regarding request routing consis= ts of a mandatory and an optional part. The mandatory part, which each CDN = should support, is to perform request routing on a per-chunk basis. This me= ans that, depending on the type of manifest file that is used, there might = be an individual inter-CDN request routing operation taking place for each = individual chunk. As an optional feature, the draft describes a method wher= ein the uCDN rewrites the manifest file so that it points directly to the d= CDN, reducing request routing overhead. Since the process of manifest file = rewriting is a uCDN-internal process, this does not require standardization= beyond the existing request routing interface. Logging * The recommendation made in the draft regarding logging also consists = of a mandatory and an optional part. As a mandatory requirement, the draft = recommends that CDNs support per-chunk logging (e.g. logging each chunk req= uest as if it were an independent content request). As an optional feature,= the draft recommends to have a system where the dCDN can include a Content= Collection Identifier (CCID) and/or Session Identifier as part of the logg= ing fields, thereby providing the option for a CDN to do per-session loggin= g of HAS content. perhaps slightly more accurately: this is to facilitate the job of a CDN th= at wants to extract per-content-collection or per-session information (e.g.= for analytics) a-posteriori, deriving those form the per-chunk logs (but t= his approach does not require.assume or even define standardized per-sessio= n log formats). URL Signing * For CDNs that want to do URL signing, the draft recommends that CDNs = support either Flexible URL Signing by the Content Provider or by the uCDN. "Flexible URL signing" includes the ability to exclude from signature cover= age a subset of the URI path that varies on a per-chunk-basis (e.g. the par= t of the URI identifying the time/byte offset). * Both scenarios result in a system where the dCDN can remain unaware o= f HAS, with either the Content Provider or the uCDN signing the URLs in the= manifest file. Cheers Francois Other topics * Regarding Content Purge, the draft does not yet include a recommendat= ion but describes two options for dealing with the purge of large numbers o= f related files from a dCDN. A recommendation for this topic will be added = to the next iteration of the draft. * The draft recommends that the CDNI Capability Advertisement method in= cludes some way for CDNs to indicate whether they support the HAS-specific = optional features recommended in the draft (such as the ability to log CCID= s). Furthermore, the draft recommends that there is some way for dCDNs to i= ndicate whether they require access to manifest in order to be able to perf= orm the delivery of HAS content. I would like to invite anyone who is interested in the topic and wishes to = discuss some of these recommendations in Vancouver, to read the draft (http= ://tools.ietf.org/html/draft-brandenburg-cdni-has-03) before the meeting, s= o that we can have a fruitful discussion in Vancouver. Best regards, Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_09C4CD029A874E5F81F427800D0FD33Eciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9A64E736CAED7A45B7D71199C9DF2685@cisco.com> Content-Transfer-Encoding: quoted-printable Ray,
    Thanks much for this great summary.

    All,
    two small  clarifications embedded (for those who did not follow = the discussions as closely):

    On 25 Jul 2012, at 09:56, Brandenburg, R. (Ray) van wrote:

    Hi all,
     
    In order to spur some online discussion before the Vancouver meeting n= ext week, I=92ve summarized here the main recommendations from the CDNI &am= p; HTTP Adaptive Streaming work we=92ve been doing over the past months (se= e http:= //tools.ietf.org/html/draft-brandenburg-cdni-has-03).
     
    Content Acquisition & File Management
    • The recommendation made in the draft is to not do anything specific for= HAS regarding Content Acquisition and File Management. This means that the= dCDN is not explicitly made aware of any relationship between different ch= unks and the dCDN handles each chunk as if it were an individual and independent content item. The result is th= at content acquisition between uCDN and dCDN also happens on a per-chunk ba= sis. The draft does identify some potential improvements in this area which= might be taken up after a possible re-chartering of the WG once the initial CDNI specification is complete.
     
    Request Routing & Manifest Files
    • The recommendation made in the draft regarding request routing consists= of a mandatory and an optional part. The mandatory part, which each CDN sh= ould support, is to perform request routing on a per-chunk basis. This mean= s that, depending on the type of manifest file that is used, there might be an individual inter-CDN request= routing operation taking place for each individual chunk. As an optional f= eature, the draft describes a method wherein the uCDN rewrites the manifest= file so that it points directly to the dCDN, reducing request routing overhead. Since the process of manif= est file rewriting is a uCDN-internal process, this does not require standa= rdization beyond the existing request routing interface.
     
    Logging
    • The recommendation made in the draft regarding logging also consists of= a mandatory and an optional part. As a mandatory requirement, the draft re= commends that CDNs support per-chunk logging (e.g. logging each chunk reque= st as if it were an independent content request). As an optional feature, the draft recommends to have a s= ystem where the dCDN can include a Content Collection Identifier (CCID) and= /or Session Identifier as part of the logging fields, thereby providing the= option for a CDN to do per-session logging of HAS content.

    perhaps slightly more accurately: this is to facilitate the job of a C= DN that wants to extract per-content-collection or per-session information = (e.g. for analytics) a-posteriori, deriving those form the per-chunk logs (= but this approach does not require.assume or even define standardized per-session log formats).

     
    URL Signing
    • For CDNs that want to do URL signing, the draft recommends that CDNs su= pport either Flexible URL Signing by the Content Provider or by the uCDN.

    "Flexible URL signing" includes the ability to exclude from = signature coverage a subset of the URI path that varies on a per-chunk-basi= s (e.g. the part of the URI identifying the time/byte offset). 

    • Both scenarios result in a system where the dCDN can remain unaware of = HAS, with either the Content Provider or the uCDN signing the URLs in the m= anifest file.
     


    Cheers

    Francois


    Other topics
    • Regarding Content Purge, the draft does not yet include a recommendatio= n but describes two options for dealing with the purge of large numbers of = related files from a dCDN. A recommendation for this topic will be added to= the next iteration of the draft.
    • The draft recommends that the CDN= I Capability Advertisement method includes some way for CDNs to indicate wh= ether they support the HAS-specific optional features recommended in the dr= aft (such as the ability to log CCIDs). Furthermore, the draft recommends that there is some way for dCDNs to indicate whether they require access t= o manifest in order to be able to perform the delivery of HAS content.
      • =
     
    I would like to invite anyone who is interested in the topic and wishe= s to discuss some of these recommendations in Vancouver, to read the draft = (http://tools.ietf.org/html/draft-brandenburg-cdni-has-03= ) before the meeting, so that we can have a fruitful discussion in Vancouver= .
     
    Best regards,
     
    Ray
     
     
     
     

    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

    --_000_09C4CD029A874E5F81F427800D0FD33Eciscocom_-- From prvs=54654aace=allan.guillou@sfr.com Wed Jul 25 03:22:45 2012 Return-Path: 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 6AC8321F842D for ; Wed, 25 Jul 2012 03:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 COhZL8AyeAOy for ; Wed, 25 Jul 2012 03:22:43 -0700 (PDT) Received: from mx1-buro.sfr.fr (mx1-buro.sfr.fr [217.70.85.100]) by ietfa.amsl.com (Postfix) with ESMTP id A40D721F842F for ; Wed, 25 Jul 2012 03:22:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,652,1336341600"; d="scan'208";a="72424480" Received: from unknown (HELO EXCH010.encara.local.ads) ([10.29.105.3]) by mx1int-buro.prod with ESMTP; 25 Jul 2012 12:22:38 +0200 Received: from EXCN015.encara.local.ads ([fe80::f109:6a12:5ba6:f568]) by EXCH010.encara.local.ads ([::1]) with mapi id 14.02.0298.004; Wed, 25 Jul 2012 12:22:38 +0200 From: "GUILLOU, Allan" To: Scott Wainner , "cdni@ietf.org" Thread-Topic: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt Thread-Index: AQHNXmxnRilqPZt7K0CKdungWKhsWpciJ1CAgAA15wCAABY7AIAAEoKAgAk3HoCADhvJIA== Date: Wed, 25 Jul 2012 10:22:38 +0000 Message-ID: References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> <2040_1341930789_4FFC3D24_2040_2504_1_b86bff40-ae68-40c0-b8e5-060f51be6864@PEXCVZYH02.corporate.adroot.infra.ftgroup> <3A7EA7EE-F8D4-4094-83F2-12CD3826B662@tno.nl> <5004079D.4000406@cisco.com> In-Reply-To: <5004079D.4000406@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.141.56] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 10:22:45 -0000 Hi, With a "recusive model" as you ask if I understand, you expect the dCDN to = send like an "ack" for each request, and if not the uCDN will try to find t= he second best dCDN and do the same thing. I think that this model may add complexity and may cause some scalability p= roblem. You will have to implement timers between request and ack, retransm= ission mechanism to make sure that request has not been lost, loop free mec= hanism, And all this may add latency on all requests and performances probl= ems. In the iterative model, if the dCDN is not able to handle the request, this= request will be lost. It is the same thing in IP network today we do not a= sk the routing protocol to change when there is saturation somewhere. It is= the responsibility of each ISP to choose another route to join this destin= ation if he want to keep a good quality of service. If a dCDN is overloaded= , it will stop announcing part of its footprint or uCDN may apply some poli= cy to force choosing another dCDN. It is right that this second model may not in case of dCDN saturation have = the best reactivity, but it is exactly the same thing on the internet today= . We can imagine that a poor dCDN which have saturation will be "black list= ed" by all the uCDN and the regulation will be done like this. I think recursive model will add complexity all the time for a gain witch i= s not in my opinion so important and that will not be seen so often. Allan > -----Message d'origine----- > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de > Scott Wainner > Envoy=E9 : lundi 16 juillet 2012 14:23 > =C0 : cdni@ietf.org > Objet : Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing- > 00.txt > > On 7/10/12 11:39 AM, Brandenburg, R. (Ray) van wrote: > > Hi Yannick, > > > > We seem to be misunderstanding each other. Maybe this will help clarify > my point: > > > >> Let me try to fully understand your point: > >> Are you really meaning that in this case the dCDN has in reality > absolutely no obligation with regards to the uCDN? > >> Are you really meaning that in this case the dCDN decides alone, in > real time, and for each content request, whether it denies or accepts to > ensure delivery? > > What I mean is that I would like to have a RR Interface at least suppor= t > a model where for every content request the uCDN asks the dCDN whether it > wants to deliver that particular content item (I believe you call this a > PULL approach). And I would like to allow the dCDN to be able to say 'No' > on this request (whether it is for purposes or failure, overload, or any > other reason). > > > >> Are you really meaning that in this case the dCDN decides alone, in > real time, and for each content request, whether it denies or accepts to > ensure delivery, and this even if the dCDN has the capability to deliver > the content? > > Yes. > I think we have to delineate between the iterative and recursive model. > > The recursive model assumes that the client request to the uCDN will be > recursive and the CDN-I RR interface will be used to provide an answer > for each client request. The choice to initiate the recursion would be > determined by the footprint / capabilities. The ability of the dCDN to > execute the specific request would provide immediate feedback to the > uCDN. A dCDN that continues to advertise the footprint / capability, > but frequently or continually rejects the request via CDN-I RR would be > a poor candidate. The opportunity now arises where the uCDN may elect > to choose an alternate dCDN because its preferred dCDN (according to > footprint / capabilities) is 'under-performing'. > > The iterative model, the uCDN blindly redirects the client to the dCDN > based on the footprint / capabilities. What the dCDN does with the > request is somewhat transparent to the uCDN. With the exception of the > CDN-I logging, the uCDN assumes the dCDN is properly handling the > requests that were delegated to the dCDN. If you are trying to > 'tighten' up the case of blind rejections, then the frequency of the > footprint / capabilities advertisements would have to be accelerated. > For the case where the dCDN repeatedly sees requests from the uCDN that > the dCDN can't handle, it should retract its footprint / capabilities > advertisement. Failing to do so would continually black-hole routing > requests which would be indicated in the logging information. > > Either way, you need a feedback loop to avoid dumping routing requests. > > With any feedback loop (recursive routing request or footprint / > capabilities advertisement), you have to be careful about rapid > oscillations and dampening the responses. > > Scott > > > >> Are you really meaning that in this case the dCDN may possibly respons= e > negatively to all requests for content request redirection submitted by > the uCDN over the CDNI request routing interface? (i.e. that possibly the > uCDN will never be allowed/invited to redirect a content request to the > dCDN?) > > > > Yes. Any negative effect this may have on the business relationship > between uCDN and dCDN should be handled on the business level. > > > > Ray > > > > > > On Jul 10, 2012, at 4:33 PM, > > wrote: > > > >> Hi Ray, > >> > >> > >> 1) Ray, quoting your mail: "The current drafts seems to assume some > particular type of contractual agreement between CDNs that might not > always be the case." > >> > >> Please quote the draft. > >> Please let us know exactly to which sentence(s) of the draft you are > referring to. > >> Otherwise it is hard to discuss and comment on your email. > >> > >> > >> 2) Ray, Quoting your mail: "If a dCDN does not live up to its > contractual agreement, this should be something that is handled on a > business level, not on a protocol level." > >> > >> Maybe there is a deep misunderstanding. > >> So I will try to be clear again. > >> We do not propose the CDNI routing interface to be used by the dCDN to > send a message saying "Sorry, but I decide unilaterally to refuse this > content request". > >> We do not propose the CDNI routing interface to be used to handle any > aspect relating to a dCDN deciding unilaterally to stop living up to its > contractual agreement. > >> > >> Please let us know where you saw such an idea in this IETF draft "CDNI > request routing". > >> > >> The only role of the CDNI routing interface is to be used to advertise > CDNI routing information from the downstream CDN to the upstream CDN. > >> And this is the description given in this IETF draft. > >> > >> > >> 3) Ray, quoting your mail: "one example of a contractual agreement > between two CDNs is one in which the uCDN and dCDN have agreed that the > dCDN will deliver some content on behalf of a uCDN, but decide on a per- > request basis whether it wants to do so (and is for example paid per > request). In these cases, the dCDN needs to have the ability to deny > delivery on a per-request basis." > >> > >> Let me try to fully understand your point: > >> Are you really meaning that in this case the dCDN has in reality > absolutely no obligation with regards to the uCDN? > >> Are you really meaning that in this case the dCDN decides alone, in > real time, and for each content request, whether it denies or accepts to > ensure delivery? > >> Are you really meaning that in this case the dCDN decides alone, in > real time, and for each content request, whether it denies or accepts to > ensure delivery, and this even if the dCDN has the capability to deliver > the content? > >> Are you really meaning that in this case the dCDN may possibly respons= e > negatively to all requests for content request redirection submitted by > the uCDN over the CDNI request routing interface? (i.e. that possibly the > uCDN will never be allowed/invited to redirect a content request to the > dCDN?) > >> > >> > >> 4) Ray, quoting your mail: "Every routing protocol defines the expecte= d > behavior of interconnected elements/networks on a technical level, not on > a business level." > >> > >> Again, this is not what I have written, and this is not the idea we > want to share. > >> I wrote "Every routing protocol has been defined (or at least > configured) so far by considering the expected behavior of the > interconnected elements/networks." > >> That's all. > >> I can rephrase this sentence the following way: "we must know what we > expect to do with a protocol to design it correctly." > >> And IHMO this is an evidence; I don't know any other way to proceed. > >> > >> Besides, let us consider BGP (which is by the way an option proposed b= y > some IETF members to implement this CDNI routing interface). > >> In IP networks, BGP configurations in IP routers are defined as per th= e > business relationships (valley free policy, etc.). > >> Of course the business relationships determine the BGP configurations. > >> And of course BGP has been designed so as to allow to configure IP > interconnections adequately depending on the corresponding > Customer/provider, sibling and peering contractual agreements. > >> But this does not mean that BGP "defines the expected behavior of > interconnected elements/networks... on a business level." > >> Even if we can indeed infer quite accurately the business relationship= s > between ISP from the BGP configuration of their IP routers (see CAIDA > project), but this is another story. > >> > >> > >> Best regards, > >> > >> Yannick Le Lou=E9dec. > >> > >> > >> > >> -----Message d'origine----- > >> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > >> Envoy=E9 : mardi 10 juillet 2012 15:13 > >> =C0 : LE LOUEDEC Yannick RD-CORE; Ben Niven-Jenkins > >> Cc : Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE > >> Objet : RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- > routing-00.txt > >> > >> Hi Yannick, > >> > >> See comments inline. > >> > >> In general: IMO the CDNI interfaces should be abstracted from any kind > of contractual/business agreement that might or might not exist between a > dCDN and uCDN. The current drafts seems to assume some particular type of > contractual agreement between CDNs that might not always be the case. > >> > >> Ray > >> > >> -----Original Message----- > >> From: yannick.lelouedec@orange.com > [mailto:yannick.lelouedec@orange.com] > >> Sent: dinsdag 10 juli 2012 12:01 > >> To: Brandenburg, R. (Ray) van; Ben Niven-Jenkins > >> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE > >> Subject: RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- > routing-00.txt > >> > >> Hi Ray, all, > >> > >> > >> 1) Ray, Quoting your mail: "I don't see why the CDNI Request Routing > interface should state that a dCDN MUST deliver the content if it has > indicated its ability to do so earlier in either a contractual agreement > or in the capability interface." > >> > >> This is not what we have written. > >> Let me try to rephrase simply. > >> > >> A contractual agreement is a contractual agreement. > >> It put in writings the respective obligations of the uCDN and of the > dCDN. > >> The uCDN may redirect any content request to the dCDN as long as it is > in full conformance with the terms of this contractual agreement (the typ= e > of the content request is in full conformance, the maximum number of > content requests per second is respected, etc.). > >> In this case the dCDN may not say "Sorry, but I decide unilaterally to > refuse this content request". > >> > >> [RvB]: This is where we disagree. IMHO, the type of behavior you > describe (the dCDN not living up to its obligation) should not be enforce= d > by the CDNI Interfaces. If a dCDN does not live up to its contractual > agreement, this should be something that is handled on a business level, > not on a protocol level. > >> > >> Why? Because this is the deal, a contractual agreement is a contractua= l > agreement! > >> Yet the dCDN may say "I do apologize, but at this time I cannot handle > correctly a certain class of content requests specified in our contractua= l > agreement" (for example the class of the HTTP content requests with token > from French end users, because of overload situation, failure, etc.) This > is the role of the CDNI routing interface to provide the uCDN with such > information. > >> > >> (And the dCDN may be given a penalty for example if this was agreed in > the terms of the contractual agreement.) > >> > >> > >> 2) Ray, Quoting your mail: "I understand that in most cases, the > contractual agreement might indeed impose this behavior on the dCDN" > >> > >> Please provide the description of an example where this is not the > case. > >> Otherwise the IETF CDNI WG shall indeed consider this is ALWAYS the > case. > >> > >> [RvB]: I can't remember ever seeing such a discussion on the WG list. > Anyway: one example of a contractual agreement between two CDNs is one in > which the uCDN and dCDN have agreed that the dCDN will deliver some > content on behalf of a uCDN, but decide on a per-request basis whether it > wants to do so (and is for example paid per request). In these cases, the > dCDN needs to have the ability to deny delivery on a per-request basis. > >> > >> And this is an important point to be able to progress in the CDNI > interfaces' specification works. > >> > >> If the contractual agreement does not define clearly the obligations o= f > the uCDN, it is impossible to dimension adequately the dCDN, neither to > define correctly the CDNI contractual agreements between the dCDN and the > dCDNs of this dCDN. > >> If the contractual agreement does not define clearly the obligations o= f > the dCDN, the dCDN may do what it wants... even to put in the trash can > any content request it accepted to handle. > >> > >> [RvB]: Exactly, this is something that needs to be discussed on a > business/contractual level and not on a technical level. That is way IMHO > the CDNI Interfaces should not make ANY assumptions on what was agreed on > a contractual level. > >> > >> In both situations it is impossible to ensure any quality of experienc= e > to the end user. > >> > >> > >> 3) Ray, Quoting your mail: "I don't think this type of behavior should > be imposed by the protocol we're developing here." > >> > >> I do not sure I understand this sentence. > >> Every routing protocol has been defined (or at least configured) so fa= r > by considering the expected behavior of the interconnected > elements/networks. > >> > >> [RvB]: Every routing protocol defines the expected behavior of > interconnected elements/networks on a technical level, not on a business > level. Having a dCDN say 'I'm not willing to deliver this content' is > perfectly fine from a technical perspective, although it could be > problematic from a contractual perspective. > >> > >> But maybe I will understand if you provide an example on the point 2 > above. > >> > >> > >> Best regards, > >> > >> Yannick Le Lou=E9dec. > >> > >> > >> > >> -----Message d'origine----- > >> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > >> Envoy=E9 : mardi 10 juillet 2012 09:20 > >> =C0 : Ben Niven-Jenkins; LE LOUEDEC Yannick RD-CORE Cc : Pilarski Marc= in > - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR: I-D > Action: draft-lelouedec-cdni-request-routing-00.txt > >> > >> Hi Yannick, Ben, > >> > >> I tend to agree with Ben here. When reading the draft, I got the > feeling that the draft seems to assume a lot about the relationship > between the uCDN and dCDN. For example, I don't see why the CDNI Request > Routing interface should state that a dCDN MUST deliver the content if it > has indicated its ability to do so earlier in either a contractual > agreement or in the capability interface. I understand that in most cases= , > the contractual agreement might indeed impose this behavior on the dCDN, > but I don't think this type of behavior should be imposed by the protocol > we're developing here. > >> > >> It was always my assumption that the Request Routing Interface would a= t > least include the option of allowing the uCDN to query the dCDN for every > content request whether the dCDN is willing to deliver that particular > request. > >> > >> I will send my full review of the draft later. > >> > >> Ray > >> > >> -----Original Message----- > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf O= f > Ben Niven-Jenkins > >> Sent: dinsdag 10 juli 2012 7:38 > >> To: yannick.lelouedec@orange.com > >> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE > >> Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- > routing-00.txt > >> > >> Yannick, > >> > >> Please see inline. > >> > >> On 9 Jul 2012, at 20:05, wrote: > >> > >>> Hi Ben, all, > >>> > >>> Ben, quoting you mail below, "... the downstream CDN could reply with > >>> either "here is how to redirect it"", > >>> > >>> =3D> This is the role of the CDNI DRIS interface to provide the uCDN > with this information, and we target to make its specification public > before Vancouver meeting so that everyone may read it before the meeting > and get full knowledge of our proposal about this part of CDNI request > routing. > >>> > >>> Ben, quoting you mail below, "... or "no I can't/won't take that > content delivery right now", reasons may include the uCDN has requested a > delivery of a protocol the dCDN does not support (possibly in error). > >>> > >>> =3D> This is the role of the CDNI logging interface to provide the uC= DN > with this information. > >> I agree this information should be logged but the Request Routing > interface (what you call the DRIS) also needs to be able to indicate a > failure. > >> > >> Otherwise the uCDN will 'blindly' redirect the the dCDN and the > delivery will fail leading to poor end user experience. > >> > >>> Ben, quoting you mail below, "... or "no I can't/won't take that > content delivery right now", reasons may include ... the dCDN has no > capacity right now etc." > >>> > >>> =3D> This is the role of the CDNI routing interface to provide the uC= DN > with this information. > >> It is the role of the CDN capability/routing interface to advertise > broad capabilities etc not to give extremely fine grained real-time > information on exactly the state of the dCDN. > >> > >> Even if the capability/routing interface is real-time there are likely > to still be race conditions where we need the dCDN to be about to indicat= e > a failure to accept a redirect through the request routing/DRIS interface > >> > >>> So we may conclude we are in line basically, which is a good point. > >>> We just aimed at checking there was a common understanding on this > point. > >>> > >>> The key point for us here is that we don't want this sentence > extracted from draft-ietf-cdni-problem-statement be interpreted as: ". an= d > the dCDN MUST accept the content request except when it has not the > "ability" to do so." > >> Why not? IMO that is a valid scenario for some use cases. > >> > >>> The fact that the dCDN is temporary unable to handle content request > correctly is not a valid reason for the dCDN to be discharged of its > obligations to the uCDN. > >>> The contract set between the uCDN and the dCDN remains valid anyway, > and the obligations of the dCDN as well. > >> Correct, but that contract may not be the same for all uCDNs & dCDNs, > for example a uCDN may not have a guarantee that a dCDN can handle > everything it is requested to handle but the contract may only be that th= e > dCDN guarantees to handle up to a certain volume of traffic. > >> > >>> The dCDN must announce to the uCDN that it is temporary unable, as > soon as possible, via the CDNI routing interface. > >>> And the uCDN must take this information into account in its CDN > selection process as soon as possible. > >>> Then if the uCDN decides to continue to redirect content requests to > the dCDN, the uCDN MAY perfectly do it, but the uCDN knows these content > requests will be lost. > >> What happens in the period between the dCDN being unable to handle > requests and the time it takes to advertise that to the uCDN and for the > uCDN to process & incorporate that new knowledge? Are requests blindly > forwarded to the dCDN which is unable to handle them leading to poor user > experience? > >> > >>> We could even imagine the situation where the uCDN continues to do it > intentionally, because it has no better option and the content request > will be lost anyway. For example in the case where neither the uCDN nor > the other downstream CDNs of the uCDN cannot manage correctly the content > request, the uCDN could do it intentionally so as to be able to clearly > prove (with CDNI logging information) that it is the dCDN, not the uCDN, > who is at fault. > >>> But, of course, if there are alternative backup options, the normal > reaction of the uCDN is to stop as soon as possible to redirect content > requests to the dCDN when the uCDN knows that the dCDN is unable to handl= e > them correctly. > >>> > >>> So, to be clear, we would prefer the sentence to be understood as: > >>> ". and the dCDN MUST accept the content request. > >>> And if it cannot handle correctly the redirected content request it > receives, the content request is lost. > >> What about scenarios where the uCDN has a choice of dCDNs (e.g. two > national-wide CDNs offering services at different costs), the uCDN may > elect to query both dCDNs and decide based on their responses which one t= o > choose. If the dCDN is unable to satisfy the request the uCDN needs to > know that so that it can fallback to the (more expensive in this example) > dCDN. > >> > >>> For example the dCDN generates a response to the content request with > an error message, or no response at all. And in parallel the CDNI logging > interface may be used to exchange logs corresponding to this problem. > Anyway the dCDN MAY NOT redirect that content request back towards the > uCDN." > >>> > >>> Exactly as in IP networks: IP packets are not sent back towards the > origin by a downstream router under failure or congestion. > >> In a routed IP network, there is often a small packet loss while the > network re-converges, by enabling the dCDN to refuse a redirection at CDN= I > Request Routing/DRIS query time we can reduce that window by giving the > uCDN the option to take an alternative action (e.g. try another dCDN) > while the routing/capability information re-converges. > >> > >>> In both networks (IP and CDN), the reason is the same. > >>> If the dCDN redirects back a content request to the uCDN, this > generates a loop. > >> Loop avoidance is a separate issue IMO to whether we should allow a > dCDN to be able to communicate "I am unable/unwilling to take that conten= t > delivery at this time". > >> > >> Regards > >> Ben > >> > >>> To manage this would introduce a very high complexity. > >>> And this would be just to try to save the content requests redirected > by the uCDN to the dCDN in the timeslot between the time the dCDN gets > down and the time the uCDN takes this failure into account in its CDN > selection process. > >>> It is much better to try to reduce this timeslot as much as possible, > with routing optimizations (we will propose as soon as possible). > >>> Rather than introducing additional complexities (to manage redirectio= n > to the uCDN) in the framework. > >>> > >>> > >>> By the way, as you know, the IESG has just approved today the 'Conten= t > Distribution Network Interconnection (CDNI) Problem Statement' draft as > informational RFC. This is a good point. > >>> And, as you may see in the draft "CDNI request routing", we do not > propose to modify this problem statement draft. > >>> We want know to focus now on getting the specifications of all CDNI > interfaces ready as soon as possible. > >>> > >>> Best regards, > >>> > >>> Yannick Le Lou=E9dec. > >>> > >>> > >>> -----Message d'origine----- > >>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part > >>> de Ben Niven-Jenkins Envoy=E9 : lundi 9 juillet 2012 20:41 =C0 : BERT= RAND > >>> Gilles RD-CORE Cc : cdni@ietf.org; Pilarski Marcin - Korpo TP; MARREC > >>> Anne RD-CORE Objet : Re: [CDNi] TR: I-D Action: > >>> draft-lelouedec-cdni-request-routing-00.txt > >>> > >>> Colleagues, > >>> > >>> I started reading draft-lelouedec-cdni-request-routing-00 and this > text caught my eye: > >>> > >>> Quoting [I-D.ietf-cdni-problem-statement ], "The CDNI Request > >>> Routing > >>> interface enables a Request Routing function in an upstream CDN to > >>> query a Request Routing function in a downstream CDN to determine i= f > >>> the downstream CDN is able (and willing) to accept the delegated > >>> content request". > >>> > >>> The "ability" and the "willingness" of the downstream CDN to accept > >>> the delegated content request match two fully different processes i= n > >>> CDN interconnection. And the description of both these processes > >>> should be reviewed and clarified for the following reasons: > >>> > >>> o Regarding the former process, i.e. related to the "ability" > >>> ("enables a Request Routing function in an upstream CDN to query > a > >>> Request Routing function in a downstream CDN to determine if the > >>> downstream CDN is able (...) to accept the delegated content > >>> request"), a routing protocol is used to achieve such a process, > >>> called routing process, in many other technologies and networks > >>> (IP, ATM, etc.). In all these technologies, it is the downstrea= m > >>> entity that provides routing information to the upstream entity. > >>> The same approach should be applied to CDN interconnection. The > >>> reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN > 2, > >>> dCDN 3, and then it selects one of them based on their > responses") > >>> would suffer from latency, signaling overhead and/or lack of > >>> reactivity to events that impact the ability of the downstream > >>> CDNs to accept delegated content requests. > >>> > >>> o Regarding the latter process, i.e. related to the "willingness" > >>> ("enables a Request Routing function in an upstream CDN to query > a > >>> Request Routing function in a downstream CDN to determine if the > >>> downstream CDN (...) is willing (...)to accept the delegated > >>> content request"), it is to be noted that the relationship > between > >>> a uCDN and a dCDN is always in the frame of a contractual > >>> agreement between the administrative entity owning the uCDN, > >>> acting as the customer, and the administrative entity owning the > >>> dCDN, acting as the service provider. Therefore, consider a cas= e > >>> where > >>> > >>> * the uCDN has a content request to redirect which is in full > >>> conformance with the terms of this contractual agreement, and > >>> > >>> * the uCDN has selected this dCDN. > >>> > >>> As the uCDN knows, thanks to the routing information exchanged > via > >>> the aforementioned routing process, that the dCDN is able to > >>> accept this content request, the uCDN MAY redirect the content > >>> request to the dCDN and the dCDN MUST accept the content request= . > >>> Exchanging over the CDNI Request Routing interface information > >>> about the "willingness" of the dCDN to accept the content reques= t > >>> is not relevant. > >>> > >>> I think you might be over thinking what we wrote in the problem > statement. > >>> > >>> What was in the problem statement was meant to convey that an upstrea= m > CDN could make a request to a downstream CDN to say "how do I redirect > this request to you" and the downstream CDN could reply with either "her > is how to redirect it", or "no I can't/won't take that content delivery > right now", reasons may include the uCDN has requested a delivery of a > protocol the dCDN does not support (possibly in error) or the dCDN has no > capacity right now etc. > >>> > >>> Ben > >>> > >>> On 9 Jul 2012, at 18:00, wrote: > >>> > >>>> Hi everyone, > >>>> > >>>> We have just submitted the draft below. We are convinced that it wil= l > help the WG to progress on the CDNI routing issues. > >>>> > >>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 > >>>> > >>>> Any feedback is very welcome. > >>>> > >>>> Best regards, > >>>> > >>>> Gilles > >>>> > >>>> > >>>> -----Message d'origine----- > >>>> De : i-d-announce-bounces@ietf.org > >>>> [mailto:i-d-announce-bounces@ietf.org] De la part de > >>>> internet-drafts@ietf.org Envoy=E9 : lundi 9 juillet 2012 18:55 =C0 : > >>>> i-d-announce@ietf.org Objet : I-D Action: > >>>> draft-lelouedec-cdni-request-routing-00.txt > >>>> > >>>> > >>>> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >>>> > >>>> > >>>> Title : CDNI Request Routing > >>>> Author(s) : Yannick Le Louedec > >>>> Anne Marrec > >>>> Gilles Bertrand > >>>> Marcin Pilarski > >>>> Filename : draft-lelouedec-cdni-request-routing-00.txt > >>>> Pages : 30 > >>>> Date : 2012-07-09 > >>>> > >>>> Abstract: > >>>> The present document proposes to clarify the CDNI Request Routing > >>>> interface introduced in [I-D.ietf-cdni-framework] and [I-D.ietf-cdni= - > >>>> problem-statement], as well as related terminology. > >>>> > >>>> In particular the present document proposes to split the CDNI > >>>> Request Routing interface into two separate interfaces with clearer > >>>> roles, named respectively CDNI Routing interface and CDNI Downstrea= m > >>>> Resource Identifier Signaling interface (CDNI DRIS interface). > >>>> > >>>> This part of the CDN interconnection framework the IETF has been > >>>> referring to so far with the term "CDNI Request Routing" is just > >>>> another routing, signaling and forwarding problem in a long series o= f > >>>> the telecommunication history. For example, one can draw a direct > >>>> analogy between the IP/MPLS-TE framework and the CDN interconnection > >>>> framework. > >>>> > >>>> In addition, this document recommends that the specification of ALL > >>>> CDN interconnection interfaces in the scope of the CDNI IETF WG > >>>> relies on the equivalent concept to IP prefix for CDN > >>>> interconnection, named 'contentRequestScope'. This highly useful an= d > >>>> powerful concept SHALL be used to simplify the specification of ALL > >>>> CDN interconnection interfaces, as well as to ensure performance and > >>>> scalability in CDN interconnection. > >>>> > >>>> All these proposals can be smoothly integrated in the WG drafts, > >>>> especially [I-D.ietf-cdni-framework] and > >>>> [I-D.ietf-cdni-requirements], as they essentially propose (useful) > >>>> clarifications of the existing framework. > >>>> > >>>> > >>>> The IETF datatracker status page for this draft is: > >>>> https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-routin= g > >>>> > >>>> There's also a htmlized version available at: > >>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 > >>>> > >>>> > >>>> Internet-Drafts are also available by anonymous FTP at: > >>>> ftp://ftp.ietf.org/internet-drafts/ > >>>> > >>>> _______________________________________________ > >>>> 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 > >>>> > >>>> ____________________________________________________________________= _ > >>>> ____________________________________________________ > >>>> > >>>> Ce message et ses pieces jointes peuvent contenir des informations > >>>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses= , > >>>> exploites ou copies sans autorisation. Si vous avez recu ce message > >>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > que les pieces jointes. Les messages electroniques etant susceptibles > d'alteration, France Telecom - Orange decline toute responsabilite si ce > message a ete altere, deforme ou falsifie. Merci. > >>>> > >>>> This message and its attachments may contain confidential or > >>>> privileged information that may be protected by law; they should not > be distributed, used or copied without authorisation. > >>>> If you have received this email in error, please notify the sender > and delete this message and its attachments. > >>>> As emails may be altered, France Telecom - Orange is not liable for > messages that have been modified, changed or falsified. > >>>> Thank you. > >>>> > >>>> _______________________________________________ > >>>> 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 > >>> > >>> _____________________________________________________________________= _ > >>> ___________________________________________________ > >>> > >>> Ce message et ses pieces jointes peuvent contenir des informations > >>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > >>> exploites ou copies sans autorisation. Si vous avez recu ce message > >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > que les pieces jointes. Les messages electroniques etant susceptibles > d'alteration, France Telecom - Orange decline toute responsabilite si ce > message a ete altere, deforme ou falsifie. Merci. > >>> > >>> This message and its attachments may contain confidential or > >>> privileged information that may be protected by law; they should not > be distributed, used or copied without authorisation. > >>> If you have received this email in error, please notify the sender an= d > delete this message and its attachments. > >>> As emails may be altered, France Telecom - Orange is not liable for > messages that have been modified, changed or falsified. > >>> Thank you. > >>> > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni > >> This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/emaildisclaimer > >> > >> > >> > _________________________________________________________________________= _ > _______________________________________________ > >> > >> Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message par > erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les > pieces jointes. Les messages electroniques etant susceptibles > d'alteration, France Telecom - Orange decline toute responsabilite si ce > message a ete altere, deforme ou falsifie. Merci. > >> > >> This message and its attachments may contain confidential or privilege= d > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > >> If you have received this email in error, please notify the sender and > delete this message and its attachments. > >> As emails may be altered, France Telecom - Orange is not liable for > messages that have been modified, changed or falsified. > >> Thank you. > >> > >> > >> > _________________________________________________________________________= _ > _______________________________________________ > >> > >> Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > >> a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > >> France Telecom - Orange decline toute responsabilite si ce message a > ete altere, deforme ou falsifie. Merci. > >> > >> This message and its attachments may contain confidential or privilege= d > information that may be protected by law; > >> they should not be distributed, used or copied without authorisation. > >> If you have received this email in error, please notify the sender and > delete this message and its attachments. > >> As emails may be altered, France Telecom - Orange is not liable for > messages that have been modified, changed or falsified. > >> Thank you. > >> > > _______________________________________________ > > 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 Wed Jul 25 03:42:24 2012 Return-Path: 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 5B81221F8567 for ; Wed, 25 Jul 2012 03:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 MKnSrf09nK-5 for ; Wed, 25 Jul 2012 03:42:21 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 34EDB21F84EB for ; Wed, 25 Jul 2012 03:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=13193; q=dns/txt; s=iport; t=1343212941; x=1344422541; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=hcROA+4Pxl8lT8cbnuhl4Xy/ahMZZwQdMbQZHj/RxYQ=; b=REMUFyufEFy2xK2jOaeG7WLZAD9xzZjHY57ET07kk+/9fVELIPHrr70l 2chMe8BInFsHe4ZFzmPW90wowkeSigf9FcuBaFx6gCdue0nRKWPAcXjKq drefmMXe1a4iCctk3sZtstH5AcrisktEU0i3yJ8fDxqLNoxSADuywv8uY k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAB3ND1CtJXG+/2dsb2JhbAA7CoJKtxmBB4IgAQEBAwEBAQEPARpBBAYGCwsYCRYPCQMCAQIBFTATBgIBAR6Fb4F2BgubFaBIi10KhloDlUmBFI0TgWaCe4FD X-IronPort-AV: E=Sophos;i="4.77,652,1336348800"; d="scan'208,217";a="104907079" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 25 Jul 2012 10:42:20 +0000 Received: from rtp-swainner-89110.cisco.com (rtp-swainner-89110.cisco.com [10.116.109.203]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6PAgJ0m002068 for ; Wed, 25 Jul 2012 10:42:20 GMT Message-ID: <500FCD8B.1010508@cisco.com> Date: Wed, 25 Jul 2012 06:42:19 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: cdni@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060605020904050505080805" Subject: Re: [CDNi] Summary of recommendations regarding CDNI and HAS 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 10:42:24 -0000 This is a multi-part message in MIME format. --------------060605020904050505080805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ray, Comments in line ... Scott On 7/25/12 3:56 AM, Brandenburg, R. (Ray) van wrote: > Hi all, > In order to spur some online discussion before the Vancouver meeting > next week, I've summarized here the main recommendations from the CDNI > & HTTP Adaptive Streaming work we've been doing over the past months > (see _http://tools.ietf.org/html/draft-brandenburg-cdni-has-03_). > Content Acquisition & File Management > > * The recommendation made in the draft is to not do anything > specific for HAS regarding Content Acquisition and File > Management. This means that the dCDN is not explicitly made aware > of any relationship between different chunks and the dCDN handles > each chunk as if it were an individual and independent content > item. The result is that content acquisition between uCDN and dCDN > also happens on a per-chunk basis. The draft does identify some > potential improvements in this area which might be taken up after > a possible re-chartering of the WG once the initial CDNI > specification is complete. > > Request Routing & Manifest Files > > * The recommendation made in the draft regarding request routing > consists of a mandatory and an optional part. The mandatory part, > which each CDN should support, is to perform request routing on a > per-chunk basis. This means that, depending on the type of > manifest file that is used, there might be an individual inter-CDN > request routing operation taking place for each individual chunk. > As an optional feature, the draft describes a method wherein the > uCDN rewrites the manifest file so that it points directly to the > dCDN, reducing request routing overhead. Since the process of > manifest file rewriting is a uCDN-internal process, this does not > require standardization beyond the existing request routing > interface. > > Logging > > * The recommendation made in the draft regarding logging also > consists of a mandatory and an optional part. As a mandatory > requirement, the draft recommends that CDNs support per-chunk > logging (e.g. logging each chunk request as if it were an > independent content request). As an optional feature, the draft > recommends to have a system where the dCDN can include a Content > Collection Identifier (CCID) and/or Session Identifier as part of > the logging fields, thereby providing the option for a CDN to do > per-session logging of HAS content. > > URL Signing > > * For CDNs that want to do URL signing, the draft recommends that > CDNs support either Flexible URL Signing by the Content Provider > or by the uCDN. Both scenarios result in a system where the dCDN > can remain unaware of HAS, with either the Content Provider or the > uCDN signing the URLs in the manifest file. > I think we also indicated that the dCDN needed to signal that it supported the Flexible URL Signing so that the uCDN would know if that particular dCDN was a candidate or not. The corollary is that the uCDN needed a way to indicate to the dCDN which portions of the URL were included in the URL signing. I don't know if there was a recommendation on where and how these capabilities and methods were conveyed between the uCDN and dCDN. > Other topics > > * Regarding Content Purge, the draft does not yet include a > recommendation but describes two options for dealing with the > purge of large numbers of related files from a dCDN. A > recommendation for this topic will be added to the next iteration > of the draft. > * The draft recommends that the CDNI Capability Advertisement method > includes some way for CDNs to indicate whether they support the > HAS-specific optional features recommended in the draft (such as > the ability to log CCIDs). Furthermore, the draft recommends that > there is some way for dCDNs to indicate whether they require > access to manifest in order to be able to perform the delivery of > HAS content. > > I would like to invite anyone who is interested in the topic and > wishes to discuss some of these recommendations in Vancouver, to read > the draft (_http://tools.ietf.org/html/draft-brandenburg-cdni-has-03_) > before the meeting, so that we can have a fruitful discussion in > Vancouver. > Best regards, > Ray > > 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 --------------060605020904050505080805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    Ray,

        Comments in line ...

    Scott

    On 7/25/12 3:56 AM, Brandenburg, R. (Ray) van wrote:
    Hi all,
     
    In order to spur some online discussion before the Vancouver meeting next week, I’ve summarized here the main recommendations from the CDNI & HTTP Adaptive Streaming work we’ve been doing over the past months (see http://tools.ietf.org/html/draft-brandenburg-cdni-has-03).
     
    Content Acquisition & File Management
    • The recommendation made in the draft is to not do anything specific for HAS regarding Content Acquisition and File Management. This means that the dCDN is not explicitly made aware of any relationship between different chunks and the dCDN handles each chunk as if it were an individual and independent content item. The result is that content acquisition between uCDN and dCDN also happens on a per-chunk basis. The draft does identify some potential improvements in this area which might be taken up after a possible re-chartering of the WG once the initial CDNI specification is complete.
     
    Request Routing & Manifest Files
    • The recommendation made in the draft regarding request routing consists of a mandatory and an optional part. The mandatory part, which each CDN should support, is to perform request routing on a per-chunk basis. This means that, depending on the type of manifest file that is used, there might be an individual inter-CDN request routing operation taking place for each individual chunk. As an optional feature, the draft describes a method wherein the uCDN rewrites the manifest file so that it points directly to the dCDN, reducing request routing overhead. Since the process of manifest file rewriting is a uCDN-internal process, this does not require standardization beyond the existing request routing interface.
     
    Logging
    • The recommendation made in the draft regarding logging also consists of a mandatory and an optional part. As a mandatory requirement, the draft recommends that CDNs support per-chunk logging (e.g. logging each chunk request as if it were an independent content request). As an optional feature, the draft recommends to have a system where the dCDN can include a Content Collection Identifier (CCID) and/or Session Identifier as part of the logging fields, thereby providing the option for a CDN to do per-session logging of HAS content.
     
    URL Signing
    • For CDNs that want to do URL signing, the draft recommends that CDNs support either Flexible URL Signing by the Content Provider or by the uCDN. Both scenarios result in a system where the dCDN can remain unaware of HAS, with either the Content Provider or the uCDN signing the URLs in the manifest file.
     
        I think we also indicated that the dCDN needed to signal that it supported the Flexible URL Signing so that the uCDN would know if that particular dCDN was a candidate or not.

        The corollary is that the uCDN needed a way to indicate to the dCDN which portions of the URL were included in the URL signing.

        I don't know if there was a recommendation on where and how these capabilities and methods were conveyed between the uCDN and dCDN.
    Other topics
    • Regarding Content Purge, the draft does not yet include a recommendation but describes two options for dealing with the purge of large numbers of related files from a dCDN. A recommendation for this topic will be added to the next iteration of the draft.
    • The draft recommends that the CDNI Capability Advertisement method includes some way for CDNs to indicate whether they support the HAS-specific optional features recommended in the draft (such as the ability to log CCIDs). Furthermore, the draft recommends that there is some way for dCDNs to indicate whether they require access to manifest in order to be able to perform the delivery of HAS content.
     
    I would like to invite anyone who is interested in the topic and wishes to discuss some of these recommendations in Vancouver, to read the draft (http://tools.ietf.org/html/draft-brandenburg-cdni-has-03) before the meeting, so that we can have a fruitful discussion in Vancouver.
     
    Best regards,
     
    Ray
     
     
     
     

    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

    --------------060605020904050505080805-- From gilles.bertrand@orange.com Wed Jul 25 04:39:19 2012 Return-Path: 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 C798621F855E for ; Wed, 25 Jul 2012 04:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 9qx07LbydL1n for ; Wed, 25 Jul 2012 04:39:16 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 403E221F8559 for ; Wed, 25 Jul 2012 04:39:15 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 03B6C18C55D; Wed, 25 Jul 2012 13:39:14 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id DD106238059; Wed, 25 Jul 2012 13:39:13 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 25 Jul 2012 13:39:13 +0200 From: To: "GUILLOU, Allan" , Scott Wainner , "cdni@ietf.org" Thread-Topic: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt Thread-Index: AQHNak9y93FMZ4uw8UKNZpQAh7XcfZc53n3g Date: Wed, 25 Jul 2012 11:39:12 +0000 Message-ID: <29661_1343216353_500FDAE1_29661_643_1_2AC63C9F27AF8446B0C064C50FC0A89305D959@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> <2040_1341930789_4FFC3D24_2040_2504_1_b86bff40-ae68-40c0-b8e5-060f51be6864@PEXCVZYH02.corporate.adroot.infra.ftgroup> <3A7EA7EE-F8D4-4094-83F2-12CD3826B662@tno.nl> <5004079D.4000406@cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 11:39:20 -0000 Hi everyone, I fully agree with Allan's comments. Putting aside the vocabulary ('recursi= ve model' etc), Allan's comment are consistent with the messages that http:= //tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 tries to conv= ey. " o Regarding the former process, i.e. related to the "ability" ("enables a Request Routing function in an upstream CDN to query a Request Routing function in a downstream CDN to determine if the downstream CDN is able (...) to accept the delegated content request"), a routing protocol is used to achieve such a process, called routing process, in many other technologies and networks (IP, ATM, etc.). In all these technologies, it is the downstream entity that provides routing information to the upstream entity. The same approach should be applied to CDN interconnection. The reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2, dCDN 3, and then it selects one of them based on their responses") would suffer from latency, signaling overhead and/or lack of reactivity to events that impact the ability of the downstream CDNs to accept delegated content requests." Best regards, -- Gilles -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de G= UILLOU, Allan Envoy=E9=A0: mercredi 25 juillet 2012 12:23 =C0=A0: Scott Wainner; cdni@ietf.org Objet=A0: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-0= 0.txt Hi, With a "recusive model" as you ask if I understand, you expect the dCDN to = send like an "ack" for each request, and if not the uCDN will try to find t= he second best dCDN and do the same thing. I think that this model may add complexity and may cause some scalability p= roblem. You will have to implement timers between request and ack, retransm= ission mechanism to make sure that request has not been lost, loop free mec= hanism, And all this may add latency on all requests and performances probl= ems. In the iterative model, if the dCDN is not able to handle the request, this= request will be lost. It is the same thing in IP network today we do not a= sk the routing protocol to change when there is saturation somewhere. It is= the responsibility of each ISP to choose another route to join this destin= ation if he want to keep a good quality of service. If a dCDN is overloaded= , it will stop announcing part of its footprint or uCDN may apply some poli= cy to force choosing another dCDN. It is right that this second model may not in case of dCDN saturation have = the best reactivity, but it is exactly the same thing on the internet today= . We can imagine that a poor dCDN which have saturation will be "black list= ed" by all the uCDN and the regulation will be done like this. I think recursive model will add complexity all the time for a gain witch i= s not in my opinion so important and that will not be seen so often. Allan > -----Message d'origine----- > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part=20 > de Scott Wainner Envoy=E9 : lundi 16 juillet 2012 14:23 =C0 :=20 > cdni@ietf.org Objet : Re: [CDNi] TR: I-D Action:=20 > draft-lelouedec-cdni-request-routing- > 00.txt > > On 7/10/12 11:39 AM, Brandenburg, R. (Ray) van wrote: > > Hi Yannick, > > > > We seem to be misunderstanding each other. Maybe this will help=20 > > clarify > my point: > > > >> Let me try to fully understand your point: > >> Are you really meaning that in this case the dCDN has in reality > absolutely no obligation with regards to the uCDN? > >> Are you really meaning that in this case the dCDN decides alone, in > real time, and for each content request, whether it denies or accepts=20 > to ensure delivery? > > What I mean is that I would like to have a RR Interface at least=20 > > support > a model where for every content request the uCDN asks the dCDN whether=20 > it wants to deliver that particular content item (I believe you call=20 > this a PULL approach). And I would like to allow the dCDN to be able to s= ay 'No' > on this request (whether it is for purposes or failure, overload, or=20 > any other reason). > > > >> Are you really meaning that in this case the dCDN decides alone, in > real time, and for each content request, whether it denies or accepts=20 > to ensure delivery, and this even if the dCDN has the capability to=20 > deliver the content? > > Yes. > I think we have to delineate between the iterative and recursive model. > > The recursive model assumes that the client request to the uCDN will=20 > be recursive and the CDN-I RR interface will be used to provide an=20 > answer for each client request. The choice to initiate the recursion=20 > would be determined by the footprint / capabilities. The ability of=20 > the dCDN to execute the specific request would provide immediate=20 > feedback to the uCDN. A dCDN that continues to advertise the=20 > footprint / capability, but frequently or continually rejects the=20 > request via CDN-I RR would be a poor candidate. The opportunity now=20 > arises where the uCDN may elect to choose an alternate dCDN because=20 > its preferred dCDN (according to footprint / capabilities) is 'under-perf= orming'. > > The iterative model, the uCDN blindly redirects the client to the dCDN=20 > based on the footprint / capabilities. What the dCDN does with the=20 > request is somewhat transparent to the uCDN. With the exception of=20 > the CDN-I logging, the uCDN assumes the dCDN is properly handling the=20 > requests that were delegated to the dCDN. If you are trying to=20 > 'tighten' up the case of blind rejections, then the frequency of the=20 > footprint / capabilities advertisements would have to be accelerated. > For the case where the dCDN repeatedly sees requests from the uCDN=20 > that the dCDN can't handle, it should retract its footprint /=20 > capabilities advertisement. Failing to do so would continually=20 > black-hole routing requests which would be indicated in the logging infor= mation. > > Either way, you need a feedback loop to avoid dumping routing requests. > > With any feedback loop (recursive routing request or footprint /=20 > capabilities advertisement), you have to be careful about rapid=20 > oscillations and dampening the responses. > > Scott > > > >> Are you really meaning that in this case the dCDN may possibly=20 > >> response > negatively to all requests for content request redirection submitted=20 > by the uCDN over the CDNI request routing interface? (i.e. that=20 > possibly the uCDN will never be allowed/invited to redirect a content=20 > request to the > dCDN?) > > > > Yes. Any negative effect this may have on the business relationship > between uCDN and dCDN should be handled on the business level. > > > > Ray > > > > > > On Jul 10, 2012, at 4:33 PM, > > wrote: > > > >> Hi Ray, > >> > >> > >> 1) Ray, quoting your mail: "The current drafts seems to assume some > particular type of contractual agreement between CDNs that might not=20 > always be the case." > >> > >> Please quote the draft. > >> Please let us know exactly to which sentence(s) of the draft you=20 > >> are > referring to. > >> Otherwise it is hard to discuss and comment on your email. > >> > >> > >> 2) Ray, Quoting your mail: "If a dCDN does not live up to its > contractual agreement, this should be something that is handled on a=20 > business level, not on a protocol level." > >> > >> Maybe there is a deep misunderstanding. > >> So I will try to be clear again. > >> We do not propose the CDNI routing interface to be used by the dCDN=20 > >> to > send a message saying "Sorry, but I decide unilaterally to refuse this=20 > content request". > >> We do not propose the CDNI routing interface to be used to handle=20 > >> any > aspect relating to a dCDN deciding unilaterally to stop living up to=20 > its contractual agreement. > >> > >> Please let us know where you saw such an idea in this IETF draft=20 > >> "CDNI > request routing". > >> > >> The only role of the CDNI routing interface is to be used to=20 > >> advertise > CDNI routing information from the downstream CDN to the upstream CDN. > >> And this is the description given in this IETF draft. > >> > >> > >> 3) Ray, quoting your mail: "one example of a contractual agreement > between two CDNs is one in which the uCDN and dCDN have agreed that=20 > the dCDN will deliver some content on behalf of a uCDN, but decide on=20 > a per- request basis whether it wants to do so (and is for example=20 > paid per request). In these cases, the dCDN needs to have the ability=20 > to deny delivery on a per-request basis." > >> > >> Let me try to fully understand your point: > >> Are you really meaning that in this case the dCDN has in reality > absolutely no obligation with regards to the uCDN? > >> Are you really meaning that in this case the dCDN decides alone, in > real time, and for each content request, whether it denies or accepts=20 > to ensure delivery? > >> Are you really meaning that in this case the dCDN decides alone, in > real time, and for each content request, whether it denies or accepts=20 > to ensure delivery, and this even if the dCDN has the capability to=20 > deliver the content? > >> Are you really meaning that in this case the dCDN may possibly=20 > >> response > negatively to all requests for content request redirection submitted=20 > by the uCDN over the CDNI request routing interface? (i.e. that=20 > possibly the uCDN will never be allowed/invited to redirect a content=20 > request to the > dCDN?) > >> > >> > >> 4) Ray, quoting your mail: "Every routing protocol defines the=20 > >> expected > behavior of interconnected elements/networks on a technical level, not=20 > on a business level." > >> > >> Again, this is not what I have written, and this is not the idea we > want to share. > >> I wrote "Every routing protocol has been defined (or at least > configured) so far by considering the expected behavior of the=20 > interconnected elements/networks." > >> That's all. > >> I can rephrase this sentence the following way: "we must know what=20 > >> we > expect to do with a protocol to design it correctly." > >> And IHMO this is an evidence; I don't know any other way to proceed. > >> > >> Besides, let us consider BGP (which is by the way an option=20 > >> proposed by > some IETF members to implement this CDNI routing interface). > >> In IP networks, BGP configurations in IP routers are defined as per=20 > >> the > business relationships (valley free policy, etc.). > >> Of course the business relationships determine the BGP configurations. > >> And of course BGP has been designed so as to allow to configure IP > interconnections adequately depending on the corresponding=20 > Customer/provider, sibling and peering contractual agreements. > >> But this does not mean that BGP "defines the expected behavior of > interconnected elements/networks... on a business level." > >> Even if we can indeed infer quite accurately the business=20 > >> relationships > between ISP from the BGP configuration of their IP routers (see CAIDA=20 > project), but this is another story. > >> > >> > >> Best regards, > >> > >> Yannick Le Lou=E9dec. > >> > >> > >> > >> -----Message d'origine----- > >> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > >> Envoy=E9 : mardi 10 juillet 2012 15:13 =C0 : LE LOUEDEC Yannick=20 > >> RD-CORE; Ben Niven-Jenkins Cc : Pilarski Marcin - Korpo TP;=20 > >> cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR: I-D=20 > >> Action: draft-lelouedec-cdni-request- > routing-00.txt > >> > >> Hi Yannick, > >> > >> See comments inline. > >> > >> In general: IMO the CDNI interfaces should be abstracted from any=20 > >> kind > of contractual/business agreement that might or might not exist=20 > between a dCDN and uCDN. The current drafts seems to assume some=20 > particular type of contractual agreement between CDNs that might not alwa= ys be the case. > >> > >> Ray > >> > >> -----Original Message----- > >> From: yannick.lelouedec@orange.com > [mailto:yannick.lelouedec@orange.com] > >> Sent: dinsdag 10 juli 2012 12:01 > >> To: Brandenburg, R. (Ray) van; Ben Niven-Jenkins > >> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE > >> Subject: RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- > routing-00.txt > >> > >> Hi Ray, all, > >> > >> > >> 1) Ray, Quoting your mail: "I don't see why the CDNI Request=20 > >> Routing > interface should state that a dCDN MUST deliver the content if it has=20 > indicated its ability to do so earlier in either a contractual=20 > agreement or in the capability interface." > >> > >> This is not what we have written. > >> Let me try to rephrase simply. > >> > >> A contractual agreement is a contractual agreement. > >> It put in writings the respective obligations of the uCDN and of=20 > >> the > dCDN. > >> The uCDN may redirect any content request to the dCDN as long as it=20 > >> is > in full conformance with the terms of this contractual agreement (the=20 > type of the content request is in full conformance, the maximum number=20 > of content requests per second is respected, etc.). > >> In this case the dCDN may not say "Sorry, but I decide unilaterally=20 > >> to > refuse this content request". > >> > >> [RvB]: This is where we disagree. IMHO, the type of behavior you > describe (the dCDN not living up to its obligation) should not be=20 > enforced by the CDNI Interfaces. If a dCDN does not live up to its=20 > contractual agreement, this should be something that is handled on a=20 > business level, not on a protocol level. > >> > >> Why? Because this is the deal, a contractual agreement is a=20 > >> contractual > agreement! > >> Yet the dCDN may say "I do apologize, but at this time I cannot=20 > >> handle > correctly a certain class of content requests specified in our=20 > contractual agreement" (for example the class of the HTTP content=20 > requests with token from French end users, because of overload=20 > situation, failure, etc.) This is the role of the CDNI routing=20 > interface to provide the uCDN with such information. > >> > >> (And the dCDN may be given a penalty for example if this was agreed=20 > >> in > the terms of the contractual agreement.) > >> > >> > >> 2) Ray, Quoting your mail: "I understand that in most cases, the > contractual agreement might indeed impose this behavior on the dCDN" > >> > >> Please provide the description of an example where this is not the > case. > >> Otherwise the IETF CDNI WG shall indeed consider this is ALWAYS the > case. > >> > >> [RvB]: I can't remember ever seeing such a discussion on the WG list. > Anyway: one example of a contractual agreement between two CDNs is one=20 > in which the uCDN and dCDN have agreed that the dCDN will deliver some=20 > content on behalf of a uCDN, but decide on a per-request basis whether=20 > it wants to do so (and is for example paid per request). In these=20 > cases, the dCDN needs to have the ability to deny delivery on a per-reque= st basis. > >> > >> And this is an important point to be able to progress in the CDNI > interfaces' specification works. > >> > >> If the contractual agreement does not define clearly the=20 > >> obligations of > the uCDN, it is impossible to dimension adequately the dCDN, neither=20 > to define correctly the CDNI contractual agreements between the dCDN=20 > and the dCDNs of this dCDN. > >> If the contractual agreement does not define clearly the=20 > >> obligations of > the dCDN, the dCDN may do what it wants... even to put in the trash=20 > can any content request it accepted to handle. > >> > >> [RvB]: Exactly, this is something that needs to be discussed on a > business/contractual level and not on a technical level. That is way=20 > IMHO the CDNI Interfaces should not make ANY assumptions on what was=20 > agreed on a contractual level. > >> > >> In both situations it is impossible to ensure any quality of=20 > >> experience > to the end user. > >> > >> > >> 3) Ray, Quoting your mail: "I don't think this type of behavior=20 > >> should > be imposed by the protocol we're developing here." > >> > >> I do not sure I understand this sentence. > >> Every routing protocol has been defined (or at least configured) so=20 > >> far > by considering the expected behavior of the interconnected=20 > elements/networks. > >> > >> [RvB]: Every routing protocol defines the expected behavior of > interconnected elements/networks on a technical level, not on a=20 > business level. Having a dCDN say 'I'm not willing to deliver this=20 > content' is perfectly fine from a technical perspective, although it=20 > could be problematic from a contractual perspective. > >> > >> But maybe I will understand if you provide an example on the point=20 > >> 2 > above. > >> > >> > >> Best regards, > >> > >> Yannick Le Lou=E9dec. > >> > >> > >> > >> -----Message d'origine----- > >> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > >> Envoy=E9 : mardi 10 juillet 2012 09:20 =C0 : Ben Niven-Jenkins; LE=20 > >> LOUEDEC Yannick RD-CORE Cc : Pilarski Marcin > - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR:=20 > I-D > Action: draft-lelouedec-cdni-request-routing-00.txt > >> > >> Hi Yannick, Ben, > >> > >> I tend to agree with Ben here. When reading the draft, I got the > feeling that the draft seems to assume a lot about the relationship=20 > between the uCDN and dCDN. For example, I don't see why the CDNI=20 > Request Routing interface should state that a dCDN MUST deliver the=20 > content if it has indicated its ability to do so earlier in either a=20 > contractual agreement or in the capability interface. I understand=20 > that in most cases, the contractual agreement might indeed impose this=20 > behavior on the dCDN, but I don't think this type of behavior should=20 > be imposed by the protocol we're developing here. > >> > >> It was always my assumption that the Request Routing Interface=20 > >> would at > least include the option of allowing the uCDN to query the dCDN for=20 > every content request whether the dCDN is willing to deliver that=20 > particular request. > >> > >> I will send my full review of the draft later. > >> > >> Ray > >> > >> -----Original Message----- > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On=20 > >> Behalf Of > Ben Niven-Jenkins > >> Sent: dinsdag 10 juli 2012 7:38 > >> To: yannick.lelouedec@orange.com > >> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE > >> Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- > routing-00.txt > >> > >> Yannick, > >> > >> Please see inline. > >> > >> On 9 Jul 2012, at 20:05, wrote: > >> > >>> Hi Ben, all, > >>> > >>> Ben, quoting you mail below, "... the downstream CDN could reply=20 > >>> with either "here is how to redirect it"", > >>> > >>> =3D> This is the role of the CDNI DRIS interface to provide the uCDN > with this information, and we target to make its specification public=20 > before Vancouver meeting so that everyone may read it before the=20 > meeting and get full knowledge of our proposal about this part of CDNI=20 > request routing. > >>> > >>> Ben, quoting you mail below, "... or "no I can't/won't take that > content delivery right now", reasons may include the uCDN has=20 > requested a delivery of a protocol the dCDN does not support (possibly in= error). > >>> > >>> =3D> This is the role of the CDNI logging interface to provide the=20 > >>> uCDN > with this information. > >> I agree this information should be logged but the Request Routing > interface (what you call the DRIS) also needs to be able to indicate a=20 > failure. > >> > >> Otherwise the uCDN will 'blindly' redirect the the dCDN and the > delivery will fail leading to poor end user experience. > >> > >>> Ben, quoting you mail below, "... or "no I can't/won't take that > content delivery right now", reasons may include ... the dCDN has no=20 > capacity right now etc." > >>> > >>> =3D> This is the role of the CDNI routing interface to provide the=20 > >>> uCDN > with this information. > >> It is the role of the CDN capability/routing interface to advertise > broad capabilities etc not to give extremely fine grained real-time=20 > information on exactly the state of the dCDN. > >> > >> Even if the capability/routing interface is real-time there are=20 > >> likely > to still be race conditions where we need the dCDN to be about to=20 > indicate a failure to accept a redirect through the request=20 > routing/DRIS interface > >> > >>> So we may conclude we are in line basically, which is a good point. > >>> We just aimed at checking there was a common understanding on this > point. > >>> > >>> The key point for us here is that we don't want this sentence > extracted from draft-ietf-cdni-problem-statement be interpreted as: ".=20 > and the dCDN MUST accept the content request except when it has not=20 > the "ability" to do so." > >> Why not? IMO that is a valid scenario for some use cases. > >> > >>> The fact that the dCDN is temporary unable to handle content=20 > >>> request > correctly is not a valid reason for the dCDN to be discharged of its=20 > obligations to the uCDN. > >>> The contract set between the uCDN and the dCDN remains valid=20 > >>> anyway, > and the obligations of the dCDN as well. > >> Correct, but that contract may not be the same for all uCDNs &=20 > >> dCDNs, > for example a uCDN may not have a guarantee that a dCDN can handle=20 > everything it is requested to handle but the contract may only be that=20 > the dCDN guarantees to handle up to a certain volume of traffic. > >> > >>> The dCDN must announce to the uCDN that it is temporary unable, as > soon as possible, via the CDNI routing interface. > >>> And the uCDN must take this information into account in its CDN > selection process as soon as possible. > >>> Then if the uCDN decides to continue to redirect content requests=20 > >>> to > the dCDN, the uCDN MAY perfectly do it, but the uCDN knows these=20 > content requests will be lost. > >> What happens in the period between the dCDN being unable to handle > requests and the time it takes to advertise that to the uCDN and for=20 > the uCDN to process & incorporate that new knowledge? Are requests=20 > blindly forwarded to the dCDN which is unable to handle them leading=20 > to poor user experience? > >> > >>> We could even imagine the situation where the uCDN continues to do=20 > >>> it > intentionally, because it has no better option and the content request=20 > will be lost anyway. For example in the case where neither the uCDN=20 > nor the other downstream CDNs of the uCDN cannot manage correctly the=20 > content request, the uCDN could do it intentionally so as to be able=20 > to clearly prove (with CDNI logging information) that it is the dCDN,=20 > not the uCDN, who is at fault. > >>> But, of course, if there are alternative backup options, the=20 > >>> normal > reaction of the uCDN is to stop as soon as possible to redirect=20 > content requests to the dCDN when the uCDN knows that the dCDN is=20 > unable to handle them correctly. > >>> > >>> So, to be clear, we would prefer the sentence to be understood as: > >>> ". and the dCDN MUST accept the content request. > >>> And if it cannot handle correctly the redirected content request=20 > >>> it > receives, the content request is lost. > >> What about scenarios where the uCDN has a choice of dCDNs (e.g. two > national-wide CDNs offering services at different costs), the uCDN may=20 > elect to query both dCDNs and decide based on their responses which=20 > one to choose. If the dCDN is unable to satisfy the request the uCDN=20 > needs to know that so that it can fallback to the (more expensive in=20 > this example) dCDN. > >> > >>> For example the dCDN generates a response to the content request=20 > >>> with > an error message, or no response at all. And in parallel the CDNI=20 > logging interface may be used to exchange logs corresponding to this prob= lem. > Anyway the dCDN MAY NOT redirect that content request back towards the=20 > uCDN." > >>> > >>> Exactly as in IP networks: IP packets are not sent back towards=20 > >>> the > origin by a downstream router under failure or congestion. > >> In a routed IP network, there is often a small packet loss while=20 > >> the > network re-converges, by enabling the dCDN to refuse a redirection at=20 > CDNI Request Routing/DRIS query time we can reduce that window by=20 > giving the uCDN the option to take an alternative action (e.g. try=20 > another dCDN) while the routing/capability information re-converges. > >> > >>> In both networks (IP and CDN), the reason is the same. > >>> If the dCDN redirects back a content request to the uCDN, this > generates a loop. > >> Loop avoidance is a separate issue IMO to whether we should allow a > dCDN to be able to communicate "I am unable/unwilling to take that=20 > content delivery at this time". > >> > >> Regards > >> Ben > >> > >>> To manage this would introduce a very high complexity. > >>> And this would be just to try to save the content requests=20 > >>> redirected > by the uCDN to the dCDN in the timeslot between the time the dCDN gets=20 > down and the time the uCDN takes this failure into account in its CDN=20 > selection process. > >>> It is much better to try to reduce this timeslot as much as=20 > >>> possible, > with routing optimizations (we will propose as soon as possible). > >>> Rather than introducing additional complexities (to manage=20 > >>> redirection > to the uCDN) in the framework. > >>> > >>> > >>> By the way, as you know, the IESG has just approved today the=20 > >>> 'Content > Distribution Network Interconnection (CDNI) Problem Statement' draft=20 > as informational RFC. This is a good point. > >>> And, as you may see in the draft "CDNI request routing", we do not > propose to modify this problem statement draft. > >>> We want know to focus now on getting the specifications of all=20 > >>> CDNI > interfaces ready as soon as possible. > >>> > >>> Best regards, > >>> > >>> Yannick Le Lou=E9dec. > >>> > >>> > >>> -----Message d'origine----- > >>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la=20 > >>> part de Ben Niven-Jenkins Envoy=E9 : lundi 9 juillet 2012 20:41 =C0 := =20 > >>> BERTRAND Gilles RD-CORE Cc : cdni@ietf.org; Pilarski Marcin -=20 > >>> Korpo TP; MARREC Anne RD-CORE Objet : Re: [CDNi] TR: I-D Action: > >>> draft-lelouedec-cdni-request-routing-00.txt > >>> > >>> Colleagues, > >>> > >>> I started reading draft-lelouedec-cdni-request-routing-00 and this > text caught my eye: > >>> > >>> Quoting [I-D.ietf-cdni-problem-statement ], "The CDNI Request=20 > >>> Routing > >>> interface enables a Request Routing function in an upstream CDN to > >>> query a Request Routing function in a downstream CDN to determine if > >>> the downstream CDN is able (and willing) to accept the delegated > >>> content request". > >>> > >>> The "ability" and the "willingness" of the downstream CDN to accept > >>> the delegated content request match two fully different processes in > >>> CDN interconnection. And the description of both these processes > >>> should be reviewed and clarified for the following reasons: > >>> > >>> o Regarding the former process, i.e. related to the "ability" > >>> ("enables a Request Routing function in an upstream CDN to=20 > >>> query > a > >>> Request Routing function in a downstream CDN to determine if the > >>> downstream CDN is able (...) to accept the delegated content > >>> request"), a routing protocol is used to achieve such a process, > >>> called routing process, in many other technologies and networks > >>> (IP, ATM, etc.). In all these technologies, it is the downstream > >>> entity that provides routing information to the upstream entity. > >>> The same approach should be applied to CDN interconnection. The > >>> reverse approach ("uCDN queries it downstream CDNs dCDN 1,=20 > >>> dCDN > 2, > >>> dCDN 3, and then it selects one of them based on their > responses") > >>> would suffer from latency, signaling overhead and/or lack of > >>> reactivity to events that impact the ability of the downstream > >>> CDNs to accept delegated content requests. > >>> > >>> o Regarding the latter process, i.e. related to the "willingness" > >>> ("enables a Request Routing function in an upstream CDN to=20 > >>> query > a > >>> Request Routing function in a downstream CDN to determine if the > >>> downstream CDN (...) is willing (...)to accept the delegated > >>> content request"), it is to be noted that the relationship > between > >>> a uCDN and a dCDN is always in the frame of a contractual > >>> agreement between the administrative entity owning the uCDN, > >>> acting as the customer, and the administrative entity owning the > >>> dCDN, acting as the service provider. Therefore, consider a case > >>> where > >>> > >>> * the uCDN has a content request to redirect which is in full > >>> conformance with the terms of this contractual agreement,=20 > >>> and > >>> > >>> * the uCDN has selected this dCDN. > >>> > >>> As the uCDN knows, thanks to the routing information=20 > >>> exchanged > via > >>> the aforementioned routing process, that the dCDN is able to > >>> accept this content request, the uCDN MAY redirect the content > >>> request to the dCDN and the dCDN MUST accept the content request. > >>> Exchanging over the CDNI Request Routing interface information > >>> about the "willingness" of the dCDN to accept the content request > >>> is not relevant. > >>> > >>> I think you might be over thinking what we wrote in the problem > statement. > >>> > >>> What was in the problem statement was meant to convey that an=20 > >>> upstream > CDN could make a request to a downstream CDN to say "how do I redirect=20 > this request to you" and the downstream CDN could reply with either=20 > "her is how to redirect it", or "no I can't/won't take that content=20 > delivery right now", reasons may include the uCDN has requested a=20 > delivery of a protocol the dCDN does not support (possibly in error)=20 > or the dCDN has no capacity right now etc. > >>> > >>> Ben > >>> > >>> On 9 Jul 2012, at 18:00, wrote: > >>> > >>>> Hi everyone, > >>>> > >>>> We have just submitted the draft below. We are convinced that it=20 > >>>> will > help the WG to progress on the CDNI routing issues. > >>>> > >>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-0 > >>>> 0 > >>>> > >>>> Any feedback is very welcome. > >>>> > >>>> Best regards, > >>>> > >>>> Gilles > >>>> > >>>> > >>>> -----Message d'origine----- > >>>> De : i-d-announce-bounces@ietf.org=20 > >>>> [mailto:i-d-announce-bounces@ietf.org] De la part de=20 > >>>> internet-drafts@ietf.org Envoy=E9 : lundi 9 juillet 2012 18:55 =C0 : > >>>> i-d-announce@ietf.org Objet : I-D Action: > >>>> draft-lelouedec-cdni-request-routing-00.txt > >>>> > >>>> > >>>> A New Internet-Draft is available from the on-line=20 > >>>> Internet-Drafts > directories. > >>>> > >>>> > >>>> Title : CDNI Request Routing > >>>> Author(s) : Yannick Le Louedec > >>>> Anne Marrec > >>>> Gilles Bertrand > >>>> Marcin Pilarski > >>>> Filename : draft-lelouedec-cdni-request-routing-00.txt > >>>> Pages : 30 > >>>> Date : 2012-07-09 > >>>> > >>>> Abstract: > >>>> The present document proposes to clarify the CDNI Request Routing=20 > >>>> interface introduced in [I-D.ietf-cdni-framework] and=20 > >>>> [I-D.ietf-cdni- problem-statement], as well as related terminology. > >>>> > >>>> In particular the present document proposes to split the CDNI=20 > >>>> Request Routing interface into two separate interfaces with=20 > >>>> clearer roles, named respectively CDNI Routing interface and=20 > >>>> CDNI Downstream Resource Identifier Signaling interface (CDNI DRIS i= nterface). > >>>> > >>>> This part of the CDN interconnection framework the IETF has been=20 > >>>> referring to so far with the term "CDNI Request Routing" is just=20 > >>>> another routing, signaling and forwarding problem in a long=20 > >>>> series of the telecommunication history. For example, one can=20 > >>>> draw a direct analogy between the IP/MPLS-TE framework and the=20 > >>>> CDN interconnection framework. > >>>> > >>>> In addition, this document recommends that the specification of=20 > >>>> ALL CDN interconnection interfaces in the scope of the CDNI IETF=20 > >>>> WG relies on the equivalent concept to IP prefix for CDN=20 > >>>> interconnection, named 'contentRequestScope'. This highly useful=20 > >>>> and powerful concept SHALL be used to simplify the specification=20 > >>>> of ALL CDN interconnection interfaces, as well as to ensure=20 > >>>> performance and scalability in CDN interconnection. > >>>> > >>>> All these proposals can be smoothly integrated in the WG drafts,=20 > >>>> especially [I-D.ietf-cdni-framework] and=20 > >>>> [I-D.ietf-cdni-requirements], as they essentially propose=20 > >>>> (useful) clarifications of the existing framework. > >>>> > >>>> > >>>> The IETF datatracker status page for this draft is: > >>>> https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-rou > >>>> ting > >>>> > >>>> There's also a htmlized version available at: > >>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-0 > >>>> 0 > >>>> > >>>> > >>>> Internet-Drafts are also available by anonymous FTP at: > >>>> ftp://ftp.ietf.org/internet-drafts/ > >>>> > >>>> _______________________________________________ > >>>> 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=20 > >>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>>> > >>>> _________________________________________________________________ > >>>> ____ ____________________________________________________ > >>>> > >>>> Ce message et ses pieces jointes peuvent contenir des=20 > >>>> informations confidentielles ou privilegiees et ne doivent donc=20 > >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 > >>>> avez recu ce message par erreur, veuillez le signaler a=20 > >>>> l'expediteur et le detruire ainsi > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, France Telecom - Orange decline toute responsabilite si=20 > ce message a ete altere, deforme ou falsifie. Merci. > >>>> > >>>> This message and its attachments may contain confidential or=20 > >>>> privileged information that may be protected by law; they should=20 > >>>> not > be distributed, used or copied without authorisation. > >>>> If you have received this email in error, please notify the=20 > >>>> sender > and delete this message and its attachments. > >>>> As emails may be altered, France Telecom - Orange is not liable=20 > >>>> for > messages that have been modified, changed or falsified. > >>>> Thank you. > >>>> > >>>> _______________________________________________ > >>>> 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 > >>> > >>> __________________________________________________________________ > >>> ____ ___________________________________________________ > >>> > >>> Ce message et ses pieces jointes peuvent contenir des informations=20 > >>> confidentielles ou privilegiees et ne doivent donc pas etre=20 > >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 > >>> ce message par erreur, veuillez le signaler a l'expediteur et le=20 > >>> detruire ainsi > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, France Telecom - Orange decline toute responsabilite si=20 > ce message a ete altere, deforme ou falsifie. Merci. > >>> > >>> This message and its attachments may contain confidential or=20 > >>> privileged information that may be protected by law; they should=20 > >>> not > be distributed, used or copied without authorisation. > >>> If you have received this email in error, please notify the sender=20 > >>> and > delete this message and its attachments. > >>> As emails may be altered, France Telecom - Orange is not liable=20 > >>> for > messages that have been modified, changed or falsified. > >>> Thank you. > >>> > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni > >> This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/emaildisclaimer > >> > >> > >> > ______________________________________________________________________ > ____ _______________________________________________ > >> > >> Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, France Telecom - Orange decline toute responsabilite si=20 > ce message a ete altere, deforme ou falsifie. Merci. > >> > >> This message and its attachments may contain confidential or=20 > >> privileged > information that may be protected by law; they should not be=20 > distributed, used or copied without authorisation. > >> If you have received this email in error, please notify the sender=20 > >> and > delete this message and its attachments. > >> As emails may be altered, France Telecom - Orange is not liable for > messages that have been modified, changed or falsified. > >> Thank you. > >> > >> > >> > ______________________________________________________________________ > ____ _______________________________________________ > >> > >> Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > >> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 > >> avez > recu ce message par erreur, veuillez le signaler > >> a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > >> France Telecom - Orange decline toute responsabilite si ce message=20 > >> a > ete altere, deforme ou falsifie. Merci. > >> > >> This message and its attachments may contain confidential or=20 > >> privileged > information that may be protected by law; > >> they should not be distributed, used or copied without authorisation. > >> If you have received this email in error, please notify the sender=20 > >> and > delete this message and its attachments. > >> As emails may be altered, France Telecom - Orange is not liable for > messages that have been modified, changed or falsified. > >> Thank you. > >> > > _______________________________________________ > > 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From flefauch@cisco.com Wed Jul 25 05:35:52 2012 Return-Path: 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 5BF3921F85C5 for ; Wed, 25 Jul 2012 05:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.171 X-Spam-Level: X-Spam-Status: No, score=-10.171 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, J_CHICKENPOX_93=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 ORMAcN3IAH4m for ; Wed, 25 Jul 2012 05:35:49 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D18A721F8599 for ; Wed, 25 Jul 2012 05:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=46020; q=dns/txt; s=iport; t=1343219749; x=1344429349; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7P48it7QrO6mbJ87G4Lwcy33DmjC1YajO14qsnw16KI=; b=LwYQaqxpSYZsBLxEXGDiKJ22kWqp2+CkU0vyBQDxNHuy0kz5wvprcNxY WJKtRdpa0rIMbzBK2agRFpI3vBiefwdZ7O8P6RpAYzScZy/GbGGXeEndh 0cqbVUEkWyvE2Fzwx83ocZtJG6YDhM+GJ5xkhzldKnDNmABOnESJ3BECp w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkGAPPmD1CtJXHB/2dsb2JhbABFuHNwgQeCIAEBAQMBAQEBDwEHAQwgJQIEBAMFBwQCAQgRBAEBARUSBycLFAkIAgQOBQkZh2UGC5sFkQWPQItNAggQgzKCSGADiBmNMIEUiXmDGoFmgl+BVgka X-IronPort-AV: E=Sophos;i="4.77,653,1336348800"; d="scan'208";a="105143217" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 25 Jul 2012 12:35:47 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6PCZlOY031203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Jul 2012 12:35:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.17]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0298.004; Wed, 25 Jul 2012 07:35:46 -0500 From: "Francois Le Faucheur (flefauch)" To: " " Thread-Topic: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.txt Thread-Index: AQHNamIDdkFhdBhnn06B7aY/p1jp3A== Date: Wed, 25 Jul 2012 12:35:45 +0000 Message-ID: <2AF54F9B-B4FF-4043-A9DE-36C0417F9EAC@cisco.com> References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> <2040_1341930789_4FFC3D24_2040_2504_1_b86bff40-ae68-40c0-b8e5-060f51be6864@PEXCVZYH02.corporate.adroot.infra.ftgroup> <3A7EA7EE-F8D4-4094-83F2-12CD3826B662@tno.nl> <5004079D.4000406@cisco.com> <29661_1343216353_500FDAE1_29661_643_1_2AC63C9F27AF8446B0C064C50FC0A89305D959@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <29661_1343216353_500FDAE1_29661_643_1_2AC63C9F27AF8446B0C064C50FC0A89305D959@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19062.004 x-tm-as-result: No--56.832800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 12:35:52 -0000 All, To help the discussion, we may need to distinguish three (main) modes: *A* the uCDN uses the Footprint&Cap information (advertised by dCDN) to sel= ect a dCDN. The uCDN redirects to the selected dCDN and considers that he i= s done with request routing. *B* the uCDN uses the Footprint&Cap information (advertised by dCDN) to sel= ect a dCDN candidate. The uCDN queries the dCDN before redirecting.=20 Querying dCDN optionally allows the dCDN to provide to uCDN the final redir= ection information so the the enduser experiences a single redirect. Querying dCDN optionally allows the uCDN to pick an alternate dCDN if the i= nitially selected dCDN cannot handle the request. *C* the uCDN queries multiple dCDNs on a per-request basis and selects dCDN= based on their responses. In other words, the Footprint&Cap advertisement = is performed via on-demand per-request queries.=20 I think: * Scott pointed out that fundamentatly both *A* and *B* have to deal with = (typically transient) situations where uCDN thinks dCDN can take a request = and dCDN actually cannot handle it. And pointed out that with *A* the trans= ient period is dictated by the Footprint&Cap advertisement "update speed" w= hile with *B* it is not. * Allan was saying *A* is all he needs and *B* is extra complexity that he= doesn't need. * Gilles and lelouedec-cdni-request-routing were saying *C* is bad.=20 My impression is that there is violent agreement that *A* is to be supporte= d. I think Allan and Gilles message indicate so. I personally support that.= I think many people have been discussing that approach. If someone feels t= his is NOT to be supported by CDNI, do let us know.=20 I think Gilles message below is primarily arguing against *C*. I personally= agree that this need not be supported in our initial deliverables. Are the= re people arguing this approach is to be supported in the initial deliverab= les?=20 Regarding *B*, I personally see it as quite useful and worth supporting in = Phase 1 (possibly as an option).=20 Regarding Allan's points: * I agree there is some "scalability" argument (i.e. state+wait-for-dCDN-r= esponse) but it amounts to a web-services call out per request and buys you= reliability of request routing, so I see that as a trade-off that some CDN= s should be able to exercise.=20 * I don't buy the latency argument because you end up with 2 RTTs in both = *A* and *B* (in normal situations where dCDN can handle the request) (i.e. = user-->uCDN, uCDN-->user, user-->dCDN, dCDN-->user versus user-->uCDN, uCDN= -->dCDN, dCDN-->uCDN, uCDN-->user) and in the transient cases where dCDN ca= nnot handle the request *B* can do as well as *A* (drop the request) or has= the option to differently i.e. re-redirect at the cost of an extra RTT.=20 * I don't buy the "loop free mechanism" argument. In *B*, it is easy to im= plement a loop detection and even loop prevention (if you want). In *A*, yo= u have no loop prevention (other than the inherent HTTP/DNS max redirect/ma= x CNAMEs) Other opinions on *B* are sought. Cheers Francois On 25 Jul 2012, at 13:39, wrote: > Hi everyone, >=20 > I fully agree with Allan's comments. Putting aside the vocabulary ('recur= sive model' etc), Allan's comment are consistent with the messages that htt= p://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 tries to co= nvey. >=20 > " o Regarding the former process, i.e. related to the "ability" > ("enables a Request Routing function in an upstream CDN to query a > Request Routing function in a downstream CDN to determine if the > downstream CDN is able (...) to accept the delegated content > request"), a routing protocol is used to achieve such a process, > called routing process, in many other technologies and networks > (IP, ATM, etc.). In all these technologies, it is the downstream > entity that provides routing information to the upstream entity. > The same approach should be applied to CDN interconnection. The > reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2, > dCDN 3, and then it selects one of them based on their responses") > would suffer from latency, signaling overhead and/or lack of > reactivity to events that impact the ability of the downstream > CDNs to accept delegated content requests." >=20 > Best regards, > -- > Gilles >=20 >=20 > -----Message d'origine----- > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de G= UILLOU, Allan > Envoy=E9 : mercredi 25 juillet 2012 12:23 > =C0 : Scott Wainner; cdni@ietf.org > Objet : Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-0= 0.txt >=20 > Hi, >=20 > With a "recusive model" as you ask if I understand, you expect the dCDN t= o send like an "ack" for each request, and if not the uCDN will try to find= the second best dCDN and do the same thing. >=20 > I think that this model may add complexity and may cause some scalability= problem. You will have to implement timers between request and ack, retran= smission mechanism to make sure that request has not been lost, loop free m= echanism, And all this may add latency on all requests and performances pro= blems. >=20 > In the iterative model, if the dCDN is not able to handle the request, th= is request will be lost. It is the same thing in IP network today we do not= ask the routing protocol to change when there is saturation somewhere. It = is the responsibility of each ISP to choose another route to join this dest= ination if he want to keep a good quality of service. If a dCDN is overload= ed, it will stop announcing part of its footprint or uCDN may apply some po= licy to force choosing another dCDN. >=20 > It is right that this second model may not in case of dCDN saturation hav= e the best reactivity, but it is exactly the same thing on the internet tod= ay. We can imagine that a poor dCDN which have saturation will be "black li= sted" by all the uCDN and the regulation will be done like this. > I think recursive model will add complexity all the time for a gain witch= is not in my opinion so important and that will not be seen so often. >=20 > Allan >=20 >> -----Message d'origine----- >> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part=20 >> de Scott Wainner Envoy=E9 : lundi 16 juillet 2012 14:23 =C0 :=20 >> cdni@ietf.org Objet : Re: [CDNi] TR: I-D Action:=20 >> draft-lelouedec-cdni-request-routing- >> 00.txt >>=20 >> On 7/10/12 11:39 AM, Brandenburg, R. (Ray) van wrote: >>> Hi Yannick, >>>=20 >>> We seem to be misunderstanding each other. Maybe this will help=20 >>> clarify >> my point: >>>=20 >>>> Let me try to fully understand your point: >>>> Are you really meaning that in this case the dCDN has in reality >> absolutely no obligation with regards to the uCDN? >>>> Are you really meaning that in this case the dCDN decides alone, in >> real time, and for each content request, whether it denies or accepts=20 >> to ensure delivery? >>> What I mean is that I would like to have a RR Interface at least=20 >>> support >> a model where for every content request the uCDN asks the dCDN whether=20 >> it wants to deliver that particular content item (I believe you call=20 >> this a PULL approach). And I would like to allow the dCDN to be able to = say 'No' >> on this request (whether it is for purposes or failure, overload, or=20 >> any other reason). >>>=20 >>>> Are you really meaning that in this case the dCDN decides alone, in >> real time, and for each content request, whether it denies or accepts=20 >> to ensure delivery, and this even if the dCDN has the capability to=20 >> deliver the content? >>> Yes. >> I think we have to delineate between the iterative and recursive model. >>=20 >> The recursive model assumes that the client request to the uCDN will=20 >> be recursive and the CDN-I RR interface will be used to provide an=20 >> answer for each client request. The choice to initiate the recursion=20 >> would be determined by the footprint / capabilities. The ability of=20 >> the dCDN to execute the specific request would provide immediate=20 >> feedback to the uCDN. A dCDN that continues to advertise the=20 >> footprint / capability, but frequently or continually rejects the=20 >> request via CDN-I RR would be a poor candidate. The opportunity now=20 >> arises where the uCDN may elect to choose an alternate dCDN because=20 >> its preferred dCDN (according to footprint / capabilities) is 'under-per= forming'. >>=20 >> The iterative model, the uCDN blindly redirects the client to the dCDN=20 >> based on the footprint / capabilities. What the dCDN does with the=20 >> request is somewhat transparent to the uCDN. With the exception of=20 >> the CDN-I logging, the uCDN assumes the dCDN is properly handling the=20 >> requests that were delegated to the dCDN. If you are trying to=20 >> 'tighten' up the case of blind rejections, then the frequency of the=20 >> footprint / capabilities advertisements would have to be accelerated. >> For the case where the dCDN repeatedly sees requests from the uCDN=20 >> that the dCDN can't handle, it should retract its footprint /=20 >> capabilities advertisement. Failing to do so would continually=20 >> black-hole routing requests which would be indicated in the logging info= rmation. >>=20 >> Either way, you need a feedback loop to avoid dumping routing requests. >>=20 >> With any feedback loop (recursive routing request or footprint /=20 >> capabilities advertisement), you have to be careful about rapid=20 >> oscillations and dampening the responses. >>=20 >> Scott >>>=20 >>>> Are you really meaning that in this case the dCDN may possibly=20 >>>> response >> negatively to all requests for content request redirection submitted=20 >> by the uCDN over the CDNI request routing interface? (i.e. that=20 >> possibly the uCDN will never be allowed/invited to redirect a content=20 >> request to the >> dCDN?) >>>=20 >>> Yes. Any negative effect this may have on the business relationship >> between uCDN and dCDN should be handled on the business level. >>>=20 >>> Ray >>>=20 >>>=20 >>> On Jul 10, 2012, at 4:33 PM, >>> wrote: >>>=20 >>>> Hi Ray, >>>>=20 >>>>=20 >>>> 1) Ray, quoting your mail: "The current drafts seems to assume some >> particular type of contractual agreement between CDNs that might not=20 >> always be the case." >>>>=20 >>>> Please quote the draft. >>>> Please let us know exactly to which sentence(s) of the draft you=20 >>>> are >> referring to. >>>> Otherwise it is hard to discuss and comment on your email. >>>>=20 >>>>=20 >>>> 2) Ray, Quoting your mail: "If a dCDN does not live up to its >> contractual agreement, this should be something that is handled on a=20 >> business level, not on a protocol level." >>>>=20 >>>> Maybe there is a deep misunderstanding. >>>> So I will try to be clear again. >>>> We do not propose the CDNI routing interface to be used by the dCDN=20 >>>> to >> send a message saying "Sorry, but I decide unilaterally to refuse this=20 >> content request". >>>> We do not propose the CDNI routing interface to be used to handle=20 >>>> any >> aspect relating to a dCDN deciding unilaterally to stop living up to=20 >> its contractual agreement. >>>>=20 >>>> Please let us know where you saw such an idea in this IETF draft=20 >>>> "CDNI >> request routing". >>>>=20 >>>> The only role of the CDNI routing interface is to be used to=20 >>>> advertise >> CDNI routing information from the downstream CDN to the upstream CDN. >>>> And this is the description given in this IETF draft. >>>>=20 >>>>=20 >>>> 3) Ray, quoting your mail: "one example of a contractual agreement >> between two CDNs is one in which the uCDN and dCDN have agreed that=20 >> the dCDN will deliver some content on behalf of a uCDN, but decide on=20 >> a per- request basis whether it wants to do so (and is for example=20 >> paid per request). In these cases, the dCDN needs to have the ability=20 >> to deny delivery on a per-request basis." >>>>=20 >>>> Let me try to fully understand your point: >>>> Are you really meaning that in this case the dCDN has in reality >> absolutely no obligation with regards to the uCDN? >>>> Are you really meaning that in this case the dCDN decides alone, in >> real time, and for each content request, whether it denies or accepts=20 >> to ensure delivery? >>>> Are you really meaning that in this case the dCDN decides alone, in >> real time, and for each content request, whether it denies or accepts=20 >> to ensure delivery, and this even if the dCDN has the capability to=20 >> deliver the content? >>>> Are you really meaning that in this case the dCDN may possibly=20 >>>> response >> negatively to all requests for content request redirection submitted=20 >> by the uCDN over the CDNI request routing interface? (i.e. that=20 >> possibly the uCDN will never be allowed/invited to redirect a content=20 >> request to the >> dCDN?) >>>>=20 >>>>=20 >>>> 4) Ray, quoting your mail: "Every routing protocol defines the=20 >>>> expected >> behavior of interconnected elements/networks on a technical level, not=20 >> on a business level." >>>>=20 >>>> Again, this is not what I have written, and this is not the idea we >> want to share. >>>> I wrote "Every routing protocol has been defined (or at least >> configured) so far by considering the expected behavior of the=20 >> interconnected elements/networks." >>>> That's all. >>>> I can rephrase this sentence the following way: "we must know what=20 >>>> we >> expect to do with a protocol to design it correctly." >>>> And IHMO this is an evidence; I don't know any other way to proceed. >>>>=20 >>>> Besides, let us consider BGP (which is by the way an option=20 >>>> proposed by >> some IETF members to implement this CDNI routing interface). >>>> In IP networks, BGP configurations in IP routers are defined as per=20 >>>> the >> business relationships (valley free policy, etc.). >>>> Of course the business relationships determine the BGP configurations. >>>> And of course BGP has been designed so as to allow to configure IP >> interconnections adequately depending on the corresponding=20 >> Customer/provider, sibling and peering contractual agreements. >>>> But this does not mean that BGP "defines the expected behavior of >> interconnected elements/networks... on a business level." >>>> Even if we can indeed infer quite accurately the business=20 >>>> relationships >> between ISP from the BGP configuration of their IP routers (see CAIDA=20 >> project), but this is another story. >>>>=20 >>>>=20 >>>> Best regards, >>>>=20 >>>> Yannick Le Lou=E9dec. >>>>=20 >>>>=20 >>>>=20 >>>> -----Message d'origine----- >>>> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >>>> Envoy=E9 : mardi 10 juillet 2012 15:13 =C0 : LE LOUEDEC Yannick=20 >>>> RD-CORE; Ben Niven-Jenkins Cc : Pilarski Marcin - Korpo TP;=20 >>>> cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR: I-D=20 >>>> Action: draft-lelouedec-cdni-request- >> routing-00.txt >>>>=20 >>>> Hi Yannick, >>>>=20 >>>> See comments inline. >>>>=20 >>>> In general: IMO the CDNI interfaces should be abstracted from any=20 >>>> kind >> of contractual/business agreement that might or might not exist=20 >> between a dCDN and uCDN. The current drafts seems to assume some=20 >> particular type of contractual agreement between CDNs that might not alw= ays be the case. >>>>=20 >>>> Ray >>>>=20 >>>> -----Original Message----- >>>> From: yannick.lelouedec@orange.com >> [mailto:yannick.lelouedec@orange.com] >>>> Sent: dinsdag 10 juli 2012 12:01 >>>> To: Brandenburg, R. (Ray) van; Ben Niven-Jenkins >>>> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE >>>> Subject: RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- >> routing-00.txt >>>>=20 >>>> Hi Ray, all, >>>>=20 >>>>=20 >>>> 1) Ray, Quoting your mail: "I don't see why the CDNI Request=20 >>>> Routing >> interface should state that a dCDN MUST deliver the content if it has=20 >> indicated its ability to do so earlier in either a contractual=20 >> agreement or in the capability interface." >>>>=20 >>>> This is not what we have written. >>>> Let me try to rephrase simply. >>>>=20 >>>> A contractual agreement is a contractual agreement. >>>> It put in writings the respective obligations of the uCDN and of=20 >>>> the >> dCDN. >>>> The uCDN may redirect any content request to the dCDN as long as it=20 >>>> is >> in full conformance with the terms of this contractual agreement (the=20 >> type of the content request is in full conformance, the maximum number=20 >> of content requests per second is respected, etc.). >>>> In this case the dCDN may not say "Sorry, but I decide unilaterally=20 >>>> to >> refuse this content request". >>>>=20 >>>> [RvB]: This is where we disagree. IMHO, the type of behavior you >> describe (the dCDN not living up to its obligation) should not be=20 >> enforced by the CDNI Interfaces. If a dCDN does not live up to its=20 >> contractual agreement, this should be something that is handled on a=20 >> business level, not on a protocol level. >>>>=20 >>>> Why? Because this is the deal, a contractual agreement is a=20 >>>> contractual >> agreement! >>>> Yet the dCDN may say "I do apologize, but at this time I cannot=20 >>>> handle >> correctly a certain class of content requests specified in our=20 >> contractual agreement" (for example the class of the HTTP content=20 >> requests with token from French end users, because of overload=20 >> situation, failure, etc.) This is the role of the CDNI routing=20 >> interface to provide the uCDN with such information. >>>>=20 >>>> (And the dCDN may be given a penalty for example if this was agreed=20 >>>> in >> the terms of the contractual agreement.) >>>>=20 >>>>=20 >>>> 2) Ray, Quoting your mail: "I understand that in most cases, the >> contractual agreement might indeed impose this behavior on the dCDN" >>>>=20 >>>> Please provide the description of an example where this is not the >> case. >>>> Otherwise the IETF CDNI WG shall indeed consider this is ALWAYS the >> case. >>>>=20 >>>> [RvB]: I can't remember ever seeing such a discussion on the WG list. >> Anyway: one example of a contractual agreement between two CDNs is one=20 >> in which the uCDN and dCDN have agreed that the dCDN will deliver some=20 >> content on behalf of a uCDN, but decide on a per-request basis whether=20 >> it wants to do so (and is for example paid per request). In these=20 >> cases, the dCDN needs to have the ability to deny delivery on a per-requ= est basis. >>>>=20 >>>> And this is an important point to be able to progress in the CDNI >> interfaces' specification works. >>>>=20 >>>> If the contractual agreement does not define clearly the=20 >>>> obligations of >> the uCDN, it is impossible to dimension adequately the dCDN, neither=20 >> to define correctly the CDNI contractual agreements between the dCDN=20 >> and the dCDNs of this dCDN. >>>> If the contractual agreement does not define clearly the=20 >>>> obligations of >> the dCDN, the dCDN may do what it wants... even to put in the trash=20 >> can any content request it accepted to handle. >>>>=20 >>>> [RvB]: Exactly, this is something that needs to be discussed on a >> business/contractual level and not on a technical level. That is way=20 >> IMHO the CDNI Interfaces should not make ANY assumptions on what was=20 >> agreed on a contractual level. >>>>=20 >>>> In both situations it is impossible to ensure any quality of=20 >>>> experience >> to the end user. >>>>=20 >>>>=20 >>>> 3) Ray, Quoting your mail: "I don't think this type of behavior=20 >>>> should >> be imposed by the protocol we're developing here." >>>>=20 >>>> I do not sure I understand this sentence. >>>> Every routing protocol has been defined (or at least configured) so=20 >>>> far >> by considering the expected behavior of the interconnected=20 >> elements/networks. >>>>=20 >>>> [RvB]: Every routing protocol defines the expected behavior of >> interconnected elements/networks on a technical level, not on a=20 >> business level. Having a dCDN say 'I'm not willing to deliver this=20 >> content' is perfectly fine from a technical perspective, although it=20 >> could be problematic from a contractual perspective. >>>>=20 >>>> But maybe I will understand if you provide an example on the point=20 >>>> 2 >> above. >>>>=20 >>>>=20 >>>> Best regards, >>>>=20 >>>> Yannick Le Lou=E9dec. >>>>=20 >>>>=20 >>>>=20 >>>> -----Message d'origine----- >>>> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >>>> Envoy=E9 : mardi 10 juillet 2012 09:20 =C0 : Ben Niven-Jenkins; LE=20 >>>> LOUEDEC Yannick RD-CORE Cc : Pilarski Marcin >> - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR:=20 >> I-D >> Action: draft-lelouedec-cdni-request-routing-00.txt >>>>=20 >>>> Hi Yannick, Ben, >>>>=20 >>>> I tend to agree with Ben here. When reading the draft, I got the >> feeling that the draft seems to assume a lot about the relationship=20 >> between the uCDN and dCDN. For example, I don't see why the CDNI=20 >> Request Routing interface should state that a dCDN MUST deliver the=20 >> content if it has indicated its ability to do so earlier in either a=20 >> contractual agreement or in the capability interface. I understand=20 >> that in most cases, the contractual agreement might indeed impose this=20 >> behavior on the dCDN, but I don't think this type of behavior should=20 >> be imposed by the protocol we're developing here. >>>>=20 >>>> It was always my assumption that the Request Routing Interface=20 >>>> would at >> least include the option of allowing the uCDN to query the dCDN for=20 >> every content request whether the dCDN is willing to deliver that=20 >> particular request. >>>>=20 >>>> I will send my full review of the draft later. >>>>=20 >>>> Ray >>>>=20 >>>> -----Original Message----- >>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On=20 >>>> Behalf Of >> Ben Niven-Jenkins >>>> Sent: dinsdag 10 juli 2012 7:38 >>>> To: yannick.lelouedec@orange.com >>>> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE >>>> Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- >> routing-00.txt >>>>=20 >>>> Yannick, >>>>=20 >>>> Please see inline. >>>>=20 >>>> On 9 Jul 2012, at 20:05, wrote: >>>>=20 >>>>> Hi Ben, all, >>>>>=20 >>>>> Ben, quoting you mail below, "... the downstream CDN could reply=20 >>>>> with either "here is how to redirect it"", >>>>>=20 >>>>> =3D> This is the role of the CDNI DRIS interface to provide the uCDN >> with this information, and we target to make its specification public=20 >> before Vancouver meeting so that everyone may read it before the=20 >> meeting and get full knowledge of our proposal about this part of CDNI=20 >> request routing. >>>>>=20 >>>>> Ben, quoting you mail below, "... or "no I can't/won't take that >> content delivery right now", reasons may include the uCDN has=20 >> requested a delivery of a protocol the dCDN does not support (possibly i= n error). >>>>>=20 >>>>> =3D> This is the role of the CDNI logging interface to provide the=20 >>>>> uCDN >> with this information. >>>> I agree this information should be logged but the Request Routing >> interface (what you call the DRIS) also needs to be able to indicate a=20 >> failure. >>>>=20 >>>> Otherwise the uCDN will 'blindly' redirect the the dCDN and the >> delivery will fail leading to poor end user experience. >>>>=20 >>>>> Ben, quoting you mail below, "... or "no I can't/won't take that >> content delivery right now", reasons may include ... the dCDN has no=20 >> capacity right now etc." >>>>>=20 >>>>> =3D> This is the role of the CDNI routing interface to provide the=20 >>>>> uCDN >> with this information. >>>> It is the role of the CDN capability/routing interface to advertise >> broad capabilities etc not to give extremely fine grained real-time=20 >> information on exactly the state of the dCDN. >>>>=20 >>>> Even if the capability/routing interface is real-time there are=20 >>>> likely >> to still be race conditions where we need the dCDN to be about to=20 >> indicate a failure to accept a redirect through the request=20 >> routing/DRIS interface >>>>=20 >>>>> So we may conclude we are in line basically, which is a good point. >>>>> We just aimed at checking there was a common understanding on this >> point. >>>>>=20 >>>>> The key point for us here is that we don't want this sentence >> extracted from draft-ietf-cdni-problem-statement be interpreted as: ".=20 >> and the dCDN MUST accept the content request except when it has not=20 >> the "ability" to do so." >>>> Why not? IMO that is a valid scenario for some use cases. >>>>=20 >>>>> The fact that the dCDN is temporary unable to handle content=20 >>>>> request >> correctly is not a valid reason for the dCDN to be discharged of its=20 >> obligations to the uCDN. >>>>> The contract set between the uCDN and the dCDN remains valid=20 >>>>> anyway, >> and the obligations of the dCDN as well. >>>> Correct, but that contract may not be the same for all uCDNs &=20 >>>> dCDNs, >> for example a uCDN may not have a guarantee that a dCDN can handle=20 >> everything it is requested to handle but the contract may only be that=20 >> the dCDN guarantees to handle up to a certain volume of traffic. >>>>=20 >>>>> The dCDN must announce to the uCDN that it is temporary unable, as >> soon as possible, via the CDNI routing interface. >>>>> And the uCDN must take this information into account in its CDN >> selection process as soon as possible. >>>>> Then if the uCDN decides to continue to redirect content requests=20 >>>>> to >> the dCDN, the uCDN MAY perfectly do it, but the uCDN knows these=20 >> content requests will be lost. >>>> What happens in the period between the dCDN being unable to handle >> requests and the time it takes to advertise that to the uCDN and for=20 >> the uCDN to process & incorporate that new knowledge? Are requests=20 >> blindly forwarded to the dCDN which is unable to handle them leading=20 >> to poor user experience? >>>>=20 >>>>> We could even imagine the situation where the uCDN continues to do=20 >>>>> it >> intentionally, because it has no better option and the content request=20 >> will be lost anyway. For example in the case where neither the uCDN=20 >> nor the other downstream CDNs of the uCDN cannot manage correctly the=20 >> content request, the uCDN could do it intentionally so as to be able=20 >> to clearly prove (with CDNI logging information) that it is the dCDN,=20 >> not the uCDN, who is at fault. >>>>> But, of course, if there are alternative backup options, the=20 >>>>> normal >> reaction of the uCDN is to stop as soon as possible to redirect=20 >> content requests to the dCDN when the uCDN knows that the dCDN is=20 >> unable to handle them correctly. >>>>>=20 >>>>> So, to be clear, we would prefer the sentence to be understood as: >>>>> ". and the dCDN MUST accept the content request. >>>>> And if it cannot handle correctly the redirected content request=20 >>>>> it >> receives, the content request is lost. >>>> What about scenarios where the uCDN has a choice of dCDNs (e.g. two >> national-wide CDNs offering services at different costs), the uCDN may=20 >> elect to query both dCDNs and decide based on their responses which=20 >> one to choose. If the dCDN is unable to satisfy the request the uCDN=20 >> needs to know that so that it can fallback to the (more expensive in=20 >> this example) dCDN. >>>>=20 >>>>> For example the dCDN generates a response to the content request=20 >>>>> with >> an error message, or no response at all. And in parallel the CDNI=20 >> logging interface may be used to exchange logs corresponding to this pro= blem. >> Anyway the dCDN MAY NOT redirect that content request back towards the=20 >> uCDN." >>>>>=20 >>>>> Exactly as in IP networks: IP packets are not sent back towards=20 >>>>> the >> origin by a downstream router under failure or congestion. >>>> In a routed IP network, there is often a small packet loss while=20 >>>> the >> network re-converges, by enabling the dCDN to refuse a redirection at=20 >> CDNI Request Routing/DRIS query time we can reduce that window by=20 >> giving the uCDN the option to take an alternative action (e.g. try=20 >> another dCDN) while the routing/capability information re-converges. >>>>=20 >>>>> In both networks (IP and CDN), the reason is the same. >>>>> If the dCDN redirects back a content request to the uCDN, this >> generates a loop. >>>> Loop avoidance is a separate issue IMO to whether we should allow a >> dCDN to be able to communicate "I am unable/unwilling to take that=20 >> content delivery at this time". >>>>=20 >>>> Regards >>>> Ben >>>>=20 >>>>> To manage this would introduce a very high complexity. >>>>> And this would be just to try to save the content requests=20 >>>>> redirected >> by the uCDN to the dCDN in the timeslot between the time the dCDN gets=20 >> down and the time the uCDN takes this failure into account in its CDN=20 >> selection process. >>>>> It is much better to try to reduce this timeslot as much as=20 >>>>> possible, >> with routing optimizations (we will propose as soon as possible). >>>>> Rather than introducing additional complexities (to manage=20 >>>>> redirection >> to the uCDN) in the framework. >>>>>=20 >>>>>=20 >>>>> By the way, as you know, the IESG has just approved today the=20 >>>>> 'Content >> Distribution Network Interconnection (CDNI) Problem Statement' draft=20 >> as informational RFC. This is a good point. >>>>> And, as you may see in the draft "CDNI request routing", we do not >> propose to modify this problem statement draft. >>>>> We want know to focus now on getting the specifications of all=20 >>>>> CDNI >> interfaces ready as soon as possible. >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Yannick Le Lou=E9dec. >>>>>=20 >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la=20 >>>>> part de Ben Niven-Jenkins Envoy=E9 : lundi 9 juillet 2012 20:41 =C0 := =20 >>>>> BERTRAND Gilles RD-CORE Cc : cdni@ietf.org; Pilarski Marcin -=20 >>>>> Korpo TP; MARREC Anne RD-CORE Objet : Re: [CDNi] TR: I-D Action: >>>>> draft-lelouedec-cdni-request-routing-00.txt >>>>>=20 >>>>> Colleagues, >>>>>=20 >>>>> I started reading draft-lelouedec-cdni-request-routing-00 and this >> text caught my eye: >>>>>=20 >>>>> Quoting [I-D.ietf-cdni-problem-statement ], "The CDNI Request=20 >>>>> Routing >>>>> interface enables a Request Routing function in an upstream CDN to >>>>> query a Request Routing function in a downstream CDN to determine if >>>>> the downstream CDN is able (and willing) to accept the delegated >>>>> content request". >>>>>=20 >>>>> The "ability" and the "willingness" of the downstream CDN to accept >>>>> the delegated content request match two fully different processes in >>>>> CDN interconnection. And the description of both these processes >>>>> should be reviewed and clarified for the following reasons: >>>>>=20 >>>>> o Regarding the former process, i.e. related to the "ability" >>>>> ("enables a Request Routing function in an upstream CDN to=20 >>>>> query >> a >>>>> Request Routing function in a downstream CDN to determine if the >>>>> downstream CDN is able (...) to accept the delegated content >>>>> request"), a routing protocol is used to achieve such a process, >>>>> called routing process, in many other technologies and networks >>>>> (IP, ATM, etc.). In all these technologies, it is the downstream >>>>> entity that provides routing information to the upstream entity. >>>>> The same approach should be applied to CDN interconnection. The >>>>> reverse approach ("uCDN queries it downstream CDNs dCDN 1,=20 >>>>> dCDN >> 2, >>>>> dCDN 3, and then it selects one of them based on their >> responses") >>>>> would suffer from latency, signaling overhead and/or lack of >>>>> reactivity to events that impact the ability of the downstream >>>>> CDNs to accept delegated content requests. >>>>>=20 >>>>> o Regarding the latter process, i.e. related to the "willingness" >>>>> ("enables a Request Routing function in an upstream CDN to=20 >>>>> query >> a >>>>> Request Routing function in a downstream CDN to determine if the >>>>> downstream CDN (...) is willing (...)to accept the delegated >>>>> content request"), it is to be noted that the relationship >> between >>>>> a uCDN and a dCDN is always in the frame of a contractual >>>>> agreement between the administrative entity owning the uCDN, >>>>> acting as the customer, and the administrative entity owning the >>>>> dCDN, acting as the service provider. Therefore, consider a case >>>>> where >>>>>=20 >>>>> * the uCDN has a content request to redirect which is in full >>>>> conformance with the terms of this contractual agreement,=20 >>>>> and >>>>>=20 >>>>> * the uCDN has selected this dCDN. >>>>>=20 >>>>> As the uCDN knows, thanks to the routing information=20 >>>>> exchanged >> via >>>>> the aforementioned routing process, that the dCDN is able to >>>>> accept this content request, the uCDN MAY redirect the content >>>>> request to the dCDN and the dCDN MUST accept the content request. >>>>> Exchanging over the CDNI Request Routing interface information >>>>> about the "willingness" of the dCDN to accept the content request >>>>> is not relevant. >>>>>=20 >>>>> I think you might be over thinking what we wrote in the problem >> statement. >>>>>=20 >>>>> What was in the problem statement was meant to convey that an=20 >>>>> upstream >> CDN could make a request to a downstream CDN to say "how do I redirect=20 >> this request to you" and the downstream CDN could reply with either=20 >> "her is how to redirect it", or "no I can't/won't take that content=20 >> delivery right now", reasons may include the uCDN has requested a=20 >> delivery of a protocol the dCDN does not support (possibly in error)=20 >> or the dCDN has no capacity right now etc. >>>>>=20 >>>>> Ben >>>>>=20 >>>>> On 9 Jul 2012, at 18:00, wrote: >>>>>=20 >>>>>> Hi everyone, >>>>>>=20 >>>>>> We have just submitted the draft below. We are convinced that it=20 >>>>>> will >> help the WG to progress on the CDNI routing issues. >>>>>>=20 >>>>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-0 >>>>>> 0 >>>>>>=20 >>>>>> Any feedback is very welcome. >>>>>>=20 >>>>>> Best regards, >>>>>>=20 >>>>>> Gilles >>>>>>=20 >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : i-d-announce-bounces@ietf.org=20 >>>>>> [mailto:i-d-announce-bounces@ietf.org] De la part de=20 >>>>>> internet-drafts@ietf.org Envoy=E9 : lundi 9 juillet 2012 18:55 =C0 : >>>>>> i-d-announce@ietf.org Objet : I-D Action: >>>>>> draft-lelouedec-cdni-request-routing-00.txt >>>>>>=20 >>>>>>=20 >>>>>> A New Internet-Draft is available from the on-line=20 >>>>>> Internet-Drafts >> directories. >>>>>>=20 >>>>>>=20 >>>>>> Title : CDNI Request Routing >>>>>> Author(s) : Yannick Le Louedec >>>>>> Anne Marrec >>>>>> Gilles Bertrand >>>>>> Marcin Pilarski >>>>>> Filename : draft-lelouedec-cdni-request-routing-00.txt >>>>>> Pages : 30 >>>>>> Date : 2012-07-09 >>>>>>=20 >>>>>> Abstract: >>>>>> The present document proposes to clarify the CDNI Request Routing=20 >>>>>> interface introduced in [I-D.ietf-cdni-framework] and=20 >>>>>> [I-D.ietf-cdni- problem-statement], as well as related terminology. >>>>>>=20 >>>>>> In particular the present document proposes to split the CDNI=20 >>>>>> Request Routing interface into two separate interfaces with=20 >>>>>> clearer roles, named respectively CDNI Routing interface and=20 >>>>>> CDNI Downstream Resource Identifier Signaling interface (CDNI DRIS i= nterface). >>>>>>=20 >>>>>> This part of the CDN interconnection framework the IETF has been=20 >>>>>> referring to so far with the term "CDNI Request Routing" is just=20 >>>>>> another routing, signaling and forwarding problem in a long=20 >>>>>> series of the telecommunication history. For example, one can=20 >>>>>> draw a direct analogy between the IP/MPLS-TE framework and the=20 >>>>>> CDN interconnection framework. >>>>>>=20 >>>>>> In addition, this document recommends that the specification of=20 >>>>>> ALL CDN interconnection interfaces in the scope of the CDNI IETF=20 >>>>>> WG relies on the equivalent concept to IP prefix for CDN=20 >>>>>> interconnection, named 'contentRequestScope'. This highly useful=20 >>>>>> and powerful concept SHALL be used to simplify the specification=20 >>>>>> of ALL CDN interconnection interfaces, as well as to ensure=20 >>>>>> performance and scalability in CDN interconnection. >>>>>>=20 >>>>>> All these proposals can be smoothly integrated in the WG drafts,=20 >>>>>> especially [I-D.ietf-cdni-framework] and=20 >>>>>> [I-D.ietf-cdni-requirements], as they essentially propose=20 >>>>>> (useful) clarifications of the existing framework. >>>>>>=20 >>>>>>=20 >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-rou >>>>>> ting >>>>>>=20 >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-0 >>>>>> 0 >>>>>>=20 >>>>>>=20 >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>=20 >>>>>> _______________________________________________ >>>>>> 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=20 >>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>=20 >>>>>> _________________________________________________________________ >>>>>> ____ ____________________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>> informations confidentielles ou privilegiees et ne doivent donc=20 >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 >>>>>> avez recu ce message par erreur, veuillez le signaler a=20 >>>>>> l'expediteur et le detruire ainsi >> que les pieces jointes. Les messages electroniques etant susceptibles=20 >> d'alteration, France Telecom - Orange decline toute responsabilite si=20 >> ce message a ete altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or=20 >>>>>> privileged information that may be protected by law; they should=20 >>>>>> not >> be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the=20 >>>>>> sender >> and delete this message and its attachments. >>>>>> As emails may be altered, France Telecom - Orange is not liable=20 >>>>>> for >> messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=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 >>>>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>>>> ce message par erreur, veuillez le signaler a l'expediteur et le=20 >>>>> detruire ainsi >> que les pieces jointes. Les messages electroniques etant susceptibles=20 >> d'alteration, France Telecom - Orange decline toute responsabilite si=20 >> ce message a ete altere, deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or=20 >>>>> privileged information that may be protected by law; they should=20 >>>>> not >> be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender=20 >>>>> and >> delete this message and its attachments. >>>>> As emails may be altered, France Telecom - Orange is not liable=20 >>>>> for >> messages that have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >>>> This e-mail and its contents are subject to the DISCLAIMER at >> http://www.tno.nl/emaildisclaimer >>>>=20 >>>>=20 >>>>=20 >> ______________________________________________________________________ >> ____ _______________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 >> que les pieces jointes. Les messages electroniques etant susceptibles=20 >> d'alteration, France Telecom - Orange decline toute responsabilite si=20 >> ce message a ete altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or=20 >>>> privileged >> information that may be protected by law; they should not be=20 >> distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender=20 >>>> and >> delete this message and its attachments. >>>> As emails may be altered, France Telecom - Orange is not liable for >> messages that have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>>=20 >>>>=20 >> ______________________________________________________________________ >> ____ _______________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 >>>> avez >> recu ce message par erreur, veuillez le signaler >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les >> messages electroniques etant susceptibles d'alteration, >>>> France Telecom - Orange decline toute responsabilite si ce message=20 >>>> a >> ete altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or=20 >>>> privileged >> information that may be protected by law; >>>> they should not be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender=20 >>>> and >> delete this message and its attachments. >>>> As emails may be altered, France Telecom - Orange is not liable for >> messages that have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>> _______________________________________________ >>> 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 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From Jan.Seedorf@neclab.eu Wed Jul 25 05:49:09 2012 Return-Path: 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 5BCAA21F857A for ; Wed, 25 Jul 2012 05:49:09 -0700 (PDT) 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 1anb0fMxOTym for ; Wed, 25 Jul 2012 05:49:08 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id B55AC21F850C for ; Wed, 25 Jul 2012 05:49:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 46E95101951 for ; Wed, 25 Jul 2012 14:53:27 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItlRJeRgUGZA for ; Wed, 25 Jul 2012 14:53:27 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 267CA101949 for ; Wed, 25 Jul 2012 14:53:22 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.252]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 25 Jul 2012 14:48:40 +0200 From: Jan Seedorf To: "cdni@ietf.org" Thread-Topic: Date and Time for IETF #84 - "footprint / capabilities advertisement" design team meeting and CDNI request routing side meeting. Thread-Index: Ac1qYYc65tm2raLnQTOXgjFNehlRIAAAi77w Date: Wed, 25 Jul 2012 12:49:33 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE32CDAF30@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] FW: Date and Time for IETF #84 - "footprint / capabilities advertisement" design team meeting and CDNI request routing side meeting. 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 12:49:09 -0000 Hi all, See below the date and time for the side meeting we are having for the "foo= tprint / capabilities advertisement" design team meeting at IETF-84. - Jan -----Original Message----- From: Jan Seedorf=20 Sent: Wednesday, July 25, 2012 2:35 PM To: cdni@ietf.org Cc: Francois Le Faucheur (flefauch); Stefano Previdi (sprevidi); Peterson, = Jon (jon.peterson@neustar.biz); Brandenburg, R. (Ray) van (ray.vanbrandenbu= rg@tno.nl); yannick.lelouedec@orange.com> -----Original Message----- > From: Enrico Marocco [mailto:enrico.marocco@telecomitalia.it] > Sent: Wednesday, July 25, 2012 2:28 PM > To: Jan Seedorf > Cc: Francois Le Faucheur (flefauch); Stefano Previdi (sprevidi); Peterson= , Jon > (jon.peterson@neustar.biz); Brandenburg, R. (Ray) van > (ray.vanbrandenburg@tno.nl); yannick.lelouedec@orange.com> > Emile RD-CORE; BERTRAND Gilles RD-CORE; Kent Leung (kleung) > Subject: Re: IETF #84 - "footprint / capabilities advertisement" design t= eam > meeting and CDNI request routing side meeting. >=20 > I can make 11:30 work. >=20 > On 7/25/12 11:11 AM, Jan Seedorf wrote: > > Guys, > > > > The doodle suggests the best time for the "footprint / capabilities > advertisement" design team meeting would actually be either Monday > 09:00-11:00 or 11:30-13:00. > > > > http://doodle.com/kkquvs4zevuakv9i > > > > Enrico and Ray: you are the only ones that cannot make both times, so c= an > you two please state your opinion? > > > > - Jan > > > >> -----Original Message----- > >> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > >> Sent: Tuesday, July 24, 2012 3:53 PM > >> To: Stefano Previdi (sprevidi); Peterson, Jon (jon.peterson@neustar.bi= z) > >> Cc: Francois Le Faucheur (flefauch); yannick.lelouedec@orange.com> > >> Seedorf; > >> STEPHAN Emile RD-CORE; BERTRAND Gilles RD-CORE; Brandenburg, R. > (Ray) > >> van; Kent Leung (kleung) > >> Subject: Re: IETF #84 - "footprint / capabilities advertisement" desig= n > team > >> meeting and CDNI request routing side meeting. > >> > >> Please confirm and announce asap the time/venue for the CDNI Footprint > >> Design Team meeting. > >> > >> On 24 Jul 2012, at 14:11, stefano previdi wrote: > >> > >>> Yannick, All, > >>> > >>> Monday 6pm-8pm would work for me. > >>> > >>> Thanks. > >>> s. > >>> > >>> > >>> On Jul 24, 2012, at 1:49 PM, > >> wrote: > >>> > >>>> Dear all, > >>>> > >>>> I just received a mail indicating Jan is away until July 25 (tomorro= w). > >>>> Could anyone else from the "footprint / capabilities advertisement" > >> design team reply to my mail below (which slot for the design team > meeting > >> on Monday)? > >>>> > >>>> Many thanks, > >>>> > >>>> Yannick Le Lou=E9dec. > >>>> > >>>> -----Message d'origine----- > >>>> De : LE LOUEDEC Yannick RD-CORE > >>>> Envoy=E9 : mardi 24 juillet 2012 13:42 > >>>> =C0 : 'Jan Seedorf'; stefano previdi (sprevidi@cisco.com); Peterson,= Jon > >> (jon.peterson@neustar.biz) > >>>> Cc : STEPHAN Emile RD-CORE; BERTRAND Gilles RD-CORE; Brandenburg, > R. > >> (Ray) van; Kent Leung (kleung); Francois Le Faucheur > (flefauch@cisco.com) > >> (flefauch@cisco.com) > >>>> Objet : TR: [CDNi] IETF #84 - Proposal for a side meeting on the CDN= I > >> request routing interface > >>>> Importance : Haute > >>>> > >>>> Dear Jan, Stefano, Jon, All, > >>>> > >>>> Monday evening seems to be the best time for both the "footprint / > >> capabilities advertisement" design team meeting and the CDNI request > >> routing side meeting. > >>>> On the following timeslots: 18:00 - 20:00 and 20:30 - 22:00. > >>>> > >>>> We should avoid to select the same timeslot for both meetings, as > several > >> people would like to attend both meetings. > >>>> And Fran=E7ois invites us to announce the selected slots asap. > >>>> > >>>> Could you please let us know what time you prefer for the "footprint= / > >> capabilities advertisement" design team meeting? > >>>> > >>>> Many thanks, > >>>> > >>>> Yannick Le Lou=E9dec. > >>>> > >>>> -----Message d'origine----- > >>>> De : Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > Envoy=E9 : > >> lundi 23 juillet 2012 18:19 =C0 : LE LOUEDEC Yannick RD-CORE Cc : > Brandenburg, > >> R. (Ray) van; Kent Leung (kleung) Objet : Re: [CDNi] IETF #84 - Propos= al for > a > >> side meeting on the CDNI request routing interface > >>>> > >>>> Hi Yannick, > >>>> Please finalize and announce the selected slot asap as many meetings > are > >> being established and this could reduce the chances of conflict. > >>>> Thanks > >>>> > >>>> > >>>> On 23 Jul 2012, at 10:07, > >> wrote: > >>>> > >>>>> Dear Gilles, All, > >>>>> > >>>>> I mean on Monday, > >>>>> After the welcome session in case the representatives from the > CDNIW > >> G must attend it (Extract from Monday's agenda : "1730 - 1800 Welcome, > 1. > >> Welcome - Bernard Aboba..."). > >>>>> Otherwise (if the representatives must not attend this welcome > >> session), we could even possibly arrange it at the same time if it app= ears > that > >> most people are available at that time. > >>>>> > >>>>> Our initial plan was indeed to arrange it rather on Sunday, but som= e > >> people will be available from Monday on only. > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Yannick Le Lou=E9dec. > >>>>> > >>>>> > >>>>> -----Message d'origine----- > >>>>> De : BERTRAND Gilles RD-CORE > >>>>> Envoy=E9 : lundi 23 juillet 2012 09:53 > >>>>> =C0 : LE LOUEDEC Yannick RD-CORE; Woundy, Richard; Francois Le > >> Faucheur > >>>>> (flefauch@cisco.com); Scott Wainner; Ben Niven-Jenkins; > Brandenburg, > >>>>> R. (Ray) van; cdni@ietf.org Cc : STEPHAN Emile RD-CORE Objet : RE: > >>>>> [CDNi] IETF #84 - Proposal for a side meeting on the CDNI request > >>>>> routing interface > >>>>> > >>>>> Yannick, > >>>>> > >>>>> You probably mean on "Sunday" evening after the welcoming > session? > >>>>> > >>>>> Best regards, > >>>>> -- > >>>>> Gilles > >>>>> > >>>>> -----Message d'origine----- > >>>>> De : LE LOUEDEC Yannick RD-CORE > >>>>> Envoy=E9 : vendredi 20 juillet 2012 14:28 =C0 : Woundy, Richard; Fr= ancois > >>>>> Le Faucheur (flefauch@cisco.com); Scott Wainner; Ben Niven-Jenkins; > >>>>> Brandenburg, R. (Ray) van; cdni@ietf.org Cc : STEPHAN Emile RD- > CORE; > >>>>> BERTRAND Gilles RD-CORE Objet : RE: [CDNi] IETF #84 - Proposal for = a > >>>>> side meeting on the CDNI request routing interface > >>>>> > >>>>> Dear all, > >>>>> > >>>>> The doodle for the side meeting in Vancouver on CDNI request > routing > >>>>> is here: http://www.doodle.com/n552qchpurfcpckn > >>>>> Please fill it in as soon as possible if you intend to attend. > >>>>> > >>>>> Ideally we would like to arrange this meeting at Hyatt Regency Hote= l, > on > >> Monday evening, after the welcoming session. > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Yannick Le Lou=E9dec. > >>>>> > >>>>> -----Message d'origine----- > >>>>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la par= t > >>>>> de yannick.lelouedec@orange.com Envoy=E9 : lundi 16 juillet 2012 16= :35 > =C0 > >>>>> : Scott Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; > >>>>> cdni@ietf.org Objet : [CDNi] IETF #84 - Proposal for a side meeting= on > >>>>> the CDNI request routing interface > >>>>> > >>>>> Dear all, > >>>>> > >>>>> We propose to arrange a side meeting on Sunday evening during IETF > >> #84 (i.e. on July 29th) on the CDNI request routing interface. > >>>>> The objective is to clear the discussion we had these last days via= the > >> IETF CDNI mailing list, and to ease an efficient meeting on Tuesday 31= . > >>>>> If everybody agrees that this is a good idea, we will set up a dood= le. > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Yannick Le Lou=E9dec, > >>>>> Orange OLNC. > >>>>> > >>>>> > >>>>> > >> > __________________________________________________________ > >> ____________ > >>>>> ___________________________________________________ > >>>>> > >>>>> Ce message et ses pieces jointes peuvent contenir des informations > >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites > >> ou copies sans autorisation. Si vous avez recu ce message par erreur, > veuillez > >> le signaler a l'expediteur et le detruire ainsi que les pieces jointes= . Les > >> messages electroniques etant susceptibles d'alteration, France Telecom= - > >> Orange decline toute responsabilite si ce message a ete altere, deform= e > ou > >> falsifie. Merci. > >>>>> > >>>>> This message and its attachments may contain confidential or > privileged > >> information that may be protected by law; they should not be distribut= ed, > >> used or copied without authorisation. > >>>>> If you have received this email in error, please notify the sender = and > >> delete this message and its attachments. > >>>>> As emails may be altered, France Telecom - Orange is not liable for > >> messages that have been modified, changed or falsified. > >>>>> Thank you. > >>>>> > >>>>> _______________________________________________ > >>>>> CDNi mailing list > >>>>> CDNi@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/cdni > >>>>> > >>>>> > >> > __________________________________________________________ > >> ____________ > >>>>> ___________________________________________________ > >>>>> > >>>>> Ce message et ses pieces jointes peuvent contenir des informations > >>>>> confidentielles ou privilegiees et ne doivent donc pas etre diffuse= s, > >>>>> exploites ou copies sans autorisation. Si vous avez recu ce message > >>>>> par erreur, veuillez le signaler a l'expediteur et le detruire ains= i que les > >> pieces jointes. Les messages electroniques etant susceptibles > d'alteration, > >> France Telecom - Orange decline toute responsabilite si ce message a e= te > >> altere, deforme ou falsifie. Merci. > >>>>> > >>>>> This message and its attachments may contain confidential or > >>>>> privileged information that may be protected by law; they should no= t > be > >> distributed, used or copied without authorisation. > >>>>> If you have received this email in error, please notify the sender = and > >> delete this message and its attachments. > >>>>> As emails may be altered, France Telecom - Orange is not liable for > >> messages that have been modified, changed or falsified. > >>>>> Thank you. > >>>>> > >>>> > >>>> > >>>> > >> > __________________________________________________________ > >> > __________________________________________________________ > >> _____ > >>>> > >>>> Ce message et ses pieces jointes peuvent contenir des informations > >> confidentielles ou privilegiees et ne doivent donc > >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous av= ez > recu > >> ce message par erreur, veuillez le signaler > >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les mess= ages > >> electroniques etant susceptibles d'alteration, > >>>> France Telecom - Orange decline toute responsabilite si ce message a > ete > >> altere, deforme ou falsifie. Merci. > >>>> > >>>> This message and its attachments may contain confidential or privile= ged > >> information that may be protected by law; > >>>> they should not be distributed, used or copied without authorisation= . > >>>> If you have received this email in error, please notify the sender a= nd > >> delete this message and its attachments. > >>>> As emails may be altered, France Telecom - Orange is not liable for > >> messages that have been modified, changed or falsified. > >>>> Thank you. > >>>> > >>>> > >>> > > >=20 From prvs=54654aace=allan.guillou@sfr.com Wed Jul 25 06:04:37 2012 Return-Path: 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 136E421F85C5 for ; Wed, 25 Jul 2012 06:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_93=0.6] 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 x8b93-18MEkj for ; Wed, 25 Jul 2012 06:04:33 -0700 (PDT) Received: from mx1-buro.sfr.fr (mx1-buro.sfr.fr [217.70.85.100]) by ietfa.amsl.com (Postfix) with ESMTP id CB67021F85B6 for ; Wed, 25 Jul 2012 06:04:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,653,1336341600"; d="scan'208";a="72458211" Received: from unknown (HELO EXCH010.encara.local.ads) ([10.29.105.3]) by mx1int-buro.prod with ESMTP; 25 Jul 2012 15:04:29 +0200 Received: from EXCN015.encara.local.ads ([fe80::f109:6a12:5ba6:f568]) by EXCH010.encara.local.ads ([::1]) with mapi id 14.02.0298.004; Wed, 25 Jul 2012 15:04:29 +0200 From: "GUILLOU, Allan" To: "Francois Le Faucheur (flefauch)" , " " Thread-Topic: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.txt Thread-Index: AQHNamIH7PoctFm5dU27Y8QCphpA4Jc59AnQ Date: Wed, 25 Jul 2012 13:04:29 +0000 Message-ID: References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> <2040_1341930789_4FFC3D24_2040_2504_1_b86bff40-ae68-40c0-b8e5-060f51be6864@PEXCVZYH02.corporate.adroot.infra.ftgroup> <3A7EA7EE-F8D4-4094-83F2-12CD3826B662@tno.nl> <5004079D.4000406@cisco.com> <29661_1343216353_500FDAE1_29661_643_1_2AC63C9F27AF8446B0C064C50FC0A89305D959@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AF54F9B-B4FF-4043-A9DE-36C0417F9EAC@cisco.com> In-Reply-To: <2AF54F9B-B4FF-4043-A9DE-36C0417F9EAC@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.141.56] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 13:04:37 -0000 In *B* you still have a per session request to the dCDN. If it is just to h= andle a problem in the dCDN, and that you consider that you realy need this= kind of information, another method can be to add an "back pressure mechan= ism". It could be done by a message sent from dCDN to uCDN when ie is overload, o= r by adding in the Footprint&Cap information a "max value" which can give t= he number of stream that the dCDN can accept from this specific uCDN. In ca= se of overload, the dCDN can just send an update with a lower value to ask = the uCDN to select another dCDN. > -----Message d'origine----- > De : Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > Envoy=E9 : mercredi 25 juillet 2012 14:36 > =C0 : > Cc : Francois Le Faucheur (flefauch); GUILLOU, Allan; Scott Wainner > (swainner); cdni@ietf.org > Objet : Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.tx= t > > All, > > To help the discussion, we may need to distinguish three (main) modes: > > *A* the uCDN uses the Footprint&Cap information (advertised by dCDN) to > select a dCDN. The uCDN redirects to the selected dCDN and considers that > he is done with request routing. > > *B* the uCDN uses the Footprint&Cap information (advertised by dCDN) to > select a dCDN candidate. The uCDN queries the dCDN before redirecting. > Querying dCDN optionally allows the dCDN to provide to uCDN the final > redirection information so the the enduser experiences a single redirect. > Querying dCDN optionally allows the uCDN to pick an alternate dCDN if the > initially selected dCDN cannot handle the request. > > *C* the uCDN queries multiple dCDNs on a per-request basis and selects > dCDN based on their responses. In other words, the Footprint&Cap > advertisement is performed via on-demand per-request queries. > > > I think: > * Scott pointed out that fundamentatly both *A* and *B* have to dea= l > with (typically transient) situations where uCDN thinks dCDN can take a > request and dCDN actually cannot handle it. And pointed out that with *A* > the transient period is dictated by the Footprint&Cap advertisement > "update speed" while with *B* it is not. > * Allan was saying *A* is all he needs and *B* is extra complexity > that he doesn't need. > * Gilles and lelouedec-cdni-request-routing were saying *C* is bad. > > My impression is that there is violent agreement that *A* is to be > supported. I think Allan and Gilles message indicate so. I personally > support that. I think many people have been discussing that approach. If > someone feels this is NOT to be supported by CDNI, do let us know. > > I think Gilles message below is primarily arguing against *C*. I > personally agree that this need not be supported in our initial > deliverables. Are there people arguing this approach is to be supported i= n > the initial deliverables? > > Regarding *B*, I personally see it as quite useful and worth supporting i= n > Phase 1 (possibly as an option). > Regarding Allan's points: > * I agree there is some "scalability" argument (i.e. state+wait-for= - > dCDN-response) but it amounts to a web-services call out per request and > buys you reliability of request routing, so I see that as a trade-off tha= t > some CDNs should be able to exercise. > > * I don't buy the latency argument because you end up with 2 RTTs i= n > both *A* and *B* (in normal situations where dCDN can handle the request) > (i.e. user-->uCDN, uCDN-->user, user-->dCDN, dCDN-->user versus user-- > >uCDN, uCDN-->dCDN, dCDN-->uCDN, uCDN-->user) and in the transient cases > where dCDN cannot handle the request *B* can do as well as *A* (drop the > request) or has the option to differently i.e. re-redirect at the cost of > an extra RTT. > * I don't buy the "loop free mechanism" argument. In *B*, it is eas= y > to implement a loop detection and even loop prevention (if you want). In > *A*, you have no loop prevention (other than the inherent HTTP/DNS max > redirect/max CNAMEs) > Other opinions on *B* are sought. > > > Cheers > > Francois > > > On 25 Jul 2012, at 13:39, > wrote: > > > Hi everyone, > > > > I fully agree with Allan's comments. Putting aside the vocabulary > ('recursive model' etc), Allan's comment are consistent with the messages > that http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 > tries to convey. > > > > " o Regarding the former process, i.e. related to the "ability" > > ("enables a Request Routing function in an upstream CDN to query a > > Request Routing function in a downstream CDN to determine if the > > downstream CDN is able (...) to accept the delegated content > > request"), a routing protocol is used to achieve such a process, > > called routing process, in many other technologies and networks > > (IP, ATM, etc.). In all these technologies, it is the downstream > > entity that provides routing information to the upstream entity. > > The same approach should be applied to CDN interconnection. The > > reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2, > > dCDN 3, and then it selects one of them based on their responses") > > would suffer from latency, signaling overhead and/or lack of > > reactivity to events that impact the ability of the downstream > > CDNs to accept delegated content requests." > > > > Best regards, > > -- > > Gilles > > > > > > -----Message d'origine----- > > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de > GUILLOU, Allan > > Envoy=E9 : mercredi 25 juillet 2012 12:23 > > =C0 : Scott Wainner; cdni@ietf.org > > Objet : Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing= - > 00.txt > > > > Hi, > > > > With a "recusive model" as you ask if I understand, you expect the dCDN > to send like an "ack" for each request, and if not the uCDN will try to > find the second best dCDN and do the same thing. > > > > I think that this model may add complexity and may cause some > scalability problem. You will have to implement timers between request an= d > ack, retransmission mechanism to make sure that request has not been lost= , > loop free mechanism, And all this may add latency on all requests and > performances problems. > > > > In the iterative model, if the dCDN is not able to handle the request, > this request will be lost. It is the same thing in IP network today we do > not ask the routing protocol to change when there is saturation somewhere= . > It is the responsibility of each ISP to choose another route to join this > destination if he want to keep a good quality of service. If a dCDN is > overloaded, it will stop announcing part of its footprint or uCDN may > apply some policy to force choosing another dCDN. > > > > It is right that this second model may not in case of dCDN saturation > have the best reactivity, but it is exactly the same thing on the interne= t > today. We can imagine that a poor dCDN which have saturation will be > "black listed" by all the uCDN and the regulation will be done like this. > > I think recursive model will add complexity all the time for a gain > witch is not in my opinion so important and that will not be seen so > often. > > > > Allan > > > >> -----Message d'origine----- > >> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part > >> de Scott Wainner Envoy=E9 : lundi 16 juillet 2012 14:23 =C0 : > >> cdni@ietf.org Objet : Re: [CDNi] TR: I-D Action: > >> draft-lelouedec-cdni-request-routing- > >> 00.txt > >> > >> On 7/10/12 11:39 AM, Brandenburg, R. (Ray) van wrote: > >>> Hi Yannick, > >>> > >>> We seem to be misunderstanding each other. Maybe this will help > >>> clarify > >> my point: > >>> > >>>> Let me try to fully understand your point: > >>>> Are you really meaning that in this case the dCDN has in reality > >> absolutely no obligation with regards to the uCDN? > >>>> Are you really meaning that in this case the dCDN decides alone, in > >> real time, and for each content request, whether it denies or accepts > >> to ensure delivery? > >>> What I mean is that I would like to have a RR Interface at least > >>> support > >> a model where for every content request the uCDN asks the dCDN whether > >> it wants to deliver that particular content item (I believe you call > >> this a PULL approach). And I would like to allow the dCDN to be able t= o > say 'No' > >> on this request (whether it is for purposes or failure, overload, or > >> any other reason). > >>> > >>>> Are you really meaning that in this case the dCDN decides alone, in > >> real time, and for each content request, whether it denies or accepts > >> to ensure delivery, and this even if the dCDN has the capability to > >> deliver the content? > >>> Yes. > >> I think we have to delineate between the iterative and recursive model= . > >> > >> The recursive model assumes that the client request to the uCDN will > >> be recursive and the CDN-I RR interface will be used to provide an > >> answer for each client request. The choice to initiate the recursion > >> would be determined by the footprint / capabilities. The ability of > >> the dCDN to execute the specific request would provide immediate > >> feedback to the uCDN. A dCDN that continues to advertise the > >> footprint / capability, but frequently or continually rejects the > >> request via CDN-I RR would be a poor candidate. The opportunity now > >> arises where the uCDN may elect to choose an alternate dCDN because > >> its preferred dCDN (according to footprint / capabilities) is 'under- > performing'. > >> > >> The iterative model, the uCDN blindly redirects the client to the dCDN > >> based on the footprint / capabilities. What the dCDN does with the > >> request is somewhat transparent to the uCDN. With the exception of > >> the CDN-I logging, the uCDN assumes the dCDN is properly handling the > >> requests that were delegated to the dCDN. If you are trying to > >> 'tighten' up the case of blind rejections, then the frequency of the > >> footprint / capabilities advertisements would have to be accelerated. > >> For the case where the dCDN repeatedly sees requests from the uCDN > >> that the dCDN can't handle, it should retract its footprint / > >> capabilities advertisement. Failing to do so would continually > >> black-hole routing requests which would be indicated in the logging > information. > >> > >> Either way, you need a feedback loop to avoid dumping routing requests= . > >> > >> With any feedback loop (recursive routing request or footprint / > >> capabilities advertisement), you have to be careful about rapid > >> oscillations and dampening the responses. > >> > >> Scott > >>> > >>>> Are you really meaning that in this case the dCDN may possibly > >>>> response > >> negatively to all requests for content request redirection submitted > >> by the uCDN over the CDNI request routing interface? (i.e. that > >> possibly the uCDN will never be allowed/invited to redirect a content > >> request to the > >> dCDN?) > >>> > >>> Yes. Any negative effect this may have on the business relationship > >> between uCDN and dCDN should be handled on the business level. > >>> > >>> Ray > >>> > >>> > >>> On Jul 10, 2012, at 4:33 PM, > >>> wrote: > >>> > >>>> Hi Ray, > >>>> > >>>> > >>>> 1) Ray, quoting your mail: "The current drafts seems to assume some > >> particular type of contractual agreement between CDNs that might not > >> always be the case." > >>>> > >>>> Please quote the draft. > >>>> Please let us know exactly to which sentence(s) of the draft you > >>>> are > >> referring to. > >>>> Otherwise it is hard to discuss and comment on your email. > >>>> > >>>> > >>>> 2) Ray, Quoting your mail: "If a dCDN does not live up to its > >> contractual agreement, this should be something that is handled on a > >> business level, not on a protocol level." > >>>> > >>>> Maybe there is a deep misunderstanding. > >>>> So I will try to be clear again. > >>>> We do not propose the CDNI routing interface to be used by the dCDN > >>>> to > >> send a message saying "Sorry, but I decide unilaterally to refuse this > >> content request". > >>>> We do not propose the CDNI routing interface to be used to handle > >>>> any > >> aspect relating to a dCDN deciding unilaterally to stop living up to > >> its contractual agreement. > >>>> > >>>> Please let us know where you saw such an idea in this IETF draft > >>>> "CDNI > >> request routing". > >>>> > >>>> The only role of the CDNI routing interface is to be used to > >>>> advertise > >> CDNI routing information from the downstream CDN to the upstream CDN. > >>>> And this is the description given in this IETF draft. > >>>> > >>>> > >>>> 3) Ray, quoting your mail: "one example of a contractual agreement > >> between two CDNs is one in which the uCDN and dCDN have agreed that > >> the dCDN will deliver some content on behalf of a uCDN, but decide on > >> a per- request basis whether it wants to do so (and is for example > >> paid per request). In these cases, the dCDN needs to have the ability > >> to deny delivery on a per-request basis." > >>>> > >>>> Let me try to fully understand your point: > >>>> Are you really meaning that in this case the dCDN has in reality > >> absolutely no obligation with regards to the uCDN? > >>>> Are you really meaning that in this case the dCDN decides alone, in > >> real time, and for each content request, whether it denies or accepts > >> to ensure delivery? > >>>> Are you really meaning that in this case the dCDN decides alone, in > >> real time, and for each content request, whether it denies or accepts > >> to ensure delivery, and this even if the dCDN has the capability to > >> deliver the content? > >>>> Are you really meaning that in this case the dCDN may possibly > >>>> response > >> negatively to all requests for content request redirection submitted > >> by the uCDN over the CDNI request routing interface? (i.e. that > >> possibly the uCDN will never be allowed/invited to redirect a content > >> request to the > >> dCDN?) > >>>> > >>>> > >>>> 4) Ray, quoting your mail: "Every routing protocol defines the > >>>> expected > >> behavior of interconnected elements/networks on a technical level, not > >> on a business level." > >>>> > >>>> Again, this is not what I have written, and this is not the idea we > >> want to share. > >>>> I wrote "Every routing protocol has been defined (or at least > >> configured) so far by considering the expected behavior of the > >> interconnected elements/networks." > >>>> That's all. > >>>> I can rephrase this sentence the following way: "we must know what > >>>> we > >> expect to do with a protocol to design it correctly." > >>>> And IHMO this is an evidence; I don't know any other way to proceed. > >>>> > >>>> Besides, let us consider BGP (which is by the way an option > >>>> proposed by > >> some IETF members to implement this CDNI routing interface). > >>>> In IP networks, BGP configurations in IP routers are defined as per > >>>> the > >> business relationships (valley free policy, etc.). > >>>> Of course the business relationships determine the BGP > configurations. > >>>> And of course BGP has been designed so as to allow to configure IP > >> interconnections adequately depending on the corresponding > >> Customer/provider, sibling and peering contractual agreements. > >>>> But this does not mean that BGP "defines the expected behavior of > >> interconnected elements/networks... on a business level." > >>>> Even if we can indeed infer quite accurately the business > >>>> relationships > >> between ISP from the BGP configuration of their IP routers (see CAIDA > >> project), but this is another story. > >>>> > >>>> > >>>> Best regards, > >>>> > >>>> Yannick Le Lou=E9dec. > >>>> > >>>> > >>>> > >>>> -----Message d'origine----- > >>>> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > >>>> Envoy=E9 : mardi 10 juillet 2012 15:13 =C0 : LE LOUEDEC Yannick > >>>> RD-CORE; Ben Niven-Jenkins Cc : Pilarski Marcin - Korpo TP; > >>>> cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR: I-D > >>>> Action: draft-lelouedec-cdni-request- > >> routing-00.txt > >>>> > >>>> Hi Yannick, > >>>> > >>>> See comments inline. > >>>> > >>>> In general: IMO the CDNI interfaces should be abstracted from any > >>>> kind > >> of contractual/business agreement that might or might not exist > >> between a dCDN and uCDN. The current drafts seems to assume some > >> particular type of contractual agreement between CDNs that might not > always be the case. > >>>> > >>>> Ray > >>>> > >>>> -----Original Message----- > >>>> From: yannick.lelouedec@orange.com > >> [mailto:yannick.lelouedec@orange.com] > >>>> Sent: dinsdag 10 juli 2012 12:01 > >>>> To: Brandenburg, R. (Ray) van; Ben Niven-Jenkins > >>>> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE > >>>> Subject: RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- > >> routing-00.txt > >>>> > >>>> Hi Ray, all, > >>>> > >>>> > >>>> 1) Ray, Quoting your mail: "I don't see why the CDNI Request > >>>> Routing > >> interface should state that a dCDN MUST deliver the content if it has > >> indicated its ability to do so earlier in either a contractual > >> agreement or in the capability interface." > >>>> > >>>> This is not what we have written. > >>>> Let me try to rephrase simply. > >>>> > >>>> A contractual agreement is a contractual agreement. > >>>> It put in writings the respective obligations of the uCDN and of > >>>> the > >> dCDN. > >>>> The uCDN may redirect any content request to the dCDN as long as it > >>>> is > >> in full conformance with the terms of this contractual agreement (the > >> type of the content request is in full conformance, the maximum number > >> of content requests per second is respected, etc.). > >>>> In this case the dCDN may not say "Sorry, but I decide unilaterally > >>>> to > >> refuse this content request". > >>>> > >>>> [RvB]: This is where we disagree. IMHO, the type of behavior you > >> describe (the dCDN not living up to its obligation) should not be > >> enforced by the CDNI Interfaces. If a dCDN does not live up to its > >> contractual agreement, this should be something that is handled on a > >> business level, not on a protocol level. > >>>> > >>>> Why? Because this is the deal, a contractual agreement is a > >>>> contractual > >> agreement! > >>>> Yet the dCDN may say "I do apologize, but at this time I cannot > >>>> handle > >> correctly a certain class of content requests specified in our > >> contractual agreement" (for example the class of the HTTP content > >> requests with token from French end users, because of overload > >> situation, failure, etc.) This is the role of the CDNI routing > >> interface to provide the uCDN with such information. > >>>> > >>>> (And the dCDN may be given a penalty for example if this was agreed > >>>> in > >> the terms of the contractual agreement.) > >>>> > >>>> > >>>> 2) Ray, Quoting your mail: "I understand that in most cases, the > >> contractual agreement might indeed impose this behavior on the dCDN" > >>>> > >>>> Please provide the description of an example where this is not the > >> case. > >>>> Otherwise the IETF CDNI WG shall indeed consider this is ALWAYS the > >> case. > >>>> > >>>> [RvB]: I can't remember ever seeing such a discussion on the WG list= . > >> Anyway: one example of a contractual agreement between two CDNs is one > >> in which the uCDN and dCDN have agreed that the dCDN will deliver some > >> content on behalf of a uCDN, but decide on a per-request basis whether > >> it wants to do so (and is for example paid per request). In these > >> cases, the dCDN needs to have the ability to deny delivery on a per- > request basis. > >>>> > >>>> And this is an important point to be able to progress in the CDNI > >> interfaces' specification works. > >>>> > >>>> If the contractual agreement does not define clearly the > >>>> obligations of > >> the uCDN, it is impossible to dimension adequately the dCDN, neither > >> to define correctly the CDNI contractual agreements between the dCDN > >> and the dCDNs of this dCDN. > >>>> If the contractual agreement does not define clearly the > >>>> obligations of > >> the dCDN, the dCDN may do what it wants... even to put in the trash > >> can any content request it accepted to handle. > >>>> > >>>> [RvB]: Exactly, this is something that needs to be discussed on a > >> business/contractual level and not on a technical level. That is way > >> IMHO the CDNI Interfaces should not make ANY assumptions on what was > >> agreed on a contractual level. > >>>> > >>>> In both situations it is impossible to ensure any quality of > >>>> experience > >> to the end user. > >>>> > >>>> > >>>> 3) Ray, Quoting your mail: "I don't think this type of behavior > >>>> should > >> be imposed by the protocol we're developing here." > >>>> > >>>> I do not sure I understand this sentence. > >>>> Every routing protocol has been defined (or at least configured) so > >>>> far > >> by considering the expected behavior of the interconnected > >> elements/networks. > >>>> > >>>> [RvB]: Every routing protocol defines the expected behavior of > >> interconnected elements/networks on a technical level, not on a > >> business level. Having a dCDN say 'I'm not willing to deliver this > >> content' is perfectly fine from a technical perspective, although it > >> could be problematic from a contractual perspective. > >>>> > >>>> But maybe I will understand if you provide an example on the point > >>>> 2 > >> above. > >>>> > >>>> > >>>> Best regards, > >>>> > >>>> Yannick Le Lou=E9dec. > >>>> > >>>> > >>>> > >>>> -----Message d'origine----- > >>>> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > >>>> Envoy=E9 : mardi 10 juillet 2012 09:20 =C0 : Ben Niven-Jenkins; LE > >>>> LOUEDEC Yannick RD-CORE Cc : Pilarski Marcin > >> - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR: > >> I-D > >> Action: draft-lelouedec-cdni-request-routing-00.txt > >>>> > >>>> Hi Yannick, Ben, > >>>> > >>>> I tend to agree with Ben here. When reading the draft, I got the > >> feeling that the draft seems to assume a lot about the relationship > >> between the uCDN and dCDN. For example, I don't see why the CDNI > >> Request Routing interface should state that a dCDN MUST deliver the > >> content if it has indicated its ability to do so earlier in either a > >> contractual agreement or in the capability interface. I understand > >> that in most cases, the contractual agreement might indeed impose this > >> behavior on the dCDN, but I don't think this type of behavior should > >> be imposed by the protocol we're developing here. > >>>> > >>>> It was always my assumption that the Request Routing Interface > >>>> would at > >> least include the option of allowing the uCDN to query the dCDN for > >> every content request whether the dCDN is willing to deliver that > >> particular request. > >>>> > >>>> I will send my full review of the draft later. > >>>> > >>>> Ray > >>>> > >>>> -----Original Message----- > >>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On > >>>> Behalf Of > >> Ben Niven-Jenkins > >>>> Sent: dinsdag 10 juli 2012 7:38 > >>>> To: yannick.lelouedec@orange.com > >>>> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE > >>>> Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- > >> routing-00.txt > >>>> > >>>> Yannick, > >>>> > >>>> Please see inline. > >>>> > >>>> On 9 Jul 2012, at 20:05, wrote: > >>>> > >>>>> Hi Ben, all, > >>>>> > >>>>> Ben, quoting you mail below, "... the downstream CDN could reply > >>>>> with either "here is how to redirect it"", > >>>>> > >>>>> =3D> This is the role of the CDNI DRIS interface to provide the uCD= N > >> with this information, and we target to make its specification public > >> before Vancouver meeting so that everyone may read it before the > >> meeting and get full knowledge of our proposal about this part of CDNI > >> request routing. > >>>>> > >>>>> Ben, quoting you mail below, "... or "no I can't/won't take that > >> content delivery right now", reasons may include the uCDN has > >> requested a delivery of a protocol the dCDN does not support (possibly > in error). > >>>>> > >>>>> =3D> This is the role of the CDNI logging interface to provide the > >>>>> uCDN > >> with this information. > >>>> I agree this information should be logged but the Request Routing > >> interface (what you call the DRIS) also needs to be able to indicate a > >> failure. > >>>> > >>>> Otherwise the uCDN will 'blindly' redirect the the dCDN and the > >> delivery will fail leading to poor end user experience. > >>>> > >>>>> Ben, quoting you mail below, "... or "no I can't/won't take that > >> content delivery right now", reasons may include ... the dCDN has no > >> capacity right now etc." > >>>>> > >>>>> =3D> This is the role of the CDNI routing interface to provide the > >>>>> uCDN > >> with this information. > >>>> It is the role of the CDN capability/routing interface to advertise > >> broad capabilities etc not to give extremely fine grained real-time > >> information on exactly the state of the dCDN. > >>>> > >>>> Even if the capability/routing interface is real-time there are > >>>> likely > >> to still be race conditions where we need the dCDN to be about to > >> indicate a failure to accept a redirect through the request > >> routing/DRIS interface > >>>> > >>>>> So we may conclude we are in line basically, which is a good point. > >>>>> We just aimed at checking there was a common understanding on this > >> point. > >>>>> > >>>>> The key point for us here is that we don't want this sentence > >> extracted from draft-ietf-cdni-problem-statement be interpreted as: ". > >> and the dCDN MUST accept the content request except when it has not > >> the "ability" to do so." > >>>> Why not? IMO that is a valid scenario for some use cases. > >>>> > >>>>> The fact that the dCDN is temporary unable to handle content > >>>>> request > >> correctly is not a valid reason for the dCDN to be discharged of its > >> obligations to the uCDN. > >>>>> The contract set between the uCDN and the dCDN remains valid > >>>>> anyway, > >> and the obligations of the dCDN as well. > >>>> Correct, but that contract may not be the same for all uCDNs & > >>>> dCDNs, > >> for example a uCDN may not have a guarantee that a dCDN can handle > >> everything it is requested to handle but the contract may only be that > >> the dCDN guarantees to handle up to a certain volume of traffic. > >>>> > >>>>> The dCDN must announce to the uCDN that it is temporary unable, as > >> soon as possible, via the CDNI routing interface. > >>>>> And the uCDN must take this information into account in its CDN > >> selection process as soon as possible. > >>>>> Then if the uCDN decides to continue to redirect content requests > >>>>> to > >> the dCDN, the uCDN MAY perfectly do it, but the uCDN knows these > >> content requests will be lost. > >>>> What happens in the period between the dCDN being unable to handle > >> requests and the time it takes to advertise that to the uCDN and for > >> the uCDN to process & incorporate that new knowledge? Are requests > >> blindly forwarded to the dCDN which is unable to handle them leading > >> to poor user experience? > >>>> > >>>>> We could even imagine the situation where the uCDN continues to do > >>>>> it > >> intentionally, because it has no better option and the content request > >> will be lost anyway. For example in the case where neither the uCDN > >> nor the other downstream CDNs of the uCDN cannot manage correctly the > >> content request, the uCDN could do it intentionally so as to be able > >> to clearly prove (with CDNI logging information) that it is the dCDN, > >> not the uCDN, who is at fault. > >>>>> But, of course, if there are alternative backup options, the > >>>>> normal > >> reaction of the uCDN is to stop as soon as possible to redirect > >> content requests to the dCDN when the uCDN knows that the dCDN is > >> unable to handle them correctly. > >>>>> > >>>>> So, to be clear, we would prefer the sentence to be understood as: > >>>>> ". and the dCDN MUST accept the content request. > >>>>> And if it cannot handle correctly the redirected content request > >>>>> it > >> receives, the content request is lost. > >>>> What about scenarios where the uCDN has a choice of dCDNs (e.g. two > >> national-wide CDNs offering services at different costs), the uCDN may > >> elect to query both dCDNs and decide based on their responses which > >> one to choose. If the dCDN is unable to satisfy the request the uCDN > >> needs to know that so that it can fallback to the (more expensive in > >> this example) dCDN. > >>>> > >>>>> For example the dCDN generates a response to the content request > >>>>> with > >> an error message, or no response at all. And in parallel the CDNI > >> logging interface may be used to exchange logs corresponding to this > problem. > >> Anyway the dCDN MAY NOT redirect that content request back towards the > >> uCDN." > >>>>> > >>>>> Exactly as in IP networks: IP packets are not sent back towards > >>>>> the > >> origin by a downstream router under failure or congestion. > >>>> In a routed IP network, there is often a small packet loss while > >>>> the > >> network re-converges, by enabling the dCDN to refuse a redirection at > >> CDNI Request Routing/DRIS query time we can reduce that window by > >> giving the uCDN the option to take an alternative action (e.g. try > >> another dCDN) while the routing/capability information re-converges. > >>>> > >>>>> In both networks (IP and CDN), the reason is the same. > >>>>> If the dCDN redirects back a content request to the uCDN, this > >> generates a loop. > >>>> Loop avoidance is a separate issue IMO to whether we should allow a > >> dCDN to be able to communicate "I am unable/unwilling to take that > >> content delivery at this time". > >>>> > >>>> Regards > >>>> Ben > >>>> > >>>>> To manage this would introduce a very high complexity. > >>>>> And this would be just to try to save the content requests > >>>>> redirected > >> by the uCDN to the dCDN in the timeslot between the time the dCDN gets > >> down and the time the uCDN takes this failure into account in its CDN > >> selection process. > >>>>> It is much better to try to reduce this timeslot as much as > >>>>> possible, > >> with routing optimizations (we will propose as soon as possible). > >>>>> Rather than introducing additional complexities (to manage > >>>>> redirection > >> to the uCDN) in the framework. > >>>>> > >>>>> > >>>>> By the way, as you know, the IESG has just approved today the > >>>>> 'Content > >> Distribution Network Interconnection (CDNI) Problem Statement' draft > >> as informational RFC. This is a good point. > >>>>> And, as you may see in the draft "CDNI request routing", we do not > >> propose to modify this problem statement draft. > >>>>> We want know to focus now on getting the specifications of all > >>>>> CDNI > >> interfaces ready as soon as possible. > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Yannick Le Lou=E9dec. > >>>>> > >>>>> > >>>>> -----Message d'origine----- > >>>>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la > >>>>> part de Ben Niven-Jenkins Envoy=E9 : lundi 9 juillet 2012 20:41 =C0= : > >>>>> BERTRAND Gilles RD-CORE Cc : cdni@ietf.org; Pilarski Marcin - > >>>>> Korpo TP; MARREC Anne RD-CORE Objet : Re: [CDNi] TR: I-D Action: > >>>>> draft-lelouedec-cdni-request-routing-00.txt > >>>>> > >>>>> Colleagues, > >>>>> > >>>>> I started reading draft-lelouedec-cdni-request-routing-00 and this > >> text caught my eye: > >>>>> > >>>>> Quoting [I-D.ietf-cdni-problem-statement ], "The CDNI Request > >>>>> Routing > >>>>> interface enables a Request Routing function in an upstream CDN to > >>>>> query a Request Routing function in a downstream CDN to determine > if > >>>>> the downstream CDN is able (and willing) to accept the delegated > >>>>> content request". > >>>>> > >>>>> The "ability" and the "willingness" of the downstream CDN to accep= t > >>>>> the delegated content request match two fully different processes > in > >>>>> CDN interconnection. And the description of both these processes > >>>>> should be reviewed and clarified for the following reasons: > >>>>> > >>>>> o Regarding the former process, i.e. related to the "ability" > >>>>> ("enables a Request Routing function in an upstream CDN to > >>>>> query > >> a > >>>>> Request Routing function in a downstream CDN to determine if th= e > >>>>> downstream CDN is able (...) to accept the delegated content > >>>>> request"), a routing protocol is used to achieve such a process= , > >>>>> called routing process, in many other technologies and networks > >>>>> (IP, ATM, etc.). In all these technologies, it is the > downstream > >>>>> entity that provides routing information to the upstream entity= . > >>>>> The same approach should be applied to CDN interconnection. Th= e > >>>>> reverse approach ("uCDN queries it downstream CDNs dCDN 1, > >>>>> dCDN > >> 2, > >>>>> dCDN 3, and then it selects one of them based on their > >> responses") > >>>>> would suffer from latency, signaling overhead and/or lack of > >>>>> reactivity to events that impact the ability of the downstream > >>>>> CDNs to accept delegated content requests. > >>>>> > >>>>> o Regarding the latter process, i.e. related to the "willingness" > >>>>> ("enables a Request Routing function in an upstream CDN to > >>>>> query > >> a > >>>>> Request Routing function in a downstream CDN to determine if th= e > >>>>> downstream CDN (...) is willing (...)to accept the delegated > >>>>> content request"), it is to be noted that the relationship > >> between > >>>>> a uCDN and a dCDN is always in the frame of a contractual > >>>>> agreement between the administrative entity owning the uCDN, > >>>>> acting as the customer, and the administrative entity owning th= e > >>>>> dCDN, acting as the service provider. Therefore, consider a > case > >>>>> where > >>>>> > >>>>> * the uCDN has a content request to redirect which is in full > >>>>> conformance with the terms of this contractual agreement, > >>>>> and > >>>>> > >>>>> * the uCDN has selected this dCDN. > >>>>> > >>>>> As the uCDN knows, thanks to the routing information > >>>>> exchanged > >> via > >>>>> the aforementioned routing process, that the dCDN is able to > >>>>> accept this content request, the uCDN MAY redirect the content > >>>>> request to the dCDN and the dCDN MUST accept the content > request. > >>>>> Exchanging over the CDNI Request Routing interface information > >>>>> about the "willingness" of the dCDN to accept the content > request > >>>>> is not relevant. > >>>>> > >>>>> I think you might be over thinking what we wrote in the problem > >> statement. > >>>>> > >>>>> What was in the problem statement was meant to convey that an > >>>>> upstream > >> CDN could make a request to a downstream CDN to say "how do I redirect > >> this request to you" and the downstream CDN could reply with either > >> "her is how to redirect it", or "no I can't/won't take that content > >> delivery right now", reasons may include the uCDN has requested a > >> delivery of a protocol the dCDN does not support (possibly in error) > >> or the dCDN has no capacity right now etc. > >>>>> > >>>>> Ben > >>>>> > >>>>> On 9 Jul 2012, at 18:00, wrote: > >>>>> > >>>>>> Hi everyone, > >>>>>> > >>>>>> We have just submitted the draft below. We are convinced that it > >>>>>> will > >> help the WG to progress on the CDNI routing issues. > >>>>>> > >>>>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-0 > >>>>>> 0 > >>>>>> > >>>>>> Any feedback is very welcome. > >>>>>> > >>>>>> Best regards, > >>>>>> > >>>>>> Gilles > >>>>>> > >>>>>> > >>>>>> -----Message d'origine----- > >>>>>> De : i-d-announce-bounces@ietf.org > >>>>>> [mailto:i-d-announce-bounces@ietf.org] De la part de > >>>>>> internet-drafts@ietf.org Envoy=E9 : lundi 9 juillet 2012 18:55 =C0= : > >>>>>> i-d-announce@ietf.org Objet : I-D Action: > >>>>>> draft-lelouedec-cdni-request-routing-00.txt > >>>>>> > >>>>>> > >>>>>> A New Internet-Draft is available from the on-line > >>>>>> Internet-Drafts > >> directories. > >>>>>> > >>>>>> > >>>>>> Title : CDNI Request Routing > >>>>>> Author(s) : Yannick Le Louedec > >>>>>> Anne Marrec > >>>>>> Gilles Bertrand > >>>>>> Marcin Pilarski > >>>>>> Filename : draft-lelouedec-cdni-request-routing-00.txt > >>>>>> Pages : 30 > >>>>>> Date : 2012-07-09 > >>>>>> > >>>>>> Abstract: > >>>>>> The present document proposes to clarify the CDNI Request Routing > >>>>>> interface introduced in [I-D.ietf-cdni-framework] and > >>>>>> [I-D.ietf-cdni- problem-statement], as well as related terminology= . > >>>>>> > >>>>>> In particular the present document proposes to split the CDNI > >>>>>> Request Routing interface into two separate interfaces with > >>>>>> clearer roles, named respectively CDNI Routing interface and > >>>>>> CDNI Downstream Resource Identifier Signaling interface (CDNI DRIS > interface). > >>>>>> > >>>>>> This part of the CDN interconnection framework the IETF has been > >>>>>> referring to so far with the term "CDNI Request Routing" is just > >>>>>> another routing, signaling and forwarding problem in a long > >>>>>> series of the telecommunication history. For example, one can > >>>>>> draw a direct analogy between the IP/MPLS-TE framework and the > >>>>>> CDN interconnection framework. > >>>>>> > >>>>>> In addition, this document recommends that the specification of > >>>>>> ALL CDN interconnection interfaces in the scope of the CDNI IETF > >>>>>> WG relies on the equivalent concept to IP prefix for CDN > >>>>>> interconnection, named 'contentRequestScope'. This highly useful > >>>>>> and powerful concept SHALL be used to simplify the specification > >>>>>> of ALL CDN interconnection interfaces, as well as to ensure > >>>>>> performance and scalability in CDN interconnection. > >>>>>> > >>>>>> All these proposals can be smoothly integrated in the WG drafts, > >>>>>> especially [I-D.ietf-cdni-framework] and > >>>>>> [I-D.ietf-cdni-requirements], as they essentially propose > >>>>>> (useful) clarifications of the existing framework. > >>>>>> > >>>>>> > >>>>>> The IETF datatracker status page for this draft is: > >>>>>> https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-rou > >>>>>> ting > >>>>>> > >>>>>> There's also a htmlized version available at: > >>>>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-0 > >>>>>> 0 > >>>>>> > >>>>>> > >>>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > >>>>>> > >>>>>> _________________________________________________________________ > >>>>>> ____ ____________________________________________________ > >>>>>> > >>>>>> Ce message et ses pieces jointes peuvent contenir des > >>>>>> informations confidentielles ou privilegiees et ne doivent donc > >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous > >>>>>> avez recu ce message par erreur, veuillez le signaler a > >>>>>> l'expediteur et le detruire ainsi > >> que les pieces jointes. Les messages electroniques etant susceptibles > >> d'alteration, France Telecom - Orange decline toute responsabilite si > >> ce message a ete altere, deforme ou falsifie. Merci. > >>>>>> > >>>>>> This message and its attachments may contain confidential or > >>>>>> privileged information that may be protected by law; they should > >>>>>> not > >> be distributed, used or copied without authorisation. > >>>>>> If you have received this email in error, please notify the > >>>>>> sender > >> and delete this message and its attachments. > >>>>>> As emails may be altered, France Telecom - Orange is not liable > >>>>>> for > >> messages that have been modified, changed or falsified. > >>>>>> Thank you. > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > >>>>> > >>>>> __________________________________________________________________ > >>>>> ____ ___________________________________________________ > >>>>> > >>>>> Ce message et ses pieces jointes peuvent contenir des informations > >>>>> confidentielles ou privilegiees et ne doivent donc pas etre > >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu > >>>>> ce message par erreur, veuillez le signaler a l'expediteur et le > >>>>> detruire ainsi > >> que les pieces jointes. Les messages electroniques etant susceptibles > >> d'alteration, France Telecom - Orange decline toute responsabilite si > >> ce message a ete altere, deforme ou falsifie. Merci. > >>>>> > >>>>> This message and its attachments may contain confidential or > >>>>> privileged information that may be protected by law; they should > >>>>> not > >> be distributed, used or copied without authorisation. > >>>>> If you have received this email in error, please notify the sender > >>>>> and > >> delete this message and its attachments. > >>>>> As emails may be altered, France Telecom - Orange is not liable > >>>>> for > >> messages that have been modified, changed or falsified. > >>>>> Thank you. > >>>>> > >>>> _______________________________________________ > >>>> CDNi mailing list > >>>> CDNi@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/cdni > >>>> This e-mail and its contents are subject to the DISCLAIMER at > >> http://www.tno.nl/emaildisclaimer > >>>> > >>>> > >>>> > >> ______________________________________________________________________ > >> ____ _______________________________________________ > >>>> > >>>> Ce message et ses pieces jointes peuvent contenir des informations > >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > >> exploites ou copies sans autorisation. Si vous avez recu ce message > >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > >> que les pieces jointes. Les messages electroniques etant susceptibles > >> d'alteration, France Telecom - Orange decline toute responsabilite si > >> ce message a ete altere, deforme ou falsifie. Merci. > >>>> > >>>> This message and its attachments may contain confidential or > >>>> privileged > >> information that may be protected by law; they should not be > >> distributed, used or copied without authorisation. > >>>> If you have received this email in error, please notify the sender > >>>> and > >> delete this message and its attachments. > >>>> As emails may be altered, France Telecom - Orange is not liable for > >> messages that have been modified, changed or falsified. > >>>> Thank you. > >>>> > >>>> > >>>> > >> ______________________________________________________________________ > >> ____ _______________________________________________ > >>>> > >>>> Ce message et ses pieces jointes peuvent contenir des informations > >> confidentielles ou privilegiees et ne doivent donc > >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous > >>>> avez > >> recu ce message par erreur, veuillez le signaler > >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les > >> messages electroniques etant susceptibles d'alteration, > >>>> France Telecom - Orange decline toute responsabilite si ce message > >>>> a > >> ete altere, deforme ou falsifie. Merci. > >>>> > >>>> This message and its attachments may contain confidential or > >>>> privileged > >> information that may be protected by law; > >>>> they should not be distributed, used or copied without authorisation= . > >>>> If you have received this email in error, please notify the sender > >>>> and > >> delete this message and its attachments. > >>>> As emails may be altered, France Telecom - Orange is not liable for > >> messages that have been modified, changed or falsified. > >>>> Thank you. > >>>> > >>> _______________________________________________ > >>> 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 > > > > > _________________________________________________________________________= _ > _______________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s > electroniques etant susceptibles d'alteration, > > France Telecom - Orange decline toute responsabilite si ce message a et= e > altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > delete this message and its attachments. > > As emails may be altered, France Telecom - Orange is not liable for > messages that have been modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From ray.vanbrandenburg@tno.nl Wed Jul 25 06:07:36 2012 Return-Path: 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 A6D4621F85CD for ; Wed, 25 Jul 2012 06:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.58 X-Spam-Level: X-Spam-Status: No, score=0.58 tagged_above=-999 required=5 tests=[AWL=0.484, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_93=0.6] 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 MDSvBUeohcZE for ; Wed, 25 Jul 2012 06:07:33 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4E02021F84E7 for ; Wed, 25 Jul 2012 06:07:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,653,1336341600"; d="scan'208";a="15869042" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 25 Jul 2012 15:07:30 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.152]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.02.0298.004; Wed, 25 Jul 2012 15:07:30 +0200 From: "Brandenburg, R. (Ray) van" To: "Francois Le Faucheur (flefauch)" , " " Thread-Topic: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.txt Thread-Index: AQHNamIcTgu/Ma+fB0qRTcb3voUnfpc58zWw Date: Wed, 25 Jul 2012 13:07:29 +0000 Message-ID: References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> <2040_1341930789_4FFC3D24_2040_2504_1_b86bff40-ae68-40c0-b8e5-060f51be6864@PEXCVZYH02.corporate.adroot.infra.ftgroup> <3A7EA7EE-F8D4-4094-83F2-12CD3826B662@tno.nl> <5004079D.4000406@cisco.com> <29661_1343216353_500FDAE1_29661_643_1_2AC63C9F27AF8446B0C064C50FC0A89305D959@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AF54F9B-B4FF-4043-A9DE-36C0417F9EAC@cisco.com> In-Reply-To: <2AF54F9B-B4FF-4043-A9DE-36C0417F9EAC@cisco.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 13:07:36 -0000 Hi all, Francois, thanks for clarifying this discussion, very helpful. I tend to agree with your assessment of the various options. Personally, I = would be opposed to a CDNI specification that does not include *B* at least= as an option, since to me *A* is not suited for 'premium'-content cases wh= ere you want to minimize the chances of content not being delivered. In the= se cases, scalability might be less of a concern, especially for CDNs that = do internal request routing for each request anyway. In addition, I think t= he CDNI interfaces should at least support a scenario where the dCDN, whate= ver it advertises, should always have the option of turning down a content = delivery request by a uCDN, whether it is for reasons of overload, technica= l difficulty or simply business reasons. If a dCDN does this too often for = a uCDNs liking, than that uCDN can simply decide to no longer do business w= ith that dCDN by not choosing it again for future redirects.=20 Finally, I think it should be up to the uCDN to decide how it chooses a dCD= N, whether it is based on capability and footprint information or simply by= polling different dCDNs. If that polling is performed by the same mechanis= m that is used by *B*, I don't see any reason not to support that.=20 Best regards, Ray -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Fra= ncois Le Faucheur (flefauch) Sent: woensdag 25 juli 2012 14:36 To: Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.txt All, To help the discussion, we may need to distinguish three (main) modes: *A* the uCDN uses the Footprint&Cap information (advertised by dCDN) to sel= ect a dCDN. The uCDN redirects to the selected dCDN and considers that he i= s done with request routing. *B* the uCDN uses the Footprint&Cap information (advertised by dCDN) to sel= ect a dCDN candidate. The uCDN queries the dCDN before redirecting.=20 Querying dCDN optionally allows the dCDN to provide to uCDN the final redir= ection information so the the enduser experiences a single redirect. Querying dCDN optionally allows the uCDN to pick an alternate dCDN if the i= nitially selected dCDN cannot handle the request. *C* the uCDN queries multiple dCDNs on a per-request basis and selects dCDN= based on their responses. In other words, the Footprint&Cap advertisement = is performed via on-demand per-request queries.=20 I think: * Scott pointed out that fundamentatly both *A* and *B* have to deal with = (typically transient) situations where uCDN thinks dCDN can take a request = and dCDN actually cannot handle it. And pointed out that with *A* the trans= ient period is dictated by the Footprint&Cap advertisement "update speed" w= hile with *B* it is not. * Allan was saying *A* is all he needs and *B* is extra complexity that he= doesn't need. * Gilles and lelouedec-cdni-request-routing were saying *C* is bad.=20 My impression is that there is violent agreement that *A* is to be supporte= d. I think Allan and Gilles message indicate so. I personally support that.= I think many people have been discussing that approach. If someone feels t= his is NOT to be supported by CDNI, do let us know.=20 I think Gilles message below is primarily arguing against *C*. I personally= agree that this need not be supported in our initial deliverables. Are the= re people arguing this approach is to be supported in the initial deliverab= les?=20 Regarding *B*, I personally see it as quite useful and worth supporting in = Phase 1 (possibly as an option).=20 Regarding Allan's points: * I agree there is some "scalability" argument (i.e. state+wait-for-dCDN-r= esponse) but it amounts to a web-services call out per request and buys you= reliability of request routing, so I see that as a trade-off that some CDN= s should be able to exercise.=20 * I don't buy the latency argument because you end up with 2 RTTs in both = *A* and *B* (in normal situations where dCDN can handle the request) (i.e. = user-->uCDN, uCDN-->user, user-->dCDN, dCDN-->user versus user-->uCDN, uCDN= -->dCDN, dCDN-->uCDN, uCDN-->user) and in the transient cases where dCDN ca= nnot handle the request *B* can do as well as *A* (drop the request) or has= the option to differently i.e. re-redirect at the cost of an extra RTT.=20 * I don't buy the "loop free mechanism" argument. In *B*, it is easy to im= plement a loop detection and even loop prevention (if you want). In *A*, yo= u have no loop prevention (other than the inherent HTTP/DNS max redirect/ma= x CNAMEs) Other opinions on *B* are sought. Cheers Francois On 25 Jul 2012, at 13:39, wrote: > Hi everyone, >=20 > I fully agree with Allan's comments. Putting aside the vocabulary ('recur= sive model' etc), Allan's comment are consistent with the messages that htt= p://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 tries to co= nvey. >=20 > " o Regarding the former process, i.e. related to the "ability" > ("enables a Request Routing function in an upstream CDN to query a > Request Routing function in a downstream CDN to determine if the > downstream CDN is able (...) to accept the delegated content > request"), a routing protocol is used to achieve such a process, > called routing process, in many other technologies and networks > (IP, ATM, etc.). In all these technologies, it is the downstream > entity that provides routing information to the upstream entity. > The same approach should be applied to CDN interconnection. The > reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2, > dCDN 3, and then it selects one of them based on their responses") > would suffer from latency, signaling overhead and/or lack of > reactivity to events that impact the ability of the downstream > CDNs to accept delegated content requests." >=20 > Best regards, > -- > Gilles >=20 >=20 > -----Message d'origine----- > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part=20 > de GUILLOU, Allan Envoy=E9 : mercredi 25 juillet 2012 12:23 =C0 : Scott=20 > Wainner; cdni@ietf.org Objet : Re: [CDNi] TR: I-D Action:=20 > draft-lelouedec-cdni-request-routing-00.txt >=20 > Hi, >=20 > With a "recusive model" as you ask if I understand, you expect the dCDN t= o send like an "ack" for each request, and if not the uCDN will try to find= the second best dCDN and do the same thing. >=20 > I think that this model may add complexity and may cause some scalability= problem. You will have to implement timers between request and ack, retran= smission mechanism to make sure that request has not been lost, loop free m= echanism, And all this may add latency on all requests and performances pro= blems. >=20 > In the iterative model, if the dCDN is not able to handle the request, th= is request will be lost. It is the same thing in IP network today we do not= ask the routing protocol to change when there is saturation somewhere. It = is the responsibility of each ISP to choose another route to join this dest= ination if he want to keep a good quality of service. If a dCDN is overload= ed, it will stop announcing part of its footprint or uCDN may apply some po= licy to force choosing another dCDN. >=20 > It is right that this second model may not in case of dCDN saturation hav= e the best reactivity, but it is exactly the same thing on the internet tod= ay. We can imagine that a poor dCDN which have saturation will be "black li= sted" by all the uCDN and the regulation will be done like this. > I think recursive model will add complexity all the time for a gain witch= is not in my opinion so important and that will not be seen so often. >=20 > Allan >=20 >> -----Message d'origine----- >> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part=20 >> de Scott Wainner Envoy=E9 : lundi 16 juillet 2012 14:23 =C0 : >> cdni@ietf.org Objet : Re: [CDNi] TR: I-D Action:=20 >> draft-lelouedec-cdni-request-routing- >> 00.txt >>=20 >> On 7/10/12 11:39 AM, Brandenburg, R. (Ray) van wrote: >>> Hi Yannick, >>>=20 >>> We seem to be misunderstanding each other. Maybe this will help=20 >>> clarify >> my point: >>>=20 >>>> Let me try to fully understand your point: >>>> Are you really meaning that in this case the dCDN has in reality >> absolutely no obligation with regards to the uCDN? >>>> Are you really meaning that in this case the dCDN decides alone, in >> real time, and for each content request, whether it denies or accepts=20 >> to ensure delivery? >>> What I mean is that I would like to have a RR Interface at least=20 >>> support >> a model where for every content request the uCDN asks the dCDN=20 >> whether it wants to deliver that particular content item (I believe=20 >> you call this a PULL approach). And I would like to allow the dCDN to be= able to say 'No' >> on this request (whether it is for purposes or failure, overload, or=20 >> any other reason). >>>=20 >>>> Are you really meaning that in this case the dCDN decides alone, in >> real time, and for each content request, whether it denies or accepts=20 >> to ensure delivery, and this even if the dCDN has the capability to=20 >> deliver the content? >>> Yes. >> I think we have to delineate between the iterative and recursive model. >>=20 >> The recursive model assumes that the client request to the uCDN will=20 >> be recursive and the CDN-I RR interface will be used to provide an=20 >> answer for each client request. The choice to initiate the recursion=20 >> would be determined by the footprint / capabilities. The ability of=20 >> the dCDN to execute the specific request would provide immediate=20 >> feedback to the uCDN. A dCDN that continues to advertise the=20 >> footprint / capability, but frequently or continually rejects the=20 >> request via CDN-I RR would be a poor candidate. The opportunity now=20 >> arises where the uCDN may elect to choose an alternate dCDN because=20 >> its preferred dCDN (according to footprint / capabilities) is 'under-per= forming'. >>=20 >> The iterative model, the uCDN blindly redirects the client to the=20 >> dCDN based on the footprint / capabilities. What the dCDN does with=20 >> the request is somewhat transparent to the uCDN. With the exception=20 >> of the CDN-I logging, the uCDN assumes the dCDN is properly handling=20 >> the requests that were delegated to the dCDN. If you are trying to=20 >> 'tighten' up the case of blind rejections, then the frequency of the=20 >> footprint / capabilities advertisements would have to be accelerated. >> For the case where the dCDN repeatedly sees requests from the uCDN=20 >> that the dCDN can't handle, it should retract its footprint /=20 >> capabilities advertisement. Failing to do so would continually=20 >> black-hole routing requests which would be indicated in the logging info= rmation. >>=20 >> Either way, you need a feedback loop to avoid dumping routing requests. >>=20 >> With any feedback loop (recursive routing request or footprint /=20 >> capabilities advertisement), you have to be careful about rapid=20 >> oscillations and dampening the responses. >>=20 >> Scott >>>=20 >>>> Are you really meaning that in this case the dCDN may possibly=20 >>>> response >> negatively to all requests for content request redirection submitted=20 >> by the uCDN over the CDNI request routing interface? (i.e. that=20 >> possibly the uCDN will never be allowed/invited to redirect a content=20 >> request to the >> dCDN?) >>>=20 >>> Yes. Any negative effect this may have on the business relationship >> between uCDN and dCDN should be handled on the business level. >>>=20 >>> Ray >>>=20 >>>=20 >>> On Jul 10, 2012, at 4:33 PM, >>> wrote: >>>=20 >>>> Hi Ray, >>>>=20 >>>>=20 >>>> 1) Ray, quoting your mail: "The current drafts seems to assume some >> particular type of contractual agreement between CDNs that might not=20 >> always be the case." >>>>=20 >>>> Please quote the draft. >>>> Please let us know exactly to which sentence(s) of the draft you=20 >>>> are >> referring to. >>>> Otherwise it is hard to discuss and comment on your email. >>>>=20 >>>>=20 >>>> 2) Ray, Quoting your mail: "If a dCDN does not live up to its >> contractual agreement, this should be something that is handled on a=20 >> business level, not on a protocol level." >>>>=20 >>>> Maybe there is a deep misunderstanding. >>>> So I will try to be clear again. >>>> We do not propose the CDNI routing interface to be used by the dCDN=20 >>>> to >> send a message saying "Sorry, but I decide unilaterally to refuse=20 >> this content request". >>>> We do not propose the CDNI routing interface to be used to handle=20 >>>> any >> aspect relating to a dCDN deciding unilaterally to stop living up to=20 >> its contractual agreement. >>>>=20 >>>> Please let us know where you saw such an idea in this IETF draft=20 >>>> "CDNI >> request routing". >>>>=20 >>>> The only role of the CDNI routing interface is to be used to=20 >>>> advertise >> CDNI routing information from the downstream CDN to the upstream CDN. >>>> And this is the description given in this IETF draft. >>>>=20 >>>>=20 >>>> 3) Ray, quoting your mail: "one example of a contractual agreement >> between two CDNs is one in which the uCDN and dCDN have agreed that=20 >> the dCDN will deliver some content on behalf of a uCDN, but decide on=20 >> a per- request basis whether it wants to do so (and is for example=20 >> paid per request). In these cases, the dCDN needs to have the ability=20 >> to deny delivery on a per-request basis." >>>>=20 >>>> Let me try to fully understand your point: >>>> Are you really meaning that in this case the dCDN has in reality >> absolutely no obligation with regards to the uCDN? >>>> Are you really meaning that in this case the dCDN decides alone, in >> real time, and for each content request, whether it denies or accepts=20 >> to ensure delivery? >>>> Are you really meaning that in this case the dCDN decides alone, in >> real time, and for each content request, whether it denies or accepts=20 >> to ensure delivery, and this even if the dCDN has the capability to=20 >> deliver the content? >>>> Are you really meaning that in this case the dCDN may possibly=20 >>>> response >> negatively to all requests for content request redirection submitted=20 >> by the uCDN over the CDNI request routing interface? (i.e. that=20 >> possibly the uCDN will never be allowed/invited to redirect a content=20 >> request to the >> dCDN?) >>>>=20 >>>>=20 >>>> 4) Ray, quoting your mail: "Every routing protocol defines the=20 >>>> expected >> behavior of interconnected elements/networks on a technical level,=20 >> not on a business level." >>>>=20 >>>> Again, this is not what I have written, and this is not the idea we >> want to share. >>>> I wrote "Every routing protocol has been defined (or at least >> configured) so far by considering the expected behavior of the=20 >> interconnected elements/networks." >>>> That's all. >>>> I can rephrase this sentence the following way: "we must know what=20 >>>> we >> expect to do with a protocol to design it correctly." >>>> And IHMO this is an evidence; I don't know any other way to proceed. >>>>=20 >>>> Besides, let us consider BGP (which is by the way an option=20 >>>> proposed by >> some IETF members to implement this CDNI routing interface). >>>> In IP networks, BGP configurations in IP routers are defined as per=20 >>>> the >> business relationships (valley free policy, etc.). >>>> Of course the business relationships determine the BGP configurations. >>>> And of course BGP has been designed so as to allow to configure IP >> interconnections adequately depending on the corresponding=20 >> Customer/provider, sibling and peering contractual agreements. >>>> But this does not mean that BGP "defines the expected behavior of >> interconnected elements/networks... on a business level." >>>> Even if we can indeed infer quite accurately the business=20 >>>> relationships >> between ISP from the BGP configuration of their IP routers (see CAIDA=20 >> project), but this is another story. >>>>=20 >>>>=20 >>>> Best regards, >>>>=20 >>>> Yannick Le Lou=E9dec. >>>>=20 >>>>=20 >>>>=20 >>>> -----Message d'origine----- >>>> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >>>> Envoy=E9 : mardi 10 juillet 2012 15:13 =C0 : LE LOUEDEC Yannick=20 >>>> RD-CORE; Ben Niven-Jenkins Cc : Pilarski Marcin - Korpo TP;=20 >>>> cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR: I-D >>>> Action: draft-lelouedec-cdni-request- >> routing-00.txt >>>>=20 >>>> Hi Yannick, >>>>=20 >>>> See comments inline. >>>>=20 >>>> In general: IMO the CDNI interfaces should be abstracted from any=20 >>>> kind >> of contractual/business agreement that might or might not exist=20 >> between a dCDN and uCDN. The current drafts seems to assume some=20 >> particular type of contractual agreement between CDNs that might not alw= ays be the case. >>>>=20 >>>> Ray >>>>=20 >>>> -----Original Message----- >>>> From: yannick.lelouedec@orange.com >> [mailto:yannick.lelouedec@orange.com] >>>> Sent: dinsdag 10 juli 2012 12:01 >>>> To: Brandenburg, R. (Ray) van; Ben Niven-Jenkins >>>> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE >>>> Subject: RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- >> routing-00.txt >>>>=20 >>>> Hi Ray, all, >>>>=20 >>>>=20 >>>> 1) Ray, Quoting your mail: "I don't see why the CDNI Request=20 >>>> Routing >> interface should state that a dCDN MUST deliver the content if it has=20 >> indicated its ability to do so earlier in either a contractual=20 >> agreement or in the capability interface." >>>>=20 >>>> This is not what we have written. >>>> Let me try to rephrase simply. >>>>=20 >>>> A contractual agreement is a contractual agreement. >>>> It put in writings the respective obligations of the uCDN and of=20 >>>> the >> dCDN. >>>> The uCDN may redirect any content request to the dCDN as long as it=20 >>>> is >> in full conformance with the terms of this contractual agreement (the=20 >> type of the content request is in full conformance, the maximum=20 >> number of content requests per second is respected, etc.). >>>> In this case the dCDN may not say "Sorry, but I decide unilaterally=20 >>>> to >> refuse this content request". >>>>=20 >>>> [RvB]: This is where we disagree. IMHO, the type of behavior you >> describe (the dCDN not living up to its obligation) should not be=20 >> enforced by the CDNI Interfaces. If a dCDN does not live up to its=20 >> contractual agreement, this should be something that is handled on a=20 >> business level, not on a protocol level. >>>>=20 >>>> Why? Because this is the deal, a contractual agreement is a=20 >>>> contractual >> agreement! >>>> Yet the dCDN may say "I do apologize, but at this time I cannot=20 >>>> handle >> correctly a certain class of content requests specified in our=20 >> contractual agreement" (for example the class of the HTTP content=20 >> requests with token from French end users, because of overload=20 >> situation, failure, etc.) This is the role of the CDNI routing=20 >> interface to provide the uCDN with such information. >>>>=20 >>>> (And the dCDN may be given a penalty for example if this was agreed=20 >>>> in >> the terms of the contractual agreement.) >>>>=20 >>>>=20 >>>> 2) Ray, Quoting your mail: "I understand that in most cases, the >> contractual agreement might indeed impose this behavior on the dCDN" >>>>=20 >>>> Please provide the description of an example where this is not the >> case. >>>> Otherwise the IETF CDNI WG shall indeed consider this is ALWAYS the >> case. >>>>=20 >>>> [RvB]: I can't remember ever seeing such a discussion on the WG list. >> Anyway: one example of a contractual agreement between two CDNs is=20 >> one in which the uCDN and dCDN have agreed that the dCDN will deliver=20 >> some content on behalf of a uCDN, but decide on a per-request basis=20 >> whether it wants to do so (and is for example paid per request). In=20 >> these cases, the dCDN needs to have the ability to deny delivery on a pe= r-request basis. >>>>=20 >>>> And this is an important point to be able to progress in the CDNI >> interfaces' specification works. >>>>=20 >>>> If the contractual agreement does not define clearly the=20 >>>> obligations of >> the uCDN, it is impossible to dimension adequately the dCDN, neither=20 >> to define correctly the CDNI contractual agreements between the dCDN=20 >> and the dCDNs of this dCDN. >>>> If the contractual agreement does not define clearly the=20 >>>> obligations of >> the dCDN, the dCDN may do what it wants... even to put in the trash=20 >> can any content request it accepted to handle. >>>>=20 >>>> [RvB]: Exactly, this is something that needs to be discussed on a >> business/contractual level and not on a technical level. That is way=20 >> IMHO the CDNI Interfaces should not make ANY assumptions on what was=20 >> agreed on a contractual level. >>>>=20 >>>> In both situations it is impossible to ensure any quality of=20 >>>> experience >> to the end user. >>>>=20 >>>>=20 >>>> 3) Ray, Quoting your mail: "I don't think this type of behavior=20 >>>> should >> be imposed by the protocol we're developing here." >>>>=20 >>>> I do not sure I understand this sentence. >>>> Every routing protocol has been defined (or at least configured) so=20 >>>> far >> by considering the expected behavior of the interconnected=20 >> elements/networks. >>>>=20 >>>> [RvB]: Every routing protocol defines the expected behavior of >> interconnected elements/networks on a technical level, not on a=20 >> business level. Having a dCDN say 'I'm not willing to deliver this=20 >> content' is perfectly fine from a technical perspective, although it=20 >> could be problematic from a contractual perspective. >>>>=20 >>>> But maybe I will understand if you provide an example on the point >>>> 2 >> above. >>>>=20 >>>>=20 >>>> Best regards, >>>>=20 >>>> Yannick Le Lou=E9dec. >>>>=20 >>>>=20 >>>>=20 >>>> -----Message d'origine----- >>>> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >>>> Envoy=E9 : mardi 10 juillet 2012 09:20 =C0 : Ben Niven-Jenkins; LE=20 >>>> LOUEDEC Yannick RD-CORE Cc : Pilarski Marcin >> - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR:=20 >> I-D >> Action: draft-lelouedec-cdni-request-routing-00.txt >>>>=20 >>>> Hi Yannick, Ben, >>>>=20 >>>> I tend to agree with Ben here. When reading the draft, I got the >> feeling that the draft seems to assume a lot about the relationship=20 >> between the uCDN and dCDN. For example, I don't see why the CDNI=20 >> Request Routing interface should state that a dCDN MUST deliver the=20 >> content if it has indicated its ability to do so earlier in either a=20 >> contractual agreement or in the capability interface. I understand=20 >> that in most cases, the contractual agreement might indeed impose=20 >> this behavior on the dCDN, but I don't think this type of behavior=20 >> should be imposed by the protocol we're developing here. >>>>=20 >>>> It was always my assumption that the Request Routing Interface=20 >>>> would at >> least include the option of allowing the uCDN to query the dCDN for=20 >> every content request whether the dCDN is willing to deliver that=20 >> particular request. >>>>=20 >>>> I will send my full review of the draft later. >>>>=20 >>>> Ray >>>>=20 >>>> -----Original Message----- >>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On=20 >>>> Behalf Of >> Ben Niven-Jenkins >>>> Sent: dinsdag 10 juli 2012 7:38 >>>> To: yannick.lelouedec@orange.com >>>> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE >>>> Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- >> routing-00.txt >>>>=20 >>>> Yannick, >>>>=20 >>>> Please see inline. >>>>=20 >>>> On 9 Jul 2012, at 20:05, wrote: >>>>=20 >>>>> Hi Ben, all, >>>>>=20 >>>>> Ben, quoting you mail below, "... the downstream CDN could reply=20 >>>>> with either "here is how to redirect it"", >>>>>=20 >>>>> =3D> This is the role of the CDNI DRIS interface to provide the uCDN >> with this information, and we target to make its specification public=20 >> before Vancouver meeting so that everyone may read it before the=20 >> meeting and get full knowledge of our proposal about this part of=20 >> CDNI request routing. >>>>>=20 >>>>> Ben, quoting you mail below, "... or "no I can't/won't take that >> content delivery right now", reasons may include the uCDN has=20 >> requested a delivery of a protocol the dCDN does not support (possibly i= n error). >>>>>=20 >>>>> =3D> This is the role of the CDNI logging interface to provide the=20 >>>>> uCDN >> with this information. >>>> I agree this information should be logged but the Request Routing >> interface (what you call the DRIS) also needs to be able to indicate=20 >> a failure. >>>>=20 >>>> Otherwise the uCDN will 'blindly' redirect the the dCDN and the >> delivery will fail leading to poor end user experience. >>>>=20 >>>>> Ben, quoting you mail below, "... or "no I can't/won't take that >> content delivery right now", reasons may include ... the dCDN has no=20 >> capacity right now etc." >>>>>=20 >>>>> =3D> This is the role of the CDNI routing interface to provide the=20 >>>>> uCDN >> with this information. >>>> It is the role of the CDN capability/routing interface to advertise >> broad capabilities etc not to give extremely fine grained real-time=20 >> information on exactly the state of the dCDN. >>>>=20 >>>> Even if the capability/routing interface is real-time there are=20 >>>> likely >> to still be race conditions where we need the dCDN to be about to=20 >> indicate a failure to accept a redirect through the request=20 >> routing/DRIS interface >>>>=20 >>>>> So we may conclude we are in line basically, which is a good point. >>>>> We just aimed at checking there was a common understanding on this >> point. >>>>>=20 >>>>> The key point for us here is that we don't want this sentence >> extracted from draft-ietf-cdni-problem-statement be interpreted as: ".=20 >> and the dCDN MUST accept the content request except when it has not=20 >> the "ability" to do so." >>>> Why not? IMO that is a valid scenario for some use cases. >>>>=20 >>>>> The fact that the dCDN is temporary unable to handle content=20 >>>>> request >> correctly is not a valid reason for the dCDN to be discharged of its=20 >> obligations to the uCDN. >>>>> The contract set between the uCDN and the dCDN remains valid=20 >>>>> anyway, >> and the obligations of the dCDN as well. >>>> Correct, but that contract may not be the same for all uCDNs &=20 >>>> dCDNs, >> for example a uCDN may not have a guarantee that a dCDN can handle=20 >> everything it is requested to handle but the contract may only be=20 >> that the dCDN guarantees to handle up to a certain volume of traffic. >>>>=20 >>>>> The dCDN must announce to the uCDN that it is temporary unable, as >> soon as possible, via the CDNI routing interface. >>>>> And the uCDN must take this information into account in its CDN >> selection process as soon as possible. >>>>> Then if the uCDN decides to continue to redirect content requests=20 >>>>> to >> the dCDN, the uCDN MAY perfectly do it, but the uCDN knows these=20 >> content requests will be lost. >>>> What happens in the period between the dCDN being unable to handle >> requests and the time it takes to advertise that to the uCDN and for=20 >> the uCDN to process & incorporate that new knowledge? Are requests=20 >> blindly forwarded to the dCDN which is unable to handle them leading=20 >> to poor user experience? >>>>=20 >>>>> We could even imagine the situation where the uCDN continues to do=20 >>>>> it >> intentionally, because it has no better option and the content=20 >> request will be lost anyway. For example in the case where neither=20 >> the uCDN nor the other downstream CDNs of the uCDN cannot manage=20 >> correctly the content request, the uCDN could do it intentionally so=20 >> as to be able to clearly prove (with CDNI logging information) that=20 >> it is the dCDN, not the uCDN, who is at fault. >>>>> But, of course, if there are alternative backup options, the=20 >>>>> normal >> reaction of the uCDN is to stop as soon as possible to redirect=20 >> content requests to the dCDN when the uCDN knows that the dCDN is=20 >> unable to handle them correctly. >>>>>=20 >>>>> So, to be clear, we would prefer the sentence to be understood as: >>>>> ". and the dCDN MUST accept the content request. >>>>> And if it cannot handle correctly the redirected content request=20 >>>>> it >> receives, the content request is lost. >>>> What about scenarios where the uCDN has a choice of dCDNs (e.g. two >> national-wide CDNs offering services at different costs), the uCDN=20 >> may elect to query both dCDNs and decide based on their responses=20 >> which one to choose. If the dCDN is unable to satisfy the request the=20 >> uCDN needs to know that so that it can fallback to the (more=20 >> expensive in this example) dCDN. >>>>=20 >>>>> For example the dCDN generates a response to the content request=20 >>>>> with >> an error message, or no response at all. And in parallel the CDNI=20 >> logging interface may be used to exchange logs corresponding to this pro= blem. >> Anyway the dCDN MAY NOT redirect that content request back towards=20 >> the uCDN." >>>>>=20 >>>>> Exactly as in IP networks: IP packets are not sent back towards=20 >>>>> the >> origin by a downstream router under failure or congestion. >>>> In a routed IP network, there is often a small packet loss while=20 >>>> the >> network re-converges, by enabling the dCDN to refuse a redirection at=20 >> CDNI Request Routing/DRIS query time we can reduce that window by=20 >> giving the uCDN the option to take an alternative action (e.g. try=20 >> another dCDN) while the routing/capability information re-converges. >>>>=20 >>>>> In both networks (IP and CDN), the reason is the same. >>>>> If the dCDN redirects back a content request to the uCDN, this >> generates a loop. >>>> Loop avoidance is a separate issue IMO to whether we should allow a >> dCDN to be able to communicate "I am unable/unwilling to take that=20 >> content delivery at this time". >>>>=20 >>>> Regards >>>> Ben >>>>=20 >>>>> To manage this would introduce a very high complexity. >>>>> And this would be just to try to save the content requests=20 >>>>> redirected >> by the uCDN to the dCDN in the timeslot between the time the dCDN=20 >> gets down and the time the uCDN takes this failure into account in=20 >> its CDN selection process. >>>>> It is much better to try to reduce this timeslot as much as=20 >>>>> possible, >> with routing optimizations (we will propose as soon as possible). >>>>> Rather than introducing additional complexities (to manage=20 >>>>> redirection >> to the uCDN) in the framework. >>>>>=20 >>>>>=20 >>>>> By the way, as you know, the IESG has just approved today the=20 >>>>> 'Content >> Distribution Network Interconnection (CDNI) Problem Statement' draft=20 >> as informational RFC. This is a good point. >>>>> And, as you may see in the draft "CDNI request routing", we do not >> propose to modify this problem statement draft. >>>>> We want know to focus now on getting the specifications of all=20 >>>>> CDNI >> interfaces ready as soon as possible. >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Yannick Le Lou=E9dec. >>>>>=20 >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la=20 >>>>> part de Ben Niven-Jenkins Envoy=E9 : lundi 9 juillet 2012 20:41 =C0 : >>>>> BERTRAND Gilles RD-CORE Cc : cdni@ietf.org; Pilarski Marcin -=20 >>>>> Korpo TP; MARREC Anne RD-CORE Objet : Re: [CDNi] TR: I-D Action: >>>>> draft-lelouedec-cdni-request-routing-00.txt >>>>>=20 >>>>> Colleagues, >>>>>=20 >>>>> I started reading draft-lelouedec-cdni-request-routing-00 and this >> text caught my eye: >>>>>=20 >>>>> Quoting [I-D.ietf-cdni-problem-statement ], "The CDNI Request=20 >>>>> Routing interface enables a Request Routing function in an=20 >>>>> upstream CDN to query a Request Routing function in a downstream=20 >>>>> CDN to determine if the downstream CDN is able (and willing) to=20 >>>>> accept the delegated content request". >>>>>=20 >>>>> The "ability" and the "willingness" of the downstream CDN to=20 >>>>> accept the delegated content request match two fully different=20 >>>>> processes in CDN interconnection. And the description of both=20 >>>>> these processes should be reviewed and clarified for the following r= easons: >>>>>=20 >>>>> o Regarding the former process, i.e. related to the "ability" >>>>> ("enables a Request Routing function in an upstream CDN to=20 >>>>> query >> a >>>>> Request Routing function in a downstream CDN to determine if the >>>>> downstream CDN is able (...) to accept the delegated content >>>>> request"), a routing protocol is used to achieve such a process, >>>>> called routing process, in many other technologies and networks >>>>> (IP, ATM, etc.). In all these technologies, it is the downstream >>>>> entity that provides routing information to the upstream entity. >>>>> The same approach should be applied to CDN interconnection. The >>>>> reverse approach ("uCDN queries it downstream CDNs dCDN 1,=20 >>>>> dCDN >> 2, >>>>> dCDN 3, and then it selects one of them based on their >> responses") >>>>> would suffer from latency, signaling overhead and/or lack of >>>>> reactivity to events that impact the ability of the downstream >>>>> CDNs to accept delegated content requests. >>>>>=20 >>>>> o Regarding the latter process, i.e. related to the "willingness" >>>>> ("enables a Request Routing function in an upstream CDN to=20 >>>>> query >> a >>>>> Request Routing function in a downstream CDN to determine if the >>>>> downstream CDN (...) is willing (...)to accept the delegated >>>>> content request"), it is to be noted that the relationship >> between >>>>> a uCDN and a dCDN is always in the frame of a contractual >>>>> agreement between the administrative entity owning the uCDN, >>>>> acting as the customer, and the administrative entity owning the >>>>> dCDN, acting as the service provider. Therefore, consider a case >>>>> where >>>>>=20 >>>>> * the uCDN has a content request to redirect which is in full >>>>> conformance with the terms of this contractual agreement,=20 >>>>> and >>>>>=20 >>>>> * the uCDN has selected this dCDN. >>>>>=20 >>>>> As the uCDN knows, thanks to the routing information exchanged >> via >>>>> the aforementioned routing process, that the dCDN is able to >>>>> accept this content request, the uCDN MAY redirect the content >>>>> request to the dCDN and the dCDN MUST accept the content request. >>>>> Exchanging over the CDNI Request Routing interface information >>>>> about the "willingness" of the dCDN to accept the content request >>>>> is not relevant. >>>>>=20 >>>>> I think you might be over thinking what we wrote in the problem >> statement. >>>>>=20 >>>>> What was in the problem statement was meant to convey that an=20 >>>>> upstream >> CDN could make a request to a downstream CDN to say "how do I=20 >> redirect this request to you" and the downstream CDN could reply with=20 >> either "her is how to redirect it", or "no I can't/won't take that=20 >> content delivery right now", reasons may include the uCDN has=20 >> requested a delivery of a protocol the dCDN does not support=20 >> (possibly in error) or the dCDN has no capacity right now etc. >>>>>=20 >>>>> Ben >>>>>=20 >>>>> On 9 Jul 2012, at 18:00, wrote: >>>>>=20 >>>>>> Hi everyone, >>>>>>=20 >>>>>> We have just submitted the draft below. We are convinced that it=20 >>>>>> will >> help the WG to progress on the CDNI routing issues. >>>>>>=20 >>>>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-0 >>>>>> 0 >>>>>>=20 >>>>>> Any feedback is very welcome. >>>>>>=20 >>>>>> Best regards, >>>>>>=20 >>>>>> Gilles >>>>>>=20 >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : i-d-announce-bounces@ietf.org=20 >>>>>> [mailto:i-d-announce-bounces@ietf.org] De la part de=20 >>>>>> internet-drafts@ietf.org Envoy=E9 : lundi 9 juillet 2012 18:55 =C0 : >>>>>> i-d-announce@ietf.org Objet : I-D Action: >>>>>> draft-lelouedec-cdni-request-routing-00.txt >>>>>>=20 >>>>>>=20 >>>>>> A New Internet-Draft is available from the on-line=20 >>>>>> Internet-Drafts >> directories. >>>>>>=20 >>>>>>=20 >>>>>> Title : CDNI Request Routing >>>>>> Author(s) : Yannick Le Louedec >>>>>> Anne Marrec >>>>>> Gilles Bertrand >>>>>> Marcin Pilarski >>>>>> Filename : draft-lelouedec-cdni-request-routing-00.txt >>>>>> Pages : 30 >>>>>> Date : 2012-07-09 >>>>>>=20 >>>>>> Abstract: >>>>>> The present document proposes to clarify the CDNI Request Routing=20 >>>>>> interface introduced in [I-D.ietf-cdni-framework] and >>>>>> [I-D.ietf-cdni- problem-statement], as well as related terminology. >>>>>>=20 >>>>>> In particular the present document proposes to split the CDNI=20 >>>>>> Request Routing interface into two separate interfaces with=20 >>>>>> clearer roles, named respectively CDNI Routing interface and=20 >>>>>> CDNI Downstream Resource Identifier Signaling interface (CDNI DRIS i= nterface). >>>>>>=20 >>>>>> This part of the CDN interconnection framework the IETF has been=20 >>>>>> referring to so far with the term "CDNI Request Routing" is just=20 >>>>>> another routing, signaling and forwarding problem in a long=20 >>>>>> series of the telecommunication history. For example, one can=20 >>>>>> draw a direct analogy between the IP/MPLS-TE framework and the=20 >>>>>> CDN interconnection framework. >>>>>>=20 >>>>>> In addition, this document recommends that the specification of=20 >>>>>> ALL CDN interconnection interfaces in the scope of the CDNI IETF=20 >>>>>> WG relies on the equivalent concept to IP prefix for CDN=20 >>>>>> interconnection, named 'contentRequestScope'. This highly useful=20 >>>>>> and powerful concept SHALL be used to simplify the specification=20 >>>>>> of ALL CDN interconnection interfaces, as well as to ensure=20 >>>>>> performance and scalability in CDN interconnection. >>>>>>=20 >>>>>> All these proposals can be smoothly integrated in the WG drafts,=20 >>>>>> especially [I-D.ietf-cdni-framework] and=20 >>>>>> [I-D.ietf-cdni-requirements], as they essentially propose >>>>>> (useful) clarifications of the existing framework. >>>>>>=20 >>>>>>=20 >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-rou >>>>>> ting >>>>>>=20 >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-0 >>>>>> 0 >>>>>>=20 >>>>>>=20 >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>=20 >>>>>> _______________________________________________ >>>>>> 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=20 >>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>=20 >>>>>> _________________________________________________________________ >>>>>> ____ ____________________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>> informations confidentielles ou privilegiees et ne doivent donc=20 >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 >>>>>> avez recu ce message par erreur, veuillez le signaler a=20 >>>>>> l'expediteur et le detruire ainsi >> que les pieces jointes. Les messages electroniques etant susceptibles=20 >> d'alteration, France Telecom - Orange decline toute responsabilite si=20 >> ce message a ete altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or=20 >>>>>> privileged information that may be protected by law; they should=20 >>>>>> not >> be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the=20 >>>>>> sender >> and delete this message and its attachments. >>>>>> As emails may be altered, France Telecom - Orange is not liable=20 >>>>>> for >> messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=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 >>>>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>>>> ce message par erreur, veuillez le signaler a l'expediteur et le=20 >>>>> detruire ainsi >> que les pieces jointes. Les messages electroniques etant susceptibles=20 >> d'alteration, France Telecom - Orange decline toute responsabilite si=20 >> ce message a ete altere, deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or=20 >>>>> privileged information that may be protected by law; they should=20 >>>>> not >> be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender=20 >>>>> and >> delete this message and its attachments. >>>>> As emails may be altered, France Telecom - Orange is not liable=20 >>>>> for >> messages that have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >>>> This e-mail and its contents are subject to the DISCLAIMER at >> http://www.tno.nl/emaildisclaimer >>>>=20 >>>>=20 >>>>=20 >> _____________________________________________________________________ >> _ ____ _______________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 >> que les pieces jointes. Les messages electroniques etant susceptibles=20 >> d'alteration, France Telecom - Orange decline toute responsabilite si=20 >> ce message a ete altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or=20 >>>> privileged >> information that may be protected by law; they should not be=20 >> distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender=20 >>>> and >> delete this message and its attachments. >>>> As emails may be altered, France Telecom - Orange is not liable for >> messages that have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>>=20 >>>>=20 >> _____________________________________________________________________ >> _ ____ _______________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 >>>> avez >> recu ce message par erreur, veuillez le signaler >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les >> messages electroniques etant susceptibles d'alteration, >>>> France Telecom - Orange decline toute responsabilite si ce message=20 >>>> a >> ete altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or=20 >>>> privileged >> information that may be protected by law; >>>> they should not be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender=20 >>>> and >> delete this message and its attachments. >>>> As emails may be altered, France Telecom - Orange is not liable for >> messages that have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>> _______________________________________________ >>> 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 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, France Telecom - Orange decline toute responsabilite si ce message a e= te altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=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 flefauch@cisco.com Wed Jul 25 06:20:50 2012 Return-Path: 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 36C7821F8567 for ; Wed, 25 Jul 2012 06:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.154 X-Spam-Level: X-Spam-Status: No, score=-10.154 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, J_CHICKENPOX_93=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 Q5m9w+bb-gUU for ; Wed, 25 Jul 2012 06:20:45 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id DB2F821F8568 for ; Wed, 25 Jul 2012 06:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=49535; q=dns/txt; s=iport; t=1343222445; x=1344432045; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TCD/gesQFqKdhChVOCjHTMuVWZ3hwW+xwfUP5qSXEnQ=; b=f4SOQWYg87VG4QAt/NGv5sgKcFmjAhPYJM7sT/wlDV2ZUcqJNpB8eK8A KmE2jPo04X4Nl7vpuH2UBOglZRGK4+8xFfJa3uXvs9knXgenWWevQKL4b Ul6GHFmXgamjJ+k55qtkDUNk50CUazejJxYifrEPyenmxeAPtgzSH20G3 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkGAOjxD1CtJXHB/2dsb2JhbABFuHNwgQeCIAEBAQMBAQEBDwEHAQwgJQIEBAMFBwQCAQgRBAEBARUSBycLFAkIAgQOBQkZh2UGC5pukQWPQotNAggQgzKCSGADiBmNMIEUiXmDGoFmgl+BVgka X-IronPort-AV: E=Sophos;i="4.77,653,1336348800"; d="scan'208";a="105142487" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 25 Jul 2012 13:20:43 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6PDKhvZ003800 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Jul 2012 13:20:43 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.17]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0298.004; Wed, 25 Jul 2012 08:20:42 -0500 From: "Francois Le Faucheur (flefauch)" To: "Brandenburg, R. (Ray) van" Thread-Topic: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.txt Thread-Index: AQHNamZ39nkanLpRQEqIQP9ngJ9pFpc6T4WA Date: Wed, 25 Jul 2012 13:20:42 +0000 Message-ID: <0B55392F-16FD-4967-9A9D-91A7D4CE1A30@cisco.com> References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> <2040_1341930789_4FFC3D24_2040_2504_1_b86bff40-ae68-40c0-b8e5-060f51be6864@PEXCVZYH02.corporate.adroot.infra.ftgroup> <3A7EA7EE-F8D4-4094-83F2-12CD3826B662@tno.nl> <5004079D.4000406@cisco.com> <29661_1343216353_500FDAE1_29661_643_1_2AC63C9F27AF8446B0C064C50FC0A89305D959@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AF54F9B-B4FF-4043-A9DE-36C0417F9EAC@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19062.004 x-tm-as-result: No--62.454400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <45466FCBD9662548AC466FE183A50401@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 13:20:50 -0000 Hi Ray, Good input. Thanks.=20 One point below: On 25 Jul 2012, at 15:07, Brandenburg, R. (Ray) van wrote: > Hi all, >=20 > Francois, thanks for clarifying this discussion, very helpful. >=20 > I tend to agree with your assessment of the various options. Personally, = I would be opposed to a CDNI specification that does not include *B* at lea= st as an option, since to me *A* is not suited for 'premium'-content cases = where you want to minimize the chances of content not being delivered. In t= hese cases, scalability might be less of a concern, especially for CDNs tha= t do internal request routing for each request anyway. In addition, I think= the CDNI interfaces should at least support a scenario where the dCDN, wha= tever it advertises, should always have the option of turning down a conten= t delivery request by a uCDN, whether it is for reasons of overload, techni= cal difficulty or simply business reasons. If a dCDN does this too often fo= r a uCDNs liking, than that uCDN can simply decide to no longer do business= with that dCDN by not choosing it again for future redirects.=20 >=20 > Finally, I think it should be up to the uCDN to decide how it chooses a d= CDN, whether it is based on capability and footprint information or simply = by polling different dCDNs. If that polling is performed by the same mechan= ism that is used by *B*, I don't see any reason not to support that.=20 You bring up a very good point here. I would probably also agree that "If t= hat polling is performed by the same mechanism that is used by *B*, I don't= see any reason not to support that". The thing is that we don't have much = time/cycles to spend to make sure the "polling" provides all the needed inf= o & knobs, and that all the error cases and scenario combinations are fully= addressed. But I take your point that, a polling interface developed for *= B* could be used by uCDN to achieve *C*. Thanks Francois >=20 > Best regards, >=20 > Ray >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of F= rancois Le Faucheur (flefauch) > Sent: woensdag 25 juli 2012 14:36 > To: > Cc: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.t= xt >=20 > All, >=20 > To help the discussion, we may need to distinguish three (main) modes: >=20 > *A* the uCDN uses the Footprint&Cap information (advertised by dCDN) to s= elect a dCDN. The uCDN redirects to the selected dCDN and considers that he= is done with request routing. >=20 > *B* the uCDN uses the Footprint&Cap information (advertised by dCDN) to s= elect a dCDN candidate. The uCDN queries the dCDN before redirecting.=20 > Querying dCDN optionally allows the dCDN to provide to uCDN the final red= irection information so the the enduser experiences a single redirect. > Querying dCDN optionally allows the uCDN to pick an alternate dCDN if the= initially selected dCDN cannot handle the request. >=20 > *C* the uCDN queries multiple dCDNs on a per-request basis and selects dC= DN based on their responses. In other words, the Footprint&Cap advertisemen= t is performed via on-demand per-request queries.=20 >=20 >=20 > I think: > * Scott pointed out that fundamentatly both *A* and *B* have to deal wit= h (typically transient) situations where uCDN thinks dCDN can take a reques= t and dCDN actually cannot handle it. And pointed out that with *A* the tra= nsient period is dictated by the Footprint&Cap advertisement "update speed"= while with *B* it is not. > * Allan was saying *A* is all he needs and *B* is extra complexity that = he doesn't need. > * Gilles and lelouedec-cdni-request-routing were saying *C* is bad.=20 >=20 > My impression is that there is violent agreement that *A* is to be suppor= ted. I think Allan and Gilles message indicate so. I personally support tha= t. I think many people have been discussing that approach. If someone feels= this is NOT to be supported by CDNI, do let us know.=20 >=20 > I think Gilles message below is primarily arguing against *C*. I personal= ly agree that this need not be supported in our initial deliverables. Are t= here people arguing this approach is to be supported in the initial deliver= ables?=20 >=20 > Regarding *B*, I personally see it as quite useful and worth supporting i= n Phase 1 (possibly as an option).=20 > Regarding Allan's points: > * I agree there is some "scalability" argument (i.e. state+wait-for-dCDN= -response) but it amounts to a web-services call out per request and buys y= ou reliability of request routing, so I see that as a trade-off that some C= DNs should be able to exercise.=20 >=20 > * I don't buy the latency argument because you end up with 2 RTTs in bot= h *A* and *B* (in normal situations where dCDN can handle the request) (i.e= . user-->uCDN, uCDN-->user, user-->dCDN, dCDN-->user versus user-->uCDN, uC= DN-->dCDN, dCDN-->uCDN, uCDN-->user) and in the transient cases where dCDN = cannot handle the request *B* can do as well as *A* (drop the request) or h= as the option to differently i.e. re-redirect at the cost of an extra RTT.= =20 > * I don't buy the "loop free mechanism" argument. In *B*, it is easy to = implement a loop detection and even loop prevention (if you want). In *A*, = you have no loop prevention (other than the inherent HTTP/DNS max redirect/= max CNAMEs) Other opinions on *B* are sought. >=20 >=20 > Cheers >=20 > Francois >=20 >=20 > On 25 Jul 2012, at 13:39, wrote: >=20 >> Hi everyone, >>=20 >> I fully agree with Allan's comments. Putting aside the vocabulary ('recu= rsive model' etc), Allan's comment are consistent with the messages that ht= tp://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 tries to c= onvey. >>=20 >> " o Regarding the former process, i.e. related to the "ability" >> ("enables a Request Routing function in an upstream CDN to query a >> Request Routing function in a downstream CDN to determine if the >> downstream CDN is able (...) to accept the delegated content >> request"), a routing protocol is used to achieve such a process, >> called routing process, in many other technologies and networks >> (IP, ATM, etc.). In all these technologies, it is the downstream >> entity that provides routing information to the upstream entity. >> The same approach should be applied to CDN interconnection. The >> reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2, >> dCDN 3, and then it selects one of them based on their responses") >> would suffer from latency, signaling overhead and/or lack of >> reactivity to events that impact the ability of the downstream >> CDNs to accept delegated content requests." >>=20 >> Best regards, >> -- >> Gilles >>=20 >>=20 >> -----Message d'origine----- >> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part=20 >> de GUILLOU, Allan Envoy=E9 : mercredi 25 juillet 2012 12:23 =C0 : Scott= =20 >> Wainner; cdni@ietf.org Objet : Re: [CDNi] TR: I-D Action:=20 >> draft-lelouedec-cdni-request-routing-00.txt >>=20 >> Hi, >>=20 >> With a "recusive model" as you ask if I understand, you expect the dCDN = to send like an "ack" for each request, and if not the uCDN will try to fin= d the second best dCDN and do the same thing. >>=20 >> I think that this model may add complexity and may cause some scalabilit= y problem. You will have to implement timers between request and ack, retra= nsmission mechanism to make sure that request has not been lost, loop free = mechanism, And all this may add latency on all requests and performances pr= oblems. >>=20 >> In the iterative model, if the dCDN is not able to handle the request, t= his request will be lost. It is the same thing in IP network today we do no= t ask the routing protocol to change when there is saturation somewhere. It= is the responsibility of each ISP to choose another route to join this des= tination if he want to keep a good quality of service. If a dCDN is overloa= ded, it will stop announcing part of its footprint or uCDN may apply some p= olicy to force choosing another dCDN. >>=20 >> It is right that this second model may not in case of dCDN saturation ha= ve the best reactivity, but it is exactly the same thing on the internet to= day. We can imagine that a poor dCDN which have saturation will be "black l= isted" by all the uCDN and the regulation will be done like this. >> I think recursive model will add complexity all the time for a gain witc= h is not in my opinion so important and that will not be seen so often. >>=20 >> Allan >>=20 >>> -----Message d'origine----- >>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part=20 >>> de Scott Wainner Envoy=E9 : lundi 16 juillet 2012 14:23 =C0 : >>> cdni@ietf.org Objet : Re: [CDNi] TR: I-D Action:=20 >>> draft-lelouedec-cdni-request-routing- >>> 00.txt >>>=20 >>> On 7/10/12 11:39 AM, Brandenburg, R. (Ray) van wrote: >>>> Hi Yannick, >>>>=20 >>>> We seem to be misunderstanding each other. Maybe this will help=20 >>>> clarify >>> my point: >>>>=20 >>>>> Let me try to fully understand your point: >>>>> Are you really meaning that in this case the dCDN has in reality >>> absolutely no obligation with regards to the uCDN? >>>>> Are you really meaning that in this case the dCDN decides alone, in >>> real time, and for each content request, whether it denies or accepts=20 >>> to ensure delivery? >>>> What I mean is that I would like to have a RR Interface at least=20 >>>> support >>> a model where for every content request the uCDN asks the dCDN=20 >>> whether it wants to deliver that particular content item (I believe=20 >>> you call this a PULL approach). And I would like to allow the dCDN to b= e able to say 'No' >>> on this request (whether it is for purposes or failure, overload, or=20 >>> any other reason). >>>>=20 >>>>> Are you really meaning that in this case the dCDN decides alone, in >>> real time, and for each content request, whether it denies or accepts=20 >>> to ensure delivery, and this even if the dCDN has the capability to=20 >>> deliver the content? >>>> Yes. >>> I think we have to delineate between the iterative and recursive model. >>>=20 >>> The recursive model assumes that the client request to the uCDN will=20 >>> be recursive and the CDN-I RR interface will be used to provide an=20 >>> answer for each client request. The choice to initiate the recursion=20 >>> would be determined by the footprint / capabilities. The ability of=20 >>> the dCDN to execute the specific request would provide immediate=20 >>> feedback to the uCDN. A dCDN that continues to advertise the=20 >>> footprint / capability, but frequently or continually rejects the=20 >>> request via CDN-I RR would be a poor candidate. The opportunity now=20 >>> arises where the uCDN may elect to choose an alternate dCDN because=20 >>> its preferred dCDN (according to footprint / capabilities) is 'under-pe= rforming'. >>>=20 >>> The iterative model, the uCDN blindly redirects the client to the=20 >>> dCDN based on the footprint / capabilities. What the dCDN does with=20 >>> the request is somewhat transparent to the uCDN. With the exception=20 >>> of the CDN-I logging, the uCDN assumes the dCDN is properly handling=20 >>> the requests that were delegated to the dCDN. If you are trying to=20 >>> 'tighten' up the case of blind rejections, then the frequency of the=20 >>> footprint / capabilities advertisements would have to be accelerated. >>> For the case where the dCDN repeatedly sees requests from the uCDN=20 >>> that the dCDN can't handle, it should retract its footprint /=20 >>> capabilities advertisement. Failing to do so would continually=20 >>> black-hole routing requests which would be indicated in the logging inf= ormation. >>>=20 >>> Either way, you need a feedback loop to avoid dumping routing requests. >>>=20 >>> With any feedback loop (recursive routing request or footprint /=20 >>> capabilities advertisement), you have to be careful about rapid=20 >>> oscillations and dampening the responses. >>>=20 >>> Scott >>>>=20 >>>>> Are you really meaning that in this case the dCDN may possibly=20 >>>>> response >>> negatively to all requests for content request redirection submitted=20 >>> by the uCDN over the CDNI request routing interface? (i.e. that=20 >>> possibly the uCDN will never be allowed/invited to redirect a content=20 >>> request to the >>> dCDN?) >>>>=20 >>>> Yes. Any negative effect this may have on the business relationship >>> between uCDN and dCDN should be handled on the business level. >>>>=20 >>>> Ray >>>>=20 >>>>=20 >>>> On Jul 10, 2012, at 4:33 PM, >>>> wrote: >>>>=20 >>>>> Hi Ray, >>>>>=20 >>>>>=20 >>>>> 1) Ray, quoting your mail: "The current drafts seems to assume some >>> particular type of contractual agreement between CDNs that might not=20 >>> always be the case." >>>>>=20 >>>>> Please quote the draft. >>>>> Please let us know exactly to which sentence(s) of the draft you=20 >>>>> are >>> referring to. >>>>> Otherwise it is hard to discuss and comment on your email. >>>>>=20 >>>>>=20 >>>>> 2) Ray, Quoting your mail: "If a dCDN does not live up to its >>> contractual agreement, this should be something that is handled on a=20 >>> business level, not on a protocol level." >>>>>=20 >>>>> Maybe there is a deep misunderstanding. >>>>> So I will try to be clear again. >>>>> We do not propose the CDNI routing interface to be used by the dCDN=20 >>>>> to >>> send a message saying "Sorry, but I decide unilaterally to refuse=20 >>> this content request". >>>>> We do not propose the CDNI routing interface to be used to handle=20 >>>>> any >>> aspect relating to a dCDN deciding unilaterally to stop living up to=20 >>> its contractual agreement. >>>>>=20 >>>>> Please let us know where you saw such an idea in this IETF draft=20 >>>>> "CDNI >>> request routing". >>>>>=20 >>>>> The only role of the CDNI routing interface is to be used to=20 >>>>> advertise >>> CDNI routing information from the downstream CDN to the upstream CDN. >>>>> And this is the description given in this IETF draft. >>>>>=20 >>>>>=20 >>>>> 3) Ray, quoting your mail: "one example of a contractual agreement >>> between two CDNs is one in which the uCDN and dCDN have agreed that=20 >>> the dCDN will deliver some content on behalf of a uCDN, but decide on=20 >>> a per- request basis whether it wants to do so (and is for example=20 >>> paid per request). In these cases, the dCDN needs to have the ability=20 >>> to deny delivery on a per-request basis." >>>>>=20 >>>>> Let me try to fully understand your point: >>>>> Are you really meaning that in this case the dCDN has in reality >>> absolutely no obligation with regards to the uCDN? >>>>> Are you really meaning that in this case the dCDN decides alone, in >>> real time, and for each content request, whether it denies or accepts=20 >>> to ensure delivery? >>>>> Are you really meaning that in this case the dCDN decides alone, in >>> real time, and for each content request, whether it denies or accepts=20 >>> to ensure delivery, and this even if the dCDN has the capability to=20 >>> deliver the content? >>>>> Are you really meaning that in this case the dCDN may possibly=20 >>>>> response >>> negatively to all requests for content request redirection submitted=20 >>> by the uCDN over the CDNI request routing interface? (i.e. that=20 >>> possibly the uCDN will never be allowed/invited to redirect a content=20 >>> request to the >>> dCDN?) >>>>>=20 >>>>>=20 >>>>> 4) Ray, quoting your mail: "Every routing protocol defines the=20 >>>>> expected >>> behavior of interconnected elements/networks on a technical level,=20 >>> not on a business level." >>>>>=20 >>>>> Again, this is not what I have written, and this is not the idea we >>> want to share. >>>>> I wrote "Every routing protocol has been defined (or at least >>> configured) so far by considering the expected behavior of the=20 >>> interconnected elements/networks." >>>>> That's all. >>>>> I can rephrase this sentence the following way: "we must know what=20 >>>>> we >>> expect to do with a protocol to design it correctly." >>>>> And IHMO this is an evidence; I don't know any other way to proceed. >>>>>=20 >>>>> Besides, let us consider BGP (which is by the way an option=20 >>>>> proposed by >>> some IETF members to implement this CDNI routing interface). >>>>> In IP networks, BGP configurations in IP routers are defined as per=20 >>>>> the >>> business relationships (valley free policy, etc.). >>>>> Of course the business relationships determine the BGP configurations= . >>>>> And of course BGP has been designed so as to allow to configure IP >>> interconnections adequately depending on the corresponding=20 >>> Customer/provider, sibling and peering contractual agreements. >>>>> But this does not mean that BGP "defines the expected behavior of >>> interconnected elements/networks... on a business level." >>>>> Even if we can indeed infer quite accurately the business=20 >>>>> relationships >>> between ISP from the BGP configuration of their IP routers (see CAIDA=20 >>> project), but this is another story. >>>>>=20 >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Yannick Le Lou=E9dec. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >>>>> Envoy=E9 : mardi 10 juillet 2012 15:13 =C0 : LE LOUEDEC Yannick=20 >>>>> RD-CORE; Ben Niven-Jenkins Cc : Pilarski Marcin - Korpo TP;=20 >>>>> cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR: I-D >>>>> Action: draft-lelouedec-cdni-request- >>> routing-00.txt >>>>>=20 >>>>> Hi Yannick, >>>>>=20 >>>>> See comments inline. >>>>>=20 >>>>> In general: IMO the CDNI interfaces should be abstracted from any=20 >>>>> kind >>> of contractual/business agreement that might or might not exist=20 >>> between a dCDN and uCDN. The current drafts seems to assume some=20 >>> particular type of contractual agreement between CDNs that might not al= ways be the case. >>>>>=20 >>>>> Ray >>>>>=20 >>>>> -----Original Message----- >>>>> From: yannick.lelouedec@orange.com >>> [mailto:yannick.lelouedec@orange.com] >>>>> Sent: dinsdag 10 juli 2012 12:01 >>>>> To: Brandenburg, R. (Ray) van; Ben Niven-Jenkins >>>>> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE >>>>> Subject: RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- >>> routing-00.txt >>>>>=20 >>>>> Hi Ray, all, >>>>>=20 >>>>>=20 >>>>> 1) Ray, Quoting your mail: "I don't see why the CDNI Request=20 >>>>> Routing >>> interface should state that a dCDN MUST deliver the content if it has=20 >>> indicated its ability to do so earlier in either a contractual=20 >>> agreement or in the capability interface." >>>>>=20 >>>>> This is not what we have written. >>>>> Let me try to rephrase simply. >>>>>=20 >>>>> A contractual agreement is a contractual agreement. >>>>> It put in writings the respective obligations of the uCDN and of=20 >>>>> the >>> dCDN. >>>>> The uCDN may redirect any content request to the dCDN as long as it=20 >>>>> is >>> in full conformance with the terms of this contractual agreement (the=20 >>> type of the content request is in full conformance, the maximum=20 >>> number of content requests per second is respected, etc.). >>>>> In this case the dCDN may not say "Sorry, but I decide unilaterally=20 >>>>> to >>> refuse this content request". >>>>>=20 >>>>> [RvB]: This is where we disagree. IMHO, the type of behavior you >>> describe (the dCDN not living up to its obligation) should not be=20 >>> enforced by the CDNI Interfaces. If a dCDN does not live up to its=20 >>> contractual agreement, this should be something that is handled on a=20 >>> business level, not on a protocol level. >>>>>=20 >>>>> Why? Because this is the deal, a contractual agreement is a=20 >>>>> contractual >>> agreement! >>>>> Yet the dCDN may say "I do apologize, but at this time I cannot=20 >>>>> handle >>> correctly a certain class of content requests specified in our=20 >>> contractual agreement" (for example the class of the HTTP content=20 >>> requests with token from French end users, because of overload=20 >>> situation, failure, etc.) This is the role of the CDNI routing=20 >>> interface to provide the uCDN with such information. >>>>>=20 >>>>> (And the dCDN may be given a penalty for example if this was agreed=20 >>>>> in >>> the terms of the contractual agreement.) >>>>>=20 >>>>>=20 >>>>> 2) Ray, Quoting your mail: "I understand that in most cases, the >>> contractual agreement might indeed impose this behavior on the dCDN" >>>>>=20 >>>>> Please provide the description of an example where this is not the >>> case. >>>>> Otherwise the IETF CDNI WG shall indeed consider this is ALWAYS the >>> case. >>>>>=20 >>>>> [RvB]: I can't remember ever seeing such a discussion on the WG list. >>> Anyway: one example of a contractual agreement between two CDNs is=20 >>> one in which the uCDN and dCDN have agreed that the dCDN will deliver=20 >>> some content on behalf of a uCDN, but decide on a per-request basis=20 >>> whether it wants to do so (and is for example paid per request). In=20 >>> these cases, the dCDN needs to have the ability to deny delivery on a p= er-request basis. >>>>>=20 >>>>> And this is an important point to be able to progress in the CDNI >>> interfaces' specification works. >>>>>=20 >>>>> If the contractual agreement does not define clearly the=20 >>>>> obligations of >>> the uCDN, it is impossible to dimension adequately the dCDN, neither=20 >>> to define correctly the CDNI contractual agreements between the dCDN=20 >>> and the dCDNs of this dCDN. >>>>> If the contractual agreement does not define clearly the=20 >>>>> obligations of >>> the dCDN, the dCDN may do what it wants... even to put in the trash=20 >>> can any content request it accepted to handle. >>>>>=20 >>>>> [RvB]: Exactly, this is something that needs to be discussed on a >>> business/contractual level and not on a technical level. That is way=20 >>> IMHO the CDNI Interfaces should not make ANY assumptions on what was=20 >>> agreed on a contractual level. >>>>>=20 >>>>> In both situations it is impossible to ensure any quality of=20 >>>>> experience >>> to the end user. >>>>>=20 >>>>>=20 >>>>> 3) Ray, Quoting your mail: "I don't think this type of behavior=20 >>>>> should >>> be imposed by the protocol we're developing here." >>>>>=20 >>>>> I do not sure I understand this sentence. >>>>> Every routing protocol has been defined (or at least configured) so=20 >>>>> far >>> by considering the expected behavior of the interconnected=20 >>> elements/networks. >>>>>=20 >>>>> [RvB]: Every routing protocol defines the expected behavior of >>> interconnected elements/networks on a technical level, not on a=20 >>> business level. Having a dCDN say 'I'm not willing to deliver this=20 >>> content' is perfectly fine from a technical perspective, although it=20 >>> could be problematic from a contractual perspective. >>>>>=20 >>>>> But maybe I will understand if you provide an example on the point >>>>> 2 >>> above. >>>>>=20 >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Yannick Le Lou=E9dec. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >>>>> Envoy=E9 : mardi 10 juillet 2012 09:20 =C0 : Ben Niven-Jenkins; LE=20 >>>>> LOUEDEC Yannick RD-CORE Cc : Pilarski Marcin >>> - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR:=20 >>> I-D >>> Action: draft-lelouedec-cdni-request-routing-00.txt >>>>>=20 >>>>> Hi Yannick, Ben, >>>>>=20 >>>>> I tend to agree with Ben here. When reading the draft, I got the >>> feeling that the draft seems to assume a lot about the relationship=20 >>> between the uCDN and dCDN. For example, I don't see why the CDNI=20 >>> Request Routing interface should state that a dCDN MUST deliver the=20 >>> content if it has indicated its ability to do so earlier in either a=20 >>> contractual agreement or in the capability interface. I understand=20 >>> that in most cases, the contractual agreement might indeed impose=20 >>> this behavior on the dCDN, but I don't think this type of behavior=20 >>> should be imposed by the protocol we're developing here. >>>>>=20 >>>>> It was always my assumption that the Request Routing Interface=20 >>>>> would at >>> least include the option of allowing the uCDN to query the dCDN for=20 >>> every content request whether the dCDN is willing to deliver that=20 >>> particular request. >>>>>=20 >>>>> I will send my full review of the draft later. >>>>>=20 >>>>> Ray >>>>>=20 >>>>> -----Original Message----- >>>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On=20 >>>>> Behalf Of >>> Ben Niven-Jenkins >>>>> Sent: dinsdag 10 juli 2012 7:38 >>>>> To: yannick.lelouedec@orange.com >>>>> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE >>>>> Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- >>> routing-00.txt >>>>>=20 >>>>> Yannick, >>>>>=20 >>>>> Please see inline. >>>>>=20 >>>>> On 9 Jul 2012, at 20:05, wrote: >>>>>=20 >>>>>> Hi Ben, all, >>>>>>=20 >>>>>> Ben, quoting you mail below, "... the downstream CDN could reply=20 >>>>>> with either "here is how to redirect it"", >>>>>>=20 >>>>>> =3D> This is the role of the CDNI DRIS interface to provide the uCDN >>> with this information, and we target to make its specification public=20 >>> before Vancouver meeting so that everyone may read it before the=20 >>> meeting and get full knowledge of our proposal about this part of=20 >>> CDNI request routing. >>>>>>=20 >>>>>> Ben, quoting you mail below, "... or "no I can't/won't take that >>> content delivery right now", reasons may include the uCDN has=20 >>> requested a delivery of a protocol the dCDN does not support (possibly = in error). >>>>>>=20 >>>>>> =3D> This is the role of the CDNI logging interface to provide the=20 >>>>>> uCDN >>> with this information. >>>>> I agree this information should be logged but the Request Routing >>> interface (what you call the DRIS) also needs to be able to indicate=20 >>> a failure. >>>>>=20 >>>>> Otherwise the uCDN will 'blindly' redirect the the dCDN and the >>> delivery will fail leading to poor end user experience. >>>>>=20 >>>>>> Ben, quoting you mail below, "... or "no I can't/won't take that >>> content delivery right now", reasons may include ... the dCDN has no=20 >>> capacity right now etc." >>>>>>=20 >>>>>> =3D> This is the role of the CDNI routing interface to provide the=20 >>>>>> uCDN >>> with this information. >>>>> It is the role of the CDN capability/routing interface to advertise >>> broad capabilities etc not to give extremely fine grained real-time=20 >>> information on exactly the state of the dCDN. >>>>>=20 >>>>> Even if the capability/routing interface is real-time there are=20 >>>>> likely >>> to still be race conditions where we need the dCDN to be about to=20 >>> indicate a failure to accept a redirect through the request=20 >>> routing/DRIS interface >>>>>=20 >>>>>> So we may conclude we are in line basically, which is a good point. >>>>>> We just aimed at checking there was a common understanding on this >>> point. >>>>>>=20 >>>>>> The key point for us here is that we don't want this sentence >>> extracted from draft-ietf-cdni-problem-statement be interpreted as: ".= =20 >>> and the dCDN MUST accept the content request except when it has not=20 >>> the "ability" to do so." >>>>> Why not? IMO that is a valid scenario for some use cases. >>>>>=20 >>>>>> The fact that the dCDN is temporary unable to handle content=20 >>>>>> request >>> correctly is not a valid reason for the dCDN to be discharged of its=20 >>> obligations to the uCDN. >>>>>> The contract set between the uCDN and the dCDN remains valid=20 >>>>>> anyway, >>> and the obligations of the dCDN as well. >>>>> Correct, but that contract may not be the same for all uCDNs &=20 >>>>> dCDNs, >>> for example a uCDN may not have a guarantee that a dCDN can handle=20 >>> everything it is requested to handle but the contract may only be=20 >>> that the dCDN guarantees to handle up to a certain volume of traffic. >>>>>=20 >>>>>> The dCDN must announce to the uCDN that it is temporary unable, as >>> soon as possible, via the CDNI routing interface. >>>>>> And the uCDN must take this information into account in its CDN >>> selection process as soon as possible. >>>>>> Then if the uCDN decides to continue to redirect content requests=20 >>>>>> to >>> the dCDN, the uCDN MAY perfectly do it, but the uCDN knows these=20 >>> content requests will be lost. >>>>> What happens in the period between the dCDN being unable to handle >>> requests and the time it takes to advertise that to the uCDN and for=20 >>> the uCDN to process & incorporate that new knowledge? Are requests=20 >>> blindly forwarded to the dCDN which is unable to handle them leading=20 >>> to poor user experience? >>>>>=20 >>>>>> We could even imagine the situation where the uCDN continues to do=20 >>>>>> it >>> intentionally, because it has no better option and the content=20 >>> request will be lost anyway. For example in the case where neither=20 >>> the uCDN nor the other downstream CDNs of the uCDN cannot manage=20 >>> correctly the content request, the uCDN could do it intentionally so=20 >>> as to be able to clearly prove (with CDNI logging information) that=20 >>> it is the dCDN, not the uCDN, who is at fault. >>>>>> But, of course, if there are alternative backup options, the=20 >>>>>> normal >>> reaction of the uCDN is to stop as soon as possible to redirect=20 >>> content requests to the dCDN when the uCDN knows that the dCDN is=20 >>> unable to handle them correctly. >>>>>>=20 >>>>>> So, to be clear, we would prefer the sentence to be understood as: >>>>>> ". and the dCDN MUST accept the content request. >>>>>> And if it cannot handle correctly the redirected content request=20 >>>>>> it >>> receives, the content request is lost. >>>>> What about scenarios where the uCDN has a choice of dCDNs (e.g. two >>> national-wide CDNs offering services at different costs), the uCDN=20 >>> may elect to query both dCDNs and decide based on their responses=20 >>> which one to choose. If the dCDN is unable to satisfy the request the=20 >>> uCDN needs to know that so that it can fallback to the (more=20 >>> expensive in this example) dCDN. >>>>>=20 >>>>>> For example the dCDN generates a response to the content request=20 >>>>>> with >>> an error message, or no response at all. And in parallel the CDNI=20 >>> logging interface may be used to exchange logs corresponding to this pr= oblem. >>> Anyway the dCDN MAY NOT redirect that content request back towards=20 >>> the uCDN." >>>>>>=20 >>>>>> Exactly as in IP networks: IP packets are not sent back towards=20 >>>>>> the >>> origin by a downstream router under failure or congestion. >>>>> In a routed IP network, there is often a small packet loss while=20 >>>>> the >>> network re-converges, by enabling the dCDN to refuse a redirection at=20 >>> CDNI Request Routing/DRIS query time we can reduce that window by=20 >>> giving the uCDN the option to take an alternative action (e.g. try=20 >>> another dCDN) while the routing/capability information re-converges. >>>>>=20 >>>>>> In both networks (IP and CDN), the reason is the same. >>>>>> If the dCDN redirects back a content request to the uCDN, this >>> generates a loop. >>>>> Loop avoidance is a separate issue IMO to whether we should allow a >>> dCDN to be able to communicate "I am unable/unwilling to take that=20 >>> content delivery at this time". >>>>>=20 >>>>> Regards >>>>> Ben >>>>>=20 >>>>>> To manage this would introduce a very high complexity. >>>>>> And this would be just to try to save the content requests=20 >>>>>> redirected >>> by the uCDN to the dCDN in the timeslot between the time the dCDN=20 >>> gets down and the time the uCDN takes this failure into account in=20 >>> its CDN selection process. >>>>>> It is much better to try to reduce this timeslot as much as=20 >>>>>> possible, >>> with routing optimizations (we will propose as soon as possible). >>>>>> Rather than introducing additional complexities (to manage=20 >>>>>> redirection >>> to the uCDN) in the framework. >>>>>>=20 >>>>>>=20 >>>>>> By the way, as you know, the IESG has just approved today the=20 >>>>>> 'Content >>> Distribution Network Interconnection (CDNI) Problem Statement' draft=20 >>> as informational RFC. This is a good point. >>>>>> And, as you may see in the draft "CDNI request routing", we do not >>> propose to modify this problem statement draft. >>>>>> We want know to focus now on getting the specifications of all=20 >>>>>> CDNI >>> interfaces ready as soon as possible. >>>>>>=20 >>>>>> Best regards, >>>>>>=20 >>>>>> Yannick Le Lou=E9dec. >>>>>>=20 >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la=20 >>>>>> part de Ben Niven-Jenkins Envoy=E9 : lundi 9 juillet 2012 20:41 =C0 = : >>>>>> BERTRAND Gilles RD-CORE Cc : cdni@ietf.org; Pilarski Marcin -=20 >>>>>> Korpo TP; MARREC Anne RD-CORE Objet : Re: [CDNi] TR: I-D Action: >>>>>> draft-lelouedec-cdni-request-routing-00.txt >>>>>>=20 >>>>>> Colleagues, >>>>>>=20 >>>>>> I started reading draft-lelouedec-cdni-request-routing-00 and this >>> text caught my eye: >>>>>>=20 >>>>>> Quoting [I-D.ietf-cdni-problem-statement ], "The CDNI Request=20 >>>>>> Routing interface enables a Request Routing function in an=20 >>>>>> upstream CDN to query a Request Routing function in a downstream=20 >>>>>> CDN to determine if the downstream CDN is able (and willing) to=20 >>>>>> accept the delegated content request". >>>>>>=20 >>>>>> The "ability" and the "willingness" of the downstream CDN to=20 >>>>>> accept the delegated content request match two fully different=20 >>>>>> processes in CDN interconnection. And the description of both=20 >>>>>> these processes should be reviewed and clarified for the following = reasons: >>>>>>=20 >>>>>> o Regarding the former process, i.e. related to the "ability" >>>>>> ("enables a Request Routing function in an upstream CDN to=20 >>>>>> query >>> a >>>>>> Request Routing function in a downstream CDN to determine if the >>>>>> downstream CDN is able (...) to accept the delegated content >>>>>> request"), a routing protocol is used to achieve such a process, >>>>>> called routing process, in many other technologies and networks >>>>>> (IP, ATM, etc.). In all these technologies, it is the downstream >>>>>> entity that provides routing information to the upstream entity. >>>>>> The same approach should be applied to CDN interconnection. The >>>>>> reverse approach ("uCDN queries it downstream CDNs dCDN 1,=20 >>>>>> dCDN >>> 2, >>>>>> dCDN 3, and then it selects one of them based on their >>> responses") >>>>>> would suffer from latency, signaling overhead and/or lack of >>>>>> reactivity to events that impact the ability of the downstream >>>>>> CDNs to accept delegated content requests. >>>>>>=20 >>>>>> o Regarding the latter process, i.e. related to the "willingness" >>>>>> ("enables a Request Routing function in an upstream CDN to=20 >>>>>> query >>> a >>>>>> Request Routing function in a downstream CDN to determine if the >>>>>> downstream CDN (...) is willing (...)to accept the delegated >>>>>> content request"), it is to be noted that the relationship >>> between >>>>>> a uCDN and a dCDN is always in the frame of a contractual >>>>>> agreement between the administrative entity owning the uCDN, >>>>>> acting as the customer, and the administrative entity owning the >>>>>> dCDN, acting as the service provider. Therefore, consider a case >>>>>> where >>>>>>=20 >>>>>> * the uCDN has a content request to redirect which is in full >>>>>> conformance with the terms of this contractual agreement,=20 >>>>>> and >>>>>>=20 >>>>>> * the uCDN has selected this dCDN. >>>>>>=20 >>>>>> As the uCDN knows, thanks to the routing information exchanged >>> via >>>>>> the aforementioned routing process, that the dCDN is able to >>>>>> accept this content request, the uCDN MAY redirect the content >>>>>> request to the dCDN and the dCDN MUST accept the content request. >>>>>> Exchanging over the CDNI Request Routing interface information >>>>>> about the "willingness" of the dCDN to accept the content request >>>>>> is not relevant. >>>>>>=20 >>>>>> I think you might be over thinking what we wrote in the problem >>> statement. >>>>>>=20 >>>>>> What was in the problem statement was meant to convey that an=20 >>>>>> upstream >>> CDN could make a request to a downstream CDN to say "how do I=20 >>> redirect this request to you" and the downstream CDN could reply with=20 >>> either "her is how to redirect it", or "no I can't/won't take that=20 >>> content delivery right now", reasons may include the uCDN has=20 >>> requested a delivery of a protocol the dCDN does not support=20 >>> (possibly in error) or the dCDN has no capacity right now etc. >>>>>>=20 >>>>>> Ben >>>>>>=20 >>>>>> On 9 Jul 2012, at 18:00, wrote: >>>>>>=20 >>>>>>> Hi everyone, >>>>>>>=20 >>>>>>> We have just submitted the draft below. We are convinced that it=20 >>>>>>> will >>> help the WG to progress on the CDNI routing issues. >>>>>>>=20 >>>>>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-0 >>>>>>> 0 >>>>>>>=20 >>>>>>> Any feedback is very welcome. >>>>>>>=20 >>>>>>> Best regards, >>>>>>>=20 >>>>>>> Gilles >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Message d'origine----- >>>>>>> De : i-d-announce-bounces@ietf.org=20 >>>>>>> [mailto:i-d-announce-bounces@ietf.org] De la part de=20 >>>>>>> internet-drafts@ietf.org Envoy=E9 : lundi 9 juillet 2012 18:55 =C0 = : >>>>>>> i-d-announce@ietf.org Objet : I-D Action: >>>>>>> draft-lelouedec-cdni-request-routing-00.txt >>>>>>>=20 >>>>>>>=20 >>>>>>> A New Internet-Draft is available from the on-line=20 >>>>>>> Internet-Drafts >>> directories. >>>>>>>=20 >>>>>>>=20 >>>>>>> Title : CDNI Request Routing >>>>>>> Author(s) : Yannick Le Louedec >>>>>>> Anne Marrec >>>>>>> Gilles Bertrand >>>>>>> Marcin Pilarski >>>>>>> Filename : draft-lelouedec-cdni-request-routing-00.txt >>>>>>> Pages : 30 >>>>>>> Date : 2012-07-09 >>>>>>>=20 >>>>>>> Abstract: >>>>>>> The present document proposes to clarify the CDNI Request Routing=20 >>>>>>> interface introduced in [I-D.ietf-cdni-framework] and >>>>>>> [I-D.ietf-cdni- problem-statement], as well as related terminology. >>>>>>>=20 >>>>>>> In particular the present document proposes to split the CDNI=20 >>>>>>> Request Routing interface into two separate interfaces with=20 >>>>>>> clearer roles, named respectively CDNI Routing interface and=20 >>>>>>> CDNI Downstream Resource Identifier Signaling interface (CDNI DRIS = interface). >>>>>>>=20 >>>>>>> This part of the CDN interconnection framework the IETF has been=20 >>>>>>> referring to so far with the term "CDNI Request Routing" is just=20 >>>>>>> another routing, signaling and forwarding problem in a long=20 >>>>>>> series of the telecommunication history. For example, one can=20 >>>>>>> draw a direct analogy between the IP/MPLS-TE framework and the=20 >>>>>>> CDN interconnection framework. >>>>>>>=20 >>>>>>> In addition, this document recommends that the specification of=20 >>>>>>> ALL CDN interconnection interfaces in the scope of the CDNI IETF=20 >>>>>>> WG relies on the equivalent concept to IP prefix for CDN=20 >>>>>>> interconnection, named 'contentRequestScope'. This highly useful=20 >>>>>>> and powerful concept SHALL be used to simplify the specification=20 >>>>>>> of ALL CDN interconnection interfaces, as well as to ensure=20 >>>>>>> performance and scalability in CDN interconnection. >>>>>>>=20 >>>>>>> All these proposals can be smoothly integrated in the WG drafts,=20 >>>>>>> especially [I-D.ietf-cdni-framework] and=20 >>>>>>> [I-D.ietf-cdni-requirements], as they essentially propose >>>>>>> (useful) clarifications of the existing framework. >>>>>>>=20 >>>>>>>=20 >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-rou >>>>>>> ting >>>>>>>=20 >>>>>>> There's also a htmlized version available at: >>>>>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-0 >>>>>>> 0 >>>>>>>=20 >>>>>>>=20 >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> 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=20 >>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>>=20 >>>>>>> _________________________________________________________________ >>>>>>> ____ ____________________________________________________ >>>>>>>=20 >>>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>>> informations confidentielles ou privilegiees et ne doivent donc=20 >>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 >>>>>>> avez recu ce message par erreur, veuillez le signaler a=20 >>>>>>> l'expediteur et le detruire ainsi >>> que les pieces jointes. Les messages electroniques etant susceptibles=20 >>> d'alteration, France Telecom - Orange decline toute responsabilite si=20 >>> ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>=20 >>>>>>> This message and its attachments may contain confidential or=20 >>>>>>> privileged information that may be protected by law; they should=20 >>>>>>> not >>> be distributed, used or copied without authorisation. >>>>>>> If you have received this email in error, please notify the=20 >>>>>>> sender >>> and delete this message and its attachments. >>>>>>> As emails may be altered, France Telecom - Orange is not liable=20 >>>>>>> for >>> messages that have been modified, changed or falsified. >>>>>>> Thank you. >>>>>>>=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 >>>>>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>>>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le=20 >>>>>> detruire ainsi >>> que les pieces jointes. Les messages electroniques etant susceptibles=20 >>> d'alteration, France Telecom - Orange decline toute responsabilite si=20 >>> ce message a ete altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or=20 >>>>>> privileged information that may be protected by law; they should=20 >>>>>> not >>> be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the sender=20 >>>>>> and >>> delete this message and its attachments. >>>>>> As emails may be altered, France Telecom - Orange is not liable=20 >>>>>> for >>> messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>> _______________________________________________ >>>>> CDNi mailing list >>>>> CDNi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>> This e-mail and its contents are subject to the DISCLAIMER at >>> http://www.tno.nl/emaildisclaimer >>>>>=20 >>>>>=20 >>>>>=20 >>> _____________________________________________________________________ >>> _ ____ _______________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >>> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 >>> que les pieces jointes. Les messages electroniques etant susceptibles=20 >>> d'alteration, France Telecom - Orange decline toute responsabilite si=20 >>> ce message a ete altere, deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or=20 >>>>> privileged >>> information that may be protected by law; they should not be=20 >>> distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender=20 >>>>> and >>> delete this message and its attachments. >>>>> As emails may be altered, France Telecom - Orange is not liable for >>> messages that have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>>>=20 >>>>>=20 >>> _____________________________________________________________________ >>> _ ____ _______________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc >>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 >>>>> avez >>> recu ce message par erreur, veuillez le signaler >>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les >>> messages electroniques etant susceptibles d'alteration, >>>>> France Telecom - Orange decline toute responsabilite si ce message=20 >>>>> a >>> ete altere, deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or=20 >>>>> privileged >>> information that may be protected by law; >>>>> they should not be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender=20 >>>>> and >>> delete this message and its attachments. >>>>> As emails may be altered, France Telecom - Orange is not liable for >>> messages that have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >>=20 >> ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for mess= ages that have been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> 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 swainner@cisco.com Wed Jul 25 08:04:56 2012 Return-Path: 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 5690A21F84E2 for ; Wed, 25 Jul 2012 08:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=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 C7XpwlfCrVvQ for ; Wed, 25 Jul 2012 08:04:53 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8D19D21F846A for ; Wed, 25 Jul 2012 08:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=50287; q=dns/txt; s=iport; t=1343228692; x=1344438292; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=EXAb/9H5J1jQMMYPYBqp7ZJ3UBzrmZk/J+BdMuHBKfk=; b=eVdABM+pCFm3nz2DJsExLNXGCV+w/alccqhbMlM5Ccsqj64QrRIClyo1 ep4qvUJc+PR6ynj3SnLWgi2jsKHM06wZBdJGL040D6c6aqVGX5e4rgEqp yrZfTeYtCWLz1uqyAvJT/oHETsE1kPNmiv6rFpWT6dvQuQQtaz8IAr2Hf U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoGAIMKEFCtJV2Y/2dsb2JhbABFuHNwgQeCIAEBAQQBAQEPAQcBDAsBBQ8lAgQEAg0ECxEEAQEBCQwKCAcJAwIBAgEVHwkIEwYCAQEFGYdrC5p/kQWPSYtNAggQgzKDKAOVSYEUiXmDGoFmgnuBOgka X-IronPort-AV: E=Sophos;i="4.77,653,1336348800"; d="scan'208";a="105230935" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 25 Jul 2012 15:04:50 +0000 Received: from rtp-swainner-89110.cisco.com (rtp-swainner-89110.cisco.com [10.116.109.203]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6PF4oSE011254 for ; Wed, 25 Jul 2012 15:04:50 GMT Message-ID: <50100B11.7090802@cisco.com> Date: Wed, 25 Jul 2012 11:04:49 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: cdni@ietf.org References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> <2040_1341930789_4FFC3D24_2040_2504_1_b86bff40-ae68-40c0-b8e5-060f51be6864@PEXCVZYH02.corporate.adroot.infra.ftgroup> <3A7EA7EE-F8D4-4094-83F2-12CD3826B662@tno.nl> <5004079D.4000406@cisco.com> <29661_1343216353_500FDAE1_29661_643_1_2AC63C9F27AF8446B0C064C50FC0A89305D959@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AF54F9B-B4FF-4043-A9DE-36C0417F9EAC@cisco.com> <0B55392F-16FD-4967-9A9D-91A7D4CE1A30@cisco.com> In-Reply-To: <0B55392F-16FD-4967-9A9D-91A7D4CE1A30@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 15:04:56 -0000 I agree with Ray that we should support *A* and *B* modes. The *C* mode is a special case of *B* where the uCDN has elected to use *B* in parallel with multiple dCDN. This is an internal implementation of the uCDN. I think we already agreed to support Iterative and Recursive modes. My point about the differences in *A* and *B* is that you need information exchange between dCDN and uCDN. You can choose to make that information exchange fast in the capabilities and footprint announcement which mitigates the value of *B* mode (the uCDN queries the dCDN before referring the client). The dCDN will need to quickly propagate information to the uCDN to avoid losing content requests when random things don't work (overload, cache node failure, routing request error, whatever, ...). The disadvantage is the uCDN must be responsive to ALL the dCDN updates coming in based on events in each dCDN. The operator will end up dampening these inputs to avoid thrashing. You can choose to make that information exchange slow in the capabilities and footprint advertisements and fast in the routing request process (per content request referral). This negates the value of *A* mode (the uCDN blindly refers the client the dCDN). The dCDN will need to quickly respond to inquiries of the uCDN. A key trade-off will be particularly noticeable where the uCDN/dCDN is supporting HAS a per-chunk request. It simply doesn't scale unless the uCDN rewrites the manifest such that the remainder of the "session requests" are referred to the dCDN and all subsequent chunks are retrieved directly from the dCDN without having to refer back to the uCDN. If the retrieval is a large-object retrieval, then *B* would be sufficient. Scott On 7/25/12 9:20 AM, Francois Le Faucheur (flefauch) wrote: > Hi Ray, > > Good input. Thanks. > One point below: > > On 25 Jul 2012, at 15:07, Brandenburg, R. (Ray) van wrote: > >> Hi all, >> >> Francois, thanks for clarifying this discussion, very helpful. >> >> I tend to agree with your assessment of the various options. Personally, I would be opposed to a CDNI specification that does not include *B* at least as an option, since to me *A* is not suited for 'premium'-content cases where you want to minimize the chances of content not being delivered. In these cases, scalability might be less of a concern, especially for CDNs that do internal request routing for each request anyway. In addition, I think the CDNI interfaces should at least support a scenario where the dCDN, whatever it advertises, should always have the option of turning down a content delivery request by a uCDN, whether it is for reasons of overload, technical difficulty or simply business reasons. If a dCDN does this too often for a uCDNs liking, than that uCDN can simply decide to no longer do business with that dCDN by not choosing it again for future redirects. >> >> Finally, I think it should be up to the uCDN to decide how it chooses a dCDN, whether it is based on capability and footprint information or simply by polling different dCDNs. If that polling is performed by the same mechanism that is used by *B*, I don't see any reason not to support that. > You bring up a very good point here. I would probably also agree that "If that polling is performed by the same mechanism that is used by *B*, I don't see any reason not to support that". The thing is that we don't have much time/cycles to spend to make sure the "polling" provides all the needed info & knobs, and that all the error cases and scenario combinations are fully addressed. But I take your point that, a polling interface developed for *B* could be used by uCDN to achieve *C*. > > Thanks > > Francois > >> Best regards, >> >> Ray >> >> >> >> >> >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch) >> Sent: woensdag 25 juli 2012 14:36 >> To: >> Cc: cdni@ietf.org >> Subject: Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.txt >> >> All, >> >> To help the discussion, we may need to distinguish three (main) modes: >> >> *A* the uCDN uses the Footprint&Cap information (advertised by dCDN) to select a dCDN. The uCDN redirects to the selected dCDN and considers that he is done with request routing. >> >> *B* the uCDN uses the Footprint&Cap information (advertised by dCDN) to select a dCDN candidate. The uCDN queries the dCDN before redirecting. >> Querying dCDN optionally allows the dCDN to provide to uCDN the final redirection information so the the enduser experiences a single redirect. >> Querying dCDN optionally allows the uCDN to pick an alternate dCDN if the initially selected dCDN cannot handle the request. >> >> *C* the uCDN queries multiple dCDNs on a per-request basis and selects dCDN based on their responses. In other words, the Footprint&Cap advertisement is performed via on-demand per-request queries. >> >> >> I think: >> * Scott pointed out that fundamentatly both *A* and *B* have to deal with (typically transient) situations where uCDN thinks dCDN can take a request and dCDN actually cannot handle it. And pointed out that with *A* the transient period is dictated by the Footprint&Cap advertisement "update speed" while with *B* it is not. >> * Allan was saying *A* is all he needs and *B* is extra complexity that he doesn't need. >> * Gilles and lelouedec-cdni-request-routing were saying *C* is bad. >> >> My impression is that there is violent agreement that *A* is to be supported. I think Allan and Gilles message indicate so. I personally support that. I think many people have been discussing that approach. If someone feels this is NOT to be supported by CDNI, do let us know. >> >> I think Gilles message below is primarily arguing against *C*. I personally agree that this need not be supported in our initial deliverables. Are there people arguing this approach is to be supported in the initial deliverables? >> >> Regarding *B*, I personally see it as quite useful and worth supporting in Phase 1 (possibly as an option). >> Regarding Allan's points: >> * I agree there is some "scalability" argument (i.e. state+wait-for-dCDN-response) but it amounts to a web-services call out per request and buys you reliability of request routing, so I see that as a trade-off that some CDNs should be able to exercise. >> >> * I don't buy the latency argument because you end up with 2 RTTs in both *A* and *B* (in normal situations where dCDN can handle the request) (i.e. user-->uCDN, uCDN-->user, user-->dCDN, dCDN-->user versus user-->uCDN, uCDN-->dCDN, dCDN-->uCDN, uCDN-->user) and in the transient cases where dCDN cannot handle the request *B* can do as well as *A* (drop the request) or has the option to differently i.e. re-redirect at the cost of an extra RTT. >> * I don't buy the "loop free mechanism" argument. In *B*, it is easy to implement a loop detection and even loop prevention (if you want). In *A*, you have no loop prevention (other than the inherent HTTP/DNS max redirect/max CNAMEs) Other opinions on *B* are sought. >> >> >> Cheers >> >> Francois >> >> >> On 25 Jul 2012, at 13:39, wrote: >> >>> Hi everyone, >>> >>> I fully agree with Allan's comments. Putting aside the vocabulary ('recursive model' etc), Allan's comment are consistent with the messages that http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 tries to convey. >>> >>> " o Regarding the former process, i.e. related to the "ability" >>> ("enables a Request Routing function in an upstream CDN to query a >>> Request Routing function in a downstream CDN to determine if the >>> downstream CDN is able (...) to accept the delegated content >>> request"), a routing protocol is used to achieve such a process, >>> called routing process, in many other technologies and networks >>> (IP, ATM, etc.). In all these technologies, it is the downstream >>> entity that provides routing information to the upstream entity. >>> The same approach should be applied to CDN interconnection. The >>> reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2, >>> dCDN 3, and then it selects one of them based on their responses") >>> would suffer from latency, signaling overhead and/or lack of >>> reactivity to events that impact the ability of the downstream >>> CDNs to accept delegated content requests." >>> >>> Best regards, >>> -- >>> Gilles >>> >>> >>> -----Message d'origine----- >>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part >>> de GUILLOU, Allan Envoyé : mercredi 25 juillet 2012 12:23 À : Scott >>> Wainner; cdni@ietf.org Objet : Re: [CDNi] TR: I-D Action: >>> draft-lelouedec-cdni-request-routing-00.txt >>> >>> Hi, >>> >>> With a "recusive model" as you ask if I understand, you expect the dCDN to send like an "ack" for each request, and if not the uCDN will try to find the second best dCDN and do the same thing. >>> >>> I think that this model may add complexity and may cause some scalability problem. You will have to implement timers between request and ack, retransmission mechanism to make sure that request has not been lost, loop free mechanism, And all this may add latency on all requests and performances problems. >>> >>> In the iterative model, if the dCDN is not able to handle the request, this request will be lost. It is the same thing in IP network today we do not ask the routing protocol to change when there is saturation somewhere. It is the responsibility of each ISP to choose another route to join this destination if he want to keep a good quality of service. If a dCDN is overloaded, it will stop announcing part of its footprint or uCDN may apply some policy to force choosing another dCDN. >>> >>> It is right that this second model may not in case of dCDN saturation have the best reactivity, but it is exactly the same thing on the internet today. We can imagine that a poor dCDN which have saturation will be "black listed" by all the uCDN and the regulation will be done like this. >>> I think recursive model will add complexity all the time for a gain witch is not in my opinion so important and that will not be seen so often. >>> >>> Allan >>> >>>> -----Message d'origine----- >>>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part >>>> de Scott Wainner Envoyé : lundi 16 juillet 2012 14:23 À : >>>> cdni@ietf.org Objet : Re: [CDNi] TR: I-D Action: >>>> draft-lelouedec-cdni-request-routing- >>>> 00.txt >>>> >>>> On 7/10/12 11:39 AM, Brandenburg, R. (Ray) van wrote: >>>>> Hi Yannick, >>>>> >>>>> We seem to be misunderstanding each other. Maybe this will help >>>>> clarify >>>> my point: >>>>>> Let me try to fully understand your point: >>>>>> Are you really meaning that in this case the dCDN has in reality >>>> absolutely no obligation with regards to the uCDN? >>>>>> Are you really meaning that in this case the dCDN decides alone, in >>>> real time, and for each content request, whether it denies or accepts >>>> to ensure delivery? >>>>> What I mean is that I would like to have a RR Interface at least >>>>> support >>>> a model where for every content request the uCDN asks the dCDN >>>> whether it wants to deliver that particular content item (I believe >>>> you call this a PULL approach). And I would like to allow the dCDN to be able to say 'No' >>>> on this request (whether it is for purposes or failure, overload, or >>>> any other reason). >>>>>> Are you really meaning that in this case the dCDN decides alone, in >>>> real time, and for each content request, whether it denies or accepts >>>> to ensure delivery, and this even if the dCDN has the capability to >>>> deliver the content? >>>>> Yes. >>>> I think we have to delineate between the iterative and recursive model. >>>> >>>> The recursive model assumes that the client request to the uCDN will >>>> be recursive and the CDN-I RR interface will be used to provide an >>>> answer for each client request. The choice to initiate the recursion >>>> would be determined by the footprint / capabilities. The ability of >>>> the dCDN to execute the specific request would provide immediate >>>> feedback to the uCDN. A dCDN that continues to advertise the >>>> footprint / capability, but frequently or continually rejects the >>>> request via CDN-I RR would be a poor candidate. The opportunity now >>>> arises where the uCDN may elect to choose an alternate dCDN because >>>> its preferred dCDN (according to footprint / capabilities) is 'under-performing'. >>>> >>>> The iterative model, the uCDN blindly redirects the client to the >>>> dCDN based on the footprint / capabilities. What the dCDN does with >>>> the request is somewhat transparent to the uCDN. With the exception >>>> of the CDN-I logging, the uCDN assumes the dCDN is properly handling >>>> the requests that were delegated to the dCDN. If you are trying to >>>> 'tighten' up the case of blind rejections, then the frequency of the >>>> footprint / capabilities advertisements would have to be accelerated. >>>> For the case where the dCDN repeatedly sees requests from the uCDN >>>> that the dCDN can't handle, it should retract its footprint / >>>> capabilities advertisement. Failing to do so would continually >>>> black-hole routing requests which would be indicated in the logging information. >>>> >>>> Either way, you need a feedback loop to avoid dumping routing requests. >>>> >>>> With any feedback loop (recursive routing request or footprint / >>>> capabilities advertisement), you have to be careful about rapid >>>> oscillations and dampening the responses. >>>> >>>> Scott >>>>>> Are you really meaning that in this case the dCDN may possibly >>>>>> response >>>> negatively to all requests for content request redirection submitted >>>> by the uCDN over the CDNI request routing interface? (i.e. that >>>> possibly the uCDN will never be allowed/invited to redirect a content >>>> request to the >>>> dCDN?) >>>>> Yes. Any negative effect this may have on the business relationship >>>> between uCDN and dCDN should be handled on the business level. >>>>> Ray >>>>> >>>>> >>>>> On Jul 10, 2012, at 4:33 PM, >>>>> wrote: >>>>> >>>>>> Hi Ray, >>>>>> >>>>>> >>>>>> 1) Ray, quoting your mail: "The current drafts seems to assume some >>>> particular type of contractual agreement between CDNs that might not >>>> always be the case." >>>>>> Please quote the draft. >>>>>> Please let us know exactly to which sentence(s) of the draft you >>>>>> are >>>> referring to. >>>>>> Otherwise it is hard to discuss and comment on your email. >>>>>> >>>>>> >>>>>> 2) Ray, Quoting your mail: "If a dCDN does not live up to its >>>> contractual agreement, this should be something that is handled on a >>>> business level, not on a protocol level." >>>>>> Maybe there is a deep misunderstanding. >>>>>> So I will try to be clear again. >>>>>> We do not propose the CDNI routing interface to be used by the dCDN >>>>>> to >>>> send a message saying "Sorry, but I decide unilaterally to refuse >>>> this content request". >>>>>> We do not propose the CDNI routing interface to be used to handle >>>>>> any >>>> aspect relating to a dCDN deciding unilaterally to stop living up to >>>> its contractual agreement. >>>>>> Please let us know where you saw such an idea in this IETF draft >>>>>> "CDNI >>>> request routing". >>>>>> The only role of the CDNI routing interface is to be used to >>>>>> advertise >>>> CDNI routing information from the downstream CDN to the upstream CDN. >>>>>> And this is the description given in this IETF draft. >>>>>> >>>>>> >>>>>> 3) Ray, quoting your mail: "one example of a contractual agreement >>>> between two CDNs is one in which the uCDN and dCDN have agreed that >>>> the dCDN will deliver some content on behalf of a uCDN, but decide on >>>> a per- request basis whether it wants to do so (and is for example >>>> paid per request). In these cases, the dCDN needs to have the ability >>>> to deny delivery on a per-request basis." >>>>>> Let me try to fully understand your point: >>>>>> Are you really meaning that in this case the dCDN has in reality >>>> absolutely no obligation with regards to the uCDN? >>>>>> Are you really meaning that in this case the dCDN decides alone, in >>>> real time, and for each content request, whether it denies or accepts >>>> to ensure delivery? >>>>>> Are you really meaning that in this case the dCDN decides alone, in >>>> real time, and for each content request, whether it denies or accepts >>>> to ensure delivery, and this even if the dCDN has the capability to >>>> deliver the content? >>>>>> Are you really meaning that in this case the dCDN may possibly >>>>>> response >>>> negatively to all requests for content request redirection submitted >>>> by the uCDN over the CDNI request routing interface? (i.e. that >>>> possibly the uCDN will never be allowed/invited to redirect a content >>>> request to the >>>> dCDN?) >>>>>> >>>>>> 4) Ray, quoting your mail: "Every routing protocol defines the >>>>>> expected >>>> behavior of interconnected elements/networks on a technical level, >>>> not on a business level." >>>>>> Again, this is not what I have written, and this is not the idea we >>>> want to share. >>>>>> I wrote "Every routing protocol has been defined (or at least >>>> configured) so far by considering the expected behavior of the >>>> interconnected elements/networks." >>>>>> That's all. >>>>>> I can rephrase this sentence the following way: "we must know what >>>>>> we >>>> expect to do with a protocol to design it correctly." >>>>>> And IHMO this is an evidence; I don't know any other way to proceed. >>>>>> >>>>>> Besides, let us consider BGP (which is by the way an option >>>>>> proposed by >>>> some IETF members to implement this CDNI routing interface). >>>>>> In IP networks, BGP configurations in IP routers are defined as per >>>>>> the >>>> business relationships (valley free policy, etc.). >>>>>> Of course the business relationships determine the BGP configurations. >>>>>> And of course BGP has been designed so as to allow to configure IP >>>> interconnections adequately depending on the corresponding >>>> Customer/provider, sibling and peering contractual agreements. >>>>>> But this does not mean that BGP "defines the expected behavior of >>>> interconnected elements/networks... on a business level." >>>>>> Even if we can indeed infer quite accurately the business >>>>>> relationships >>>> between ISP from the BGP configuration of their IP routers (see CAIDA >>>> project), but this is another story. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Yannick Le Louédec. >>>>>> >>>>>> >>>>>> >>>>>> -----Message d'origine----- >>>>>> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >>>>>> Envoyé : mardi 10 juillet 2012 15:13 À : LE LOUEDEC Yannick >>>>>> RD-CORE; Ben Niven-Jenkins Cc : Pilarski Marcin - Korpo TP; >>>>>> cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR: I-D >>>>>> Action: draft-lelouedec-cdni-request- >>>> routing-00.txt >>>>>> Hi Yannick, >>>>>> >>>>>> See comments inline. >>>>>> >>>>>> In general: IMO the CDNI interfaces should be abstracted from any >>>>>> kind >>>> of contractual/business agreement that might or might not exist >>>> between a dCDN and uCDN. The current drafts seems to assume some >>>> particular type of contractual agreement between CDNs that might not always be the case. >>>>>> Ray >>>>>> >>>>>> -----Original Message----- >>>>>> From: yannick.lelouedec@orange.com >>>> [mailto:yannick.lelouedec@orange.com] >>>>>> Sent: dinsdag 10 juli 2012 12:01 >>>>>> To: Brandenburg, R. (Ray) van; Ben Niven-Jenkins >>>>>> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE >>>>>> Subject: RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- >>>> routing-00.txt >>>>>> Hi Ray, all, >>>>>> >>>>>> >>>>>> 1) Ray, Quoting your mail: "I don't see why the CDNI Request >>>>>> Routing >>>> interface should state that a dCDN MUST deliver the content if it has >>>> indicated its ability to do so earlier in either a contractual >>>> agreement or in the capability interface." >>>>>> This is not what we have written. >>>>>> Let me try to rephrase simply. >>>>>> >>>>>> A contractual agreement is a contractual agreement. >>>>>> It put in writings the respective obligations of the uCDN and of >>>>>> the >>>> dCDN. >>>>>> The uCDN may redirect any content request to the dCDN as long as it >>>>>> is >>>> in full conformance with the terms of this contractual agreement (the >>>> type of the content request is in full conformance, the maximum >>>> number of content requests per second is respected, etc.). >>>>>> In this case the dCDN may not say "Sorry, but I decide unilaterally >>>>>> to >>>> refuse this content request". >>>>>> [RvB]: This is where we disagree. IMHO, the type of behavior you >>>> describe (the dCDN not living up to its obligation) should not be >>>> enforced by the CDNI Interfaces. If a dCDN does not live up to its >>>> contractual agreement, this should be something that is handled on a >>>> business level, not on a protocol level. >>>>>> Why? Because this is the deal, a contractual agreement is a >>>>>> contractual >>>> agreement! >>>>>> Yet the dCDN may say "I do apologize, but at this time I cannot >>>>>> handle >>>> correctly a certain class of content requests specified in our >>>> contractual agreement" (for example the class of the HTTP content >>>> requests with token from French end users, because of overload >>>> situation, failure, etc.) This is the role of the CDNI routing >>>> interface to provide the uCDN with such information. >>>>>> (And the dCDN may be given a penalty for example if this was agreed >>>>>> in >>>> the terms of the contractual agreement.) >>>>>> >>>>>> 2) Ray, Quoting your mail: "I understand that in most cases, the >>>> contractual agreement might indeed impose this behavior on the dCDN" >>>>>> Please provide the description of an example where this is not the >>>> case. >>>>>> Otherwise the IETF CDNI WG shall indeed consider this is ALWAYS the >>>> case. >>>>>> [RvB]: I can't remember ever seeing such a discussion on the WG list. >>>> Anyway: one example of a contractual agreement between two CDNs is >>>> one in which the uCDN and dCDN have agreed that the dCDN will deliver >>>> some content on behalf of a uCDN, but decide on a per-request basis >>>> whether it wants to do so (and is for example paid per request). In >>>> these cases, the dCDN needs to have the ability to deny delivery on a per-request basis. >>>>>> And this is an important point to be able to progress in the CDNI >>>> interfaces' specification works. >>>>>> If the contractual agreement does not define clearly the >>>>>> obligations of >>>> the uCDN, it is impossible to dimension adequately the dCDN, neither >>>> to define correctly the CDNI contractual agreements between the dCDN >>>> and the dCDNs of this dCDN. >>>>>> If the contractual agreement does not define clearly the >>>>>> obligations of >>>> the dCDN, the dCDN may do what it wants... even to put in the trash >>>> can any content request it accepted to handle. >>>>>> [RvB]: Exactly, this is something that needs to be discussed on a >>>> business/contractual level and not on a technical level. That is way >>>> IMHO the CDNI Interfaces should not make ANY assumptions on what was >>>> agreed on a contractual level. >>>>>> In both situations it is impossible to ensure any quality of >>>>>> experience >>>> to the end user. >>>>>> >>>>>> 3) Ray, Quoting your mail: "I don't think this type of behavior >>>>>> should >>>> be imposed by the protocol we're developing here." >>>>>> I do not sure I understand this sentence. >>>>>> Every routing protocol has been defined (or at least configured) so >>>>>> far >>>> by considering the expected behavior of the interconnected >>>> elements/networks. >>>>>> [RvB]: Every routing protocol defines the expected behavior of >>>> interconnected elements/networks on a technical level, not on a >>>> business level. Having a dCDN say 'I'm not willing to deliver this >>>> content' is perfectly fine from a technical perspective, although it >>>> could be problematic from a contractual perspective. >>>>>> But maybe I will understand if you provide an example on the point >>>>>> 2 >>>> above. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Yannick Le Louédec. >>>>>> >>>>>> >>>>>> >>>>>> -----Message d'origine----- >>>>>> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >>>>>> Envoyé : mardi 10 juillet 2012 09:20 À : Ben Niven-Jenkins; LE >>>>>> LOUEDEC Yannick RD-CORE Cc : Pilarski Marcin >>>> - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR: >>>> I-D >>>> Action: draft-lelouedec-cdni-request-routing-00.txt >>>>>> Hi Yannick, Ben, >>>>>> >>>>>> I tend to agree with Ben here. When reading the draft, I got the >>>> feeling that the draft seems to assume a lot about the relationship >>>> between the uCDN and dCDN. For example, I don't see why the CDNI >>>> Request Routing interface should state that a dCDN MUST deliver the >>>> content if it has indicated its ability to do so earlier in either a >>>> contractual agreement or in the capability interface. I understand >>>> that in most cases, the contractual agreement might indeed impose >>>> this behavior on the dCDN, but I don't think this type of behavior >>>> should be imposed by the protocol we're developing here. >>>>>> It was always my assumption that the Request Routing Interface >>>>>> would at >>>> least include the option of allowing the uCDN to query the dCDN for >>>> every content request whether the dCDN is willing to deliver that >>>> particular request. >>>>>> I will send my full review of the draft later. >>>>>> >>>>>> Ray >>>>>> >>>>>> -----Original Message----- >>>>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On >>>>>> Behalf Of >>>> Ben Niven-Jenkins >>>>>> Sent: dinsdag 10 juli 2012 7:38 >>>>>> To: yannick.lelouedec@orange.com >>>>>> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE >>>>>> Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- >>>> routing-00.txt >>>>>> Yannick, >>>>>> >>>>>> Please see inline. >>>>>> >>>>>> On 9 Jul 2012, at 20:05, wrote: >>>>>> >>>>>>> Hi Ben, all, >>>>>>> >>>>>>> Ben, quoting you mail below, "... the downstream CDN could reply >>>>>>> with either "here is how to redirect it"", >>>>>>> >>>>>>> => This is the role of the CDNI DRIS interface to provide the uCDN >>>> with this information, and we target to make its specification public >>>> before Vancouver meeting so that everyone may read it before the >>>> meeting and get full knowledge of our proposal about this part of >>>> CDNI request routing. >>>>>>> Ben, quoting you mail below, "... or "no I can't/won't take that >>>> content delivery right now", reasons may include the uCDN has >>>> requested a delivery of a protocol the dCDN does not support (possibly in error). >>>>>>> => This is the role of the CDNI logging interface to provide the >>>>>>> uCDN >>>> with this information. >>>>>> I agree this information should be logged but the Request Routing >>>> interface (what you call the DRIS) also needs to be able to indicate >>>> a failure. >>>>>> Otherwise the uCDN will 'blindly' redirect the the dCDN and the >>>> delivery will fail leading to poor end user experience. >>>>>>> Ben, quoting you mail below, "... or "no I can't/won't take that >>>> content delivery right now", reasons may include ... the dCDN has no >>>> capacity right now etc." >>>>>>> => This is the role of the CDNI routing interface to provide the >>>>>>> uCDN >>>> with this information. >>>>>> It is the role of the CDN capability/routing interface to advertise >>>> broad capabilities etc not to give extremely fine grained real-time >>>> information on exactly the state of the dCDN. >>>>>> Even if the capability/routing interface is real-time there are >>>>>> likely >>>> to still be race conditions where we need the dCDN to be about to >>>> indicate a failure to accept a redirect through the request >>>> routing/DRIS interface >>>>>>> So we may conclude we are in line basically, which is a good point. >>>>>>> We just aimed at checking there was a common understanding on this >>>> point. >>>>>>> The key point for us here is that we don't want this sentence >>>> extracted from draft-ietf-cdni-problem-statement be interpreted as: ". >>>> and the dCDN MUST accept the content request except when it has not >>>> the "ability" to do so." >>>>>> Why not? IMO that is a valid scenario for some use cases. >>>>>> >>>>>>> The fact that the dCDN is temporary unable to handle content >>>>>>> request >>>> correctly is not a valid reason for the dCDN to be discharged of its >>>> obligations to the uCDN. >>>>>>> The contract set between the uCDN and the dCDN remains valid >>>>>>> anyway, >>>> and the obligations of the dCDN as well. >>>>>> Correct, but that contract may not be the same for all uCDNs & >>>>>> dCDNs, >>>> for example a uCDN may not have a guarantee that a dCDN can handle >>>> everything it is requested to handle but the contract may only be >>>> that the dCDN guarantees to handle up to a certain volume of traffic. >>>>>>> The dCDN must announce to the uCDN that it is temporary unable, as >>>> soon as possible, via the CDNI routing interface. >>>>>>> And the uCDN must take this information into account in its CDN >>>> selection process as soon as possible. >>>>>>> Then if the uCDN decides to continue to redirect content requests >>>>>>> to >>>> the dCDN, the uCDN MAY perfectly do it, but the uCDN knows these >>>> content requests will be lost. >>>>>> What happens in the period between the dCDN being unable to handle >>>> requests and the time it takes to advertise that to the uCDN and for >>>> the uCDN to process & incorporate that new knowledge? Are requests >>>> blindly forwarded to the dCDN which is unable to handle them leading >>>> to poor user experience? >>>>>>> We could even imagine the situation where the uCDN continues to do >>>>>>> it >>>> intentionally, because it has no better option and the content >>>> request will be lost anyway. For example in the case where neither >>>> the uCDN nor the other downstream CDNs of the uCDN cannot manage >>>> correctly the content request, the uCDN could do it intentionally so >>>> as to be able to clearly prove (with CDNI logging information) that >>>> it is the dCDN, not the uCDN, who is at fault. >>>>>>> But, of course, if there are alternative backup options, the >>>>>>> normal >>>> reaction of the uCDN is to stop as soon as possible to redirect >>>> content requests to the dCDN when the uCDN knows that the dCDN is >>>> unable to handle them correctly. >>>>>>> So, to be clear, we would prefer the sentence to be understood as: >>>>>>> ". and the dCDN MUST accept the content request. >>>>>>> And if it cannot handle correctly the redirected content request >>>>>>> it >>>> receives, the content request is lost. >>>>>> What about scenarios where the uCDN has a choice of dCDNs (e.g. two >>>> national-wide CDNs offering services at different costs), the uCDN >>>> may elect to query both dCDNs and decide based on their responses >>>> which one to choose. If the dCDN is unable to satisfy the request the >>>> uCDN needs to know that so that it can fallback to the (more >>>> expensive in this example) dCDN. >>>>>>> For example the dCDN generates a response to the content request >>>>>>> with >>>> an error message, or no response at all. And in parallel the CDNI >>>> logging interface may be used to exchange logs corresponding to this problem. >>>> Anyway the dCDN MAY NOT redirect that content request back towards >>>> the uCDN." >>>>>>> Exactly as in IP networks: IP packets are not sent back towards >>>>>>> the >>>> origin by a downstream router under failure or congestion. >>>>>> In a routed IP network, there is often a small packet loss while >>>>>> the >>>> network re-converges, by enabling the dCDN to refuse a redirection at >>>> CDNI Request Routing/DRIS query time we can reduce that window by >>>> giving the uCDN the option to take an alternative action (e.g. try >>>> another dCDN) while the routing/capability information re-converges. >>>>>>> In both networks (IP and CDN), the reason is the same. >>>>>>> If the dCDN redirects back a content request to the uCDN, this >>>> generates a loop. >>>>>> Loop avoidance is a separate issue IMO to whether we should allow a >>>> dCDN to be able to communicate "I am unable/unwilling to take that >>>> content delivery at this time". >>>>>> Regards >>>>>> Ben >>>>>> >>>>>>> To manage this would introduce a very high complexity. >>>>>>> And this would be just to try to save the content requests >>>>>>> redirected >>>> by the uCDN to the dCDN in the timeslot between the time the dCDN >>>> gets down and the time the uCDN takes this failure into account in >>>> its CDN selection process. >>>>>>> It is much better to try to reduce this timeslot as much as >>>>>>> possible, >>>> with routing optimizations (we will propose as soon as possible). >>>>>>> Rather than introducing additional complexities (to manage >>>>>>> redirection >>>> to the uCDN) in the framework. >>>>>>> >>>>>>> By the way, as you know, the IESG has just approved today the >>>>>>> 'Content >>>> Distribution Network Interconnection (CDNI) Problem Statement' draft >>>> as informational RFC. This is a good point. >>>>>>> And, as you may see in the draft "CDNI request routing", we do not >>>> propose to modify this problem statement draft. >>>>>>> We want know to focus now on getting the specifications of all >>>>>>> CDNI >>>> interfaces ready as soon as possible. >>>>>>> Best regards, >>>>>>> >>>>>>> Yannick Le Louédec. >>>>>>> >>>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la >>>>>>> part de Ben Niven-Jenkins Envoyé : lundi 9 juillet 2012 20:41 À : >>>>>>> BERTRAND Gilles RD-CORE Cc : cdni@ietf.org; Pilarski Marcin - >>>>>>> Korpo TP; MARREC Anne RD-CORE Objet : Re: [CDNi] TR: I-D Action: >>>>>>> draft-lelouedec-cdni-request-routing-00.txt >>>>>>> >>>>>>> Colleagues, >>>>>>> >>>>>>> I started reading draft-lelouedec-cdni-request-routing-00 and this >>>> text caught my eye: >>>>>>> Quoting [I-D.ietf-cdni-problem-statement ], "The CDNI Request >>>>>>> Routing interface enables a Request Routing function in an >>>>>>> upstream CDN to query a Request Routing function in a downstream >>>>>>> CDN to determine if the downstream CDN is able (and willing) to >>>>>>> accept the delegated content request". >>>>>>> >>>>>>> The "ability" and the "willingness" of the downstream CDN to >>>>>>> accept the delegated content request match two fully different >>>>>>> processes in CDN interconnection. And the description of both >>>>>>> these processes should be reviewed and clarified for the following reasons: >>>>>>> >>>>>>> o Regarding the former process, i.e. related to the "ability" >>>>>>> ("enables a Request Routing function in an upstream CDN to >>>>>>> query >>>> a >>>>>>> Request Routing function in a downstream CDN to determine if the >>>>>>> downstream CDN is able (...) to accept the delegated content >>>>>>> request"), a routing protocol is used to achieve such a process, >>>>>>> called routing process, in many other technologies and networks >>>>>>> (IP, ATM, etc.). In all these technologies, it is the downstream >>>>>>> entity that provides routing information to the upstream entity. >>>>>>> The same approach should be applied to CDN interconnection. The >>>>>>> reverse approach ("uCDN queries it downstream CDNs dCDN 1, >>>>>>> dCDN >>>> 2, >>>>>>> dCDN 3, and then it selects one of them based on their >>>> responses") >>>>>>> would suffer from latency, signaling overhead and/or lack of >>>>>>> reactivity to events that impact the ability of the downstream >>>>>>> CDNs to accept delegated content requests. >>>>>>> >>>>>>> o Regarding the latter process, i.e. related to the "willingness" >>>>>>> ("enables a Request Routing function in an upstream CDN to >>>>>>> query >>>> a >>>>>>> Request Routing function in a downstream CDN to determine if the >>>>>>> downstream CDN (...) is willing (...)to accept the delegated >>>>>>> content request"), it is to be noted that the relationship >>>> between >>>>>>> a uCDN and a dCDN is always in the frame of a contractual >>>>>>> agreement between the administrative entity owning the uCDN, >>>>>>> acting as the customer, and the administrative entity owning the >>>>>>> dCDN, acting as the service provider. Therefore, consider a case >>>>>>> where >>>>>>> >>>>>>> * the uCDN has a content request to redirect which is in full >>>>>>> conformance with the terms of this contractual agreement, >>>>>>> and >>>>>>> >>>>>>> * the uCDN has selected this dCDN. >>>>>>> >>>>>>> As the uCDN knows, thanks to the routing information exchanged >>>> via >>>>>>> the aforementioned routing process, that the dCDN is able to >>>>>>> accept this content request, the uCDN MAY redirect the content >>>>>>> request to the dCDN and the dCDN MUST accept the content request. >>>>>>> Exchanging over the CDNI Request Routing interface information >>>>>>> about the "willingness" of the dCDN to accept the content request >>>>>>> is not relevant. >>>>>>> >>>>>>> I think you might be over thinking what we wrote in the problem >>>> statement. >>>>>>> What was in the problem statement was meant to convey that an >>>>>>> upstream >>>> CDN could make a request to a downstream CDN to say "how do I >>>> redirect this request to you" and the downstream CDN could reply with >>>> either "her is how to redirect it", or "no I can't/won't take that >>>> content delivery right now", reasons may include the uCDN has >>>> requested a delivery of a protocol the dCDN does not support >>>> (possibly in error) or the dCDN has no capacity right now etc. >>>>>>> Ben >>>>>>> >>>>>>> On 9 Jul 2012, at 18:00, wrote: >>>>>>> >>>>>>>> Hi everyone, >>>>>>>> >>>>>>>> We have just submitted the draft below. We are convinced that it >>>>>>>> will >>>> help the WG to progress on the CDNI routing issues. >>>>>>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-0 >>>>>>>> 0 >>>>>>>> >>>>>>>> Any feedback is very welcome. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Gilles >>>>>>>> >>>>>>>> >>>>>>>> -----Message d'origine----- >>>>>>>> De : i-d-announce-bounces@ietf.org >>>>>>>> [mailto:i-d-announce-bounces@ietf.org] De la part de >>>>>>>> internet-drafts@ietf.org Envoyé : lundi 9 juillet 2012 18:55 À : >>>>>>>> i-d-announce@ietf.org Objet : I-D Action: >>>>>>>> draft-lelouedec-cdni-request-routing-00.txt >>>>>>>> >>>>>>>> >>>>>>>> A New Internet-Draft is available from the on-line >>>>>>>> Internet-Drafts >>>> directories. >>>>>>>> >>>>>>>> Title : CDNI Request Routing >>>>>>>> Author(s) : Yannick Le Louedec >>>>>>>> Anne Marrec >>>>>>>> Gilles Bertrand >>>>>>>> Marcin Pilarski >>>>>>>> Filename : draft-lelouedec-cdni-request-routing-00.txt >>>>>>>> Pages : 30 >>>>>>>> Date : 2012-07-09 >>>>>>>> >>>>>>>> Abstract: >>>>>>>> The present document proposes to clarify the CDNI Request Routing >>>>>>>> interface introduced in [I-D.ietf-cdni-framework] and >>>>>>>> [I-D.ietf-cdni- problem-statement], as well as related terminology. >>>>>>>> >>>>>>>> In particular the present document proposes to split the CDNI >>>>>>>> Request Routing interface into two separate interfaces with >>>>>>>> clearer roles, named respectively CDNI Routing interface and >>>>>>>> CDNI Downstream Resource Identifier Signaling interface (CDNI DRIS interface). >>>>>>>> >>>>>>>> This part of the CDN interconnection framework the IETF has been >>>>>>>> referring to so far with the term "CDNI Request Routing" is just >>>>>>>> another routing, signaling and forwarding problem in a long >>>>>>>> series of the telecommunication history. For example, one can >>>>>>>> draw a direct analogy between the IP/MPLS-TE framework and the >>>>>>>> CDN interconnection framework. >>>>>>>> >>>>>>>> In addition, this document recommends that the specification of >>>>>>>> ALL CDN interconnection interfaces in the scope of the CDNI IETF >>>>>>>> WG relies on the equivalent concept to IP prefix for CDN >>>>>>>> interconnection, named 'contentRequestScope'. This highly useful >>>>>>>> and powerful concept SHALL be used to simplify the specification >>>>>>>> of ALL CDN interconnection interfaces, as well as to ensure >>>>>>>> performance and scalability in CDN interconnection. >>>>>>>> >>>>>>>> All these proposals can be smoothly integrated in the WG drafts, >>>>>>>> especially [I-D.ietf-cdni-framework] and >>>>>>>> [I-D.ietf-cdni-requirements], as they essentially propose >>>>>>>> (useful) clarifications of the existing framework. >>>>>>>> >>>>>>>> >>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>> https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-rou >>>>>>>> ting >>>>>>>> >>>>>>>> There's also a htmlized version available at: >>>>>>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-0 >>>>>>>> 0 >>>>>>>> >>>>>>>> >>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>>> >>>>>>>> _________________________________________________________________ >>>>>>>> ____ ____________________________________________________ >>>>>>>> >>>>>>>> Ce message et ses pieces jointes peuvent contenir des >>>>>>>> informations confidentielles ou privilegiees et ne doivent donc >>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous >>>>>>>> avez recu ce message par erreur, veuillez le signaler a >>>>>>>> l'expediteur et le detruire ainsi >>>> que les pieces jointes. Les messages electroniques etant susceptibles >>>> d'alteration, France Telecom - Orange decline toute responsabilite si >>>> ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>> This message and its attachments may contain confidential or >>>>>>>> privileged information that may be protected by law; they should >>>>>>>> not >>>> be distributed, used or copied without authorisation. >>>>>>>> If you have received this email in error, please notify the >>>>>>>> sender >>>> and delete this message and its attachments. >>>>>>>> As emails may be altered, France Telecom - Orange is not liable >>>>>>>> for >>>> messages that have been modified, changed or falsified. >>>>>>>> Thank you. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >>>>>>> __________________________________________________________________ >>>>>>> ____ ___________________________________________________ >>>>>>> >>>>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le >>>>>>> detruire ainsi >>>> que les pieces jointes. Les messages electroniques etant susceptibles >>>> d'alteration, France Telecom - Orange decline toute responsabilite si >>>> ce message a ete altere, deforme ou falsifie. Merci. >>>>>>> This message and its attachments may contain confidential or >>>>>>> privileged information that may be protected by law; they should >>>>>>> not >>>> be distributed, used or copied without authorisation. >>>>>>> If you have received this email in error, please notify the sender >>>>>>> and >>>> delete this message and its attachments. >>>>>>> As emails may be altered, France Telecom - Orange is not liable >>>>>>> for >>>> messages that have been modified, changed or falsified. >>>>>>> Thank you. >>>>>>> >>>>>> _______________________________________________ >>>>>> CDNi mailing list >>>>>> CDNi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>> This e-mail and its contents are subject to the DISCLAIMER at >>>> http://www.tno.nl/emaildisclaimer >>>>>> >>>>>> >>>> _____________________________________________________________________ >>>> _ ____ _______________________________________________ >>>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>>> exploites ou copies sans autorisation. Si vous avez recu ce message >>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi >>>> que les pieces jointes. Les messages electroniques etant susceptibles >>>> d'alteration, France Telecom - Orange decline toute responsabilite si >>>> ce message a ete altere, deforme ou falsifie. Merci. >>>>>> This message and its attachments may contain confidential or >>>>>> privileged >>>> information that may be protected by law; they should not be >>>> distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the sender >>>>>> and >>>> delete this message and its attachments. >>>>>> As emails may be altered, France Telecom - Orange is not liable for >>>> messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>> >>>>>> >>>>>> >>>> _____________________________________________________________________ >>>> _ ____ _______________________________________________ >>>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous >>>>>> avez >>>> recu ce message par erreur, veuillez le signaler >>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les >>>> messages electroniques etant susceptibles d'alteration, >>>>>> France Telecom - Orange decline toute responsabilite si ce message >>>>>> a >>>> ete altere, deforme ou falsifie. Merci. >>>>>> This message and its attachments may contain confidential or >>>>>> privileged >>>> information that may be protected by law; >>>>>> they should not be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the sender >>>>>> and >>>> delete this message and its attachments. >>>>>> As emails may be altered, France Telecom - Orange is not liable for >>>> messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> ______________________________________________________________________ >>> ___________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce message >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and delete this message and its attachments. >>> As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> 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 ben@niven-jenkins.co.uk Wed Jul 25 11:53:47 2012 Return-Path: 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 6D4C221F86C7 for ; Wed, 25 Jul 2012 11:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 sy0YcRb12diL for ; Wed, 25 Jul 2012 11:53:46 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 97EA521F8764 for ; Wed, 25 Jul 2012 11:53:46 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginmedia.com ([86.14.227.47] helo=[192.168.0.4]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Su6iO-0004aS-Vb; Wed, 25 Jul 2012 19:53:45 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <291CC3F9E50E7641901A54E85D0977C65326EC6EE7@MAILR002.mail.lan> Date: Wed, 25 Jul 2012 19:53:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <64ECD7B2-7A0D-4406-A580-21AB0A6D5329@niven-jenkins.co.uk> References: <166EBB70C264A9479E459B01B1BA6C9201B060@xmb-aln-x03.cisco.com> <291CC3F9E50E7641901A54E85D0977C65326E2AA7F@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C65326E2B302@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C65326EC6EE7@MAILR002.mail.lan> To: Kevin J Ma X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "Ben Niven-Jenkins \(ben@velocix.com\)" , "cdni@ietf.org" Subject: Re: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni-metadata-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 18:53:47 -0000 Kevin, On 19 Jul 2012, at 22:27, Kevin J Ma wrote: >> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] >> On 18 Jul 2012, at 20:11, Kevin J Ma wrote: >>>>> Also, >>>>> does hostnames support both IP and DNS values? >>>>=20 >>>> I'm not sure of the use case for IP values as clients connecting to >> CDNs >>>> aren't typically given a URL with an IP address as a hostname. >>>=20 >>> For the public Internet I would agree, however, there are cases = where >> MSOs >>> building internal CDNs prefer (for whatever reason) IP addresses. >>=20 >> Let me understand this use case a bit more. >>=20 >> Is it that the MSO/CDN operator prefers that redirects are performed = to IP >> addresses? >>=20 >> or >>=20 >> That the value of the Host: header the client presents in its GET = request >> is an IP address? >>=20 >> I'm aware of the former, I'm not aware of the latter. >=20 > We have seen cases where there is no DNS in the network and the client = is > only presented with an IP address. I don't know how prevalent it is, = but > it should not really be an issue to support, should it? Right, it's not an issue, we can change the draft to make allowing IP = addresses more explicit. I was trying to understand the use case more to check it was actually = interconnectable but I think it is, so that's OK. Ben From haibin.song@huawei.com Wed Jul 25 21:57:49 2012 Return-Path: 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 C2A4A21F85E3 for ; Wed, 25 Jul 2012 21:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[AWL=0.228, 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 ligv1E5cjnpw for ; Wed, 25 Jul 2012 21:57:49 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0299E21F8592 for ; Wed, 25 Jul 2012 21:57:48 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AII80582; Thu, 26 Jul 2012 00:57:48 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Jul 2012 21:55:47 -0700 Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Jul 2012 21:55:45 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.243]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Thu, 26 Jul 2012 12:55:41 +0800 From: Songhaibin To: "Francois Le Faucheur (flefauch)" Thread-Topic: [CDNi] New Version Notification for draft-song-cdni-slr-based-footprint-01.txt Thread-Index: AQHNajqDgGWH62XWikmLQmQYvguKKJc7AMTg Date: Thu, 26 Jul 2012 04:55:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "cdni@ietf.org" Subject: Re: [CDNi] New Version Notification for draft-song-cdni-slr-based-footprint-01.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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 04:57:49 -0000 OK. Thanks for the good suggestion. I notice there will be side meeting on = footprint and cap advertisement. I will try to join the discussion. -Haibin > -----Original Message----- > From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > Sent: Wednesday, July 25, 2012 3:53 PM > To: Songhaibin > Cc: cdni@ietf.org; Jan Seedorf; Jon Peterson (jon.peterson@neustar.biz); > Stefano Previdi (sprevidi) > Subject: Re: [CDNi] New Version Notification for > draft-song-cdni-slr-based-footprint-01.txt >=20 > Hello Haibin, >=20 > As per your request, you'll have a 5 min slot in Vancouver to introduce t= his notion > of service level requirements based footprint. > Moving forward, I strongly recommend you input your ideas directly into t= he > work of the "CDNI Footprint and Capabilities Advertisement" Design Team t= hat is > chartered with defining the semantics of the information that is to be ad= vertised. >=20 > Thanks >=20 > Francois >=20 > On 16 Jul 2012, at 12:36, Songhaibin wrote: >=20 > > Hi, > > > > We just submitted a draft about service level requirements based footpr= int. > This draft is mainly used to generate the discussion on this aspect and i= t is still on > a high level idea stage. We have not given deep thought on the details in= this > document. So any discussion and comments are welcome! > > > > http://www.ietf.org/internet-drafts/draft-song-cdni-slr-based-footprint= -01.txt > > > > BR, > > -Haibin > > > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Monday, July 16, 2012 6:31 PM > >> To: Songhaibin > >> Cc: zhangyunfei@chinamobile.com > >> Subject: New Version Notification for > draft-song-cdni-slr-based-footprint-01.txt > >> > >> > >> A new version of I-D, draft-song-cdni-slr-based-footprint-01.txt > >> has been successfully submitted by Haibin Song and posted to the > >> IETF repository. > >> > >> Filename: draft-song-cdni-slr-based-footprint > >> Revision: 01 > >> Title: A SLR (Service Level Requirements) based footprint for CDNI > >> Creation date: 2012-07-16 > >> WG ID: Individual Submission > >> Number of pages: 7 > >> URL: > >> > http://www.ietf.org/internet-drafts/draft-song-cdni-slr-based-footprint-0= 1.txt > >> Status: > >> http://datatracker.ietf.org/doc/draft-song-cdni-slr-based-footprint > >> Htmlized: > >> http://tools.ietf.org/html/draft-song-cdni-slr-based-footprint-01 > >> Diff: > >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-song-cdni-slr-based-footpri= nt-01 > >> > >> Abstract: > >> Footprint advertisement is a very important step for CDN > >> interconnection and generates a lot of discussion. Actually, each > >> CDN can serve the whole world if its surrogates are publicly > >> reachable by IP addresses. But if a CDN does that, it can not > >> satisfy the requirements from the applications. So CDNs deliver > >> contents for applications, and the basic requirements should be from > >> the applications, but there is rare discussion on service level > >> requirements based footprint. This document is used to generate the > >> discussion on this aspect. > >> > >> > >> > >> > >> The IETF Secretariat > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From yannick.lelouedec@orange.com Wed Jul 25 22:54:34 2012 Return-Path: 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 13CCB21F8700 for ; Wed, 25 Jul 2012 22:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=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 hZDLAUi65Uzp for ; Wed, 25 Jul 2012 22:54:33 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C83DF21F86FD for ; Wed, 25 Jul 2012 22:54:32 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 159F2264197; Thu, 26 Jul 2012 07:54:31 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id E87F723804B; Thu, 26 Jul 2012 07:54:30 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 26 Jul 2012 07:54:30 +0200 From: To: "Woundy, Richard" , "Francois Le Faucheur (flefauch@cisco.com)" , Scott Wainner , Ben Niven-Jenkins , "Brandenburg, R. (Ray) van" , "cdni@ietf.org" Thread-Topic: IETF #84 - CDNI Side meetings Thread-Index: Ac1q8v4Y2poVDq5GRHiU7VbboGTdMw== Date: Thu, 26 Jul 2012 05:54:29 +0000 Message-ID: <7339_1343282071_5010DB96_7339_2672_1_457F4B94DBADF743B61D350B3E7929FE029815@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.26.43324 Subject: [CDNi] IETF #84 - CDNI Side meetings 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 05:54:34 -0000 Dear all, In my mail below I mentioned (a bit too early) that the "footprint / capabi= lities advertisement" design team meeting would be held on Monday from 18:0= 0 to 20:00. Please note, if you have not done it yet, that the "footprint / capabilitie= s advertisement" design team meeting will be on Monday from 9:00-11:00 (Mee= ting point at the IETF registration desk). (See the mails from Jan Seedorf on the CDNI mailing list). Besides we do confirm the side meeting on CDNI request routing will be on = Monday 30 from 20:30 to 22:00 @ Hyatt Regency Hotel (Meeting point at the I= ETF registration desk). Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de y= annick.lelouedec@orange.com Envoy=E9=A0: mardi 24 juillet 2012 15:16 =C0=A0: Woundy, Richard; Francois Le Faucheur (flefauch@cisco.com); Scott W= ainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.org Objet=A0: [CDNi] IETF #84 - Side meeting on the CDNI request routing interf= ace - Monday 30 from 20:30 to 22:00 @ Hyatt Regency Hotel. Dear all, We propose to arrange the side meeting on CDNI request routing on Monday 30= from 20:30 to 22:00 at Hyatt Regency Hotel. The "footprint / capabilities advertisement" design team meeting will be he= ld just before, the same day, from 18:00 to 20:00. These slots seemed to be the ones that suit most people who wish to attend. Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: LE LOUEDEC Yannick RD-CORE Envoy=E9=A0: vendredi 20 juillet 2012 14:28 =C0=A0: 'Woundy, Richard'; Francois Le Faucheur (flefauch@cisco.com); Scott= Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.org Cc=A0= : STEPHAN Emile RD-CORE; BERTRAND Gilles RD-CORE Objet=A0: RE: [CDNi] IETF = #84 - Proposal for a side meeting on the CDNI request routing interface Dear all, The doodle for the side meeting in Vancouver on CDNI request routing is her= e: http://www.doodle.com/n552qchpurfcpckn Please fill it in as soon as possible if you intend to attend. Ideally we would like to arrange this meeting at Hyatt Regency Hotel, on Mo= nday evening, after the welcoming session. Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de y= annick.lelouedec@orange.com Envoy=E9=A0: lundi 16 juillet 2012 16:35 =C0=A0= : Scott Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.or= g Objet=A0: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI reque= st routing interface Dear all, We propose to arrange a side meeting on Sunday evening during IETF #84 (i.e= . on July 29th) on the CDNI request routing interface. The objective is to clear the discussion we had these last days via the IET= F CDNI mailing list, and to ease an efficient meeting on Tuesday 31. If everybody agrees that this is a good idea, we will set up a doodle. Best regards, Yannick Le Lou=E9dec, Orange OLNC. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, France Telecom - = Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, France Telecom - = Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From Jan.Seedorf@neclab.eu Thu Jul 26 00:10:17 2012 Return-Path: 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 326ED21F8568 for ; Thu, 26 Jul 2012 00:10:17 -0700 (PDT) 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 1nwy37PWmkCr for ; Thu, 26 Jul 2012 00:10:15 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE4D21F856D for ; Thu, 26 Jul 2012 00:10:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 77BCF101944; Thu, 26 Jul 2012 09:14:41 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8ebVV3ezaGL; Thu, 26 Jul 2012 09:14:41 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 5535810192C; Thu, 26 Jul 2012 09:14:06 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.252]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 26 Jul 2012 09:09:38 +0200 From: Jan Seedorf To: "yannick.lelouedec@orange.com" , "Woundy, Richard" , "Francois Le Faucheur (flefauch@cisco.com)" , Scott Wainner , Ben Niven-Jenkins , "Brandenburg, R. (Ray) van" , "cdni@ietf.org" Thread-Topic: [CDNi] IETF #84 - CDNI Side meetings Thread-Index: Ac1q8v4Y2poVDq5GRHiU7VbboGTdMwACmgKQ Date: Thu, 26 Jul 2012 07:10:37 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE32CDC233@PALLENE.office.hd> References: <7339_1343282071_5010DB96_7339_2672_1_457F4B94DBADF743B61D350B3E7929FE029815@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <7339_1343282071_5010DB96_7339_2672_1_457F4B94DBADF743B61D350B3E7929FE029815@PEXCVZYM11.corporate.adroot.infra.ftgroup> 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] IETF #84 - CDNI Side meetings 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 07:10:17 -0000 Thanks Yannick for the confirmation, I think we are all in agreement now an= d the meeting times for both side meetings should be clear. I will join both meetings. - Jan > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > yannick.lelouedec@orange.com > Sent: Thursday, July 26, 2012 7:54 AM > To: Woundy, Richard; Francois Le Faucheur (flefauch@cisco.com); Scott > Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.org > Subject: [CDNi] IETF #84 - CDNI Side meetings >=20 > Dear all, >=20 > In my mail below I mentioned (a bit too early) that the "footprint / > capabilities advertisement" design team meeting would be held on Monday > from 18:00 to 20:00. > Please note, if you have not done it yet, that the "footprint / capabilit= ies > advertisement" design team meeting will be on Monday from 9:00-11:00 > (Meeting point at the IETF registration desk). > (See the mails from Jan Seedorf on the CDNI mailing list). >=20 > Besides we do confirm the side meeting on CDNI request routing will be on > Monday 30 from 20:30 to 22:00 @ Hyatt Regency Hotel (Meeting point at the > IETF registration desk). >=20 > Best regards, >=20 > Yannick Le Lou=E9dec. >=20 > -----Message d'origine----- > De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de > yannick.lelouedec@orange.com > Envoy=E9=A0: mardi 24 juillet 2012 15:16 > =C0=A0: Woundy, Richard; Francois Le Faucheur (flefauch@cisco.com); Scott > Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.org > Objet=A0: [CDNi] IETF #84 - Side meeting on the CDNI request routing inte= rface - > Monday 30 from 20:30 to 22:00 @ Hyatt Regency Hotel. >=20 > Dear all, >=20 > We propose to arrange the side meeting on CDNI request routing on > Monday 30 from 20:30 to 22:00 at Hyatt Regency Hotel. > The "footprint / capabilities advertisement" design team meeting will be = held > just before, the same day, from 18:00 to 20:00. > These slots seemed to be the ones that suit most people who wish to > attend. >=20 > Best regards, >=20 > Yannick Le Lou=E9dec. >=20 > -----Message d'origine----- > De=A0: LE LOUEDEC Yannick RD-CORE > Envoy=E9=A0: vendredi 20 juillet 2012 14:28 > =C0=A0: 'Woundy, Richard'; Francois Le Faucheur (flefauch@cisco.com); Sco= tt > Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.org Cc= =A0: > STEPHAN Emile RD-CORE; BERTRAND Gilles RD-CORE Objet=A0: RE: [CDNi] IETF > #84 - Proposal for a side meeting on the CDNI request routing interface >=20 > Dear all, >=20 > The doodle for the side meeting in Vancouver on CDNI request routing is > here: http://www.doodle.com/n552qchpurfcpckn > Please fill it in as soon as possible if you intend to attend. >=20 > Ideally we would like to arrange this meeting at Hyatt Regency Hotel, on > Monday evening, after the welcoming session. >=20 > Best regards, >=20 > Yannick Le Lou=E9dec. >=20 > -----Message d'origine----- > De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de > yannick.lelouedec@orange.com Envoy=E9=A0: lundi 16 juillet 2012 16:35 =C0= =A0: Scott > Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.org > Objet=A0: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI reque= st > routing interface >=20 > Dear all, >=20 > We propose to arrange a side meeting on Sunday evening during IETF #84 > (i.e. on July 29th) on the CDNI request routing interface. > The objective is to clear the discussion we had these last days via the I= ETF > CDNI mailing list, and to ease an efficient meeting on Tuesday 31. > If everybody agrees that this is a good idea, we will set up a doodle. >=20 > Best regards, >=20 > Yannick Le Lou=E9dec, > Orange OLNC. >=20 >=20 > __________________________________________________________ > __________________________________________________________ > _____ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veu= illez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. L= es > messages electroniques etant susceptibles d'alteration, France Telecom - > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete > this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges > that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 > __________________________________________________________ > __________________________________________________________ > _____ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veu= illez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. L= es > messages electroniques etant susceptibles d'alteration, France Telecom - > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete > this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges > that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 > __________________________________________________________ > __________________________________________________________ > _____ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce > message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete > this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges > that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From yannick.lelouedec@orange.com Thu Jul 26 00:42:04 2012 Return-Path: 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 2250C21F8745 for ; Thu, 26 Jul 2012 00:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, UNPARSEABLE_RELAY=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 DOUIISdsvSNn for ; Thu, 26 Jul 2012 00:42:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id EBC0D21F873A for ; Thu, 26 Jul 2012 00:41:59 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 3AFF93B4407 for ; Thu, 26 Jul 2012 09:41:59 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 28C4527C053 for ; Thu, 26 Jul 2012 09:41:59 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 26 Jul 2012 09:41:58 +0200 From: To: "cdni@ietf.org" Thread-Topic: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.txt Thread-Index: AQHNanbdDt5/WFxTGUOr3GgzYrRzfJc7FTLQ Date: Thu, 26 Jul 2012 07:41:58 +0000 Message-ID: <1912_1343288519_5010F4C7_1912_5600_1_457F4B94DBADF743B61D350B3E7929FE029865@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> <2040_1341930789_4FFC3D24_2040_2504_1_b86bff40-ae68-40c0-b8e5-060f51be6864@PEXCVZYH02.corporate.adroot.infra.ftgroup> <3A7EA7EE-F8D4-4094-83F2-12CD3826B662@tno.nl> <5004079D.4000406@cisco.com> <29661_1343216353_500FDAE1_29661_643_1_2AC63C9F27AF8446B0C064C50FC0A89305D959@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AF54F9B-B4FF-4043-A9DE-36C0417F9EAC@cisco.com> <0B55392F-16FD-4967-9A9D-91A7D4CE1A30@cisco.com> <50100B11.7090802@cisco.com> In-Reply-To: <50100B11.7090802@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.26.43324 Subject: Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 07:42:04 -0000 Dear all, Many thanks for this discussion! These are some of the questions I wished to be addressed at the Vancouver m= eeting. Here are some comments on the draft http://tools.ietf.org/html/draft-leloue= dec-cdni-request-routing-00 using the three (main) modes (A, B and C) liste= d by Fran=E7ois Le Faucheur in its mail below. ****** First comment: Quoting the description from Fran=E7ois of the mode B: "*B* the uCDN uses the Footprint&Cap information (advertised by dCDN) to se= lect a dCDN candidate. The uCDN queries the dCDN before redirecting.=20 Querying dCDN optionally allows the dCDN to provide to uCDN the final redir= ection information so the the enduser experiences a single redirect. Querying dCDN optionally allows the uCDN to pick an alternate dCDN if the i= nitially selected dCDN cannot handle the request." This description from Fran=E7ois shows clearly that there is a first step t= hat consists in the uCDN using the Footprint&Cap information (advertised by= dCDN) to select a dCDN candidate. This is the role of what we call the CDNI routing interface in the draft ht= tp://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00.=20 ****** Second comment: After this dCDN candidate is selected, we mentioned in draft http://tools.ietf.org/html/draft-lelouedec-cdni-reque= st-routing-00 that the next step is managed by another process that exploit= s information provided by the interface we call "CDNI Downstream Resource I= dentifier (DRIS) interface". As mentioned earlier in a mail, our intent is to come in Vancouver with a d= escription of that CDNI DRIS interface, even if we will be probably a bit s= hort of time to publish an IETF draft with this specification before the en= d of the week. But basically this interface allows to support the modes A and B (and also = the mode C, as mentioned in my fourth comment below). In mode A, and to quote Fran=E7ois' descriptions, this CDNI DRIS allows to = proceed as follows: "The uCDN redirects to the selected dCDN and considers = that he is done with request routing." In mode B, and to quote Fran=E7ois' descriptions, this CDNI DRIS allows to = proceed as follows: " The uCDN queries the dCDN before redirecting.=20 Querying dCDN optionally allows the dCDN to provide to uCDN the final redir= ection information so the the enduser experiences a single redirect. Querying dCDN optionally allows the uCDN to pick an alternate dCDN if the i= nitially selected dCDN cannot handle the request." Our intent (the co-authors of the draft http://tools.ietf.org/html/draft-le= louedec-cdni-request-routing-00) is indeed to make proposals that support m= odes A and B. ******* Third comment The way Fran=E7ois described the mode B tends again to confirm the interest= to split the CDNI request routing interface into two sub-interfaces, at le= ast very clearly for mode B. But I do not comment this further as there is a priori a clear consensus on= that point within the CDNI WG. ****** Fourth comment: I have a common comment about : ** this following sentence from Fran=E7ois in its description of mode B: "Q= uerying dCDN optionally allows the uCDN to pick an alternate dCDN if the in= itially selected dCDN cannot handle the request." ** the following comment from Scott in its mail below: "The *C* mode is a s= pecial case of *B* where the uCDN has elected to use *B* in parallel with m= ultiple dCDN. This is an internal implementation of the uCDN." Indeed fully agree that all this relates to the internal implementation of = the uCDN. Another way to say this is "Provided its CDNI interfaces allow to support m= ode B, an uCDN can support the mode C (on condition the uCDN has the adequa= te internal implementation for mode C)". We (Orange) have published the draft http://tools.ietf.org/html/draft-lelou= edec-cdni-request-routing-00 having in mind that the mode C is not our prio= rity (which is per se something we wanted to share). But our proposals about the CDNI request routing interface (with these CDNI= routing interface and CDNI DRIS interface) allow therefore also to support= the mode C, on condition indeed that the uCDN has the adequate internal im= plementation for mode C. We did not detail this point in the IETF draft (as, again, mode C was not o= ur priority). But these comments from Fran=E7ois and Scott are very much helpful to clari= fy and underline this point. ****** Fourth comment: In the same vein, and to come back to the mail exchanges we had right after= the publication of the draft http://tools.ietf.org/html/draft-lelouedec-cd= ni-request-routing-00 about capability and "willingness", if the standard specifications from the CDNI WG MUST indeed allow the dCDN = to refuse that a given content request be redirected to it even if it has e= nough capabilities to handle that content request (the dCDN can but does no= t want to handle that content request), the specification of the CDNI DRIS = interface we were about to share allows also to support this. Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de S= cott Wainner Envoy=E9=A0: mercredi 25 juillet 2012 17:05 =C0=A0: cdni@ietf.org Objet=A0: Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.txt I agree with Ray that we should support *A* and *B* modes. The *C* mode is a special case of *B* where the uCDN has elected to use *B* in parallel with multiple dCDN. This is an internal implementation of = the uCDN. I think we already agreed to support Iterative and Recursive modes. My point about the differences in *A* and *B* is that you need information = exchange between dCDN and uCDN. You can choose to make that information exchange fast in the capabilities a= nd footprint announcement which mitigates the value of *B* mode (the uCDN q= ueries the dCDN before referring the client). The dCDN will need to quickl= y propagate information to the uCDN to avoid losing content requests when r= andom things don't work (overload, cache node failure, routing request erro= r, whatever, ...). The disadvantage is the uCDN must be responsive to ALL = the dCDN updates coming in based on events in each dCDN. The operator will = end up dampening these inputs to avoid thrashing. You can choose to make that information exchange slow in the capabilities a= nd footprint advertisements and fast in the routing request process (per co= ntent request referral). This negates the value of *A* mode (the uCDN blin= dly refers the client the dCDN). The dCDN will need to quickly respond to i= nquiries of the uCDN. A key trade-off will be particularly noticeable where the uCDN/dCDN is supp= orting HAS a per-chunk request. It simply doesn't scale unless the uCDN re= writes the manifest such that the remainder of the "session requests" are r= eferred to the dCDN and all subsequent chunks are retrieved directly from t= he dCDN without having to refer back to the uCDN. If the retrieval is a large-object retrieval, then *B* would be sufficient. Scott On 7/25/12 9:20 AM, Francois Le Faucheur (flefauch) wrote: > Hi Ray, > > Good input. Thanks. > One point below: > > On 25 Jul 2012, at 15:07, Brandenburg, R. (Ray) van wrote: > >> Hi all, >> >> Francois, thanks for clarifying this discussion, very helpful. >> >> I tend to agree with your assessment of the various options. Personally,= I would be opposed to a CDNI specification that does not include *B* at le= ast as an option, since to me *A* is not suited for 'premium'-content cases= where you want to minimize the chances of content not being delivered. In = these cases, scalability might be less of a concern, especially for CDNs th= at do internal request routing for each request anyway. In addition, I thin= k the CDNI interfaces should at least support a scenario where the dCDN, wh= atever it advertises, should always have the option of turning down a conte= nt delivery request by a uCDN, whether it is for reasons of overload, techn= ical difficulty or simply business reasons. If a dCDN does this too often f= or a uCDNs liking, than that uCDN can simply decide to no longer do busines= s with that dCDN by not choosing it again for future redirects. >> >> Finally, I think it should be up to the uCDN to decide how it chooses a = dCDN, whether it is based on capability and footprint information or simply= by polling different dCDNs. If that polling is performed by the same mecha= nism that is used by *B*, I don't see any reason not to support that. > You bring up a very good point here. I would probably also agree that "If= that polling is performed by the same mechanism that is used by *B*, I don= 't see any reason not to support that". The thing is that we don't have muc= h time/cycles to spend to make sure the "polling" provides all the needed i= nfo & knobs, and that all the error cases and scenario combinations are ful= ly addressed. But I take your point that, a polling interface developed for= *B* could be used by uCDN to achieve *C*. > > Thanks > > Francois > >> Best regards, >> >> Ray >> >> >> >> >> >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf=20 >> Of Francois Le Faucheur (flefauch) >> Sent: woensdag 25 juli 2012 14:36 >> To: >> Cc: cdni@ietf.org >> Subject: Re: [CDNi] I-D Action:=20 >> draft-lelouedec-cdni-request-routing-00.txt >> >> All, >> >> To help the discussion, we may need to distinguish three (main) modes: >> >> *A* the uCDN uses the Footprint&Cap information (advertised by dCDN) to = select a dCDN. The uCDN redirects to the selected dCDN and considers that h= e is done with request routing. >> >> *B* the uCDN uses the Footprint&Cap information (advertised by dCDN) to = select a dCDN candidate. The uCDN queries the dCDN before redirecting. >> Querying dCDN optionally allows the dCDN to provide to uCDN the final re= direction information so the the enduser experiences a single redirect. >> Querying dCDN optionally allows the uCDN to pick an alternate dCDN if th= e initially selected dCDN cannot handle the request. >> >> *C* the uCDN queries multiple dCDNs on a per-request basis and selects d= CDN based on their responses. In other words, the Footprint&Cap advertiseme= nt is performed via on-demand per-request queries. >> >> >> I think: >> * Scott pointed out that fundamentatly both *A* and *B* have to deal wi= th (typically transient) situations where uCDN thinks dCDN can take a reque= st and dCDN actually cannot handle it. And pointed out that with *A* the tr= ansient period is dictated by the Footprint&Cap advertisement "update speed= " while with *B* it is not. >> * Allan was saying *A* is all he needs and *B* is extra complexity that= he doesn't need. >> * Gilles and lelouedec-cdni-request-routing were saying *C* is bad. >> >> My impression is that there is violent agreement that *A* is to be suppo= rted. I think Allan and Gilles message indicate so. I personally support th= at. I think many people have been discussing that approach. If someone feel= s this is NOT to be supported by CDNI, do let us know. >> >> I think Gilles message below is primarily arguing against *C*. I persona= lly agree that this need not be supported in our initial deliverables. Are = there people arguing this approach is to be supported in the initial delive= rables? >> >> Regarding *B*, I personally see it as quite useful and worth supporting = in Phase 1 (possibly as an option). >> Regarding Allan's points: >> * I agree there is some "scalability" argument (i.e. state+wait-for-dCD= N-response) but it amounts to a web-services call out per request and buys = you reliability of request routing, so I see that as a trade-off that some = CDNs should be able to exercise. >> >> * I don't buy the latency argument because you end up with 2 RTTs in bo= th *A* and *B* (in normal situations where dCDN can handle the request) (i.= e. user-->uCDN, uCDN-->user, user-->dCDN, dCDN-->user versus user-->uCDN, u= CDN-->dCDN, dCDN-->uCDN, uCDN-->user) and in the transient cases where dCDN= cannot handle the request *B* can do as well as *A* (drop the request) or = has the option to differently i.e. re-redirect at the cost of an extra RTT. >> * I don't buy the "loop free mechanism" argument. In *B*, it is easy to= implement a loop detection and even loop prevention (if you want). In *A*,= you have no loop prevention (other than the inherent HTTP/DNS max redirect= /max CNAMEs) Other opinions on *B* are sought. >> >> >> Cheers >> >> Francois >> >> >> On 25 Jul 2012, at 13:39, wrote: >> >>> Hi everyone, >>> >>> I fully agree with Allan's comments. Putting aside the vocabulary ('rec= ursive model' etc), Allan's comment are consistent with the messages that h= ttp://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 tries to = convey. >>> >>> " o Regarding the former process, i.e. related to the "ability" >>> ("enables a Request Routing function in an upstream CDN to query a >>> Request Routing function in a downstream CDN to determine if the >>> downstream CDN is able (...) to accept the delegated content >>> request"), a routing protocol is used to achieve such a process, >>> called routing process, in many other technologies and networks >>> (IP, ATM, etc.). In all these technologies, it is the downstream >>> entity that provides routing information to the upstream entity. >>> The same approach should be applied to CDN interconnection. The >>> reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2, >>> dCDN 3, and then it selects one of them based on their responses") >>> would suffer from latency, signaling overhead and/or lack of >>> reactivity to events that impact the ability of the downstream >>> CDNs to accept delegated content requests." >>> >>> Best regards, >>> -- >>> Gilles >>> >>> >>> -----Message d'origine----- >>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part=20 >>> de GUILLOU, Allan Envoy=E9 : mercredi 25 juillet 2012 12:23 =C0 : Scott= =20 >>> Wainner; cdni@ietf.org Objet : Re: [CDNi] TR: I-D Action: >>> draft-lelouedec-cdni-request-routing-00.txt >>> >>> Hi, >>> >>> With a "recusive model" as you ask if I understand, you expect the dCDN= to send like an "ack" for each request, and if not the uCDN will try to fi= nd the second best dCDN and do the same thing. >>> >>> I think that this model may add complexity and may cause some scalabili= ty problem. You will have to implement timers between request and ack, retr= ansmission mechanism to make sure that request has not been lost, loop free= mechanism, And all this may add latency on all requests and performances p= roblems. >>> >>> In the iterative model, if the dCDN is not able to handle the request, = this request will be lost. It is the same thing in IP network today we do n= ot ask the routing protocol to change when there is saturation somewhere. I= t is the responsibility of each ISP to choose another route to join this de= stination if he want to keep a good quality of service. If a dCDN is overlo= aded, it will stop announcing part of its footprint or uCDN may apply some = policy to force choosing another dCDN. >>> >>> It is right that this second model may not in case of dCDN saturation h= ave the best reactivity, but it is exactly the same thing on the internet t= oday. We can imagine that a poor dCDN which have saturation will be "black = listed" by all the uCDN and the regulation will be done like this. >>> I think recursive model will add complexity all the time for a gain wit= ch is not in my opinion so important and that will not be seen so often. >>> >>> Allan >>> >>>> -----Message d'origine----- >>>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la=20 >>>> part de Scott Wainner Envoy=E9 : lundi 16 juillet 2012 14:23 =C0 : >>>> cdni@ietf.org Objet : Re: [CDNi] TR: I-D Action: >>>> draft-lelouedec-cdni-request-routing- >>>> 00.txt >>>> >>>> On 7/10/12 11:39 AM, Brandenburg, R. (Ray) van wrote: >>>>> Hi Yannick, >>>>> >>>>> We seem to be misunderstanding each other. Maybe this will help=20 >>>>> clarify >>>> my point: >>>>>> Let me try to fully understand your point: >>>>>> Are you really meaning that in this case the dCDN has in reality >>>> absolutely no obligation with regards to the uCDN? >>>>>> Are you really meaning that in this case the dCDN decides alone,=20 >>>>>> in >>>> real time, and for each content request, whether it denies or=20 >>>> accepts to ensure delivery? >>>>> What I mean is that I would like to have a RR Interface at least=20 >>>>> support >>>> a model where for every content request the uCDN asks the dCDN=20 >>>> whether it wants to deliver that particular content item (I believe=20 >>>> you call this a PULL approach). And I would like to allow the dCDN to = be able to say 'No' >>>> on this request (whether it is for purposes or failure, overload,=20 >>>> or any other reason). >>>>>> Are you really meaning that in this case the dCDN decides alone,=20 >>>>>> in >>>> real time, and for each content request, whether it denies or=20 >>>> accepts to ensure delivery, and this even if the dCDN has the=20 >>>> capability to deliver the content? >>>>> Yes. >>>> I think we have to delineate between the iterative and recursive model. >>>> >>>> The recursive model assumes that the client request to the uCDN=20 >>>> will be recursive and the CDN-I RR interface will be used to=20 >>>> provide an answer for each client request. The choice to initiate=20 >>>> the recursion would be determined by the footprint / capabilities.=20= =20 >>>> The ability of the dCDN to execute the specific request would=20 >>>> provide immediate feedback to the uCDN. A dCDN that continues to=20 >>>> advertise the footprint / capability, but frequently or continually=20 >>>> rejects the request via CDN-I RR would be a poor candidate. The=20 >>>> opportunity now arises where the uCDN may elect to choose an=20 >>>> alternate dCDN because its preferred dCDN (according to footprint / ca= pabilities) is 'under-performing'. >>>> >>>> The iterative model, the uCDN blindly redirects the client to the=20 >>>> dCDN based on the footprint / capabilities. What the dCDN does=20 >>>> with the request is somewhat transparent to the uCDN. With the=20 >>>> exception of the CDN-I logging, the uCDN assumes the dCDN is=20 >>>> properly handling the requests that were delegated to the dCDN. If=20 >>>> you are trying to 'tighten' up the case of blind rejections, then=20 >>>> the frequency of the footprint / capabilities advertisements would hav= e to be accelerated. >>>> For the case where the dCDN repeatedly sees requests from the uCDN=20 >>>> that the dCDN can't handle, it should retract its footprint /=20 >>>> capabilities advertisement. Failing to do so would continually=20 >>>> black-hole routing requests which would be indicated in the logging in= formation. >>>> >>>> Either way, you need a feedback loop to avoid dumping routing requests. >>>> >>>> With any feedback loop (recursive routing request or footprint /=20 >>>> capabilities advertisement), you have to be careful about rapid=20 >>>> oscillations and dampening the responses. >>>> >>>> Scott >>>>>> Are you really meaning that in this case the dCDN may possibly=20 >>>>>> response >>>> negatively to all requests for content request redirection=20 >>>> submitted by the uCDN over the CDNI request routing interface?=20 >>>> (i.e. that possibly the uCDN will never be allowed/invited to=20 >>>> redirect a content request to the >>>> dCDN?) >>>>> Yes. Any negative effect this may have on the business=20 >>>>> relationship >>>> between uCDN and dCDN should be handled on the business level. >>>>> Ray >>>>> >>>>> >>>>> On Jul 10, 2012, at 4:33 PM, >>>>> wrote: >>>>> >>>>>> Hi Ray, >>>>>> >>>>>> >>>>>> 1) Ray, quoting your mail: "The current drafts seems to assume=20 >>>>>> some >>>> particular type of contractual agreement between CDNs that might=20 >>>> not always be the case." >>>>>> Please quote the draft. >>>>>> Please let us know exactly to which sentence(s) of the draft you=20 >>>>>> are >>>> referring to. >>>>>> Otherwise it is hard to discuss and comment on your email. >>>>>> >>>>>> >>>>>> 2) Ray, Quoting your mail: "If a dCDN does not live up to its >>>> contractual agreement, this should be something that is handled on=20 >>>> a business level, not on a protocol level." >>>>>> Maybe there is a deep misunderstanding. >>>>>> So I will try to be clear again. >>>>>> We do not propose the CDNI routing interface to be used by the=20 >>>>>> dCDN to >>>> send a message saying "Sorry, but I decide unilaterally to refuse=20 >>>> this content request". >>>>>> We do not propose the CDNI routing interface to be used to handle=20 >>>>>> any >>>> aspect relating to a dCDN deciding unilaterally to stop living up=20 >>>> to its contractual agreement. >>>>>> Please let us know where you saw such an idea in this IETF draft=20 >>>>>> "CDNI >>>> request routing". >>>>>> The only role of the CDNI routing interface is to be used to=20 >>>>>> advertise >>>> CDNI routing information from the downstream CDN to the upstream CDN. >>>>>> And this is the description given in this IETF draft. >>>>>> >>>>>> >>>>>> 3) Ray, quoting your mail: "one example of a contractual=20 >>>>>> agreement >>>> between two CDNs is one in which the uCDN and dCDN have agreed that=20 >>>> the dCDN will deliver some content on behalf of a uCDN, but decide=20 >>>> on a per- request basis whether it wants to do so (and is for=20 >>>> example paid per request). In these cases, the dCDN needs to have=20 >>>> the ability to deny delivery on a per-request basis." >>>>>> Let me try to fully understand your point: >>>>>> Are you really meaning that in this case the dCDN has in reality >>>> absolutely no obligation with regards to the uCDN? >>>>>> Are you really meaning that in this case the dCDN decides alone,=20 >>>>>> in >>>> real time, and for each content request, whether it denies or=20 >>>> accepts to ensure delivery? >>>>>> Are you really meaning that in this case the dCDN decides alone,=20 >>>>>> in >>>> real time, and for each content request, whether it denies or=20 >>>> accepts to ensure delivery, and this even if the dCDN has the=20 >>>> capability to deliver the content? >>>>>> Are you really meaning that in this case the dCDN may possibly=20 >>>>>> response >>>> negatively to all requests for content request redirection=20 >>>> submitted by the uCDN over the CDNI request routing interface?=20 >>>> (i.e. that possibly the uCDN will never be allowed/invited to=20 >>>> redirect a content request to the >>>> dCDN?) >>>>>> >>>>>> 4) Ray, quoting your mail: "Every routing protocol defines the=20 >>>>>> expected >>>> behavior of interconnected elements/networks on a technical level,=20 >>>> not on a business level." >>>>>> Again, this is not what I have written, and this is not the idea=20 >>>>>> we >>>> want to share. >>>>>> I wrote "Every routing protocol has been defined (or at least >>>> configured) so far by considering the expected behavior of the=20 >>>> interconnected elements/networks." >>>>>> That's all. >>>>>> I can rephrase this sentence the following way: "we must know=20 >>>>>> what we >>>> expect to do with a protocol to design it correctly." >>>>>> And IHMO this is an evidence; I don't know any other way to proceed. >>>>>> >>>>>> Besides, let us consider BGP (which is by the way an option=20 >>>>>> proposed by >>>> some IETF members to implement this CDNI routing interface). >>>>>> In IP networks, BGP configurations in IP routers are defined as=20 >>>>>> per the >>>> business relationships (valley free policy, etc.). >>>>>> Of course the business relationships determine the BGP configuration= s. >>>>>> And of course BGP has been designed so as to allow to configure=20 >>>>>> IP >>>> interconnections adequately depending on the corresponding=20 >>>> Customer/provider, sibling and peering contractual agreements. >>>>>> But this does not mean that BGP "defines the expected behavior of >>>> interconnected elements/networks... on a business level." >>>>>> Even if we can indeed infer quite accurately the business=20 >>>>>> relationships >>>> between ISP from the BGP configuration of their IP routers (see=20 >>>> CAIDA project), but this is another story. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Yannick Le Lou=E9dec. >>>>>> >>>>>> >>>>>> >>>>>> -----Message d'origine----- >>>>>> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >>>>>> Envoy=E9 : mardi 10 juillet 2012 15:13 =C0 : LE LOUEDEC Yannick=20 >>>>>> RD-CORE; Ben Niven-Jenkins Cc : Pilarski Marcin - Korpo TP;=20 >>>>>> cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR: I-D >>>>>> Action: draft-lelouedec-cdni-request- >>>> routing-00.txt >>>>>> Hi Yannick, >>>>>> >>>>>> See comments inline. >>>>>> >>>>>> In general: IMO the CDNI interfaces should be abstracted from any=20 >>>>>> kind >>>> of contractual/business agreement that might or might not exist=20 >>>> between a dCDN and uCDN. The current drafts seems to assume some=20 >>>> particular type of contractual agreement between CDNs that might not a= lways be the case. >>>>>> Ray >>>>>> >>>>>> -----Original Message----- >>>>>> From: yannick.lelouedec@orange.com >>>> [mailto:yannick.lelouedec@orange.com] >>>>>> Sent: dinsdag 10 juli 2012 12:01 >>>>>> To: Brandenburg, R. (Ray) van; Ben Niven-Jenkins >>>>>> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne=20 >>>>>> RD-CORE >>>>>> Subject: RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- >>>> routing-00.txt >>>>>> Hi Ray, all, >>>>>> >>>>>> >>>>>> 1) Ray, Quoting your mail: "I don't see why the CDNI Request=20 >>>>>> Routing >>>> interface should state that a dCDN MUST deliver the content if it=20 >>>> has indicated its ability to do so earlier in either a contractual=20 >>>> agreement or in the capability interface." >>>>>> This is not what we have written. >>>>>> Let me try to rephrase simply. >>>>>> >>>>>> A contractual agreement is a contractual agreement. >>>>>> It put in writings the respective obligations of the uCDN and of=20 >>>>>> the >>>> dCDN. >>>>>> The uCDN may redirect any content request to the dCDN as long as=20 >>>>>> it is >>>> in full conformance with the terms of this contractual agreement=20 >>>> (the type of the content request is in full conformance, the=20 >>>> maximum number of content requests per second is respected, etc.). >>>>>> In this case the dCDN may not say "Sorry, but I decide=20 >>>>>> unilaterally to >>>> refuse this content request". >>>>>> [RvB]: This is where we disagree. IMHO, the type of behavior you >>>> describe (the dCDN not living up to its obligation) should not be=20 >>>> enforced by the CDNI Interfaces. If a dCDN does not live up to its=20 >>>> contractual agreement, this should be something that is handled on=20 >>>> a business level, not on a protocol level. >>>>>> Why? Because this is the deal, a contractual agreement is a=20 >>>>>> contractual >>>> agreement! >>>>>> Yet the dCDN may say "I do apologize, but at this time I cannot=20 >>>>>> handle >>>> correctly a certain class of content requests specified in our=20 >>>> contractual agreement" (for example the class of the HTTP content=20 >>>> requests with token from French end users, because of overload=20 >>>> situation, failure, etc.) This is the role of the CDNI routing=20 >>>> interface to provide the uCDN with such information. >>>>>> (And the dCDN may be given a penalty for example if this was=20 >>>>>> agreed in >>>> the terms of the contractual agreement.) >>>>>> >>>>>> 2) Ray, Quoting your mail: "I understand that in most cases, the >>>> contractual agreement might indeed impose this behavior on the dCDN" >>>>>> Please provide the description of an example where this is not=20 >>>>>> the >>>> case. >>>>>> Otherwise the IETF CDNI WG shall indeed consider this is ALWAYS=20 >>>>>> the >>>> case. >>>>>> [RvB]: I can't remember ever seeing such a discussion on the WG list. >>>> Anyway: one example of a contractual agreement between two CDNs is=20 >>>> one in which the uCDN and dCDN have agreed that the dCDN will=20 >>>> deliver some content on behalf of a uCDN, but decide on a=20 >>>> per-request basis whether it wants to do so (and is for example=20 >>>> paid per request). In these cases, the dCDN needs to have the ability = to deny delivery on a per-request basis. >>>>>> And this is an important point to be able to progress in the CDNI >>>> interfaces' specification works. >>>>>> If the contractual agreement does not define clearly the=20 >>>>>> obligations of >>>> the uCDN, it is impossible to dimension adequately the dCDN,=20 >>>> neither to define correctly the CDNI contractual agreements between=20 >>>> the dCDN and the dCDNs of this dCDN. >>>>>> If the contractual agreement does not define clearly the=20 >>>>>> obligations of >>>> the dCDN, the dCDN may do what it wants... even to put in the trash=20 >>>> can any content request it accepted to handle. >>>>>> [RvB]: Exactly, this is something that needs to be discussed on a >>>> business/contractual level and not on a technical level. That is=20 >>>> way IMHO the CDNI Interfaces should not make ANY assumptions on=20 >>>> what was agreed on a contractual level. >>>>>> In both situations it is impossible to ensure any quality of=20 >>>>>> experience >>>> to the end user. >>>>>> >>>>>> 3) Ray, Quoting your mail: "I don't think this type of behavior=20 >>>>>> should >>>> be imposed by the protocol we're developing here." >>>>>> I do not sure I understand this sentence. >>>>>> Every routing protocol has been defined (or at least configured)=20 >>>>>> so far >>>> by considering the expected behavior of the interconnected=20 >>>> elements/networks. >>>>>> [RvB]: Every routing protocol defines the expected behavior of >>>> interconnected elements/networks on a technical level, not on a=20 >>>> business level. Having a dCDN say 'I'm not willing to deliver this=20 >>>> content' is perfectly fine from a technical perspective, although=20 >>>> it could be problematic from a contractual perspective. >>>>>> But maybe I will understand if you provide an example on the=20 >>>>>> point >>>>>> 2 >>>> above. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Yannick Le Lou=E9dec. >>>>>> >>>>>> >>>>>> >>>>>> -----Message d'origine----- >>>>>> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >>>>>> Envoy=E9 : mardi 10 juillet 2012 09:20 =C0 : Ben Niven-Jenkins; LE= =20 >>>>>> LOUEDEC Yannick RD-CORE Cc : Pilarski Marcin >>>> - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR: >>>> I-D >>>> Action: draft-lelouedec-cdni-request-routing-00.txt >>>>>> Hi Yannick, Ben, >>>>>> >>>>>> I tend to agree with Ben here. When reading the draft, I got the >>>> feeling that the draft seems to assume a lot about the relationship=20 >>>> between the uCDN and dCDN. For example, I don't see why the CDNI=20 >>>> Request Routing interface should state that a dCDN MUST deliver the=20 >>>> content if it has indicated its ability to do so earlier in either=20 >>>> a contractual agreement or in the capability interface. I=20 >>>> understand that in most cases, the contractual agreement might=20 >>>> indeed impose this behavior on the dCDN, but I don't think this=20 >>>> type of behavior should be imposed by the protocol we're developing he= re. >>>>>> It was always my assumption that the Request Routing Interface=20 >>>>>> would at >>>> least include the option of allowing the uCDN to query the dCDN for=20 >>>> every content request whether the dCDN is willing to deliver that=20 >>>> particular request. >>>>>> I will send my full review of the draft later. >>>>>> >>>>>> Ray >>>>>> >>>>>> -----Original Message----- >>>>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On=20 >>>>>> Behalf Of >>>> Ben Niven-Jenkins >>>>>> Sent: dinsdag 10 juli 2012 7:38 >>>>>> To: yannick.lelouedec@orange.com >>>>>> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne=20 >>>>>> RD-CORE >>>>>> Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- >>>> routing-00.txt >>>>>> Yannick, >>>>>> >>>>>> Please see inline. >>>>>> >>>>>> On 9 Jul 2012, at 20:05, wrote: >>>>>> >>>>>>> Hi Ben, all, >>>>>>> >>>>>>> Ben, quoting you mail below, "... the downstream CDN could reply=20 >>>>>>> with either "here is how to redirect it"", >>>>>>> >>>>>>> =3D> This is the role of the CDNI DRIS interface to provide the=20 >>>>>>> uCDN >>>> with this information, and we target to make its specification=20 >>>> public before Vancouver meeting so that everyone may read it before=20 >>>> the meeting and get full knowledge of our proposal about this part=20 >>>> of CDNI request routing. >>>>>>> Ben, quoting you mail below, "... or "no I can't/won't take that >>>> content delivery right now", reasons may include the uCDN has=20 >>>> requested a delivery of a protocol the dCDN does not support (possibly= in error). >>>>>>> =3D> This is the role of the CDNI logging interface to provide the= =20 >>>>>>> uCDN >>>> with this information. >>>>>> I agree this information should be logged but the Request Routing >>>> interface (what you call the DRIS) also needs to be able to=20 >>>> indicate a failure. >>>>>> Otherwise the uCDN will 'blindly' redirect the the dCDN and the >>>> delivery will fail leading to poor end user experience. >>>>>>> Ben, quoting you mail below, "... or "no I can't/won't take that >>>> content delivery right now", reasons may include ... the dCDN has=20 >>>> no capacity right now etc." >>>>>>> =3D> This is the role of the CDNI routing interface to provide the= =20 >>>>>>> uCDN >>>> with this information. >>>>>> It is the role of the CDN capability/routing interface to=20 >>>>>> advertise >>>> broad capabilities etc not to give extremely fine grained real-time=20 >>>> information on exactly the state of the dCDN. >>>>>> Even if the capability/routing interface is real-time there are=20 >>>>>> likely >>>> to still be race conditions where we need the dCDN to be about to=20 >>>> indicate a failure to accept a redirect through the request=20 >>>> routing/DRIS interface >>>>>>> So we may conclude we are in line basically, which is a good point. >>>>>>> We just aimed at checking there was a common understanding on=20 >>>>>>> this >>>> point. >>>>>>> The key point for us here is that we don't want this sentence >>>> extracted from draft-ietf-cdni-problem-statement be interpreted as: ". >>>> and the dCDN MUST accept the content request except when it has not=20 >>>> the "ability" to do so." >>>>>> Why not? IMO that is a valid scenario for some use cases. >>>>>> >>>>>>> The fact that the dCDN is temporary unable to handle content=20 >>>>>>> request >>>> correctly is not a valid reason for the dCDN to be discharged of=20 >>>> its obligations to the uCDN. >>>>>>> The contract set between the uCDN and the dCDN remains valid=20 >>>>>>> anyway, >>>> and the obligations of the dCDN as well. >>>>>> Correct, but that contract may not be the same for all uCDNs &=20 >>>>>> dCDNs, >>>> for example a uCDN may not have a guarantee that a dCDN can handle=20 >>>> everything it is requested to handle but the contract may only be=20 >>>> that the dCDN guarantees to handle up to a certain volume of traffic. >>>>>>> The dCDN must announce to the uCDN that it is temporary unable,=20 >>>>>>> as >>>> soon as possible, via the CDNI routing interface. >>>>>>> And the uCDN must take this information into account in its CDN >>>> selection process as soon as possible. >>>>>>> Then if the uCDN decides to continue to redirect content=20 >>>>>>> requests to >>>> the dCDN, the uCDN MAY perfectly do it, but the uCDN knows these=20 >>>> content requests will be lost. >>>>>> What happens in the period between the dCDN being unable to=20 >>>>>> handle >>>> requests and the time it takes to advertise that to the uCDN and=20 >>>> for the uCDN to process & incorporate that new knowledge? Are=20 >>>> requests blindly forwarded to the dCDN which is unable to handle=20 >>>> them leading to poor user experience? >>>>>>> We could even imagine the situation where the uCDN continues to=20 >>>>>>> do it >>>> intentionally, because it has no better option and the content=20 >>>> request will be lost anyway. For example in the case where neither=20 >>>> the uCDN nor the other downstream CDNs of the uCDN cannot manage=20 >>>> correctly the content request, the uCDN could do it intentionally=20 >>>> so as to be able to clearly prove (with CDNI logging information)=20 >>>> that it is the dCDN, not the uCDN, who is at fault. >>>>>>> But, of course, if there are alternative backup options, the=20 >>>>>>> normal >>>> reaction of the uCDN is to stop as soon as possible to redirect=20 >>>> content requests to the dCDN when the uCDN knows that the dCDN is=20 >>>> unable to handle them correctly. >>>>>>> So, to be clear, we would prefer the sentence to be understood as: >>>>>>> ". and the dCDN MUST accept the content request. >>>>>>> And if it cannot handle correctly the redirected content request=20 >>>>>>> it >>>> receives, the content request is lost. >>>>>> What about scenarios where the uCDN has a choice of dCDNs (e.g.=20 >>>>>> two >>>> national-wide CDNs offering services at different costs), the uCDN=20 >>>> may elect to query both dCDNs and decide based on their responses=20 >>>> which one to choose. If the dCDN is unable to satisfy the request=20 >>>> the uCDN needs to know that so that it can fallback to the (more=20 >>>> expensive in this example) dCDN. >>>>>>> For example the dCDN generates a response to the content request=20 >>>>>>> with >>>> an error message, or no response at all. And in parallel the CDNI=20 >>>> logging interface may be used to exchange logs corresponding to this p= roblem. >>>> Anyway the dCDN MAY NOT redirect that content request back towards=20 >>>> the uCDN." >>>>>>> Exactly as in IP networks: IP packets are not sent back towards=20 >>>>>>> the >>>> origin by a downstream router under failure or congestion. >>>>>> In a routed IP network, there is often a small packet loss while=20 >>>>>> the >>>> network re-converges, by enabling the dCDN to refuse a redirection=20 >>>> at CDNI Request Routing/DRIS query time we can reduce that window=20 >>>> by giving the uCDN the option to take an alternative action (e.g.=20 >>>> try another dCDN) while the routing/capability information re-converge= s. >>>>>>> In both networks (IP and CDN), the reason is the same. >>>>>>> If the dCDN redirects back a content request to the uCDN, this >>>> generates a loop. >>>>>> Loop avoidance is a separate issue IMO to whether we should allow=20 >>>>>> a >>>> dCDN to be able to communicate "I am unable/unwilling to take that=20 >>>> content delivery at this time". >>>>>> Regards >>>>>> Ben >>>>>> >>>>>>> To manage this would introduce a very high complexity. >>>>>>> And this would be just to try to save the content requests=20 >>>>>>> redirected >>>> by the uCDN to the dCDN in the timeslot between the time the dCDN=20 >>>> gets down and the time the uCDN takes this failure into account in=20 >>>> its CDN selection process. >>>>>>> It is much better to try to reduce this timeslot as much as=20 >>>>>>> possible, >>>> with routing optimizations (we will propose as soon as possible). >>>>>>> Rather than introducing additional complexities (to manage=20 >>>>>>> redirection >>>> to the uCDN) in the framework. >>>>>>> >>>>>>> By the way, as you know, the IESG has just approved today the=20 >>>>>>> 'Content >>>> Distribution Network Interconnection (CDNI) Problem Statement'=20 >>>> draft as informational RFC. This is a good point. >>>>>>> And, as you may see in the draft "CDNI request routing", we do=20 >>>>>>> not >>>> propose to modify this problem statement draft. >>>>>>> We want know to focus now on getting the specifications of all=20 >>>>>>> CDNI >>>> interfaces ready as soon as possible. >>>>>>> Best regards, >>>>>>> >>>>>>> Yannick Le Lou=E9dec. >>>>>>> >>>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la=20 >>>>>>> part de Ben Niven-Jenkins Envoy=E9 : lundi 9 juillet 2012 20:41 =C0= : >>>>>>> BERTRAND Gilles RD-CORE Cc : cdni@ietf.org; Pilarski Marcin -=20 >>>>>>> Korpo TP; MARREC Anne RD-CORE Objet : Re: [CDNi] TR: I-D Action: >>>>>>> draft-lelouedec-cdni-request-routing-00.txt >>>>>>> >>>>>>> Colleagues, >>>>>>> >>>>>>> I started reading draft-lelouedec-cdni-request-routing-00 and=20 >>>>>>> this >>>> text caught my eye: >>>>>>> Quoting [I-D.ietf-cdni-problem-statement ], "The CDNI Request=20 >>>>>>> Routing interface enables a Request Routing function in an=20 >>>>>>> upstream CDN to query a Request Routing function in a=20 >>>>>>> downstream CDN to determine if the downstream CDN is able (and=20 >>>>>>> willing) to accept the delegated content request". >>>>>>> >>>>>>> The "ability" and the "willingness" of the downstream CDN to=20 >>>>>>> accept the delegated content request match two fully different=20 >>>>>>> processes in CDN interconnection. And the description of both=20 >>>>>>> these processes should be reviewed and clarified for the following= reasons: >>>>>>> >>>>>>> o Regarding the former process, i.e. related to the "ability" >>>>>>> ("enables a Request Routing function in an upstream CDN to=20 >>>>>>> query >>>> a >>>>>>> Request Routing function in a downstream CDN to determine if the >>>>>>> downstream CDN is able (...) to accept the delegated content >>>>>>> request"), a routing protocol is used to achieve such a process, >>>>>>> called routing process, in many other technologies and networks >>>>>>> (IP, ATM, etc.). In all these technologies, it is the downstre= am >>>>>>> entity that provides routing information to the upstream entity. >>>>>>> The same approach should be applied to CDN interconnection. The >>>>>>> reverse approach ("uCDN queries it downstream CDNs dCDN 1,=20 >>>>>>> dCDN >>>> 2, >>>>>>> dCDN 3, and then it selects one of them based on their >>>> responses") >>>>>>> would suffer from latency, signaling overhead and/or lack of >>>>>>> reactivity to events that impact the ability of the downstream >>>>>>> CDNs to accept delegated content requests. >>>>>>> >>>>>>> o Regarding the latter process, i.e. related to the "willingness" >>>>>>> ("enables a Request Routing function in an upstream CDN to=20 >>>>>>> query >>>> a >>>>>>> Request Routing function in a downstream CDN to determine if the >>>>>>> downstream CDN (...) is willing (...)to accept the delegated >>>>>>> content request"), it is to be noted that the relationship >>>> between >>>>>>> a uCDN and a dCDN is always in the frame of a contractual >>>>>>> agreement between the administrative entity owning the uCDN, >>>>>>> acting as the customer, and the administrative entity owning the >>>>>>> dCDN, acting as the service provider. Therefore, consider a ca= se >>>>>>> where >>>>>>> >>>>>>> * the uCDN has a content request to redirect which is in full >>>>>>> conformance with the terms of this contractual agreement,=20 >>>>>>> and >>>>>>> >>>>>>> * the uCDN has selected this dCDN. >>>>>>> >>>>>>> As the uCDN knows, thanks to the routing information=20 >>>>>>> exchanged >>>> via >>>>>>> the aforementioned routing process, that the dCDN is able to >>>>>>> accept this content request, the uCDN MAY redirect the content >>>>>>> request to the dCDN and the dCDN MUST accept the content reques= t. >>>>>>> Exchanging over the CDNI Request Routing interface information >>>>>>> about the "willingness" of the dCDN to accept the content reque= st >>>>>>> is not relevant. >>>>>>> >>>>>>> I think you might be over thinking what we wrote in the problem >>>> statement. >>>>>>> What was in the problem statement was meant to convey that an=20 >>>>>>> upstream >>>> CDN could make a request to a downstream CDN to say "how do I=20 >>>> redirect this request to you" and the downstream CDN could reply=20 >>>> with either "her is how to redirect it", or "no I can't/won't take=20 >>>> that content delivery right now", reasons may include the uCDN has=20 >>>> requested a delivery of a protocol the dCDN does not support=20 >>>> (possibly in error) or the dCDN has no capacity right now etc. >>>>>>> Ben >>>>>>> >>>>>>> On 9 Jul 2012, at 18:00, wrote: >>>>>>> >>>>>>>> Hi everyone, >>>>>>>> >>>>>>>> We have just submitted the draft below. We are convinced that=20 >>>>>>>> it will >>>> help the WG to progress on the CDNI routing issues. >>>>>>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing >>>>>>>> -0 >>>>>>>> 0 >>>>>>>> >>>>>>>> Any feedback is very welcome. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Gilles >>>>>>>> >>>>>>>> >>>>>>>> -----Message d'origine----- >>>>>>>> De : i-d-announce-bounces@ietf.org=20 >>>>>>>> [mailto:i-d-announce-bounces@ietf.org] De la part de=20 >>>>>>>> internet-drafts@ietf.org Envoy=E9 : lundi 9 juillet 2012 18:55 =C0= : >>>>>>>> i-d-announce@ietf.org Objet : I-D Action: >>>>>>>> draft-lelouedec-cdni-request-routing-00.txt >>>>>>>> >>>>>>>> >>>>>>>> A New Internet-Draft is available from the on-line=20 >>>>>>>> Internet-Drafts >>>> directories. >>>>>>>> >>>>>>>> Title : CDNI Request Routing >>>>>>>> Author(s) : Yannick Le Louedec >>>>>>>> Anne Marrec >>>>>>>> Gilles Bertrand >>>>>>>> Marcin Pilarski >>>>>>>> Filename : draft-lelouedec-cdni-request-routing-00.txt >>>>>>>> Pages : 30 >>>>>>>> Date : 2012-07-09 >>>>>>>> >>>>>>>> Abstract: >>>>>>>> The present document proposes to clarify the CDNI Request=20 >>>>>>>> Routing interface introduced in [I-D.ietf-cdni-framework] and >>>>>>>> [I-D.ietf-cdni- problem-statement], as well as related terminology. >>>>>>>> >>>>>>>> In particular the present document proposes to split the CDNI=20 >>>>>>>> Request Routing interface into two separate interfaces with=20 >>>>>>>> clearer roles, named respectively CDNI Routing interface and=20 >>>>>>>> CDNI Downstream Resource Identifier Signaling interface (CDNI DRIS= interface). >>>>>>>> >>>>>>>> This part of the CDN interconnection framework the IETF has=20 >>>>>>>> been referring to so far with the term "CDNI Request Routing"=20 >>>>>>>> is just another routing, signaling and forwarding problem in a=20 >>>>>>>> long series of the telecommunication history. For example, one=20 >>>>>>>> can draw a direct analogy between the IP/MPLS-TE framework and=20 >>>>>>>> the CDN interconnection framework. >>>>>>>> >>>>>>>> In addition, this document recommends that the specification of=20 >>>>>>>> ALL CDN interconnection interfaces in the scope of the CDNI=20 >>>>>>>> IETF WG relies on the equivalent concept to IP prefix for CDN=20 >>>>>>>> interconnection, named 'contentRequestScope'. This highly=20 >>>>>>>> useful and powerful concept SHALL be used to simplify the=20 >>>>>>>> specification of ALL CDN interconnection interfaces, as well as=20 >>>>>>>> to ensure performance and scalability in CDN interconnection. >>>>>>>> >>>>>>>> All these proposals can be smoothly integrated in the WG=20 >>>>>>>> drafts, especially [I-D.ietf-cdni-framework] and=20 >>>>>>>> [I-D.ietf-cdni-requirements], as they essentially propose >>>>>>>> (useful) clarifications of the existing framework. >>>>>>>> >>>>>>>> >>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>> https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-r >>>>>>>> ou >>>>>>>> ting >>>>>>>> >>>>>>>> There's also a htmlized version available at: >>>>>>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing >>>>>>>> -0 >>>>>>>> 0 >>>>>>>> >>>>>>>> >>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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=20 >>>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>>> >>>>>>>> _______________________________________________________________ >>>>>>>> __ ____ ____________________________________________________ >>>>>>>> >>>>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>>>> informations confidentielles ou privilegiees et ne doivent donc=20 >>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si=20 >>>>>>>> vous avez recu ce message par erreur, veuillez le signaler a=20 >>>>>>>> l'expediteur et le detruire ainsi >>>> que les pieces jointes. Les messages electroniques etant=20 >>>> susceptibles d'alteration, France Telecom - Orange decline toute=20 >>>> responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>> This message and its attachments may contain confidential or=20 >>>>>>>> privileged information that may be protected by law; they=20 >>>>>>>> should not >>>> be distributed, used or copied without authorisation. >>>>>>>> If you have received this email in error, please notify the=20 >>>>>>>> sender >>>> and delete this message and its attachments. >>>>>>>> As emails may be altered, France Telecom - Orange is not liable=20 >>>>>>>> for >>>> messages that have been modified, changed or falsified. >>>>>>>> Thank you. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >>>>>>> ________________________________________________________________ >>>>>>> __ ____ ___________________________________________________ >>>>>>> >>>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>>> informations confidentielles ou privilegiees et ne doivent donc=20 >>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si=20 >>>>>>> vous avez recu ce message par erreur, veuillez le signaler a=20 >>>>>>> l'expediteur et le detruire ainsi >>>> que les pieces jointes. Les messages electroniques etant=20 >>>> susceptibles d'alteration, France Telecom - Orange decline toute=20 >>>> responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>>>>> This message and its attachments may contain confidential or=20 >>>>>>> privileged information that may be protected by law; they should=20 >>>>>>> not >>>> be distributed, used or copied without authorisation. >>>>>>> If you have received this email in error, please notify the=20 >>>>>>> sender and >>>> delete this message and its attachments. >>>>>>> As emails may be altered, France Telecom - Orange is not liable=20 >>>>>>> for >>>> messages that have been modified, changed or falsified. >>>>>>> Thank you. >>>>>>> >>>>>> _______________________________________________ >>>>>> CDNi mailing list >>>>>> CDNi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>> This e-mail and its contents are subject to the DISCLAIMER at >>>> http://www.tno.nl/emaildisclaimer >>>>>> >>>>>> >>>> ___________________________________________________________________ >>>> __ _ ____ _______________________________________________ >>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>> informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>>> ce message par erreur, veuillez le signaler a l'expediteur et le=20 >>>> detruire ainsi que les pieces jointes. Les messages electroniques=20 >>>> etant susceptibles d'alteration, France Telecom - Orange decline=20 >>>> toute responsabilite si ce message a ete altere, deforme ou falsifie. = Merci. >>>>>> This message and its attachments may contain confidential or=20 >>>>>> privileged >>>> information that may be protected by law; they should not be=20 >>>> distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the=20 >>>>>> sender and >>>> delete this message and its attachments. >>>>>> As emails may be altered, France Telecom - Orange is not liable=20 >>>>>> for >>>> messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>> >>>>>> >>>>>> >>>> ___________________________________________________________________ >>>> __ _ ____ _______________________________________________ >>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>> informations >>>> confidentielles ou privilegiees et ne doivent donc >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 >>>>>> avez >>>> recu ce message par erreur, veuillez le signaler >>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les >>>> messages electroniques etant susceptibles d'alteration, >>>>>> France Telecom - Orange decline toute responsabilite si ce=20 >>>>>> message a >>>> ete altere, deforme ou falsifie. Merci. >>>>>> This message and its attachments may contain confidential or=20 >>>>>> privileged >>>> information that may be protected by law; >>>>>> they should not be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the=20 >>>>>> sender and >>>> delete this message and its attachments. >>>>>> As emails may be altered, France Telecom - Orange is not liable=20 >>>>>> for >>>> messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> ____________________________________________________________________ >>> __ ___________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>> ce message par erreur, veuillez le signaler a l'expediteur et le detrui= re ainsi que les pieces jointes. Les messages electroniques etant susceptib= les d'alteration, France Telecom - Orange decline toute responsabilite si c= e message a ete altere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or=20 >>> privileged information that may be protected by law; they should not be= distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and = delete this message and its attachments. >>> As emails may be altered, France Telecom - Orange is not liable for mes= sages that have been modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> 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 > . > _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From li.mian@zte.com.cn Thu Jul 26 02:48:13 2012 Return-Path: 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 AD9D021F86DC for ; Thu, 26 Jul 2012 02:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.79 X-Spam-Level: X-Spam-Status: No, score=-92.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 eUjrQPQEPJwR for ; Thu, 26 Jul 2012 02:48:12 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 93A2521F869F for ; Thu, 26 Jul 2012 02:48:11 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 107231050216600; Thu, 26 Jul 2012 17:38:17 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 67879.2492587212; Thu, 26 Jul 2012 17:48:06 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q6Q9lsHX075560; Thu, 26 Jul 2012 17:47:54 +0800 (GMT-8) (envelope-from li.mian@zte.com.cn) In-Reply-To: To: "Francois Le Faucheur (flefauch)" , bhumip.khasnabish@zteusa.com, "cdni@ietf.org" , jin.weiyi@zte.com.cn MIME-Version: 1.0 X-KeepSent: 80B825B7:361F4A85-48257A47:00274841; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: li.mian@zte.com.cn Date: Thu, 26 Jul 2012 17:47:29 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-07-26 17:47:50, Serialize complete at 2012-07-26 17:47:50 Content-Type: multipart/alternative; boundary="=_alternative 0035D28F48257A47_=" X-MAIL: mse02.zte.com.cn q6Q9lsHX075560 Subject: [CDNi] =?gb2312?b?tPC4tDogQ29tbWVudHMgb24gZHJhZnQtamluLWNkbmkt?= =?gb2312?b?Y29udGVudC1kZWR1cGxpY2F0aW9uLW9wdGltaXphdGlvbi0wMS50eHQ=?= 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 09:48:13 -0000 This is a multipart message in MIME format. --=_alternative 0035D28F48257A47_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVhciBGcmFuY29pcywNCg0KVGhhbmsgeW91IGZvciB5b3VyIGtpbmQgcmV2aWV3IGFuZCBjb21t ZW50cyBvbiBjb250ZW50IGRlLWR1cGxpY2F0aW9uIA0KZHJhZnQuIFBsZWFzZSBzZWUgbXkgZmVl ZGJhY2sgYmVsb3c6DQoNCjEuIFlvdSBhcmUgcmlnaHQuIFRoZSBjb250ZW50IGR1cGxpY2F0aW9u IGlzc3VlIG9jY3VycyBpbiBib3RoIA0KcHJlLXBvc2l0aW9uaW5nIGNhc2UgYW5kIGNvbnRlbnQg YWNxdWlzaXRpb24gY2FzZSB3aXRoIG5vIGRpZmZlcmVuY2UuIFRoZSANCmNvbnRlbnQgaXRlbSBj YW4gYmUgZGVsaXZlcmVkIGZyb20gdUNETiB0byBkQ0ROIHZpYSBlaXRoZXIgd2F5IGFuZCB0aGVu IA0KcmVxdWVzdGVkIHRvIGRvd25sb2FkIHRvIGRDRE4gYWdhaW4gdmlhIGVpdGhlciB3YXkuIFRo ZSBzb2x1dGlvbnMgZm9yIGJvdGggDQpjYXNlcyBhcmUgdGhlIHNhbWUuIEZpcnN0bHksIHRoZSBD b250ZW50LUlEIGlzIGRlbGl2ZXJlZCBmcm9tIHVDRE4gdG8gZENETiANCmZvciBzdG9yYWdlLiBT ZWNvbmRseSwgaW4gZWl0aGVyIHByZS1wb3NpdGlvbmluZyBwcm9jZWR1cmUgb3IgY29udGVudCAN CmFjcXVpc2l0aW9uIHByb2NlZHVyZSwgYmVmb3JlIHVDRE4gZGVsaXZlcnMgdGhlIGFjdXRhbCBj b250ZW50IHRvIGRDRE4sIA0KQ29udGVudC1JRCBpcyBleGNoYW5nZWQgdG8gY2hlY2sgdGhlIGF2 YWlsYWJpbGl0eSBvZiB0aGUgcmVxdWVzdGVkIGNvbnRlbnQgDQppbiBkQ0ROLiBUaGlyZGx5LCBk Q0ROIGRldGVybWluZXMgd2hldGhlciB0byBkb3dubG9hZCB0aGUgYWN0dWFsIGNvbnRlbnQgDQpv ciBub3QuIEFzIGZvciB0aGUgZmlyc3QgcG9pbnQgeW91IG1lbnRpb25lZCBiZWxvdywgZG8geW91 IG1lYW4gdGhpcyBkcmFmdCANCmxpc3RzIGRpZmZlcmVudCBwcm9jZWR1cmVzIGluIHNlY3Rpb24g NC4zIGZvciBwcmUtcG9zaXRpb25pbmcgYW5kIGZvciANCmNvbnRlbnQgYWNxdWlzdGlvbiBzZXBh cmF0ZWx5PyBXZSBkbyBub3QgaW50ZW5kIHRvIHNlcGFyYXRlIHRoZSBwcm9ibGVtIA0KYW5kIHRo ZSBzb2x1dGlvbi4gV2UgZG8gc28gYmVjYXVzZSB0aGUgcHJlLXBvc2l0aW9uaW5nIHByb2NlZHVy ZSBhbmQgdGhlIA0KY29udGVudCBhY3F1aXNpdGlvbiBwcm9jZWR1cmUgYXJlIHR3byBwcm9jZWR1 cmVzIGFuZCB3ZSBkZXNjcmliZSB0aGVtIGluIA0KdHdvIHN1Yi1zZWN0aW9ucyBpbiBvcmRlciB0 byBtYWtlIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgc29sdXRpb24gY2xlYXJlci4NCg0KMi4gQXMg Zm9yIHRoZSBjb250ZW50IHJlbW92YWwsIHllcywgaXQgaXMgYW4gaW50ZXJlc3RpbmcgYXNwZWN0 IHRoYXQgd2UgDQpkaWQgbm90IGRpc2N1c3MgaW4gb3VyIHByb3Bvc2FsLiBJdCBpcyBvdXIgb3Bp bmlvbiB0aGF0IG9ubHkgdGhlIHVDRE4gdGhhdCANCmRlbGl2ZXJlZCB0aGUgY29udGVudCBpdGVt IHRvIHRoZSBkQ0ROIGlzIHByb3BlciBhbmQgaXMgYXV0aG9yaXplZCB0byBzZW5kIA0KdGhlIHJl bW92YWwgY29tbWFuZCB0byBkZWxldGUgdGhlIGNvbnRlbnQuIENvbnNpZGVyaW5nIHRoYXQgQ0RO IEEgYW5kIENETiANCkIgYXJlIHVDRE5zIG9mIENETiBDLCBDRE4gQSBkZWxpdmVycyBhIGNvbnRl bnQgaXRlbSB0byBDRE4gQyB2aWEgDQpwcmUtcG9zaXRpb25pbmcgcHJvY2VkdXJlIG9yIENETiBD IGFjcXVpcmVzIGEgY29udGVudCBpdGVtIGZyb20gQ0ROIEEgdmlhIA0KY29udGVudCBhY3F1aXNp dGlvbiBwcm9jZWR1cmUuIENETiBBIGlzIGF1dGhvcmlzZWQgdG8gZGVsZXRlIHRoZSBjb250ZW50 LiANCkFzIGZvciBDRE4gQiwgcmUtc2VuZGluZyB0aGUgY29udGVudCB3aWxsIG5vdCBvY2N1ciBp ZiB0aGUgc29sdXRpb24gaW4gDQp0aGlzIGRyYWZ0IGlzIGFwcGxpZWQuIFNvIENETiBCIHdpbGwg bm90IGluaXRpYXRlIHRoZSByZW1vdmFsIGFjdGlvbi4gSG93IA0KZG8geW91IHRoaW5rPw0KVGhp cyBpcyBhIG1pc3NpbmcgcGFydCB0aGF0IHdlIG5lZWQgdG8gY2xhcmlmeSBpbiB0aGUgZHJhZnQu IFRoYW5rIHlvdSBmb3IgDQpwb2ludGluZyBpdCBvdXQuDQoNCjMuIEFjdHVhbGx5IGFzIHdoYXQg eW91IGV4cGxhaW5lZCBiZWxvdyBpcyBqdXN0IHdoYXQgd2Ugd2FudCB0byBwcm9wb3NlIGluIA0K b3VyIGRyYWZ0IGJ1dCB3ZSBkaWQgbm90IG1ha2UgaXQgY2xlYXIgZW5vdWdoLiBTbyB0aGF0IG1h a2VzIHlvdSBjb25mdXNlZC4gDQpDb250ZW50LUlEIGFzIGFuIG9wdGlvbmFsIG1ldGFkYXRhIG9i amVjdCwgaXMgZXhhY3RseSBvbmUgaW1wb3J0YW50IHBhcnQgDQp3ZSBhcmUgcHJvcG9zaW5nLiBU aGUgY29udGVudC1JRCBpcyBkaXN0cmlidXRlZCBhcyBhbiBvcHRpb25hbCBjb250ZW50IA0KbWV0 YWRhdGEgd2l0aC93aXRob3V0IHRoZSBhY3R1YWwgY29udGVudCBpdGVtIGZyb20gdUNETiB0byBk Q0ROIGZvciANCnN0b3JhZ2UuIFRoZW4gZm9yIGV4YW1wbGUsIGlmIHRoZSB1Q0ROIHdhbnRzIHRv IHByZS1wb3NpdGlvbiBjb250ZW50IA0KaXRlbXMsIGNvcnJlc3BvbmRpbmcgY29udGVudC1JRCBh bmQgUmVzb3VyY2UgSUQgYXJlIHNlbnQgaW4gdGhlIA0KcHJlLXBvc2l0aW9uaW5nIHJlcXVlc3Qg bWVzc2FnZSBmcm9tIHVDRE4gdG8gZENETi4gVGhlbiB0aGUgZENETiBjYW4gdXNlIA0KdGhpcyBj b250ZW50LUlEIGFzIGFuIGluZGV4IHRvIGxvb2sgdXAgaXRzIHN0b3JlZCBtZXRhZGF0YSBpbmZv cm1hdGlvbiB0byANCmNoZWNrIHdoZXRoZXIgdGhlIGNvbnRlbnQgaXRlbSBoYXMgYmVlbiBzdG9y ZWQgb3Igbm90LiBUaGUgY29udGVudCANCmFjcXVpc2l0aW9uIHByb2NlZHVyZSBpcyBzaW1pbGFy IHRvIGFib3ZlIG9uZS4gDQpJIHdpbGwgbWFrZSB0aGUgZGVzY3JpcHRpb24gY2xlYXJlciBpbiB0 aGUgdXBkYXRlZCB2ZXJzaW9uLiBUaGFuayB5b3V+DQoNCiJGcmFuY29pcyBMZSBGYXVjaGV1ciAo ZmxlZmF1Y2gpIiA8ZmxlZmF1Y2hAY2lzY28uY29tPiDQtNPaIDIwMTItMDctMjQgDQoyMjoyOTow NDoNCg0KPiBIaSwNCj4gDQo+IEEgZmV3IGNvbW1lbnRzIG9uIGRyYWZ0LWppbi1jZG5pLWNvbnRl bnQtZGVkdXBsaWNhdGlvbi1vcHRpbWl6YXRpb24gDQpiZWxvdy4NCj4gDQo+ICogaW4gc2V2ZXJh bCBwbGFjZXMsIHRoZSBkb2N1bWVudCBkaXNjdXNzZXMgc2VwYXJhdGVseSBwcmUtcG9zaXRpb24g DQo+IHZlcnN1cyBkeW5hbWljIGFjcXVpc2l0aW9uLiBJIGRvbid0IHRoaW5rIHRoZXJlIG5lZWRz IHRvIGJlIGFueSANCj4gZGlmZmVyZW5jZSBpbiB0aGUgcHJvYmxlbSBvciB0aGUgc29sdXRpb24g Zm9yIHRoZSB0d28gY2FzZXMuIA0KPiBUaGUgaXNzdWUgaXM6IHdoZW4gYSBkQ0ROIG5lZWRzIHRv IGdldCBhIGNvbnRlbnQgKHdoZXRoZXIgZm9yIHByZS0NCj4gcG9zaXRpb24gb3IgZm9yIGR5bmFt aWMgYWNxdWlzaXRpb24pOg0KPiAgICAxKSBjYW4gaXQgYXZvaWQgcmUtc3RvcmluZyBhIDJuZCBj b3B5IG9mIHNhbWUgY29udGVudA0KPiAgICAyKSBjYW4gaXQgYXZvaWQgcmVxdWVzdGluZyB0aGF0 IDJuZCBjb3B5Lg0KPiBZb3UgbWF5IHdhbnQgdG8gY29uc2lkZXIgZGlzY3Vzc2luZyB0aGUgcHJv YmxlbS9zb2x1dGlvbiANCj4gaW5kZXBlbmRlbnRseSBvZiB0aGUgYWNxdWlzaXRpb24gbWV0aG9k Lg0KPiANCj4gDQo+ICogc2VjdGlvbiA0LjMuMyBkaXNjdXNzZXMgY29udGVudCByZW1vdmFsIGJ1 dCBkb2VzIG5vdCBzZWVtIHRvIA0KPiBkaXNjdXNzIG9uZSBpbnRlcmVzdGluZyBhc3BlY3Qgb2Yg Y29udGVudCByZWR1cGxpY2F0aW9uOiB3aGVuIGEgZENETg0KPiBlbmRzIHVwIHN0b3JpbmcgYSBn aXZlbiBjb250ZW50IG9uIGJlaGFsZiBvZiB0d28gdUNETnMsIGFuZCB0aGVuIG9uZQ0KPiB1Q0RO IHRyaWdnZXJzIGNvbnRlbnQgcmVtb3ZhbCBidXQgdGhlIG90aGVyIG9uZSBkb2VzIG5vdCwgZG8g eW91IA0KPiByZW1vdmUgdGhlIGNvbnRlbnQgb3Igbm90Pw0KPiBDYW4geW91IGRpc2N1c3MgdGhh dCB0b3BpYz8NCj4gDQo+IA0KPiAqIEkgd2FzIHBpY3R1cmluZyB0aGF0IHRoZSBDb250ZW50LUlE IHdvdWxkIGJlIGFzc29jaWF0ZWQgdG8gYSBnaXZlbg0KPiBjb250ZW50IHJlcXVlc3QgdGhyb3Vn aCB0aGUgQ0ROSSBtZXRhZGF0YS4gSW4gb3RoZXIgd29yZHMsIHdlIGNvdWxkIA0KPiBkZWZpbmUg YW4gb3B0aW9uYWwgTWV0YWRhdGEgb2JqZWN0IGNvbnRhaW5pbmcgdGhlIENvbnRlbnQtSUQuIFRo ZW4gDQo+IHdoZW5ldmVyIGFuIGFjdGlvbiBpcyBuZWVkZWQgKGUuZy4gY29udGVudCBhY3F1aXNp dGlvbikgZm9yIGEgDQo+IHJlc291cmNlIFVSSSwgdGhlIENETiB3b3VsZCBmaXJzdCBhY3F1aXJl IHRoZSBtZXRhZGF0YSAoYXMgdXN1YWwpIA0KPiBhbmQgdGhlbiBnZXQgdGhlIENvbnRlbnQtSUQu IEl0IGNhbiB0aGVuIG1ha2UgdGhlIGRldGVybWluYXRpb24gb24gDQo+IHdoZXRoZXIgdGhlIGNv bnRlbnQgaXMgYWxyZWFkeSBzdG9yZWQuDQo+IElzIHRoaXMgd2hhdCB5b3UgaGF2ZSBpbiBtaW5k IGFsc28/DQo+IEkgZ290IGEgbGl0dGxlIGNvbmZ1c2VkIGJ5IHRoaXMgdGV4dDogIlJlY2Vpdmlu ZyB0aGUgbWVzc2FnZSwgdGhlIA0KPiBkQ0ROIHVzZXMgdGhlIENvbnRlbnQgSWRlbnRpZmllciB0 byBsb29rIHVwIHRhcmdldCBtZXRhZGF0YS4iIFRoaXMgDQo+IHN1Z2dlc3RzIHRoYXQgdGhlIG1l dGFkYXRhIGFyZSBoYW5naW5nIG9mZiB0aGUgQ29udGVudCBJRC4gSSB0aGluayANCj4geW91IG5l ZWQgdG8gaGF2ZSB0aGUgbWV0YWRhdGEgaGFuZ2luZyBvZmYgdGhlIHJlc291cmNlIFVSTCwgaW4g DQo+IHBhcnRpY3VsYXIgYmVjYXVzZSB5b3UgbmVlZCBzZXBhcmF0ZSBtZXRhZGF0YSBwZXIgdUNE TiAoZXZlbiBmb3IgdGhlDQo+IHNhbWUgY29udGVudCkuIEFuZCBJIHRoaW5rIHRoZSBDb250ZW50 LUlEIGlzIHRoZW4gY29udmV5ZWQgaW5zaWRlIA0KPiB0aGUgY29udGVudCBtZXRhZGF0YSwNCj4g RG9lcyB0aGF0IG1ha2Ugc2Vuc2UgPw0KPiANCj4gQ2hlZXJzDQo+IA0KPiBGcmFuY29pcw0KPiAN Cj4gDQo+IA0KPiBPbiAxOSBKdW4gMjAxMiwgYXQgMDU6MTcsIEludGVybmV0LURyYWZ0c0BpZXRm Lm9yZyB3cm90ZToNCj4gDQo+ID4gDQo+ID4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxh YmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+IGRpcmVjdG9yaWVzLg0KPiA+ IA0KPiA+IA0KPiA+ICAgIFRpdGxlICAgICAgICAgICA6IENvbnRlbnQgRGUtZHVwbGljYXRpb24g Zm9yIENETmkgT3B0aW1pemF0aW9uDQo+ID4gICAgQXV0aG9yKHMpICAgICAgIDogV2VpWWkgSmlu DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgIE1pYW4gTGkNCj4gPiAgICAgICAgICAgICAg ICAgICAgICAgICAgQmh1bWlwIEtoYXNuYWJpc2gNCj4gPiAgICBGaWxlbmFtZSAgICAgICAgOiBk cmFmdC1qaW4tY2RuaS1jb250ZW50LWRlZHVwbGljYXRpb24tDQo+IG9wdGltaXphdGlvbi0wMS50 eHQNCj4gPiAgICBQYWdlcyAgICAgICAgICAgOiAxNw0KPiA+ICAgIERhdGUgICAgICAgICAgICA6 IDIwMTItMDYtMTgNCj4gPiANCj4gPiBBYnN0cmFjdDoNCj4gPiAgIFJlY2VudCBleHBsb3NpdmUg Z3Jvd3RoIG9mIGNvbnRlbnQgZGVsaXZlcnkvZGlzdHJpYnV0aW9uIG5ldHdvcmtzDQo+ID4gICAo Q0ROcykgYW5kIHRoZWlyIGludGVyY29ubmVjdGlvbiBhcmUgY2F1c2luZyB1bmludGVuZGVkIHJl cGV0aXRpb24gDQpvZg0KPiA+ICAgY29udGVudCBzdG9yYWdlIGluIHRoZSBzYW1lIGRDRE4uICBU aGlzIGNhbiBiZSBhdm9pZGVkIGJ5IHVzaW5nIGENCj4gPiAgIHN1aXRhYmxlIGRlLWR1cGxpY2F0 aW9uIG1lY2hhbmlzbS4gIFRoaXMgZG9jdW1lbnQgZXhwbG9yZXMgdGhlDQo+ID4gICBzY2VuYXJp b3Mgd2hpY2ggY3JlYXRlIHRoZSBwcm9ibGVtcywgYW5kIHRoZW4gZGlzY3Vzc2VzIHRoZQ0KPiA+ ICAgYXBwcm9hY2hlcyB0byBlbGltaW5hdGUgdGhlIGR1cGxpY2F0ZWQgdHJhbnNtaXNzaW9uIG9m IHRoZSBzYW1lDQo+ID4gICBjb250ZW50IGZyb20gdUNETihzKSB0byBkQ0ROIGluIENETmkgbmV0 d29ya3MuICBUbyBpbXBsZW1lbnQgdGhlDQo+ID4gICBvcHRpbWl6YXRpb24sIHNvbWUgZW5oYW5j ZW1lbnRzIHRvIHRoZSBDRE5pIG1ldGFkYXRhIG1vZGVsIGFuZA0KPiA+ICAgaW50ZXJmYWNlIGFy ZSByZXF1aXJlZC4NCj4gPiANCj4gPiANCj4gPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMg cGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1qaW4tY2RuaS1jb250ZW50LQ0KPiBkZWR1cGxpY2F0aW9uLW9wdGltaXphdGlv bg0KPiA+IA0KPiA+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0 Og0KPiA+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWppbi1jZG5pLWNvbnRlbnQt ZGVkdXBsaWNhdGlvbi0NCj4gb3B0aW1pemF0aW9uLTAxDQo+ID4gDQo+ID4gQSBkaWZmIGZyb20g cHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+ID4gaHR0cDovL3Rvb2xzLmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1qaW4tY2RuaS1jb250ZW50LQ0KPiBkZWR1cGxpY2F0aW9u LW9wdGltaXphdGlvbi0wMQ0KPiA+IA0KPiA+IA0KPiA+IEludGVybmV0LURyYWZ0cyBhcmUgYWxz byBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPiBmdHA6Ly9mdHAuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzLw0KPiA+IA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdA0KPiA+IEkt RC1Bbm5vdW5jZUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaS1kLWFubm91bmNlDQo+ID4gSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6 Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCj4gPiBvciBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0 Zi8xc2hhZG93LXNpdGVzLnR4dA0KPiANCj4gDQoNCg== --=_alternative 0035D28F48257A47_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkRlYXIgRnJhbmNvaXMsPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFuayB5b3UgZm9y IHlvdXIga2luZCByZXZpZXcgYW5kIGNvbW1lbnRzDQpvbiBjb250ZW50IGRlLWR1cGxpY2F0aW9u IGRyYWZ0LiBQbGVhc2Ugc2VlIG15IGZlZWRiYWNrIGJlbG93OjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+MS4gWW91IGFyZSByaWdodC4gVGhlIGNvbnRl bnQgZHVwbGljYXRpb24NCmlzc3VlIG9jY3VycyBpbiBib3RoIHByZS1wb3NpdGlvbmluZyBjYXNl IGFuZCBjb250ZW50IGFjcXVpc2l0aW9uIGNhc2UNCndpdGggbm8gZGlmZmVyZW5jZS4gVGhlIGNv bnRlbnQgaXRlbSBjYW4gYmUgZGVsaXZlcmVkIGZyb20gdUNETiB0byBkQ0RODQp2aWEgZWl0aGVy IHdheSBhbmQgdGhlbiByZXF1ZXN0ZWQgdG8gZG93bmxvYWQgdG8gZENETiBhZ2FpbiB2aWEgZWl0 aGVyDQp3YXkuIFRoZSBzb2x1dGlvbnMgZm9yIGJvdGggY2FzZXMgYXJlIHRoZSBzYW1lLiBGaXJz dGx5LCB0aGUgQ29udGVudC1JRA0KaXMgZGVsaXZlcmVkIGZyb20gdUNETiB0byBkQ0ROIGZvciBz dG9yYWdlLiBTZWNvbmRseSwgaW4gZWl0aGVyIHByZS1wb3NpdGlvbmluZw0KcHJvY2VkdXJlIG9y IGNvbnRlbnQgYWNxdWlzaXRpb24gcHJvY2VkdXJlLCBiZWZvcmUgdUNETiBkZWxpdmVycyB0aGUg YWN1dGFsDQpjb250ZW50IHRvIGRDRE4sIENvbnRlbnQtSUQgaXMgZXhjaGFuZ2VkIHRvIGNoZWNr IHRoZSBhdmFpbGFiaWxpdHkgb2YgdGhlDQpyZXF1ZXN0ZWQgY29udGVudCBpbiBkQ0ROLiBUaGly ZGx5LCBkQ0ROIGRldGVybWluZXMgd2hldGhlciB0byBkb3dubG9hZA0KdGhlIGFjdHVhbCBjb250 ZW50IG9yIG5vdC4gQXMgZm9yIHRoZSBmaXJzdCBwb2ludCB5b3UgbWVudGlvbmVkIGJlbG93LA0K ZG8geW91IG1lYW4gdGhpcyBkcmFmdCBsaXN0cyBkaWZmZXJlbnQgcHJvY2VkdXJlcyBpbiBzZWN0 aW9uIDQuMyBmb3IgcHJlLXBvc2l0aW9uaW5nDQphbmQgZm9yIGNvbnRlbnQgYWNxdWlzdGlvbiBz ZXBhcmF0ZWx5PyBXZSBkbyBub3QgaW50ZW5kIHRvIHNlcGFyYXRlIHRoZQ0KcHJvYmxlbSBhbmQg dGhlIHNvbHV0aW9uLiBXZSBkbyBzbyBiZWNhdXNlIHRoZSBwcmUtcG9zaXRpb25pbmcgcHJvY2Vk dXJlDQphbmQgdGhlIGNvbnRlbnQgYWNxdWlzaXRpb24gcHJvY2VkdXJlIGFyZSB0d28gcHJvY2Vk dXJlcyBhbmQgd2UgZGVzY3JpYmUNCnRoZW0gaW4gdHdvIHN1Yi1zZWN0aW9ucyBpbiBvcmRlciB0 byBtYWtlIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgc29sdXRpb24NCmNsZWFyZXIuPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4yLiBBcyBmb3IgdGhlIGNv bnRlbnQgcmVtb3ZhbCwgeWVzLA0KaXQgaXMgYW4gaW50ZXJlc3RpbmcgYXNwZWN0IHRoYXQgd2Ug ZGlkIG5vdCBkaXNjdXNzIGluIG91ciBwcm9wb3NhbC4gSXQNCmlzIG91ciBvcGluaW9uIHRoYXQg b25seSB0aGUgdUNETiB0aGF0IGRlbGl2ZXJlZCB0aGUgY29udGVudCBpdGVtIHRvIHRoZQ0KZENE TiBpcyBwcm9wZXIgYW5kIGlzIGF1dGhvcml6ZWQgdG8gc2VuZCB0aGUgcmVtb3ZhbCBjb21tYW5k IHRvIGRlbGV0ZQ0KdGhlIGNvbnRlbnQuIENvbnNpZGVyaW5nIHRoYXQgQ0ROIEEgYW5kIENETiBC IGFyZSB1Q0ROcyBvZiBDRE4gQywgQ0ROIEENCmRlbGl2ZXJzIGEgY29udGVudCBpdGVtIHRvIENE TiBDIHZpYSBwcmUtcG9zaXRpb25pbmcgcHJvY2VkdXJlIG9yIENETiBDDQphY3F1aXJlcyBhIGNv bnRlbnQgaXRlbSBmcm9tIENETiBBIHZpYSBjb250ZW50IGFjcXVpc2l0aW9uIHByb2NlZHVyZS4g Q0RODQpBIGlzIGF1dGhvcmlzZWQgdG8gZGVsZXRlIHRoZSBjb250ZW50LiBBcyBmb3IgQ0ROIEIs IHJlLXNlbmRpbmcgdGhlIGNvbnRlbnQNCndpbGwgbm90IG9jY3VyIGlmIHRoZSBzb2x1dGlvbiBp biB0aGlzIGRyYWZ0IGlzIGFwcGxpZWQuIFNvIENETiBCIHdpbGwNCm5vdCBpbml0aWF0ZSB0aGUg cmVtb3ZhbCBhY3Rpb24uIEhvdyBkbyB5b3UgdGhpbms/PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGlzIGlzIGEgbWlzc2luZyBwYXJ0IHRoYXQgd2UgbmVlZA0K dG8gY2xhcmlmeSBpbiB0aGUgZHJhZnQuIFRoYW5rIHlvdSBmb3IgcG9pbnRpbmcgaXQgb3V0Ljwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+My4gPC9mb250 Pjx0dD48Zm9udCBzaXplPTI+QWN0dWFsbHkNCmFzIHdoYXQgeW91IGV4cGxhaW5lZCBiZWxvdyBp cyBqdXN0IHdoYXQgd2Ugd2FudCB0byBwcm9wb3NlIGluIG91ciBkcmFmdA0KYnV0IHdlIGRpZCBu b3QgbWFrZSBpdCBjbGVhciBlbm91Z2guPC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPg0KU28gdGhhdCBtYWtlcyB5b3UgY29uZnVzZWQuIENvbnRlbnQtSUQgYXMgYW4g b3B0aW9uYWwgbWV0YWRhdGEgb2JqZWN0LA0KaXMgZXhhY3RseSBvbmUgaW1wb3J0YW50IHBhcnQg d2UgYXJlIHByb3Bvc2luZy4gVGhlIGNvbnRlbnQtSUQgaXMgZGlzdHJpYnV0ZWQNCmFzIGFuIG9w dGlvbmFsIGNvbnRlbnQgbWV0YWRhdGEgd2l0aC93aXRob3V0IHRoZSBhY3R1YWwgY29udGVudCBp dGVtIGZyb20NCnVDRE4gdG8gZENETiBmb3Igc3RvcmFnZS4gVGhlbiBmb3IgZXhhbXBsZSwgaWYg dGhlIHVDRE4gd2FudHMgdG8gcHJlLXBvc2l0aW9uDQpjb250ZW50IGl0ZW1zLCBjb3JyZXNwb25k aW5nIGNvbnRlbnQtSUQgYW5kIFJlc291cmNlIElEIGFyZSBzZW50IGluIHRoZQ0KcHJlLXBvc2l0 aW9uaW5nIHJlcXVlc3QgbWVzc2FnZSBmcm9tIHVDRE4gdG8gZENETi4gVGhlbiB0aGUgZENETiBj YW4gdXNlDQp0aGlzIGNvbnRlbnQtSUQgYXMgYW4gaW5kZXggdG8gbG9vayB1cCBpdHMgc3RvcmVk IG1ldGFkYXRhIGluZm9ybWF0aW9uDQp0byBjaGVjayB3aGV0aGVyIHRoZSBjb250ZW50IGl0ZW0g aGFzIGJlZW4gc3RvcmVkIG9yIG5vdC4gVGhlIGNvbnRlbnQgYWNxdWlzaXRpb24NCnByb2NlZHVy ZSBpcyBzaW1pbGFyIHRvIGFib3ZlIG9uZS4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5JIHdpbGwgbWFrZSB0aGUgZGVzY3JpcHRpb24gY2xlYXJlcg0KaW4gdGhl IHVwZGF0ZWQgdmVyc2lvbi4gVGhhbmsgeW91fjwvZm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZxdW90O0ZyYW5jb2lzIExlIEZhdWNoZXVyIChmbGVmYXVjaCkmcXVvdDsgJmx0O2Zs ZWZhdWNoQGNpc2NvLmNvbSZndDsNCtC009ogMjAxMi0wNy0yNCAyMjoyOTowNDo8YnI+DQo8YnI+ DQomZ3Q7IEhpLDxicj4NCiZndDsgPGJyPg0KJmd0OyBBIGZldyBjb21tZW50cyBvbiBkcmFmdC1q aW4tY2RuaS1jb250ZW50LWRlZHVwbGljYXRpb24tb3B0aW1pemF0aW9uDQpiZWxvdy48YnI+DQom Z3Q7IDxicj4NCiZndDsgKiBpbiBzZXZlcmFsIHBsYWNlcywgdGhlIGRvY3VtZW50IGRpc2N1c3Nl cyBzZXBhcmF0ZWx5IHByZS1wb3NpdGlvbg0KPGJyPg0KJmd0OyB2ZXJzdXMgZHluYW1pYyBhY3F1 aXNpdGlvbi4gSSBkb24ndCB0aGluayB0aGVyZSBuZWVkcyB0byBiZSBhbnkgPGJyPg0KJmd0OyBk aWZmZXJlbmNlIGluIHRoZSBwcm9ibGVtIG9yIHRoZSBzb2x1dGlvbiBmb3IgdGhlIHR3byBjYXNl cy4gPGJyPg0KJmd0OyBUaGUgaXNzdWUgaXM6IHdoZW4gYSBkQ0ROIG5lZWRzIHRvIGdldCBhIGNv bnRlbnQgKHdoZXRoZXIgZm9yIHByZS08YnI+DQomZ3Q7IHBvc2l0aW9uIG9yIGZvciBkeW5hbWlj IGFjcXVpc2l0aW9uKTo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsxKSBjYW4gaXQgYXZvaWQgcmUt c3RvcmluZyBhIDJuZCBjb3B5IG9mIHNhbWUgY29udGVudDxicj4NCiZndDsgJm5ic3A7ICZuYnNw OzIpIGNhbiBpdCBhdm9pZCByZXF1ZXN0aW5nIHRoYXQgMm5kIGNvcHkuPGJyPg0KJmd0OyBZb3Ug bWF5IHdhbnQgdG8gY29uc2lkZXIgZGlzY3Vzc2luZyB0aGUgcHJvYmxlbS9zb2x1dGlvbiA8YnI+ DQomZ3Q7IGluZGVwZW5kZW50bHkgb2YgdGhlIGFjcXVpc2l0aW9uIG1ldGhvZC48YnI+DQomZ3Q7 IDxicj4NCiZndDsgPGJyPg0KJmd0OyAqIHNlY3Rpb24gNC4zLjMgZGlzY3Vzc2VzIGNvbnRlbnQg cmVtb3ZhbCBidXQgZG9lcyBub3Qgc2VlbSB0byA8YnI+DQomZ3Q7IGRpc2N1c3Mgb25lIGludGVy ZXN0aW5nIGFzcGVjdCBvZiBjb250ZW50IHJlZHVwbGljYXRpb246IHdoZW4gYSBkQ0ROPGJyPg0K Jmd0OyBlbmRzIHVwIHN0b3JpbmcgYSBnaXZlbiBjb250ZW50IG9uIGJlaGFsZiBvZiB0d28gdUNE TnMsIGFuZCB0aGVuIG9uZTxicj4NCiZndDsgdUNETiB0cmlnZ2VycyBjb250ZW50IHJlbW92YWwg YnV0IHRoZSBvdGhlciBvbmUgZG9lcyBub3QsIGRvIHlvdSA8YnI+DQomZ3Q7IHJlbW92ZSB0aGUg Y29udGVudCBvciBub3Q/PGJyPg0KJmd0OyBDYW4geW91IGRpc2N1c3MgdGhhdCB0b3BpYz88YnI+ DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAqIEkgd2FzIHBpY3R1cmluZyB0aGF0IHRoZSBD b250ZW50LUlEIHdvdWxkIGJlIGFzc29jaWF0ZWQgdG8gYSBnaXZlbjxicj4NCiZndDsgY29udGVu dCByZXF1ZXN0IHRocm91Z2ggdGhlIENETkkgbWV0YWRhdGEuIEluIG90aGVyIHdvcmRzLCB3ZSBj b3VsZA0KPGJyPg0KJmd0OyBkZWZpbmUgYW4gb3B0aW9uYWwgTWV0YWRhdGEgb2JqZWN0IGNvbnRh aW5pbmcgdGhlIENvbnRlbnQtSUQuIFRoZW4NCjxicj4NCiZndDsgd2hlbmV2ZXIgYW4gYWN0aW9u IGlzIG5lZWRlZCAoZS5nLiBjb250ZW50IGFjcXVpc2l0aW9uKSBmb3IgYSA8YnI+DQomZ3Q7IHJl c291cmNlIFVSSSwgdGhlIENETiB3b3VsZCBmaXJzdCBhY3F1aXJlIHRoZSBtZXRhZGF0YSAoYXMg dXN1YWwpDQo8YnI+DQomZ3Q7IGFuZCB0aGVuIGdldCB0aGUgQ29udGVudC1JRC4gSXQgY2FuIHRo ZW4gbWFrZSB0aGUgZGV0ZXJtaW5hdGlvbiBvbg0KPGJyPg0KJmd0OyB3aGV0aGVyIHRoZSBjb250 ZW50IGlzIGFscmVhZHkgc3RvcmVkLjxicj4NCiZndDsgSXMgdGhpcyB3aGF0IHlvdSBoYXZlIGlu IG1pbmQgYWxzbz88YnI+DQomZ3Q7IEkgZ290IGEgbGl0dGxlIGNvbmZ1c2VkIGJ5IHRoaXMgdGV4 dDogJnF1b3Q7UmVjZWl2aW5nIHRoZSBtZXNzYWdlLA0KdGhlIDxicj4NCiZndDsgZENETiB1c2Vz IHRoZSBDb250ZW50IElkZW50aWZpZXIgdG8gbG9vayB1cCB0YXJnZXQgbWV0YWRhdGEuJnF1b3Q7 DQpUaGlzIDxicj4NCiZndDsgc3VnZ2VzdHMgdGhhdCB0aGUgbWV0YWRhdGEgYXJlIGhhbmdpbmcg b2ZmIHRoZSBDb250ZW50IElELiBJIHRoaW5rDQo8YnI+DQomZ3Q7IHlvdSBuZWVkIHRvIGhhdmUg dGhlIG1ldGFkYXRhIGhhbmdpbmcgb2ZmIHRoZSByZXNvdXJjZSBVUkwsIGluIDxicj4NCiZndDsg cGFydGljdWxhciBiZWNhdXNlIHlvdSBuZWVkIHNlcGFyYXRlIG1ldGFkYXRhIHBlciB1Q0ROIChl dmVuIGZvciB0aGU8YnI+DQomZ3Q7IHNhbWUgY29udGVudCkuIEFuZCBJIHRoaW5rIHRoZSBDb250 ZW50LUlEIGlzIHRoZW4gY29udmV5ZWQgaW5zaWRlDQo8YnI+DQomZ3Q7IHRoZSBjb250ZW50IG1l dGFkYXRhLDxicj4NCiZndDsgRG9lcyB0aGF0IG1ha2Ugc2Vuc2UgPzxicj4NCiZndDsgJm5ic3A7 PGJyPg0KJmd0OyBDaGVlcnM8YnI+DQomZ3Q7IDxicj4NCiZndDsgRnJhbmNvaXM8YnI+DQomZ3Q7 IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIDE5IEp1biAyMDEyLCBhdCAwNTox NywgSW50ZXJuZXQtRHJhZnRzQGlldGYub3JnIHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJv bSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHM8YnI+DQomZ3Q7IGRpcmVjdG9yaWVzLjxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtU aXRsZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogQ29udGVudA0KRGUtZHVw bGljYXRpb24gZm9yIENETmkgT3B0aW1pemF0aW9uPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz cDtBdXRob3IocykgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBXZWlZaSBKaW48YnI+DQomZ3Q7ICZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO01pYW4gTGk8YnI+DQomZ3Q7ICZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0JodW1pcCBLaGFzbmFiaXNoPGJy Pg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtGaWxlbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs6IGRyYWZ0LWppbi1jZG5pLWNvbnRlbnQtZGVkdXBsaWNhdGlvbi08YnI+DQomZ3Q7IG9w dGltaXphdGlvbi0wMS50eHQ8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1BhZ2VzICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAxNzxicj4NCiZndDsgJmd0OyAmbmJzcDsg Jm5ic3A7RGF0ZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzoNCjIw MTItMDYtMTg8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEFic3RyYWN0Ojxicj4NCiZn dDsgJmd0OyAmbmJzcDsgUmVjZW50IGV4cGxvc2l2ZSBncm93dGggb2YgY29udGVudCBkZWxpdmVy eS9kaXN0cmlidXRpb24NCm5ldHdvcmtzPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAoQ0ROcykgYW5k IHRoZWlyIGludGVyY29ubmVjdGlvbiBhcmUgY2F1c2luZyB1bmludGVuZGVkDQpyZXBldGl0aW9u IG9mPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyBjb250ZW50IHN0b3JhZ2UgaW4gdGhlIHNhbWUgZENE Ti4gJm5ic3A7VGhpcyBjYW4gYmUgYXZvaWRlZA0KYnkgdXNpbmcgYTxicj4NCiZndDsgJmd0OyAm bmJzcDsgc3VpdGFibGUgZGUtZHVwbGljYXRpb24gbWVjaGFuaXNtLiAmbmJzcDtUaGlzIGRvY3Vt ZW50DQpleHBsb3JlcyB0aGU8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IHNjZW5hcmlvcyB3aGljaCBj cmVhdGUgdGhlIHByb2JsZW1zLCBhbmQgdGhlbiBkaXNjdXNzZXMNCnRoZTxicj4NCiZndDsgJmd0 OyAmbmJzcDsgYXBwcm9hY2hlcyB0byBlbGltaW5hdGUgdGhlIGR1cGxpY2F0ZWQgdHJhbnNtaXNz aW9uIG9mDQp0aGUgc2FtZTxicj4NCiZndDsgJmd0OyAmbmJzcDsgY29udGVudCBmcm9tIHVDRE4o cykgdG8gZENETiBpbiBDRE5pIG5ldHdvcmtzLiAmbmJzcDtUbw0KaW1wbGVtZW50IHRoZTxicj4N CiZndDsgJmd0OyAmbmJzcDsgb3B0aW1pemF0aW9uLCBzb21lIGVuaGFuY2VtZW50cyB0byB0aGUg Q0ROaSBtZXRhZGF0YSBtb2RlbA0KYW5kPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyBpbnRlcmZhY2Ug YXJlIHJlcXVpcmVkLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxi cj4NCiZndDsgJmd0OyBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qaW4t Y2RuaS1jb250ZW50LTxicj4NCiZndDsgZGVkdXBsaWNhdGlvbi1vcHRpbWl6YXRpb248YnI+DQom Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24g YXZhaWxhYmxlIGF0Ojxicj4NCiZndDsgJmd0OyBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1qaW4tY2RuaS1jb250ZW50LWRlZHVwbGljYXRpb24tPGJyPg0KJmd0OyBvcHRpbWl6YXRp b24tMDE8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEEgZGlmZiBmcm9tIHByZXZpb3Vz IHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4NCiZndDsgJmd0OyBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWppbi1jZG5pLWNvbnRlbnQtPGJyPg0KJmd0OyBkZWR1 cGxpY2F0aW9uLW9wdGltaXphdGlvbi0wMTxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5v bnltb3VzIEZUUCBhdDo8YnI+DQomZ3Q7ICZndDsgZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy88YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IEktRC1Bbm5vdW5j ZSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgSS1ELUFubm91bmNlQGlldGYub3JnPGJyPg0K Jmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91 bmNlPGJyPg0KJmd0OyAmZ3Q7IEludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3 LmlldGYub3JnL3NoYWRvdy5odG1sPGJyPg0KJmd0OyAmZ3Q7IG9yIGZ0cDovL2Z0cC5pZXRmLm9y Zy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCjwvZm9u dD48L3R0Pg0K --=_alternative 0035D28F48257A47_=-- From ben@niven-jenkins.co.uk Thu Jul 26 04:02:11 2012 Return-Path: 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 A473F21F85EF for ; Thu, 26 Jul 2012 04:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 M6j+dG6e2ONR for ; Thu, 26 Jul 2012 04:02:08 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id B25DE21F8703 for ; Thu, 26 Jul 2012 04:02:07 -0700 (PDT) Received: from [81.134.152.4] (helo=xxx.corp.velocix.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SuLpU-0002Eg-JA; Thu, 26 Jul 2012 12:02:06 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Ben Niven-Jenkins In-Reply-To: Date: Thu, 26 Jul 2012 12:02:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <605D99D5-3524-4887-85FB-0EA690F28CC7@niven-jenkins.co.uk> References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> <2040_1341930789_4FFC3D24_2040_2504_1_b86bff40-ae68-40c0-b8e5-060f51be6864@PEXCVZYH02.corporate.adroot.infra.ftgroup> <3A7EA7EE-F8D4-4094-83F2-12CD3826B662@tno.nl> <5004079D.4000406@cisco.com> <29661_1343216353_500FDAE1_29661_643_1_2AC63C9F27AF8446B0C064C50FC0A89305D959@PEXCVZYM13.corporate.adroot.infra.f tgroup> <2AF54F9B-B4FF-4043-A9DE-36C0417F9EAC@cisco.com> To: "GUILLOU, Allan" X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 11:02:11 -0000 Allan, On 25 Jul 2012, at 14:04, GUILLOU, Allan wrote: > In *B* you still have a per session request to the dCDN. Not necessarily. How I would like to see this work is that the protocol = allows the dCDN's response to be scoped wider than the uCDN's request. For example, a uCDN could request a redirection for a specific IP = address and the dCDN could return a response scoped to an entire (set = of) IP subnet(s) that is cacheable & reusable by the uCDN for a period = of time to avoid the uCDN having to make a request to the dCDN for each = redirection while leaving control with the dCDN to determine how widely = to scope its requests (based on its knowledge of its footprint, load, = etc) & how long it wants its responses to be cached for. Ben > If it is just to handle a problem in the dCDN, and that you consider = that you realy need this kind of information, another method can be to = add an "back pressure mechanism". >=20 > It could be done by a message sent from dCDN to uCDN when ie is = overload, or by adding in the Footprint&Cap information a "max value" = which can give the number of stream that the dCDN can accept from this = specific uCDN. In case of overload, the dCDN can just send an update = with a lower value to ask the uCDN to select another dCDN. >=20 >=20 >=20 >> -----Message d'origine----- >> De : Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] >> Envoy=E9 : mercredi 25 juillet 2012 14:36 >> =C0 : >> Cc : Francois Le Faucheur (flefauch); GUILLOU, Allan; Scott Wainner >> (swainner); cdni@ietf.org >> Objet : Re: [CDNi] I-D Action: = draft-lelouedec-cdni-request-routing-00.txt >>=20 >> All, >>=20 >> To help the discussion, we may need to distinguish three (main) = modes: >>=20 >> *A* the uCDN uses the Footprint&Cap information (advertised by dCDN) = to >> select a dCDN. The uCDN redirects to the selected dCDN and considers = that >> he is done with request routing. >>=20 >> *B* the uCDN uses the Footprint&Cap information (advertised by dCDN) = to >> select a dCDN candidate. The uCDN queries the dCDN before = redirecting. >> Querying dCDN optionally allows the dCDN to provide to uCDN the final >> redirection information so the the enduser experiences a single = redirect. >> Querying dCDN optionally allows the uCDN to pick an alternate dCDN if = the >> initially selected dCDN cannot handle the request. >>=20 >> *C* the uCDN queries multiple dCDNs on a per-request basis and = selects >> dCDN based on their responses. In other words, the Footprint&Cap >> advertisement is performed via on-demand per-request queries. >>=20 >>=20 >> I think: >> * Scott pointed out that fundamentatly both *A* and *B* have to = deal >> with (typically transient) situations where uCDN thinks dCDN can take = a >> request and dCDN actually cannot handle it. And pointed out that with = *A* >> the transient period is dictated by the Footprint&Cap advertisement >> "update speed" while with *B* it is not. >> * Allan was saying *A* is all he needs and *B* is extra = complexity >> that he doesn't need. >> * Gilles and lelouedec-cdni-request-routing were saying *C* is = bad. >>=20 >> My impression is that there is violent agreement that *A* is to be >> supported. I think Allan and Gilles message indicate so. I personally >> support that. I think many people have been discussing that approach. = If >> someone feels this is NOT to be supported by CDNI, do let us know. >>=20 >> I think Gilles message below is primarily arguing against *C*. I >> personally agree that this need not be supported in our initial >> deliverables. Are there people arguing this approach is to be = supported in >> the initial deliverables? >>=20 >> Regarding *B*, I personally see it as quite useful and worth = supporting in >> Phase 1 (possibly as an option). >> Regarding Allan's points: >> * I agree there is some "scalability" argument (i.e. = state+wait-for- >> dCDN-response) but it amounts to a web-services call out per request = and >> buys you reliability of request routing, so I see that as a trade-off = that >> some CDNs should be able to exercise. >>=20 >> * I don't buy the latency argument because you end up with 2 = RTTs in >> both *A* and *B* (in normal situations where dCDN can handle the = request) >> (i.e. user-->uCDN, uCDN-->user, user-->dCDN, dCDN-->user versus = user-- >>> uCDN, uCDN-->dCDN, dCDN-->uCDN, uCDN-->user) and in the transient = cases >> where dCDN cannot handle the request *B* can do as well as *A* (drop = the >> request) or has the option to differently i.e. re-redirect at the = cost of >> an extra RTT. >> * I don't buy the "loop free mechanism" argument. In *B*, it is = easy >> to implement a loop detection and even loop prevention (if you want). = In >> *A*, you have no loop prevention (other than the inherent HTTP/DNS = max >> redirect/max CNAMEs) >> Other opinions on *B* are sought. >>=20 >>=20 >> Cheers >>=20 >> Francois >>=20 >>=20 >> On 25 Jul 2012, at 13:39, >> wrote: >>=20 >>> Hi everyone, >>>=20 >>> I fully agree with Allan's comments. Putting aside the vocabulary >> ('recursive model' etc), Allan's comment are consistent with the = messages >> that = http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >> tries to convey. >>>=20 >>> " o Regarding the former process, i.e. related to the "ability" >>> ("enables a Request Routing function in an upstream CDN to query = a >>> Request Routing function in a downstream CDN to determine if the >>> downstream CDN is able (...) to accept the delegated content >>> request"), a routing protocol is used to achieve such a process, >>> called routing process, in many other technologies and networks >>> (IP, ATM, etc.). In all these technologies, it is the = downstream >>> entity that provides routing information to the upstream entity. >>> The same approach should be applied to CDN interconnection. The >>> reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN = 2, >>> dCDN 3, and then it selects one of them based on their = responses") >>> would suffer from latency, signaling overhead and/or lack of >>> reactivity to events that impact the ability of the downstream >>> CDNs to accept delegated content requests." >>>=20 >>> Best regards, >>> -- >>> Gilles >>>=20 >>>=20 >>> -----Message d'origine----- >>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part = de >> GUILLOU, Allan >>> Envoy=E9 : mercredi 25 juillet 2012 12:23 >>> =C0 : Scott Wainner; cdni@ietf.org >>> Objet : Re: [CDNi] TR: I-D Action: = draft-lelouedec-cdni-request-routing- >> 00.txt >>>=20 >>> Hi, >>>=20 >>> With a "recusive model" as you ask if I understand, you expect the = dCDN >> to send like an "ack" for each request, and if not the uCDN will try = to >> find the second best dCDN and do the same thing. >>>=20 >>> I think that this model may add complexity and may cause some >> scalability problem. You will have to implement timers between = request and >> ack, retransmission mechanism to make sure that request has not been = lost, >> loop free mechanism, And all this may add latency on all requests and >> performances problems. >>>=20 >>> In the iterative model, if the dCDN is not able to handle the = request, >> this request will be lost. It is the same thing in IP network today = we do >> not ask the routing protocol to change when there is saturation = somewhere. >> It is the responsibility of each ISP to choose another route to join = this >> destination if he want to keep a good quality of service. If a dCDN = is >> overloaded, it will stop announcing part of its footprint or uCDN may >> apply some policy to force choosing another dCDN. >>>=20 >>> It is right that this second model may not in case of dCDN = saturation >> have the best reactivity, but it is exactly the same thing on the = internet >> today. We can imagine that a poor dCDN which have saturation will be >> "black listed" by all the uCDN and the regulation will be done like = this. >>> I think recursive model will add complexity all the time for a gain >> witch is not in my opinion so important and that will not be seen so >> often. >>>=20 >>> Allan >>>=20 >>>> -----Message d'origine----- >>>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la = part >>>> de Scott Wainner Envoy=E9 : lundi 16 juillet 2012 14:23 =C0 : >>>> cdni@ietf.org Objet : Re: [CDNi] TR: I-D Action: >>>> draft-lelouedec-cdni-request-routing- >>>> 00.txt >>>>=20 >>>> On 7/10/12 11:39 AM, Brandenburg, R. (Ray) van wrote: >>>>> Hi Yannick, >>>>>=20 >>>>> We seem to be misunderstanding each other. Maybe this will help >>>>> clarify >>>> my point: >>>>>=20 >>>>>> Let me try to fully understand your point: >>>>>> Are you really meaning that in this case the dCDN has in reality >>>> absolutely no obligation with regards to the uCDN? >>>>>> Are you really meaning that in this case the dCDN decides alone, = in >>>> real time, and for each content request, whether it denies or = accepts >>>> to ensure delivery? >>>>> What I mean is that I would like to have a RR Interface at least >>>>> support >>>> a model where for every content request the uCDN asks the dCDN = whether >>>> it wants to deliver that particular content item (I believe you = call >>>> this a PULL approach). And I would like to allow the dCDN to be = able to >> say 'No' >>>> on this request (whether it is for purposes or failure, overload, = or >>>> any other reason). >>>>>=20 >>>>>> Are you really meaning that in this case the dCDN decides alone, = in >>>> real time, and for each content request, whether it denies or = accepts >>>> to ensure delivery, and this even if the dCDN has the capability to >>>> deliver the content? >>>>> Yes. >>>> I think we have to delineate between the iterative and recursive = model. >>>>=20 >>>> The recursive model assumes that the client request to the uCDN = will >>>> be recursive and the CDN-I RR interface will be used to provide an >>>> answer for each client request. The choice to initiate the = recursion >>>> would be determined by the footprint / capabilities. The ability = of >>>> the dCDN to execute the specific request would provide immediate >>>> feedback to the uCDN. A dCDN that continues to advertise the >>>> footprint / capability, but frequently or continually rejects the >>>> request via CDN-I RR would be a poor candidate. The opportunity = now >>>> arises where the uCDN may elect to choose an alternate dCDN because >>>> its preferred dCDN (according to footprint / capabilities) is = 'under- >> performing'. >>>>=20 >>>> The iterative model, the uCDN blindly redirects the client to the = dCDN >>>> based on the footprint / capabilities. What the dCDN does with the >>>> request is somewhat transparent to the uCDN. With the exception of >>>> the CDN-I logging, the uCDN assumes the dCDN is properly handling = the >>>> requests that were delegated to the dCDN. If you are trying to >>>> 'tighten' up the case of blind rejections, then the frequency of = the >>>> footprint / capabilities advertisements would have to be = accelerated. >>>> For the case where the dCDN repeatedly sees requests from the uCDN >>>> that the dCDN can't handle, it should retract its footprint / >>>> capabilities advertisement. Failing to do so would continually >>>> black-hole routing requests which would be indicated in the logging >> information. >>>>=20 >>>> Either way, you need a feedback loop to avoid dumping routing = requests. >>>>=20 >>>> With any feedback loop (recursive routing request or footprint / >>>> capabilities advertisement), you have to be careful about rapid >>>> oscillations and dampening the responses. >>>>=20 >>>> Scott >>>>>=20 >>>>>> Are you really meaning that in this case the dCDN may possibly >>>>>> response >>>> negatively to all requests for content request redirection = submitted >>>> by the uCDN over the CDNI request routing interface? (i.e. that >>>> possibly the uCDN will never be allowed/invited to redirect a = content >>>> request to the >>>> dCDN?) >>>>>=20 >>>>> Yes. Any negative effect this may have on the business = relationship >>>> between uCDN and dCDN should be handled on the business level. >>>>>=20 >>>>> Ray >>>>>=20 >>>>>=20 >>>>> On Jul 10, 2012, at 4:33 PM, >>>>> wrote: >>>>>=20 >>>>>> Hi Ray, >>>>>>=20 >>>>>>=20 >>>>>> 1) Ray, quoting your mail: "The current drafts seems to assume = some >>>> particular type of contractual agreement between CDNs that might = not >>>> always be the case." >>>>>>=20 >>>>>> Please quote the draft. >>>>>> Please let us know exactly to which sentence(s) of the draft you >>>>>> are >>>> referring to. >>>>>> Otherwise it is hard to discuss and comment on your email. >>>>>>=20 >>>>>>=20 >>>>>> 2) Ray, Quoting your mail: "If a dCDN does not live up to its >>>> contractual agreement, this should be something that is handled on = a >>>> business level, not on a protocol level." >>>>>>=20 >>>>>> Maybe there is a deep misunderstanding. >>>>>> So I will try to be clear again. >>>>>> We do not propose the CDNI routing interface to be used by the = dCDN >>>>>> to >>>> send a message saying "Sorry, but I decide unilaterally to refuse = this >>>> content request". >>>>>> We do not propose the CDNI routing interface to be used to handle >>>>>> any >>>> aspect relating to a dCDN deciding unilaterally to stop living up = to >>>> its contractual agreement. >>>>>>=20 >>>>>> Please let us know where you saw such an idea in this IETF draft >>>>>> "CDNI >>>> request routing". >>>>>>=20 >>>>>> The only role of the CDNI routing interface is to be used to >>>>>> advertise >>>> CDNI routing information from the downstream CDN to the upstream = CDN. >>>>>> And this is the description given in this IETF draft. >>>>>>=20 >>>>>>=20 >>>>>> 3) Ray, quoting your mail: "one example of a contractual = agreement >>>> between two CDNs is one in which the uCDN and dCDN have agreed that >>>> the dCDN will deliver some content on behalf of a uCDN, but decide = on >>>> a per- request basis whether it wants to do so (and is for example >>>> paid per request). In these cases, the dCDN needs to have the = ability >>>> to deny delivery on a per-request basis." >>>>>>=20 >>>>>> Let me try to fully understand your point: >>>>>> Are you really meaning that in this case the dCDN has in reality >>>> absolutely no obligation with regards to the uCDN? >>>>>> Are you really meaning that in this case the dCDN decides alone, = in >>>> real time, and for each content request, whether it denies or = accepts >>>> to ensure delivery? >>>>>> Are you really meaning that in this case the dCDN decides alone, = in >>>> real time, and for each content request, whether it denies or = accepts >>>> to ensure delivery, and this even if the dCDN has the capability to >>>> deliver the content? >>>>>> Are you really meaning that in this case the dCDN may possibly >>>>>> response >>>> negatively to all requests for content request redirection = submitted >>>> by the uCDN over the CDNI request routing interface? (i.e. that >>>> possibly the uCDN will never be allowed/invited to redirect a = content >>>> request to the >>>> dCDN?) >>>>>>=20 >>>>>>=20 >>>>>> 4) Ray, quoting your mail: "Every routing protocol defines the >>>>>> expected >>>> behavior of interconnected elements/networks on a technical level, = not >>>> on a business level." >>>>>>=20 >>>>>> Again, this is not what I have written, and this is not the idea = we >>>> want to share. >>>>>> I wrote "Every routing protocol has been defined (or at least >>>> configured) so far by considering the expected behavior of the >>>> interconnected elements/networks." >>>>>> That's all. >>>>>> I can rephrase this sentence the following way: "we must know = what >>>>>> we >>>> expect to do with a protocol to design it correctly." >>>>>> And IHMO this is an evidence; I don't know any other way to = proceed. >>>>>>=20 >>>>>> Besides, let us consider BGP (which is by the way an option >>>>>> proposed by >>>> some IETF members to implement this CDNI routing interface). >>>>>> In IP networks, BGP configurations in IP routers are defined as = per >>>>>> the >>>> business relationships (valley free policy, etc.). >>>>>> Of course the business relationships determine the BGP >> configurations. >>>>>> And of course BGP has been designed so as to allow to configure = IP >>>> interconnections adequately depending on the corresponding >>>> Customer/provider, sibling and peering contractual agreements. >>>>>> But this does not mean that BGP "defines the expected behavior of >>>> interconnected elements/networks... on a business level." >>>>>> Even if we can indeed infer quite accurately the business >>>>>> relationships >>>> between ISP from the BGP configuration of their IP routers (see = CAIDA >>>> project), but this is another story. >>>>>>=20 >>>>>>=20 >>>>>> Best regards, >>>>>>=20 >>>>>> Yannick Le Lou=E9dec. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >>>>>> Envoy=E9 : mardi 10 juillet 2012 15:13 =C0 : LE LOUEDEC Yannick >>>>>> RD-CORE; Ben Niven-Jenkins Cc : Pilarski Marcin - Korpo TP; >>>>>> cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR: I-D >>>>>> Action: draft-lelouedec-cdni-request- >>>> routing-00.txt >>>>>>=20 >>>>>> Hi Yannick, >>>>>>=20 >>>>>> See comments inline. >>>>>>=20 >>>>>> In general: IMO the CDNI interfaces should be abstracted from any >>>>>> kind >>>> of contractual/business agreement that might or might not exist >>>> between a dCDN and uCDN. The current drafts seems to assume some >>>> particular type of contractual agreement between CDNs that might = not >> always be the case. >>>>>>=20 >>>>>> Ray >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: yannick.lelouedec@orange.com >>>> [mailto:yannick.lelouedec@orange.com] >>>>>> Sent: dinsdag 10 juli 2012 12:01 >>>>>> To: Brandenburg, R. (Ray) van; Ben Niven-Jenkins >>>>>> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne = RD-CORE >>>>>> Subject: RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- >>>> routing-00.txt >>>>>>=20 >>>>>> Hi Ray, all, >>>>>>=20 >>>>>>=20 >>>>>> 1) Ray, Quoting your mail: "I don't see why the CDNI Request >>>>>> Routing >>>> interface should state that a dCDN MUST deliver the content if it = has >>>> indicated its ability to do so earlier in either a contractual >>>> agreement or in the capability interface." >>>>>>=20 >>>>>> This is not what we have written. >>>>>> Let me try to rephrase simply. >>>>>>=20 >>>>>> A contractual agreement is a contractual agreement. >>>>>> It put in writings the respective obligations of the uCDN and of >>>>>> the >>>> dCDN. >>>>>> The uCDN may redirect any content request to the dCDN as long as = it >>>>>> is >>>> in full conformance with the terms of this contractual agreement = (the >>>> type of the content request is in full conformance, the maximum = number >>>> of content requests per second is respected, etc.). >>>>>> In this case the dCDN may not say "Sorry, but I decide = unilaterally >>>>>> to >>>> refuse this content request". >>>>>>=20 >>>>>> [RvB]: This is where we disagree. IMHO, the type of behavior you >>>> describe (the dCDN not living up to its obligation) should not be >>>> enforced by the CDNI Interfaces. If a dCDN does not live up to its >>>> contractual agreement, this should be something that is handled on = a >>>> business level, not on a protocol level. >>>>>>=20 >>>>>> Why? Because this is the deal, a contractual agreement is a >>>>>> contractual >>>> agreement! >>>>>> Yet the dCDN may say "I do apologize, but at this time I cannot >>>>>> handle >>>> correctly a certain class of content requests specified in our >>>> contractual agreement" (for example the class of the HTTP content >>>> requests with token from French end users, because of overload >>>> situation, failure, etc.) This is the role of the CDNI routing >>>> interface to provide the uCDN with such information. >>>>>>=20 >>>>>> (And the dCDN may be given a penalty for example if this was = agreed >>>>>> in >>>> the terms of the contractual agreement.) >>>>>>=20 >>>>>>=20 >>>>>> 2) Ray, Quoting your mail: "I understand that in most cases, the >>>> contractual agreement might indeed impose this behavior on the = dCDN" >>>>>>=20 >>>>>> Please provide the description of an example where this is not = the >>>> case. >>>>>> Otherwise the IETF CDNI WG shall indeed consider this is ALWAYS = the >>>> case. >>>>>>=20 >>>>>> [RvB]: I can't remember ever seeing such a discussion on the WG = list. >>>> Anyway: one example of a contractual agreement between two CDNs is = one >>>> in which the uCDN and dCDN have agreed that the dCDN will deliver = some >>>> content on behalf of a uCDN, but decide on a per-request basis = whether >>>> it wants to do so (and is for example paid per request). In these >>>> cases, the dCDN needs to have the ability to deny delivery on a = per- >> request basis. >>>>>>=20 >>>>>> And this is an important point to be able to progress in the CDNI >>>> interfaces' specification works. >>>>>>=20 >>>>>> If the contractual agreement does not define clearly the >>>>>> obligations of >>>> the uCDN, it is impossible to dimension adequately the dCDN, = neither >>>> to define correctly the CDNI contractual agreements between the = dCDN >>>> and the dCDNs of this dCDN. >>>>>> If the contractual agreement does not define clearly the >>>>>> obligations of >>>> the dCDN, the dCDN may do what it wants... even to put in the trash >>>> can any content request it accepted to handle. >>>>>>=20 >>>>>> [RvB]: Exactly, this is something that needs to be discussed on a >>>> business/contractual level and not on a technical level. That is = way >>>> IMHO the CDNI Interfaces should not make ANY assumptions on what = was >>>> agreed on a contractual level. >>>>>>=20 >>>>>> In both situations it is impossible to ensure any quality of >>>>>> experience >>>> to the end user. >>>>>>=20 >>>>>>=20 >>>>>> 3) Ray, Quoting your mail: "I don't think this type of behavior >>>>>> should >>>> be imposed by the protocol we're developing here." >>>>>>=20 >>>>>> I do not sure I understand this sentence. >>>>>> Every routing protocol has been defined (or at least configured) = so >>>>>> far >>>> by considering the expected behavior of the interconnected >>>> elements/networks. >>>>>>=20 >>>>>> [RvB]: Every routing protocol defines the expected behavior of >>>> interconnected elements/networks on a technical level, not on a >>>> business level. Having a dCDN say 'I'm not willing to deliver this >>>> content' is perfectly fine from a technical perspective, although = it >>>> could be problematic from a contractual perspective. >>>>>>=20 >>>>>> But maybe I will understand if you provide an example on the = point >>>>>> 2 >>>> above. >>>>>>=20 >>>>>>=20 >>>>>> Best regards, >>>>>>=20 >>>>>> Yannick Le Lou=E9dec. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >>>>>> Envoy=E9 : mardi 10 juillet 2012 09:20 =C0 : Ben Niven-Jenkins; = LE >>>>>> LOUEDEC Yannick RD-CORE Cc : Pilarski Marcin >>>> - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] = TR: >>>> I-D >>>> Action: draft-lelouedec-cdni-request-routing-00.txt >>>>>>=20 >>>>>> Hi Yannick, Ben, >>>>>>=20 >>>>>> I tend to agree with Ben here. When reading the draft, I got the >>>> feeling that the draft seems to assume a lot about the relationship >>>> between the uCDN and dCDN. For example, I don't see why the CDNI >>>> Request Routing interface should state that a dCDN MUST deliver the >>>> content if it has indicated its ability to do so earlier in either = a >>>> contractual agreement or in the capability interface. I understand >>>> that in most cases, the contractual agreement might indeed impose = this >>>> behavior on the dCDN, but I don't think this type of behavior = should >>>> be imposed by the protocol we're developing here. >>>>>>=20 >>>>>> It was always my assumption that the Request Routing Interface >>>>>> would at >>>> least include the option of allowing the uCDN to query the dCDN for >>>> every content request whether the dCDN is willing to deliver that >>>> particular request. >>>>>>=20 >>>>>> I will send my full review of the draft later. >>>>>>=20 >>>>>> Ray >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On >>>>>> Behalf Of >>>> Ben Niven-Jenkins >>>>>> Sent: dinsdag 10 juli 2012 7:38 >>>>>> To: yannick.lelouedec@orange.com >>>>>> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne = RD-CORE >>>>>> Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- >>>> routing-00.txt >>>>>>=20 >>>>>> Yannick, >>>>>>=20 >>>>>> Please see inline. >>>>>>=20 >>>>>> On 9 Jul 2012, at 20:05, wrote: >>>>>>=20 >>>>>>> Hi Ben, all, >>>>>>>=20 >>>>>>> Ben, quoting you mail below, "... the downstream CDN could reply >>>>>>> with either "here is how to redirect it"", >>>>>>>=20 >>>>>>> =3D> This is the role of the CDNI DRIS interface to provide the = uCDN >>>> with this information, and we target to make its specification = public >>>> before Vancouver meeting so that everyone may read it before the >>>> meeting and get full knowledge of our proposal about this part of = CDNI >>>> request routing. >>>>>>>=20 >>>>>>> Ben, quoting you mail below, "... or "no I can't/won't take that >>>> content delivery right now", reasons may include the uCDN has >>>> requested a delivery of a protocol the dCDN does not support = (possibly >> in error). >>>>>>>=20 >>>>>>> =3D> This is the role of the CDNI logging interface to provide = the >>>>>>> uCDN >>>> with this information. >>>>>> I agree this information should be logged but the Request Routing >>>> interface (what you call the DRIS) also needs to be able to = indicate a >>>> failure. >>>>>>=20 >>>>>> Otherwise the uCDN will 'blindly' redirect the the dCDN and the >>>> delivery will fail leading to poor end user experience. >>>>>>=20 >>>>>>> Ben, quoting you mail below, "... or "no I can't/won't take that >>>> content delivery right now", reasons may include ... the dCDN has = no >>>> capacity right now etc." >>>>>>>=20 >>>>>>> =3D> This is the role of the CDNI routing interface to provide = the >>>>>>> uCDN >>>> with this information. >>>>>> It is the role of the CDN capability/routing interface to = advertise >>>> broad capabilities etc not to give extremely fine grained real-time >>>> information on exactly the state of the dCDN. >>>>>>=20 >>>>>> Even if the capability/routing interface is real-time there are >>>>>> likely >>>> to still be race conditions where we need the dCDN to be about to >>>> indicate a failure to accept a redirect through the request >>>> routing/DRIS interface >>>>>>=20 >>>>>>> So we may conclude we are in line basically, which is a good = point. >>>>>>> We just aimed at checking there was a common understanding on = this >>>> point. >>>>>>>=20 >>>>>>> The key point for us here is that we don't want this sentence >>>> extracted from draft-ietf-cdni-problem-statement be interpreted as: = ". >>>> and the dCDN MUST accept the content request except when it has not >>>> the "ability" to do so." >>>>>> Why not? IMO that is a valid scenario for some use cases. >>>>>>=20 >>>>>>> The fact that the dCDN is temporary unable to handle content >>>>>>> request >>>> correctly is not a valid reason for the dCDN to be discharged of = its >>>> obligations to the uCDN. >>>>>>> The contract set between the uCDN and the dCDN remains valid >>>>>>> anyway, >>>> and the obligations of the dCDN as well. >>>>>> Correct, but that contract may not be the same for all uCDNs & >>>>>> dCDNs, >>>> for example a uCDN may not have a guarantee that a dCDN can handle >>>> everything it is requested to handle but the contract may only be = that >>>> the dCDN guarantees to handle up to a certain volume of traffic. >>>>>>=20 >>>>>>> The dCDN must announce to the uCDN that it is temporary unable, = as >>>> soon as possible, via the CDNI routing interface. >>>>>>> And the uCDN must take this information into account in its CDN >>>> selection process as soon as possible. >>>>>>> Then if the uCDN decides to continue to redirect content = requests >>>>>>> to >>>> the dCDN, the uCDN MAY perfectly do it, but the uCDN knows these >>>> content requests will be lost. >>>>>> What happens in the period between the dCDN being unable to = handle >>>> requests and the time it takes to advertise that to the uCDN and = for >>>> the uCDN to process & incorporate that new knowledge? Are requests >>>> blindly forwarded to the dCDN which is unable to handle them = leading >>>> to poor user experience? >>>>>>=20 >>>>>>> We could even imagine the situation where the uCDN continues to = do >>>>>>> it >>>> intentionally, because it has no better option and the content = request >>>> will be lost anyway. For example in the case where neither the uCDN >>>> nor the other downstream CDNs of the uCDN cannot manage correctly = the >>>> content request, the uCDN could do it intentionally so as to be = able >>>> to clearly prove (with CDNI logging information) that it is the = dCDN, >>>> not the uCDN, who is at fault. >>>>>>> But, of course, if there are alternative backup options, the >>>>>>> normal >>>> reaction of the uCDN is to stop as soon as possible to redirect >>>> content requests to the dCDN when the uCDN knows that the dCDN is >>>> unable to handle them correctly. >>>>>>>=20 >>>>>>> So, to be clear, we would prefer the sentence to be understood = as: >>>>>>> ". and the dCDN MUST accept the content request. >>>>>>> And if it cannot handle correctly the redirected content request >>>>>>> it >>>> receives, the content request is lost. >>>>>> What about scenarios where the uCDN has a choice of dCDNs (e.g. = two >>>> national-wide CDNs offering services at different costs), the uCDN = may >>>> elect to query both dCDNs and decide based on their responses which >>>> one to choose. If the dCDN is unable to satisfy the request the = uCDN >>>> needs to know that so that it can fallback to the (more expensive = in >>>> this example) dCDN. >>>>>>=20 >>>>>>> For example the dCDN generates a response to the content request >>>>>>> with >>>> an error message, or no response at all. And in parallel the CDNI >>>> logging interface may be used to exchange logs corresponding to = this >> problem. >>>> Anyway the dCDN MAY NOT redirect that content request back towards = the >>>> uCDN." >>>>>>>=20 >>>>>>> Exactly as in IP networks: IP packets are not sent back towards >>>>>>> the >>>> origin by a downstream router under failure or congestion. >>>>>> In a routed IP network, there is often a small packet loss while >>>>>> the >>>> network re-converges, by enabling the dCDN to refuse a redirection = at >>>> CDNI Request Routing/DRIS query time we can reduce that window by >>>> giving the uCDN the option to take an alternative action (e.g. try >>>> another dCDN) while the routing/capability information = re-converges. >>>>>>=20 >>>>>>> In both networks (IP and CDN), the reason is the same. >>>>>>> If the dCDN redirects back a content request to the uCDN, this >>>> generates a loop. >>>>>> Loop avoidance is a separate issue IMO to whether we should allow = a >>>> dCDN to be able to communicate "I am unable/unwilling to take that >>>> content delivery at this time". >>>>>>=20 >>>>>> Regards >>>>>> Ben >>>>>>=20 >>>>>>> To manage this would introduce a very high complexity. >>>>>>> And this would be just to try to save the content requests >>>>>>> redirected >>>> by the uCDN to the dCDN in the timeslot between the time the dCDN = gets >>>> down and the time the uCDN takes this failure into account in its = CDN >>>> selection process. >>>>>>> It is much better to try to reduce this timeslot as much as >>>>>>> possible, >>>> with routing optimizations (we will propose as soon as possible). >>>>>>> Rather than introducing additional complexities (to manage >>>>>>> redirection >>>> to the uCDN) in the framework. >>>>>>>=20 >>>>>>>=20 >>>>>>> By the way, as you know, the IESG has just approved today the >>>>>>> 'Content >>>> Distribution Network Interconnection (CDNI) Problem Statement' = draft >>>> as informational RFC. This is a good point. >>>>>>> And, as you may see in the draft "CDNI request routing", we do = not >>>> propose to modify this problem statement draft. >>>>>>> We want know to focus now on getting the specifications of all >>>>>>> CDNI >>>> interfaces ready as soon as possible. >>>>>>>=20 >>>>>>> Best regards, >>>>>>>=20 >>>>>>> Yannick Le Lou=E9dec. >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Message d'origine----- >>>>>>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la >>>>>>> part de Ben Niven-Jenkins Envoy=E9 : lundi 9 juillet 2012 20:41 = =C0 : >>>>>>> BERTRAND Gilles RD-CORE Cc : cdni@ietf.org; Pilarski Marcin - >>>>>>> Korpo TP; MARREC Anne RD-CORE Objet : Re: [CDNi] TR: I-D Action: >>>>>>> draft-lelouedec-cdni-request-routing-00.txt >>>>>>>=20 >>>>>>> Colleagues, >>>>>>>=20 >>>>>>> I started reading draft-lelouedec-cdni-request-routing-00 and = this >>>> text caught my eye: >>>>>>>=20 >>>>>>> Quoting [I-D.ietf-cdni-problem-statement ], "The CDNI Request >>>>>>> Routing >>>>>>> interface enables a Request Routing function in an upstream CDN = to >>>>>>> query a Request Routing function in a downstream CDN to = determine >> if >>>>>>> the downstream CDN is able (and willing) to accept the delegated >>>>>>> content request". >>>>>>>=20 >>>>>>> The "ability" and the "willingness" of the downstream CDN to = accept >>>>>>> the delegated content request match two fully different = processes >> in >>>>>>> CDN interconnection. And the description of both these = processes >>>>>>> should be reviewed and clarified for the following reasons: >>>>>>>=20 >>>>>>> o Regarding the former process, i.e. related to the "ability" >>>>>>> ("enables a Request Routing function in an upstream CDN to >>>>>>> query >>>> a >>>>>>> Request Routing function in a downstream CDN to determine if = the >>>>>>> downstream CDN is able (...) to accept the delegated content >>>>>>> request"), a routing protocol is used to achieve such a = process, >>>>>>> called routing process, in many other technologies and = networks >>>>>>> (IP, ATM, etc.). In all these technologies, it is the >> downstream >>>>>>> entity that provides routing information to the upstream = entity. >>>>>>> The same approach should be applied to CDN interconnection. = The >>>>>>> reverse approach ("uCDN queries it downstream CDNs dCDN 1, >>>>>>> dCDN >>>> 2, >>>>>>> dCDN 3, and then it selects one of them based on their >>>> responses") >>>>>>> would suffer from latency, signaling overhead and/or lack of >>>>>>> reactivity to events that impact the ability of the = downstream >>>>>>> CDNs to accept delegated content requests. >>>>>>>=20 >>>>>>> o Regarding the latter process, i.e. related to the = "willingness" >>>>>>> ("enables a Request Routing function in an upstream CDN to >>>>>>> query >>>> a >>>>>>> Request Routing function in a downstream CDN to determine if = the >>>>>>> downstream CDN (...) is willing (...)to accept the delegated >>>>>>> content request"), it is to be noted that the relationship >>>> between >>>>>>> a uCDN and a dCDN is always in the frame of a contractual >>>>>>> agreement between the administrative entity owning the uCDN, >>>>>>> acting as the customer, and the administrative entity owning = the >>>>>>> dCDN, acting as the service provider. Therefore, consider a >> case >>>>>>> where >>>>>>>=20 >>>>>>> * the uCDN has a content request to redirect which is in = full >>>>>>> conformance with the terms of this contractual agreement, >>>>>>> and >>>>>>>=20 >>>>>>> * the uCDN has selected this dCDN. >>>>>>>=20 >>>>>>> As the uCDN knows, thanks to the routing information >>>>>>> exchanged >>>> via >>>>>>> the aforementioned routing process, that the dCDN is able to >>>>>>> accept this content request, the uCDN MAY redirect the = content >>>>>>> request to the dCDN and the dCDN MUST accept the content >> request. >>>>>>> Exchanging over the CDNI Request Routing interface = information >>>>>>> about the "willingness" of the dCDN to accept the content >> request >>>>>>> is not relevant. >>>>>>>=20 >>>>>>> I think you might be over thinking what we wrote in the problem >>>> statement. >>>>>>>=20 >>>>>>> What was in the problem statement was meant to convey that an >>>>>>> upstream >>>> CDN could make a request to a downstream CDN to say "how do I = redirect >>>> this request to you" and the downstream CDN could reply with either >>>> "her is how to redirect it", or "no I can't/won't take that content >>>> delivery right now", reasons may include the uCDN has requested a >>>> delivery of a protocol the dCDN does not support (possibly in = error) >>>> or the dCDN has no capacity right now etc. >>>>>>>=20 >>>>>>> Ben >>>>>>>=20 >>>>>>> On 9 Jul 2012, at 18:00, wrote: >>>>>>>=20 >>>>>>>> Hi everyone, >>>>>>>>=20 >>>>>>>> We have just submitted the draft below. We are convinced that = it >>>>>>>> will >>>> help the WG to progress on the CDNI routing issues. >>>>>>>>=20 >>>>>>>> = http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-0 >>>>>>>> 0 >>>>>>>>=20 >>>>>>>> Any feedback is very welcome. >>>>>>>>=20 >>>>>>>> Best regards, >>>>>>>>=20 >>>>>>>> Gilles >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Message d'origine----- >>>>>>>> De : i-d-announce-bounces@ietf.org >>>>>>>> [mailto:i-d-announce-bounces@ietf.org] De la part de >>>>>>>> internet-drafts@ietf.org Envoy=E9 : lundi 9 juillet 2012 18:55 = =C0 : >>>>>>>> i-d-announce@ietf.org Objet : I-D Action: >>>>>>>> draft-lelouedec-cdni-request-routing-00.txt >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> A New Internet-Draft is available from the on-line >>>>>>>> Internet-Drafts >>>> directories. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Title : CDNI Request Routing >>>>>>>> Author(s) : Yannick Le Louedec >>>>>>>> Anne Marrec >>>>>>>> Gilles Bertrand >>>>>>>> Marcin Pilarski >>>>>>>> Filename : draft-lelouedec-cdni-request-routing-00.txt >>>>>>>> Pages : 30 >>>>>>>> Date : 2012-07-09 >>>>>>>>=20 >>>>>>>> Abstract: >>>>>>>> The present document proposes to clarify the CDNI Request = Routing >>>>>>>> interface introduced in [I-D.ietf-cdni-framework] and >>>>>>>> [I-D.ietf-cdni- problem-statement], as well as related = terminology. >>>>>>>>=20 >>>>>>>> In particular the present document proposes to split the CDNI >>>>>>>> Request Routing interface into two separate interfaces with >>>>>>>> clearer roles, named respectively CDNI Routing interface and >>>>>>>> CDNI Downstream Resource Identifier Signaling interface (CDNI = DRIS >> interface). >>>>>>>>=20 >>>>>>>> This part of the CDN interconnection framework the IETF has = been >>>>>>>> referring to so far with the term "CDNI Request Routing" is = just >>>>>>>> another routing, signaling and forwarding problem in a long >>>>>>>> series of the telecommunication history. For example, one can >>>>>>>> draw a direct analogy between the IP/MPLS-TE framework and the >>>>>>>> CDN interconnection framework. >>>>>>>>=20 >>>>>>>> In addition, this document recommends that the specification of >>>>>>>> ALL CDN interconnection interfaces in the scope of the CDNI = IETF >>>>>>>> WG relies on the equivalent concept to IP prefix for CDN >>>>>>>> interconnection, named 'contentRequestScope'. This highly = useful >>>>>>>> and powerful concept SHALL be used to simplify the = specification >>>>>>>> of ALL CDN interconnection interfaces, as well as to ensure >>>>>>>> performance and scalability in CDN interconnection. >>>>>>>>=20 >>>>>>>> All these proposals can be smoothly integrated in the WG = drafts, >>>>>>>> especially [I-D.ietf-cdni-framework] and >>>>>>>> [I-D.ietf-cdni-requirements], as they essentially propose >>>>>>>> (useful) clarifications of the existing framework. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>> = https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-rou >>>>>>>> ting >>>>>>>>=20 >>>>>>>> There's also a htmlized version available at: >>>>>>>> = http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-0 >>>>>>>> 0 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>>>=20 >>>>>>>> = _________________________________________________________________ >>>>>>>> ____ ____________________________________________________ >>>>>>>>=20 >>>>>>>> Ce message et ses pieces jointes peuvent contenir des >>>>>>>> informations confidentielles ou privilegiees et ne doivent donc >>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si = vous >>>>>>>> avez recu ce message par erreur, veuillez le signaler a >>>>>>>> l'expediteur et le detruire ainsi >>>> que les pieces jointes. Les messages electroniques etant = susceptibles >>>> d'alteration, France Telecom - Orange decline toute responsabilite = si >>>> ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>>=20 >>>>>>>> This message and its attachments may contain confidential or >>>>>>>> privileged information that may be protected by law; they = should >>>>>>>> not >>>> be distributed, used or copied without authorisation. >>>>>>>> If you have received this email in error, please notify the >>>>>>>> sender >>>> and delete this message and its attachments. >>>>>>>> As emails may be altered, France Telecom - Orange is not liable >>>>>>>> for >>>> messages that have been modified, changed or falsified. >>>>>>>> Thank you. >>>>>>>>=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 >>>>>>> Ce message et ses pieces jointes peuvent contenir des = informations >>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez = recu >>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le >>>>>>> detruire ainsi >>>> que les pieces jointes. Les messages electroniques etant = susceptibles >>>> d'alteration, France Telecom - Orange decline toute responsabilite = si >>>> ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>=20 >>>>>>> This message and its attachments may contain confidential or >>>>>>> privileged information that may be protected by law; they should >>>>>>> not >>>> be distributed, used or copied without authorisation. >>>>>>> If you have received this email in error, please notify the = sender >>>>>>> and >>>> delete this message and its attachments. >>>>>>> As emails may be altered, France Telecom - Orange is not liable >>>>>>> for >>>> messages that have been modified, changed or falsified. >>>>>>> Thank you. >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> CDNi mailing list >>>>>> CDNi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>> This e-mail and its contents are subject to the DISCLAIMER at >>>> http://www.tno.nl/emaildisclaimer >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>> = ______________________________________________________________________ >>>> ____ _______________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des = informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses, >>>> exploites ou copies sans autorisation. Si vous avez recu ce message >>>> par erreur, veuillez le signaler a l'expediteur et le detruire = ainsi >>>> que les pieces jointes. Les messages electroniques etant = susceptibles >>>> d'alteration, France Telecom - Orange decline toute responsabilite = si >>>> ce message a ete altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or >>>>>> privileged >>>> information that may be protected by law; they should not be >>>> distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the = sender >>>>>> and >>>> delete this message and its attachments. >>>>>> As emails may be altered, France Telecom - Orange is not liable = for >>>> messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>> = ______________________________________________________________________ >>>> ____ _______________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des = informations >>>> confidentielles ou privilegiees et ne doivent donc >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous >>>>>> avez >>>> recu ce message par erreur, veuillez le signaler >>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les >>>> messages electroniques etant susceptibles d'alteration, >>>>>> France Telecom - Orange decline toute responsabilite si ce = message >>>>>> a >>>> ete altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or >>>>>> privileged >>>> information that may be protected by law; >>>>>> they should not be distributed, used or copied without = authorisation. >>>>>> If you have received this email in error, please notify the = sender >>>>>> and >>>> delete this message and its attachments. >>>>>> As emails may be altered, France Telecom - Orange is not liable = for >>>> messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>>=20 >>>=20 >> = __________________________________________________________________________= >> _______________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez >> recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages >> electroniques etant susceptibles d'alteration, >>> France Telecom - Orange decline toute responsabilite si ce message a = ete >> altere, deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or = privileged >> information that may be protected by law; >>> they should not be distributed, used or copied without = authorisation. >>> If you have received this email in error, please notify the sender = and >> delete this message and its attachments. >>> As emails may be altered, France Telecom - Orange is not liable for >> messages that have been modified, changed or falsified. >>> Thank you. >>>=20 >>> _______________________________________________ >>> 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 oskar.vandeventer@tno.nl Thu Jul 26 04:34:34 2012 Return-Path: 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 244B221F86C2 for ; Thu, 26 Jul 2012 04:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.046 X-Spam-Level: **** X-Spam-Status: No, score=4.046 tagged_above=-999 required=5 tests=[AWL=3.950, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_93=0.6] 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 0zlRusUoAwnm for ; Thu, 26 Jul 2012 04:34:31 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2B64F21F86D1 for ; Thu, 26 Jul 2012 04:34:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,659,1336341600"; d="scan'208";a="73022680" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1a.tno.nl with ESMTP; 26 Jul 2012 13:34:28 +0200 Received: from EXC-MBX02.tsn.tno.nl ([169.254.2.202]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.02.0298.004; Thu, 26 Jul 2012 13:34:28 +0200 From: "Deventer, M.O. (Oskar) van" To: "GUILLOU, Allan" Thread-Topic: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.txt Thread-Index: AQHNamIcTgu/Ma+fB0qRTcb3voUnfpc51cGAgAFwIICAACnlAA== Date: Thu, 26 Jul 2012 11:34:28 +0000 Message-ID: References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> <2040_1341930789_4FFC3D24_2040_2504_1_b86bff40-ae68-40c0-b8e5-060f51be6864@PEXCVZYH02.corporate.adroot.infra.ftgroup> <3A7EA7EE-F8D4-4094-83F2-12CD3826B662@tno.nl> <5004079D.4000406@cisco.com> <29661_1343216353_500FDAE1_29661_643_1_2AC63C9F27AF8446B0C064C50FC0A89305D959@PEXCVZYM13.corporate.adroot.infra.f tgroup> <2AF54F9B-B4FF-4043-A9DE-36C0417F9EAC@cisco.com> <605D99D5-3524-4887-85FB-0EA690F28CC7@niven-jenkins.co.uk> In-Reply-To: <605D99D5-3524-4887-85FB-0EA690F28CC7@niven-jenkins.co.uk> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 11:34:34 -0000 >> In *B* you still have a per session request to the dCDN. > Not necessarily. How I would like to see this work is that the protocol a= llows > the dCDN's response to be scoped wider than the uCDN's request. Also, the uCDN could bundle a set of associated requests. E.g. in de case o= f HAS, the contents of a complete manifest file could be resolved in a sing= le request from the uCDN to the dCDN.=20 Oskar -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben= Niven-Jenkins Sent: Thursday, 26 July, 2012 13:02 To: GUILLOU, Allan Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.txt Allan, On 25 Jul 2012, at 14:04, GUILLOU, Allan wrote: > In *B* you still have a per session request to the dCDN. Not necessarily. How I would like to see this work is that the protocol all= ows the dCDN's response to be scoped wider than the uCDN's request. For example, a uCDN could request a redirection for a specific IP address a= nd the dCDN could return a response scoped to an entire (set of) IP subnet(= s) that is cacheable & reusable by the uCDN for a period of time to avoid t= he uCDN having to make a request to the dCDN for each redirection while lea= ving control with the dCDN to determine how widely to scope its requests (b= ased on its knowledge of its footprint, load, etc) & how long it wants its = responses to be cached for. Ben > If it is just to handle a problem in the dCDN, and that you consider that= you realy need this kind of information, another method can be to add an "= back pressure mechanism". >=20 > It could be done by a message sent from dCDN to uCDN when ie is overload,= or by adding in the Footprint&Cap information a "max value" which can give= the number of stream that the dCDN can accept from this specific uCDN. In = case of overload, the dCDN can just send an update with a lower value to as= k the uCDN to select another dCDN. >=20 >=20 >=20 >> -----Message d'origine----- >> De : Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]=20 >> Envoy=E9 : mercredi 25 juillet 2012 14:36 =C0 :=20 >> Cc :=20 >> Francois Le Faucheur (flefauch); GUILLOU, Allan; Scott Wainner=20 >> (swainner); cdni@ietf.org Objet : Re: [CDNi] I-D Action:=20 >> draft-lelouedec-cdni-request-routing-00.txt >>=20 >> All, >>=20 >> To help the discussion, we may need to distinguish three (main) modes: >>=20 >> *A* the uCDN uses the Footprint&Cap information (advertised by dCDN)=20 >> to select a dCDN. The uCDN redirects to the selected dCDN and=20 >> considers that he is done with request routing. >>=20 >> *B* the uCDN uses the Footprint&Cap information (advertised by dCDN)=20 >> to select a dCDN candidate. The uCDN queries the dCDN before redirecting= . >> Querying dCDN optionally allows the dCDN to provide to uCDN the final=20 >> redirection information so the the enduser experiences a single redirect= . >> Querying dCDN optionally allows the uCDN to pick an alternate dCDN if=20 >> the initially selected dCDN cannot handle the request. >>=20 >> *C* the uCDN queries multiple dCDNs on a per-request basis and=20 >> selects dCDN based on their responses. In other words, the=20 >> Footprint&Cap advertisement is performed via on-demand per-request queri= es. >>=20 >>=20 >> I think: >> * Scott pointed out that fundamentatly both *A* and *B* have to=20 >> deal with (typically transient) situations where uCDN thinks dCDN can=20 >> take a request and dCDN actually cannot handle it. And pointed out=20 >> that with *A* the transient period is dictated by the Footprint&Cap=20 >> advertisement "update speed" while with *B* it is not. >> * Allan was saying *A* is all he needs and *B* is extra=20 >> complexity that he doesn't need. >> * Gilles and lelouedec-cdni-request-routing were saying *C* is bad. >>=20 >> My impression is that there is violent agreement that *A* is to be=20 >> supported. I think Allan and Gilles message indicate so. I personally=20 >> support that. I think many people have been discussing that approach.=20 >> If someone feels this is NOT to be supported by CDNI, do let us know. >>=20 >> I think Gilles message below is primarily arguing against *C*. I=20 >> personally agree that this need not be supported in our initial=20 >> deliverables. Are there people arguing this approach is to be=20 >> supported in the initial deliverables? >>=20 >> Regarding *B*, I personally see it as quite useful and worth=20 >> supporting in Phase 1 (possibly as an option). >> Regarding Allan's points: >> * I agree there is some "scalability" argument (i.e.=20 >> state+wait-for- >> dCDN-response) but it amounts to a web-services call out per request=20 >> and buys you reliability of request routing, so I see that as a=20 >> trade-off that some CDNs should be able to exercise. >>=20 >> * I don't buy the latency argument because you end up with 2=20 >> RTTs in both *A* and *B* (in normal situations where dCDN can handle=20 >> the request) (i.e. user-->uCDN, uCDN-->user, user-->dCDN, dCDN-->user=20 >> versus user-- >>> uCDN, uCDN-->dCDN, dCDN-->uCDN, uCDN-->user) and in the transient=20 >>> cases >> where dCDN cannot handle the request *B* can do as well as *A* (drop=20 >> the >> request) or has the option to differently i.e. re-redirect at the=20 >> cost of an extra RTT. >> * I don't buy the "loop free mechanism" argument. In *B*, it is=20 >> easy to implement a loop detection and even loop prevention (if you=20 >> want). In *A*, you have no loop prevention (other than the inherent=20 >> HTTP/DNS max redirect/max CNAMEs) Other opinions on *B* are sought. >>=20 >>=20 >> Cheers >>=20 >> Francois >>=20 >>=20 >> On 25 Jul 2012, at 13:39, =20 >> wrote: >>=20 >>> Hi everyone, >>>=20 >>> I fully agree with Allan's comments. Putting aside the vocabulary >> ('recursive model' etc), Allan's comment are consistent with the=20 >> messages that=20 >> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >> tries to convey. >>>=20 >>> " o Regarding the former process, i.e. related to the "ability" >>> ("enables a Request Routing function in an upstream CDN to query a >>> Request Routing function in a downstream CDN to determine if the >>> downstream CDN is able (...) to accept the delegated content >>> request"), a routing protocol is used to achieve such a process, >>> called routing process, in many other technologies and networks >>> (IP, ATM, etc.). In all these technologies, it is the downstream >>> entity that provides routing information to the upstream entity. >>> The same approach should be applied to CDN interconnection. The >>> reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2, >>> dCDN 3, and then it selects one of them based on their responses") >>> would suffer from latency, signaling overhead and/or lack of >>> reactivity to events that impact the ability of the downstream >>> CDNs to accept delegated content requests." >>>=20 >>> Best regards, >>> -- >>> Gilles >>>=20 >>>=20 >>> -----Message d'origine----- >>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part=20 >>> de >> GUILLOU, Allan >>> Envoy=E9 : mercredi 25 juillet 2012 12:23 =C0 : Scott Wainner;=20 >>> cdni@ietf.org Objet : Re: [CDNi] TR: I-D Action:=20 >>> draft-lelouedec-cdni-request-routing- >> 00.txt >>>=20 >>> Hi, >>>=20 >>> With a "recusive model" as you ask if I understand, you expect the=20 >>> dCDN >> to send like an "ack" for each request, and if not the uCDN will try=20 >> to find the second best dCDN and do the same thing. >>>=20 >>> I think that this model may add complexity and may cause some >> scalability problem. You will have to implement timers between=20 >> request and ack, retransmission mechanism to make sure that request=20 >> has not been lost, loop free mechanism, And all this may add latency=20 >> on all requests and performances problems. >>>=20 >>> In the iterative model, if the dCDN is not able to handle the=20 >>> request, >> this request will be lost. It is the same thing in IP network today=20 >> we do not ask the routing protocol to change when there is saturation so= mewhere. >> It is the responsibility of each ISP to choose another route to join=20 >> this destination if he want to keep a good quality of service. If a=20 >> dCDN is overloaded, it will stop announcing part of its footprint or=20 >> uCDN may apply some policy to force choosing another dCDN. >>>=20 >>> It is right that this second model may not in case of dCDN=20 >>> saturation >> have the best reactivity, but it is exactly the same thing on the=20 >> internet today. We can imagine that a poor dCDN which have saturation=20 >> will be "black listed" by all the uCDN and the regulation will be done l= ike this. >>> I think recursive model will add complexity all the time for a gain >> witch is not in my opinion so important and that will not be seen so=20 >> often. >>>=20 >>> Allan >>>=20 >>>> -----Message d'origine----- >>>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la=20 >>>> part de Scott Wainner Envoy=E9 : lundi 16 juillet 2012 14:23 =C0 : >>>> cdni@ietf.org Objet : Re: [CDNi] TR: I-D Action: >>>> draft-lelouedec-cdni-request-routing- >>>> 00.txt >>>>=20 >>>> On 7/10/12 11:39 AM, Brandenburg, R. (Ray) van wrote: >>>>> Hi Yannick, >>>>>=20 >>>>> We seem to be misunderstanding each other. Maybe this will help=20 >>>>> clarify >>>> my point: >>>>>=20 >>>>>> Let me try to fully understand your point: >>>>>> Are you really meaning that in this case the dCDN has in reality >>>> absolutely no obligation with regards to the uCDN? >>>>>> Are you really meaning that in this case the dCDN decides alone,=20 >>>>>> in >>>> real time, and for each content request, whether it denies or=20 >>>> accepts to ensure delivery? >>>>> What I mean is that I would like to have a RR Interface at least=20 >>>>> support >>>> a model where for every content request the uCDN asks the dCDN=20 >>>> whether it wants to deliver that particular content item (I believe=20 >>>> you call this a PULL approach). And I would like to allow the dCDN=20 >>>> to be able to >> say 'No' >>>> on this request (whether it is for purposes or failure, overload,=20 >>>> or any other reason). >>>>>=20 >>>>>> Are you really meaning that in this case the dCDN decides alone,=20 >>>>>> in >>>> real time, and for each content request, whether it denies or=20 >>>> accepts to ensure delivery, and this even if the dCDN has the=20 >>>> capability to deliver the content? >>>>> Yes. >>>> I think we have to delineate between the iterative and recursive model= . >>>>=20 >>>> The recursive model assumes that the client request to the uCDN=20 >>>> will be recursive and the CDN-I RR interface will be used to=20 >>>> provide an answer for each client request. The choice to initiate=20 >>>> the recursion would be determined by the footprint / capabilities. =20 >>>> The ability of the dCDN to execute the specific request would=20 >>>> provide immediate feedback to the uCDN. A dCDN that continues to=20 >>>> advertise the footprint / capability, but frequently or continually=20 >>>> rejects the request via CDN-I RR would be a poor candidate. The=20 >>>> opportunity now arises where the uCDN may elect to choose an=20 >>>> alternate dCDN because its preferred dCDN (according to footprint /=20 >>>> capabilities) is 'under- >> performing'. >>>>=20 >>>> The iterative model, the uCDN blindly redirects the client to the=20 >>>> dCDN based on the footprint / capabilities. What the dCDN does=20 >>>> with the request is somewhat transparent to the uCDN. With the=20 >>>> exception of the CDN-I logging, the uCDN assumes the dCDN is=20 >>>> properly handling the requests that were delegated to the dCDN. If=20 >>>> you are trying to 'tighten' up the case of blind rejections, then=20 >>>> the frequency of the footprint / capabilities advertisements would hav= e to be accelerated. >>>> For the case where the dCDN repeatedly sees requests from the uCDN=20 >>>> that the dCDN can't handle, it should retract its footprint /=20 >>>> capabilities advertisement. Failing to do so would continually=20 >>>> black-hole routing requests which would be indicated in the logging >> information. >>>>=20 >>>> Either way, you need a feedback loop to avoid dumping routing requests= . >>>>=20 >>>> With any feedback loop (recursive routing request or footprint /=20 >>>> capabilities advertisement), you have to be careful about rapid=20 >>>> oscillations and dampening the responses. >>>>=20 >>>> Scott >>>>>=20 >>>>>> Are you really meaning that in this case the dCDN may possibly=20 >>>>>> response >>>> negatively to all requests for content request redirection=20 >>>> submitted by the uCDN over the CDNI request routing interface?=20 >>>> (i.e. that possibly the uCDN will never be allowed/invited to=20 >>>> redirect a content request to the >>>> dCDN?) >>>>>=20 >>>>> Yes. Any negative effect this may have on the business=20 >>>>> relationship >>>> between uCDN and dCDN should be handled on the business level. >>>>>=20 >>>>> Ray >>>>>=20 >>>>>=20 >>>>> On Jul 10, 2012, at 4:33 PM, >>>>> wrote: >>>>>=20 >>>>>> Hi Ray, >>>>>>=20 >>>>>>=20 >>>>>> 1) Ray, quoting your mail: "The current drafts seems to assume=20 >>>>>> some >>>> particular type of contractual agreement between CDNs that might=20 >>>> not always be the case." >>>>>>=20 >>>>>> Please quote the draft. >>>>>> Please let us know exactly to which sentence(s) of the draft you=20 >>>>>> are >>>> referring to. >>>>>> Otherwise it is hard to discuss and comment on your email. >>>>>>=20 >>>>>>=20 >>>>>> 2) Ray, Quoting your mail: "If a dCDN does not live up to its >>>> contractual agreement, this should be something that is handled on=20 >>>> a business level, not on a protocol level." >>>>>>=20 >>>>>> Maybe there is a deep misunderstanding. >>>>>> So I will try to be clear again. >>>>>> We do not propose the CDNI routing interface to be used by the=20 >>>>>> dCDN to >>>> send a message saying "Sorry, but I decide unilaterally to refuse=20 >>>> this content request". >>>>>> We do not propose the CDNI routing interface to be used to handle=20 >>>>>> any >>>> aspect relating to a dCDN deciding unilaterally to stop living up=20 >>>> to its contractual agreement. >>>>>>=20 >>>>>> Please let us know where you saw such an idea in this IETF draft=20 >>>>>> "CDNI >>>> request routing". >>>>>>=20 >>>>>> The only role of the CDNI routing interface is to be used to=20 >>>>>> advertise >>>> CDNI routing information from the downstream CDN to the upstream CDN. >>>>>> And this is the description given in this IETF draft. >>>>>>=20 >>>>>>=20 >>>>>> 3) Ray, quoting your mail: "one example of a contractual=20 >>>>>> agreement >>>> between two CDNs is one in which the uCDN and dCDN have agreed that=20 >>>> the dCDN will deliver some content on behalf of a uCDN, but decide=20 >>>> on a per- request basis whether it wants to do so (and is for=20 >>>> example paid per request). In these cases, the dCDN needs to have=20 >>>> the ability to deny delivery on a per-request basis." >>>>>>=20 >>>>>> Let me try to fully understand your point: >>>>>> Are you really meaning that in this case the dCDN has in reality >>>> absolutely no obligation with regards to the uCDN? >>>>>> Are you really meaning that in this case the dCDN decides alone,=20 >>>>>> in >>>> real time, and for each content request, whether it denies or=20 >>>> accepts to ensure delivery? >>>>>> Are you really meaning that in this case the dCDN decides alone,=20 >>>>>> in >>>> real time, and for each content request, whether it denies or=20 >>>> accepts to ensure delivery, and this even if the dCDN has the=20 >>>> capability to deliver the content? >>>>>> Are you really meaning that in this case the dCDN may possibly=20 >>>>>> response >>>> negatively to all requests for content request redirection=20 >>>> submitted by the uCDN over the CDNI request routing interface?=20 >>>> (i.e. that possibly the uCDN will never be allowed/invited to=20 >>>> redirect a content request to the >>>> dCDN?) >>>>>>=20 >>>>>>=20 >>>>>> 4) Ray, quoting your mail: "Every routing protocol defines the=20 >>>>>> expected >>>> behavior of interconnected elements/networks on a technical level,=20 >>>> not on a business level." >>>>>>=20 >>>>>> Again, this is not what I have written, and this is not the idea=20 >>>>>> we >>>> want to share. >>>>>> I wrote "Every routing protocol has been defined (or at least >>>> configured) so far by considering the expected behavior of the=20 >>>> interconnected elements/networks." >>>>>> That's all. >>>>>> I can rephrase this sentence the following way: "we must know=20 >>>>>> what we >>>> expect to do with a protocol to design it correctly." >>>>>> And IHMO this is an evidence; I don't know any other way to proceed. >>>>>>=20 >>>>>> Besides, let us consider BGP (which is by the way an option=20 >>>>>> proposed by >>>> some IETF members to implement this CDNI routing interface). >>>>>> In IP networks, BGP configurations in IP routers are defined as=20 >>>>>> per the >>>> business relationships (valley free policy, etc.). >>>>>> Of course the business relationships determine the BGP >> configurations. >>>>>> And of course BGP has been designed so as to allow to configure=20 >>>>>> IP >>>> interconnections adequately depending on the corresponding=20 >>>> Customer/provider, sibling and peering contractual agreements. >>>>>> But this does not mean that BGP "defines the expected behavior of >>>> interconnected elements/networks... on a business level." >>>>>> Even if we can indeed infer quite accurately the business=20 >>>>>> relationships >>>> between ISP from the BGP configuration of their IP routers (see=20 >>>> CAIDA project), but this is another story. >>>>>>=20 >>>>>>=20 >>>>>> Best regards, >>>>>>=20 >>>>>> Yannick Le Lou=E9dec. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >>>>>> Envoy=E9 : mardi 10 juillet 2012 15:13 =C0 : LE LOUEDEC Yannick=20 >>>>>> RD-CORE; Ben Niven-Jenkins Cc : Pilarski Marcin - Korpo TP;=20 >>>>>> cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR: I-D >>>>>> Action: draft-lelouedec-cdni-request- >>>> routing-00.txt >>>>>>=20 >>>>>> Hi Yannick, >>>>>>=20 >>>>>> See comments inline. >>>>>>=20 >>>>>> In general: IMO the CDNI interfaces should be abstracted from any=20 >>>>>> kind >>>> of contractual/business agreement that might or might not exist=20 >>>> between a dCDN and uCDN. The current drafts seems to assume some=20 >>>> particular type of contractual agreement between CDNs that might=20 >>>> not >> always be the case. >>>>>>=20 >>>>>> Ray >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: yannick.lelouedec@orange.com >>>> [mailto:yannick.lelouedec@orange.com] >>>>>> Sent: dinsdag 10 juli 2012 12:01 >>>>>> To: Brandenburg, R. (Ray) van; Ben Niven-Jenkins >>>>>> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne=20 >>>>>> RD-CORE >>>>>> Subject: RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- >>>> routing-00.txt >>>>>>=20 >>>>>> Hi Ray, all, >>>>>>=20 >>>>>>=20 >>>>>> 1) Ray, Quoting your mail: "I don't see why the CDNI Request=20 >>>>>> Routing >>>> interface should state that a dCDN MUST deliver the content if it=20 >>>> has indicated its ability to do so earlier in either a contractual=20 >>>> agreement or in the capability interface." >>>>>>=20 >>>>>> This is not what we have written. >>>>>> Let me try to rephrase simply. >>>>>>=20 >>>>>> A contractual agreement is a contractual agreement. >>>>>> It put in writings the respective obligations of the uCDN and of=20 >>>>>> the >>>> dCDN. >>>>>> The uCDN may redirect any content request to the dCDN as long as=20 >>>>>> it is >>>> in full conformance with the terms of this contractual agreement=20 >>>> (the type of the content request is in full conformance, the=20 >>>> maximum number of content requests per second is respected, etc.). >>>>>> In this case the dCDN may not say "Sorry, but I decide=20 >>>>>> unilaterally to >>>> refuse this content request". >>>>>>=20 >>>>>> [RvB]: This is where we disagree. IMHO, the type of behavior you >>>> describe (the dCDN not living up to its obligation) should not be=20 >>>> enforced by the CDNI Interfaces. If a dCDN does not live up to its=20 >>>> contractual agreement, this should be something that is handled on=20 >>>> a business level, not on a protocol level. >>>>>>=20 >>>>>> Why? Because this is the deal, a contractual agreement is a=20 >>>>>> contractual >>>> agreement! >>>>>> Yet the dCDN may say "I do apologize, but at this time I cannot=20 >>>>>> handle >>>> correctly a certain class of content requests specified in our=20 >>>> contractual agreement" (for example the class of the HTTP content=20 >>>> requests with token from French end users, because of overload=20 >>>> situation, failure, etc.) This is the role of the CDNI routing=20 >>>> interface to provide the uCDN with such information. >>>>>>=20 >>>>>> (And the dCDN may be given a penalty for example if this was=20 >>>>>> agreed in >>>> the terms of the contractual agreement.) >>>>>>=20 >>>>>>=20 >>>>>> 2) Ray, Quoting your mail: "I understand that in most cases, the >>>> contractual agreement might indeed impose this behavior on the dCDN" >>>>>>=20 >>>>>> Please provide the description of an example where this is not=20 >>>>>> the >>>> case. >>>>>> Otherwise the IETF CDNI WG shall indeed consider this is ALWAYS=20 >>>>>> the >>>> case. >>>>>>=20 >>>>>> [RvB]: I can't remember ever seeing such a discussion on the WG list= . >>>> Anyway: one example of a contractual agreement between two CDNs is=20 >>>> one in which the uCDN and dCDN have agreed that the dCDN will=20 >>>> deliver some content on behalf of a uCDN, but decide on a=20 >>>> per-request basis whether it wants to do so (and is for example=20 >>>> paid per request). In these cases, the dCDN needs to have the=20 >>>> ability to deny delivery on a per- >> request basis. >>>>>>=20 >>>>>> And this is an important point to be able to progress in the CDNI >>>> interfaces' specification works. >>>>>>=20 >>>>>> If the contractual agreement does not define clearly the=20 >>>>>> obligations of >>>> the uCDN, it is impossible to dimension adequately the dCDN,=20 >>>> neither to define correctly the CDNI contractual agreements between=20 >>>> the dCDN and the dCDNs of this dCDN. >>>>>> If the contractual agreement does not define clearly the=20 >>>>>> obligations of >>>> the dCDN, the dCDN may do what it wants... even to put in the trash=20 >>>> can any content request it accepted to handle. >>>>>>=20 >>>>>> [RvB]: Exactly, this is something that needs to be discussed on a >>>> business/contractual level and not on a technical level. That is=20 >>>> way IMHO the CDNI Interfaces should not make ANY assumptions on=20 >>>> what was agreed on a contractual level. >>>>>>=20 >>>>>> In both situations it is impossible to ensure any quality of=20 >>>>>> experience >>>> to the end user. >>>>>>=20 >>>>>>=20 >>>>>> 3) Ray, Quoting your mail: "I don't think this type of behavior=20 >>>>>> should >>>> be imposed by the protocol we're developing here." >>>>>>=20 >>>>>> I do not sure I understand this sentence. >>>>>> Every routing protocol has been defined (or at least configured)=20 >>>>>> so far >>>> by considering the expected behavior of the interconnected=20 >>>> elements/networks. >>>>>>=20 >>>>>> [RvB]: Every routing protocol defines the expected behavior of >>>> interconnected elements/networks on a technical level, not on a=20 >>>> business level. Having a dCDN say 'I'm not willing to deliver this=20 >>>> content' is perfectly fine from a technical perspective, although=20 >>>> it could be problematic from a contractual perspective. >>>>>>=20 >>>>>> But maybe I will understand if you provide an example on the=20 >>>>>> point >>>>>> 2 >>>> above. >>>>>>=20 >>>>>>=20 >>>>>> Best regards, >>>>>>=20 >>>>>> Yannick Le Lou=E9dec. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >>>>>> Envoy=E9 : mardi 10 juillet 2012 09:20 =C0 : Ben Niven-Jenkins; LE=20 >>>>>> LOUEDEC Yannick RD-CORE Cc : Pilarski Marcin >>>> - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR: >>>> I-D >>>> Action: draft-lelouedec-cdni-request-routing-00.txt >>>>>>=20 >>>>>> Hi Yannick, Ben, >>>>>>=20 >>>>>> I tend to agree with Ben here. When reading the draft, I got the >>>> feeling that the draft seems to assume a lot about the relationship=20 >>>> between the uCDN and dCDN. For example, I don't see why the CDNI=20 >>>> Request Routing interface should state that a dCDN MUST deliver the=20 >>>> content if it has indicated its ability to do so earlier in either=20 >>>> a contractual agreement or in the capability interface. I=20 >>>> understand that in most cases, the contractual agreement might=20 >>>> indeed impose this behavior on the dCDN, but I don't think this=20 >>>> type of behavior should be imposed by the protocol we're developing he= re. >>>>>>=20 >>>>>> It was always my assumption that the Request Routing Interface=20 >>>>>> would at >>>> least include the option of allowing the uCDN to query the dCDN for=20 >>>> every content request whether the dCDN is willing to deliver that=20 >>>> particular request. >>>>>>=20 >>>>>> I will send my full review of the draft later. >>>>>>=20 >>>>>> Ray >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On=20 >>>>>> Behalf Of >>>> Ben Niven-Jenkins >>>>>> Sent: dinsdag 10 juli 2012 7:38 >>>>>> To: yannick.lelouedec@orange.com >>>>>> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne=20 >>>>>> RD-CORE >>>>>> Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- >>>> routing-00.txt >>>>>>=20 >>>>>> Yannick, >>>>>>=20 >>>>>> Please see inline. >>>>>>=20 >>>>>> On 9 Jul 2012, at 20:05, wrote: >>>>>>=20 >>>>>>> Hi Ben, all, >>>>>>>=20 >>>>>>> Ben, quoting you mail below, "... the downstream CDN could reply=20 >>>>>>> with either "here is how to redirect it"", >>>>>>>=20 >>>>>>> =3D> This is the role of the CDNI DRIS interface to provide the=20 >>>>>>> uCDN >>>> with this information, and we target to make its specification=20 >>>> public before Vancouver meeting so that everyone may read it before=20 >>>> the meeting and get full knowledge of our proposal about this part=20 >>>> of CDNI request routing. >>>>>>>=20 >>>>>>> Ben, quoting you mail below, "... or "no I can't/won't take that >>>> content delivery right now", reasons may include the uCDN has=20 >>>> requested a delivery of a protocol the dCDN does not support=20 >>>> (possibly >> in error). >>>>>>>=20 >>>>>>> =3D> This is the role of the CDNI logging interface to provide the= =20 >>>>>>> uCDN >>>> with this information. >>>>>> I agree this information should be logged but the Request Routing >>>> interface (what you call the DRIS) also needs to be able to=20 >>>> indicate a failure. >>>>>>=20 >>>>>> Otherwise the uCDN will 'blindly' redirect the the dCDN and the >>>> delivery will fail leading to poor end user experience. >>>>>>=20 >>>>>>> Ben, quoting you mail below, "... or "no I can't/won't take that >>>> content delivery right now", reasons may include ... the dCDN has=20 >>>> no capacity right now etc." >>>>>>>=20 >>>>>>> =3D> This is the role of the CDNI routing interface to provide the= =20 >>>>>>> uCDN >>>> with this information. >>>>>> It is the role of the CDN capability/routing interface to=20 >>>>>> advertise >>>> broad capabilities etc not to give extremely fine grained real-time=20 >>>> information on exactly the state of the dCDN. >>>>>>=20 >>>>>> Even if the capability/routing interface is real-time there are=20 >>>>>> likely >>>> to still be race conditions where we need the dCDN to be about to=20 >>>> indicate a failure to accept a redirect through the request=20 >>>> routing/DRIS interface >>>>>>=20 >>>>>>> So we may conclude we are in line basically, which is a good point. >>>>>>> We just aimed at checking there was a common understanding on=20 >>>>>>> this >>>> point. >>>>>>>=20 >>>>>>> The key point for us here is that we don't want this sentence >>>> extracted from draft-ietf-cdni-problem-statement be interpreted as: ". >>>> and the dCDN MUST accept the content request except when it has not=20 >>>> the "ability" to do so." >>>>>> Why not? IMO that is a valid scenario for some use cases. >>>>>>=20 >>>>>>> The fact that the dCDN is temporary unable to handle content=20 >>>>>>> request >>>> correctly is not a valid reason for the dCDN to be discharged of=20 >>>> its obligations to the uCDN. >>>>>>> The contract set between the uCDN and the dCDN remains valid=20 >>>>>>> anyway, >>>> and the obligations of the dCDN as well. >>>>>> Correct, but that contract may not be the same for all uCDNs &=20 >>>>>> dCDNs, >>>> for example a uCDN may not have a guarantee that a dCDN can handle=20 >>>> everything it is requested to handle but the contract may only be=20 >>>> that the dCDN guarantees to handle up to a certain volume of traffic. >>>>>>=20 >>>>>>> The dCDN must announce to the uCDN that it is temporary unable,=20 >>>>>>> as >>>> soon as possible, via the CDNI routing interface. >>>>>>> And the uCDN must take this information into account in its CDN >>>> selection process as soon as possible. >>>>>>> Then if the uCDN decides to continue to redirect content=20 >>>>>>> requests to >>>> the dCDN, the uCDN MAY perfectly do it, but the uCDN knows these=20 >>>> content requests will be lost. >>>>>> What happens in the period between the dCDN being unable to=20 >>>>>> handle >>>> requests and the time it takes to advertise that to the uCDN and=20 >>>> for the uCDN to process & incorporate that new knowledge? Are=20 >>>> requests blindly forwarded to the dCDN which is unable to handle=20 >>>> them leading to poor user experience? >>>>>>=20 >>>>>>> We could even imagine the situation where the uCDN continues to=20 >>>>>>> do it >>>> intentionally, because it has no better option and the content=20 >>>> request will be lost anyway. For example in the case where neither=20 >>>> the uCDN nor the other downstream CDNs of the uCDN cannot manage=20 >>>> correctly the content request, the uCDN could do it intentionally=20 >>>> so as to be able to clearly prove (with CDNI logging information)=20 >>>> that it is the dCDN, not the uCDN, who is at fault. >>>>>>> But, of course, if there are alternative backup options, the=20 >>>>>>> normal >>>> reaction of the uCDN is to stop as soon as possible to redirect=20 >>>> content requests to the dCDN when the uCDN knows that the dCDN is=20 >>>> unable to handle them correctly. >>>>>>>=20 >>>>>>> So, to be clear, we would prefer the sentence to be understood as: >>>>>>> ". and the dCDN MUST accept the content request. >>>>>>> And if it cannot handle correctly the redirected content request=20 >>>>>>> it >>>> receives, the content request is lost. >>>>>> What about scenarios where the uCDN has a choice of dCDNs (e.g.=20 >>>>>> two >>>> national-wide CDNs offering services at different costs), the uCDN=20 >>>> may elect to query both dCDNs and decide based on their responses=20 >>>> which one to choose. If the dCDN is unable to satisfy the request=20 >>>> the uCDN needs to know that so that it can fallback to the (more=20 >>>> expensive in this example) dCDN. >>>>>>=20 >>>>>>> For example the dCDN generates a response to the content request=20 >>>>>>> with >>>> an error message, or no response at all. And in parallel the CDNI=20 >>>> logging interface may be used to exchange logs corresponding to=20 >>>> this >> problem. >>>> Anyway the dCDN MAY NOT redirect that content request back towards=20 >>>> the uCDN." >>>>>>>=20 >>>>>>> Exactly as in IP networks: IP packets are not sent back towards=20 >>>>>>> the >>>> origin by a downstream router under failure or congestion. >>>>>> In a routed IP network, there is often a small packet loss while=20 >>>>>> the >>>> network re-converges, by enabling the dCDN to refuse a redirection=20 >>>> at CDNI Request Routing/DRIS query time we can reduce that window=20 >>>> by giving the uCDN the option to take an alternative action (e.g.=20 >>>> try another dCDN) while the routing/capability information re-converge= s. >>>>>>=20 >>>>>>> In both networks (IP and CDN), the reason is the same. >>>>>>> If the dCDN redirects back a content request to the uCDN, this >>>> generates a loop. >>>>>> Loop avoidance is a separate issue IMO to whether we should allow=20 >>>>>> a >>>> dCDN to be able to communicate "I am unable/unwilling to take that=20 >>>> content delivery at this time". >>>>>>=20 >>>>>> Regards >>>>>> Ben >>>>>>=20 >>>>>>> To manage this would introduce a very high complexity. >>>>>>> And this would be just to try to save the content requests=20 >>>>>>> redirected >>>> by the uCDN to the dCDN in the timeslot between the time the dCDN=20 >>>> gets down and the time the uCDN takes this failure into account in=20 >>>> its CDN selection process. >>>>>>> It is much better to try to reduce this timeslot as much as=20 >>>>>>> possible, >>>> with routing optimizations (we will propose as soon as possible). >>>>>>> Rather than introducing additional complexities (to manage=20 >>>>>>> redirection >>>> to the uCDN) in the framework. >>>>>>>=20 >>>>>>>=20 >>>>>>> By the way, as you know, the IESG has just approved today the=20 >>>>>>> 'Content >>>> Distribution Network Interconnection (CDNI) Problem Statement'=20 >>>> draft as informational RFC. This is a good point. >>>>>>> And, as you may see in the draft "CDNI request routing", we do=20 >>>>>>> not >>>> propose to modify this problem statement draft. >>>>>>> We want know to focus now on getting the specifications of all=20 >>>>>>> CDNI >>>> interfaces ready as soon as possible. >>>>>>>=20 >>>>>>> Best regards, >>>>>>>=20 >>>>>>> Yannick Le Lou=E9dec. >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Message d'origine----- >>>>>>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la=20 >>>>>>> part de Ben Niven-Jenkins Envoy=E9 : lundi 9 juillet 2012 20:41 =C0= : >>>>>>> BERTRAND Gilles RD-CORE Cc : cdni@ietf.org; Pilarski Marcin -=20 >>>>>>> Korpo TP; MARREC Anne RD-CORE Objet : Re: [CDNi] TR: I-D Action: >>>>>>> draft-lelouedec-cdni-request-routing-00.txt >>>>>>>=20 >>>>>>> Colleagues, >>>>>>>=20 >>>>>>> I started reading draft-lelouedec-cdni-request-routing-00 and=20 >>>>>>> this >>>> text caught my eye: >>>>>>>=20 >>>>>>> Quoting [I-D.ietf-cdni-problem-statement ], "The CDNI Request=20 >>>>>>> Routing interface enables a Request Routing function in an=20 >>>>>>> upstream CDN to query a Request Routing function in a downstream=20 >>>>>>> CDN to determine >> if >>>>>>> the downstream CDN is able (and willing) to accept the delegated=20 >>>>>>> content request". >>>>>>>=20 >>>>>>> The "ability" and the "willingness" of the downstream CDN to=20 >>>>>>> accept the delegated content request match two fully different=20 >>>>>>> processes >> in >>>>>>> CDN interconnection. And the description of both these=20 >>>>>>> processes should be reviewed and clarified for the following reason= s: >>>>>>>=20 >>>>>>> o Regarding the former process, i.e. related to the "ability" >>>>>>> ("enables a Request Routing function in an upstream CDN to=20 >>>>>>> query >>>> a >>>>>>> Request Routing function in a downstream CDN to determine if the >>>>>>> downstream CDN is able (...) to accept the delegated content >>>>>>> request"), a routing protocol is used to achieve such a process, >>>>>>> called routing process, in many other technologies and networks >>>>>>> (IP, ATM, etc.). In all these technologies, it is the >> downstream >>>>>>> entity that provides routing information to the upstream entity. >>>>>>> The same approach should be applied to CDN interconnection. The >>>>>>> reverse approach ("uCDN queries it downstream CDNs dCDN 1,=20 >>>>>>> dCDN >>>> 2, >>>>>>> dCDN 3, and then it selects one of them based on their >>>> responses") >>>>>>> would suffer from latency, signaling overhead and/or lack of >>>>>>> reactivity to events that impact the ability of the downstream >>>>>>> CDNs to accept delegated content requests. >>>>>>>=20 >>>>>>> o Regarding the latter process, i.e. related to the "willingness" >>>>>>> ("enables a Request Routing function in an upstream CDN to=20 >>>>>>> query >>>> a >>>>>>> Request Routing function in a downstream CDN to determine if the >>>>>>> downstream CDN (...) is willing (...)to accept the delegated >>>>>>> content request"), it is to be noted that the relationship >>>> between >>>>>>> a uCDN and a dCDN is always in the frame of a contractual >>>>>>> agreement between the administrative entity owning the uCDN, >>>>>>> acting as the customer, and the administrative entity owning the >>>>>>> dCDN, acting as the service provider. Therefore, consider a >> case >>>>>>> where >>>>>>>=20 >>>>>>> * the uCDN has a content request to redirect which is in full >>>>>>> conformance with the terms of this contractual agreement,=20 >>>>>>> and >>>>>>>=20 >>>>>>> * the uCDN has selected this dCDN. >>>>>>>=20 >>>>>>> As the uCDN knows, thanks to the routing information=20 >>>>>>> exchanged >>>> via >>>>>>> the aforementioned routing process, that the dCDN is able to >>>>>>> accept this content request, the uCDN MAY redirect the content >>>>>>> request to the dCDN and the dCDN MUST accept the content >> request. >>>>>>> Exchanging over the CDNI Request Routing interface information >>>>>>> about the "willingness" of the dCDN to accept the content >> request >>>>>>> is not relevant. >>>>>>>=20 >>>>>>> I think you might be over thinking what we wrote in the problem >>>> statement. >>>>>>>=20 >>>>>>> What was in the problem statement was meant to convey that an=20 >>>>>>> upstream >>>> CDN could make a request to a downstream CDN to say "how do I=20 >>>> redirect this request to you" and the downstream CDN could reply=20 >>>> with either "her is how to redirect it", or "no I can't/won't take=20 >>>> that content delivery right now", reasons may include the uCDN has=20 >>>> requested a delivery of a protocol the dCDN does not support=20 >>>> (possibly in error) or the dCDN has no capacity right now etc. >>>>>>>=20 >>>>>>> Ben >>>>>>>=20 >>>>>>> On 9 Jul 2012, at 18:00, wrote: >>>>>>>=20 >>>>>>>> Hi everyone, >>>>>>>>=20 >>>>>>>> We have just submitted the draft below. We are convinced that=20 >>>>>>>> it will >>>> help the WG to progress on the CDNI routing issues. >>>>>>>>=20 >>>>>>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing >>>>>>>> -0 >>>>>>>> 0 >>>>>>>>=20 >>>>>>>> Any feedback is very welcome. >>>>>>>>=20 >>>>>>>> Best regards, >>>>>>>>=20 >>>>>>>> Gilles >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Message d'origine----- >>>>>>>> De : i-d-announce-bounces@ietf.org=20 >>>>>>>> [mailto:i-d-announce-bounces@ietf.org] De la part de=20 >>>>>>>> internet-drafts@ietf.org Envoy=E9 : lundi 9 juillet 2012 18:55 =C0= : >>>>>>>> i-d-announce@ietf.org Objet : I-D Action: >>>>>>>> draft-lelouedec-cdni-request-routing-00.txt >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> A New Internet-Draft is available from the on-line=20 >>>>>>>> Internet-Drafts >>>> directories. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Title : CDNI Request Routing >>>>>>>> Author(s) : Yannick Le Louedec >>>>>>>> Anne Marrec >>>>>>>> Gilles Bertrand >>>>>>>> Marcin Pilarski >>>>>>>> Filename : draft-lelouedec-cdni-request-routing-00.txt >>>>>>>> Pages : 30 >>>>>>>> Date : 2012-07-09 >>>>>>>>=20 >>>>>>>> Abstract: >>>>>>>> The present document proposes to clarify the CDNI Request=20 >>>>>>>> Routing interface introduced in [I-D.ietf-cdni-framework] and >>>>>>>> [I-D.ietf-cdni- problem-statement], as well as related terminology= . >>>>>>>>=20 >>>>>>>> In particular the present document proposes to split the CDNI=20 >>>>>>>> Request Routing interface into two separate interfaces with=20 >>>>>>>> clearer roles, named respectively CDNI Routing interface and=20 >>>>>>>> CDNI Downstream Resource Identifier Signaling interface (CDNI=20 >>>>>>>> DRIS >> interface). >>>>>>>>=20 >>>>>>>> This part of the CDN interconnection framework the IETF has=20 >>>>>>>> been referring to so far with the term "CDNI Request Routing"=20 >>>>>>>> is just another routing, signaling and forwarding problem in a=20 >>>>>>>> long series of the telecommunication history. For example, one=20 >>>>>>>> can draw a direct analogy between the IP/MPLS-TE framework and=20 >>>>>>>> the CDN interconnection framework. >>>>>>>>=20 >>>>>>>> In addition, this document recommends that the specification of=20 >>>>>>>> ALL CDN interconnection interfaces in the scope of the CDNI=20 >>>>>>>> IETF WG relies on the equivalent concept to IP prefix for CDN=20 >>>>>>>> interconnection, named 'contentRequestScope'. This highly=20 >>>>>>>> useful and powerful concept SHALL be used to simplify the=20 >>>>>>>> specification of ALL CDN interconnection interfaces, as well as=20 >>>>>>>> to ensure performance and scalability in CDN interconnection. >>>>>>>>=20 >>>>>>>> All these proposals can be smoothly integrated in the WG=20 >>>>>>>> drafts, especially [I-D.ietf-cdni-framework] and=20 >>>>>>>> [I-D.ietf-cdni-requirements], as they essentially propose >>>>>>>> (useful) clarifications of the existing framework. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>> https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-r >>>>>>>> ou >>>>>>>> ting >>>>>>>>=20 >>>>>>>> There's also a htmlized version available at: >>>>>>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing >>>>>>>> -0 >>>>>>>> 0 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> 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=20 >>>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>>>=20 >>>>>>>> _______________________________________________________________ >>>>>>>> __ ____ ____________________________________________________ >>>>>>>>=20 >>>>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>>>> informations confidentielles ou privilegiees et ne doivent donc=20 >>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si=20 >>>>>>>> vous avez recu ce message par erreur, veuillez le signaler a=20 >>>>>>>> l'expediteur et le detruire ainsi >>>> que les pieces jointes. Les messages electroniques etant=20 >>>> susceptibles d'alteration, France Telecom - Orange decline toute=20 >>>> responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>>=20 >>>>>>>> This message and its attachments may contain confidential or=20 >>>>>>>> privileged information that may be protected by law; they=20 >>>>>>>> should not >>>> be distributed, used or copied without authorisation. >>>>>>>> If you have received this email in error, please notify the=20 >>>>>>>> sender >>>> and delete this message and its attachments. >>>>>>>> As emails may be altered, France Telecom - Orange is not liable=20 >>>>>>>> for >>>> messages that have been modified, changed or falsified. >>>>>>>> Thank you. >>>>>>>>=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 >>>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>>> informations confidentielles ou privilegiees et ne doivent donc=20 >>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si=20 >>>>>>> vous avez recu ce message par erreur, veuillez le signaler a=20 >>>>>>> l'expediteur et le detruire ainsi >>>> que les pieces jointes. Les messages electroniques etant=20 >>>> susceptibles d'alteration, France Telecom - Orange decline toute=20 >>>> responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>=20 >>>>>>> This message and its attachments may contain confidential or=20 >>>>>>> privileged information that may be protected by law; they should=20 >>>>>>> not >>>> be distributed, used or copied without authorisation. >>>>>>> If you have received this email in error, please notify the=20 >>>>>>> sender and >>>> delete this message and its attachments. >>>>>>> As emails may be altered, France Telecom - Orange is not liable=20 >>>>>>> for >>>> messages that have been modified, changed or falsified. >>>>>>> Thank you. >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> CDNi mailing list >>>>>> CDNi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>> This e-mail and its contents are subject to the DISCLAIMER at >>>> http://www.tno.nl/emaildisclaimer >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>> ___________________________________________________________________ >>>> ___ ____ _______________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>> informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>>> ce message par erreur, veuillez le signaler a l'expediteur et le=20 >>>> detruire ainsi que les pieces jointes. Les messages electroniques=20 >>>> etant susceptibles d'alteration, France Telecom - Orange decline=20 >>>> toute responsabilite si ce message a ete altere, deforme ou falsifie. = Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or=20 >>>>>> privileged >>>> information that may be protected by law; they should not be=20 >>>> distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the=20 >>>>>> sender and >>>> delete this message and its attachments. >>>>>> As emails may be altered, France Telecom - Orange is not liable=20 >>>>>> for >>>> messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>> ___________________________________________________________________ >>>> ___ ____ _______________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>> informations >>>> confidentielles ou privilegiees et ne doivent donc >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 >>>>>> avez >>>> recu ce message par erreur, veuillez le signaler >>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les >>>> messages electroniques etant susceptibles d'alteration, >>>>>> France Telecom - Orange decline toute responsabilite si ce=20 >>>>>> message a >>>> ete altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or=20 >>>>>> privileged >>>> information that may be protected by law; >>>>>> they should not be distributed, used or copied without authorisation= . >>>>>> If you have received this email in error, please notify the=20 >>>>>> sender and >>>> delete this message and its attachments. >>>>>> As emails may be altered, France Telecom - Orange is not liable=20 >>>>>> for >>>> messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>>=20 >>>=20 >> _____________________________________________________________________ >> _____ _______________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 >>> avez >> recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les=20 >>> messages >> electroniques etant susceptibles d'alteration, >>> France Telecom - Orange decline toute responsabilite si ce message a=20 >>> ete >> altere, deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or=20 >>> privileged >> information that may be protected by law; >>> they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender=20 >>> and >> delete this message and its attachments. >>> As emails may be altered, France Telecom - Orange is not liable for >> messages that have been modified, changed or falsified. >>> Thank you. >>>=20 >>> _______________________________________________ >>> 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 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From yannick.lelouedec@orange.com Thu Jul 26 05:01:07 2012 Return-Path: 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 4A0A221F8700 for ; Thu, 26 Jul 2012 05:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, UNPARSEABLE_RELAY=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 N8SDuWokZzCn for ; Thu, 26 Jul 2012 05:01:03 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 19AE621F86F9 for ; Thu, 26 Jul 2012 05:01:02 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 260D22DC315; Thu, 26 Jul 2012 14:01:02 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 0F1904C017; Thu, 26 Jul 2012 14:01:02 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 26 Jul 2012 14:01:01 +0200 From: To: Ben Niven-Jenkins , "GUILLOU, Allan" , "cdni@ietf.org" Thread-Topic: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.txt Thread-Index: AQHNax4WDt5/WFxTGUOr3GgzYrRzfJc7a6DQ Date: Thu, 26 Jul 2012 12:01:00 +0000 Message-ID: <23580_1343304062_5011317E_23580_5266_1_457F4B94DBADF743B61D350B3E7929FE029937@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> <2040_1341930789_4FFC3D24_2040_2504_1_b86bff40-ae68-40c0-b8e5-060f51be6864@PEXCVZYH02.corporate.adroot.infra.ftgroup> <3A7EA7EE-F8D4-4094-83F2-12CD3826B662@tno.nl> <5004079D.4000406@cisco.com> <29661_1343216353_500FDAE1_29661_643_1_2AC63C9F27AF8446B0C064C50FC0A89305D959@PEXCVZYM13.corporate.adroot.infra.f tgroup> <2AF54F9B-B4FF-4043-A9DE-36C0417F9EAC@cisco.com> <605D99D5-3524-4887-85FB-0EA690F28CC7@niven-jenkins.co.uk> In-Reply-To: <605D99D5-3524-4887-85FB-0EA690F28CC7@niven-jenkins.co.uk> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.26.112414 Subject: Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 12:01:07 -0000 Hi Ben, All, The specifications we have been producing for what we called the CDNI DRIS = interface in draft http://tools.ietf.org/html/draft-lelouedec-cdni-request-= routing-00, and that we are eager to share as soon as possible (again we ar= e sorry but we are doing our best...), allows=20 ** to support for synchronous operations (i.e. triggered by the reception o= f a content request by the uCDN) as well as asynchronous operations ** to support for operations initiated by the uCDN (a.k.a. PULL operations)= and by the dCDN (a.k.a. PUSH operations). Ben, what you describe in your mail below corresponds exactly to the "synch= ronous PULL" operations in these specifications. The idea is indeed to proceed that way to ensure maximal cacheability of in= formation exchanged over that interface. There is one key difference in our proposal as compared to your mail. It is the fact that we use this "contentRequestScope" concept mentioned in = draft http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00. This allows to generalize and to exploit fully the idea you mention, not on= ly for "an entire (set of) IP subnet(s)", but for any class of content requ= ests whatever the way it is structured. Such a class of content requests could be indeed the set of content request= s sent by end user agent whose IP addressed belong to the same "entire (set= of) IP subnet(s)". But such a class of content requests could also be the set of content reque= sts having HTTP as protocol. Or the class of contents having RTSP. Or the class of contents having RTSP as protocol and a token. Etc. Etc. As mentioned in draft http://tools.ietf.org/html/draft-lelouedec-cdni-reque= st-routing-00, this full flexibility is what makes this "contentRequestScop= e" concept "highly useful and powerful concept to simplify the specificatio= n of ALL CDN interconnection interfaces, as well as to ensure performance a= nd scalability in CDN interconnection". There are also some other differences, but of lesser importance. For example, about "how long it wants its responses to be cached for" (I qu= ote your mail, Ben).=20 We propose instead to associate a Boolean called "alwaysValid" that indicat= es whether the response is valid for any upcoming content request or just o= nly once, typically for the content request for which the uCDN requested th= is response to the dCDN. And it is up to the dCDN to send a message to invalidate any "alwaysValid" = information provided earlier and stored by the uCDN (because these informat= ion are now outdated or just because the dCDN prefers to stop to be obliged= to update them when needed). The dCDN may also send exactly the same type of message at query time, when= it cannot handle a content request the uCDN intends to redirect to him. In any case this may be useful when some events impact the ability of the d= ownstream CDNs to accept delegated content requests.=20 This is to reduce the "bind window" due to routing convergence we discussed= earlier by mail (really useful only when the routing/capability informatio= n re-convergence is too long). But I stop here,=20 Otherwise I should rather just make a copy paste of our proposed specificat= ions in a mail... We look forward to discuss this next week. Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de B= en Niven-Jenkins Envoy=E9=A0: jeudi 26 juillet 2012 13:02 =C0=A0: GUILLOU, Allan Cc=A0: cdni@ietf.org Objet=A0: Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.txt Allan, On 25 Jul 2012, at 14:04, GUILLOU, Allan wrote: > In *B* you still have a per session request to the dCDN. Not necessarily. How I would like to see this work is that the protocol all= ows the dCDN's response to be scoped wider than the uCDN's request. For example, a uCDN could request a redirection for a specific IP address a= nd the dCDN could return a response scoped to an entire (set of) IP subnet(= s) that is cacheable & reusable by the uCDN for a period of time to avoid t= he uCDN having to make a request to the dCDN for each redirection while lea= ving control with the dCDN to determine how widely to scope its requests (b= ased on its knowledge of its footprint, load, etc) & how long it wants its = responses to be cached for. Ben > If it is just to handle a problem in the dCDN, and that you consider that= you realy need this kind of information, another method can be to add an "= back pressure mechanism". >=20 > It could be done by a message sent from dCDN to uCDN when ie is overload,= or by adding in the Footprint&Cap information a "max value" which can give= the number of stream that the dCDN can accept from this specific uCDN. In = case of overload, the dCDN can just send an update with a lower value to as= k the uCDN to select another dCDN. >=20 >=20 >=20 >> -----Message d'origine----- >> De : Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]=20 >> Envoy=E9 : mercredi 25 juillet 2012 14:36 =C0 :=20 >> Cc :=20 >> Francois Le Faucheur (flefauch); GUILLOU, Allan; Scott Wainner=20 >> (swainner); cdni@ietf.org Objet : Re: [CDNi] I-D Action:=20 >> draft-lelouedec-cdni-request-routing-00.txt >>=20 >> All, >>=20 >> To help the discussion, we may need to distinguish three (main) modes: >>=20 >> *A* the uCDN uses the Footprint&Cap information (advertised by dCDN)=20 >> to select a dCDN. The uCDN redirects to the selected dCDN and=20 >> considers that he is done with request routing. >>=20 >> *B* the uCDN uses the Footprint&Cap information (advertised by dCDN)=20 >> to select a dCDN candidate. The uCDN queries the dCDN before redirecting. >> Querying dCDN optionally allows the dCDN to provide to uCDN the final=20 >> redirection information so the the enduser experiences a single redirect. >> Querying dCDN optionally allows the uCDN to pick an alternate dCDN if=20 >> the initially selected dCDN cannot handle the request. >>=20 >> *C* the uCDN queries multiple dCDNs on a per-request basis and=20 >> selects dCDN based on their responses. In other words, the=20 >> Footprint&Cap advertisement is performed via on-demand per-request queri= es. >>=20 >>=20 >> I think: >> * Scott pointed out that fundamentatly both *A* and *B* have to=20 >> deal with (typically transient) situations where uCDN thinks dCDN can=20 >> take a request and dCDN actually cannot handle it. And pointed out=20 >> that with *A* the transient period is dictated by the Footprint&Cap=20 >> advertisement "update speed" while with *B* it is not. >> * Allan was saying *A* is all he needs and *B* is extra=20 >> complexity that he doesn't need. >> * Gilles and lelouedec-cdni-request-routing were saying *C* is bad. >>=20 >> My impression is that there is violent agreement that *A* is to be=20 >> supported. I think Allan and Gilles message indicate so. I personally=20 >> support that. I think many people have been discussing that approach.=20 >> If someone feels this is NOT to be supported by CDNI, do let us know. >>=20 >> I think Gilles message below is primarily arguing against *C*. I=20 >> personally agree that this need not be supported in our initial=20 >> deliverables. Are there people arguing this approach is to be=20 >> supported in the initial deliverables? >>=20 >> Regarding *B*, I personally see it as quite useful and worth=20 >> supporting in Phase 1 (possibly as an option). >> Regarding Allan's points: >> * I agree there is some "scalability" argument (i.e.=20 >> state+wait-for- >> dCDN-response) but it amounts to a web-services call out per request=20 >> and buys you reliability of request routing, so I see that as a=20 >> trade-off that some CDNs should be able to exercise. >>=20 >> * I don't buy the latency argument because you end up with 2=20 >> RTTs in both *A* and *B* (in normal situations where dCDN can handle=20 >> the request) (i.e. user-->uCDN, uCDN-->user, user-->dCDN, dCDN-->user=20 >> versus user-- >>> uCDN, uCDN-->dCDN, dCDN-->uCDN, uCDN-->user) and in the transient=20 >>> cases >> where dCDN cannot handle the request *B* can do as well as *A* (drop=20 >> the >> request) or has the option to differently i.e. re-redirect at the=20 >> cost of an extra RTT. >> * I don't buy the "loop free mechanism" argument. In *B*, it is=20 >> easy to implement a loop detection and even loop prevention (if you=20 >> want). In *A*, you have no loop prevention (other than the inherent=20 >> HTTP/DNS max redirect/max CNAMEs) Other opinions on *B* are sought. >>=20 >>=20 >> Cheers >>=20 >> Francois >>=20 >>=20 >> On 25 Jul 2012, at 13:39, =20 >> wrote: >>=20 >>> Hi everyone, >>>=20 >>> I fully agree with Allan's comments. Putting aside the vocabulary >> ('recursive model' etc), Allan's comment are consistent with the=20 >> messages that=20 >> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 >> tries to convey. >>>=20 >>> " o Regarding the former process, i.e. related to the "ability" >>> ("enables a Request Routing function in an upstream CDN to query a >>> Request Routing function in a downstream CDN to determine if the >>> downstream CDN is able (...) to accept the delegated content >>> request"), a routing protocol is used to achieve such a process, >>> called routing process, in many other technologies and networks >>> (IP, ATM, etc.). In all these technologies, it is the downstream >>> entity that provides routing information to the upstream entity. >>> The same approach should be applied to CDN interconnection. The >>> reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2, >>> dCDN 3, and then it selects one of them based on their responses") >>> would suffer from latency, signaling overhead and/or lack of >>> reactivity to events that impact the ability of the downstream >>> CDNs to accept delegated content requests." >>>=20 >>> Best regards, >>> -- >>> Gilles >>>=20 >>>=20 >>> -----Message d'origine----- >>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part=20 >>> de >> GUILLOU, Allan >>> Envoy=E9 : mercredi 25 juillet 2012 12:23 =C0 : Scott Wainner;=20 >>> cdni@ietf.org Objet : Re: [CDNi] TR: I-D Action:=20 >>> draft-lelouedec-cdni-request-routing- >> 00.txt >>>=20 >>> Hi, >>>=20 >>> With a "recusive model" as you ask if I understand, you expect the=20 >>> dCDN >> to send like an "ack" for each request, and if not the uCDN will try=20 >> to find the second best dCDN and do the same thing. >>>=20 >>> I think that this model may add complexity and may cause some >> scalability problem. You will have to implement timers between=20 >> request and ack, retransmission mechanism to make sure that request=20 >> has not been lost, loop free mechanism, And all this may add latency=20 >> on all requests and performances problems. >>>=20 >>> In the iterative model, if the dCDN is not able to handle the=20 >>> request, >> this request will be lost. It is the same thing in IP network today=20 >> we do not ask the routing protocol to change when there is saturation so= mewhere. >> It is the responsibility of each ISP to choose another route to join=20 >> this destination if he want to keep a good quality of service. If a=20 >> dCDN is overloaded, it will stop announcing part of its footprint or=20 >> uCDN may apply some policy to force choosing another dCDN. >>>=20 >>> It is right that this second model may not in case of dCDN=20 >>> saturation >> have the best reactivity, but it is exactly the same thing on the=20 >> internet today. We can imagine that a poor dCDN which have saturation=20 >> will be "black listed" by all the uCDN and the regulation will be done l= ike this. >>> I think recursive model will add complexity all the time for a gain >> witch is not in my opinion so important and that will not be seen so=20 >> often. >>>=20 >>> Allan >>>=20 >>>> -----Message d'origine----- >>>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la=20 >>>> part de Scott Wainner Envoy=E9 : lundi 16 juillet 2012 14:23 =C0 : >>>> cdni@ietf.org Objet : Re: [CDNi] TR: I-D Action: >>>> draft-lelouedec-cdni-request-routing- >>>> 00.txt >>>>=20 >>>> On 7/10/12 11:39 AM, Brandenburg, R. (Ray) van wrote: >>>>> Hi Yannick, >>>>>=20 >>>>> We seem to be misunderstanding each other. Maybe this will help=20 >>>>> clarify >>>> my point: >>>>>=20 >>>>>> Let me try to fully understand your point: >>>>>> Are you really meaning that in this case the dCDN has in reality >>>> absolutely no obligation with regards to the uCDN? >>>>>> Are you really meaning that in this case the dCDN decides alone,=20 >>>>>> in >>>> real time, and for each content request, whether it denies or=20 >>>> accepts to ensure delivery? >>>>> What I mean is that I would like to have a RR Interface at least=20 >>>>> support >>>> a model where for every content request the uCDN asks the dCDN=20 >>>> whether it wants to deliver that particular content item (I believe=20 >>>> you call this a PULL approach). And I would like to allow the dCDN=20 >>>> to be able to >> say 'No' >>>> on this request (whether it is for purposes or failure, overload,=20 >>>> or any other reason). >>>>>=20 >>>>>> Are you really meaning that in this case the dCDN decides alone,=20 >>>>>> in >>>> real time, and for each content request, whether it denies or=20 >>>> accepts to ensure delivery, and this even if the dCDN has the=20 >>>> capability to deliver the content? >>>>> Yes. >>>> I think we have to delineate between the iterative and recursive model. >>>>=20 >>>> The recursive model assumes that the client request to the uCDN=20 >>>> will be recursive and the CDN-I RR interface will be used to=20 >>>> provide an answer for each client request. The choice to initiate=20 >>>> the recursion would be determined by the footprint / capabilities.=20= =20 >>>> The ability of the dCDN to execute the specific request would=20 >>>> provide immediate feedback to the uCDN. A dCDN that continues to=20 >>>> advertise the footprint / capability, but frequently or continually=20 >>>> rejects the request via CDN-I RR would be a poor candidate. The=20 >>>> opportunity now arises where the uCDN may elect to choose an=20 >>>> alternate dCDN because its preferred dCDN (according to footprint /=20 >>>> capabilities) is 'under- >> performing'. >>>>=20 >>>> The iterative model, the uCDN blindly redirects the client to the=20 >>>> dCDN based on the footprint / capabilities. What the dCDN does=20 >>>> with the request is somewhat transparent to the uCDN. With the=20 >>>> exception of the CDN-I logging, the uCDN assumes the dCDN is=20 >>>> properly handling the requests that were delegated to the dCDN. If=20 >>>> you are trying to 'tighten' up the case of blind rejections, then=20 >>>> the frequency of the footprint / capabilities advertisements would hav= e to be accelerated. >>>> For the case where the dCDN repeatedly sees requests from the uCDN=20 >>>> that the dCDN can't handle, it should retract its footprint /=20 >>>> capabilities advertisement. Failing to do so would continually=20 >>>> black-hole routing requests which would be indicated in the logging >> information. >>>>=20 >>>> Either way, you need a feedback loop to avoid dumping routing requests. >>>>=20 >>>> With any feedback loop (recursive routing request or footprint /=20 >>>> capabilities advertisement), you have to be careful about rapid=20 >>>> oscillations and dampening the responses. >>>>=20 >>>> Scott >>>>>=20 >>>>>> Are you really meaning that in this case the dCDN may possibly=20 >>>>>> response >>>> negatively to all requests for content request redirection=20 >>>> submitted by the uCDN over the CDNI request routing interface?=20 >>>> (i.e. that possibly the uCDN will never be allowed/invited to=20 >>>> redirect a content request to the >>>> dCDN?) >>>>>=20 >>>>> Yes. Any negative effect this may have on the business=20 >>>>> relationship >>>> between uCDN and dCDN should be handled on the business level. >>>>>=20 >>>>> Ray >>>>>=20 >>>>>=20 >>>>> On Jul 10, 2012, at 4:33 PM, >>>>> wrote: >>>>>=20 >>>>>> Hi Ray, >>>>>>=20 >>>>>>=20 >>>>>> 1) Ray, quoting your mail: "The current drafts seems to assume=20 >>>>>> some >>>> particular type of contractual agreement between CDNs that might=20 >>>> not always be the case." >>>>>>=20 >>>>>> Please quote the draft. >>>>>> Please let us know exactly to which sentence(s) of the draft you=20 >>>>>> are >>>> referring to. >>>>>> Otherwise it is hard to discuss and comment on your email. >>>>>>=20 >>>>>>=20 >>>>>> 2) Ray, Quoting your mail: "If a dCDN does not live up to its >>>> contractual agreement, this should be something that is handled on=20 >>>> a business level, not on a protocol level." >>>>>>=20 >>>>>> Maybe there is a deep misunderstanding. >>>>>> So I will try to be clear again. >>>>>> We do not propose the CDNI routing interface to be used by the=20 >>>>>> dCDN to >>>> send a message saying "Sorry, but I decide unilaterally to refuse=20 >>>> this content request". >>>>>> We do not propose the CDNI routing interface to be used to handle=20 >>>>>> any >>>> aspect relating to a dCDN deciding unilaterally to stop living up=20 >>>> to its contractual agreement. >>>>>>=20 >>>>>> Please let us know where you saw such an idea in this IETF draft=20 >>>>>> "CDNI >>>> request routing". >>>>>>=20 >>>>>> The only role of the CDNI routing interface is to be used to=20 >>>>>> advertise >>>> CDNI routing information from the downstream CDN to the upstream CDN. >>>>>> And this is the description given in this IETF draft. >>>>>>=20 >>>>>>=20 >>>>>> 3) Ray, quoting your mail: "one example of a contractual=20 >>>>>> agreement >>>> between two CDNs is one in which the uCDN and dCDN have agreed that=20 >>>> the dCDN will deliver some content on behalf of a uCDN, but decide=20 >>>> on a per- request basis whether it wants to do so (and is for=20 >>>> example paid per request). In these cases, the dCDN needs to have=20 >>>> the ability to deny delivery on a per-request basis." >>>>>>=20 >>>>>> Let me try to fully understand your point: >>>>>> Are you really meaning that in this case the dCDN has in reality >>>> absolutely no obligation with regards to the uCDN? >>>>>> Are you really meaning that in this case the dCDN decides alone,=20 >>>>>> in >>>> real time, and for each content request, whether it denies or=20 >>>> accepts to ensure delivery? >>>>>> Are you really meaning that in this case the dCDN decides alone,=20 >>>>>> in >>>> real time, and for each content request, whether it denies or=20 >>>> accepts to ensure delivery, and this even if the dCDN has the=20 >>>> capability to deliver the content? >>>>>> Are you really meaning that in this case the dCDN may possibly=20 >>>>>> response >>>> negatively to all requests for content request redirection=20 >>>> submitted by the uCDN over the CDNI request routing interface?=20 >>>> (i.e. that possibly the uCDN will never be allowed/invited to=20 >>>> redirect a content request to the >>>> dCDN?) >>>>>>=20 >>>>>>=20 >>>>>> 4) Ray, quoting your mail: "Every routing protocol defines the=20 >>>>>> expected >>>> behavior of interconnected elements/networks on a technical level,=20 >>>> not on a business level." >>>>>>=20 >>>>>> Again, this is not what I have written, and this is not the idea=20 >>>>>> we >>>> want to share. >>>>>> I wrote "Every routing protocol has been defined (or at least >>>> configured) so far by considering the expected behavior of the=20 >>>> interconnected elements/networks." >>>>>> That's all. >>>>>> I can rephrase this sentence the following way: "we must know=20 >>>>>> what we >>>> expect to do with a protocol to design it correctly." >>>>>> And IHMO this is an evidence; I don't know any other way to proceed. >>>>>>=20 >>>>>> Besides, let us consider BGP (which is by the way an option=20 >>>>>> proposed by >>>> some IETF members to implement this CDNI routing interface). >>>>>> In IP networks, BGP configurations in IP routers are defined as=20 >>>>>> per the >>>> business relationships (valley free policy, etc.). >>>>>> Of course the business relationships determine the BGP >> configurations. >>>>>> And of course BGP has been designed so as to allow to configure=20 >>>>>> IP >>>> interconnections adequately depending on the corresponding=20 >>>> Customer/provider, sibling and peering contractual agreements. >>>>>> But this does not mean that BGP "defines the expected behavior of >>>> interconnected elements/networks... on a business level." >>>>>> Even if we can indeed infer quite accurately the business=20 >>>>>> relationships >>>> between ISP from the BGP configuration of their IP routers (see=20 >>>> CAIDA project), but this is another story. >>>>>>=20 >>>>>>=20 >>>>>> Best regards, >>>>>>=20 >>>>>> Yannick Le Lou=E9dec. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >>>>>> Envoy=E9 : mardi 10 juillet 2012 15:13 =C0 : LE LOUEDEC Yannick=20 >>>>>> RD-CORE; Ben Niven-Jenkins Cc : Pilarski Marcin - Korpo TP;=20 >>>>>> cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR: I-D >>>>>> Action: draft-lelouedec-cdni-request- >>>> routing-00.txt >>>>>>=20 >>>>>> Hi Yannick, >>>>>>=20 >>>>>> See comments inline. >>>>>>=20 >>>>>> In general: IMO the CDNI interfaces should be abstracted from any=20 >>>>>> kind >>>> of contractual/business agreement that might or might not exist=20 >>>> between a dCDN and uCDN. The current drafts seems to assume some=20 >>>> particular type of contractual agreement between CDNs that might=20 >>>> not >> always be the case. >>>>>>=20 >>>>>> Ray >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: yannick.lelouedec@orange.com >>>> [mailto:yannick.lelouedec@orange.com] >>>>>> Sent: dinsdag 10 juli 2012 12:01 >>>>>> To: Brandenburg, R. (Ray) van; Ben Niven-Jenkins >>>>>> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne=20 >>>>>> RD-CORE >>>>>> Subject: RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- >>>> routing-00.txt >>>>>>=20 >>>>>> Hi Ray, all, >>>>>>=20 >>>>>>=20 >>>>>> 1) Ray, Quoting your mail: "I don't see why the CDNI Request=20 >>>>>> Routing >>>> interface should state that a dCDN MUST deliver the content if it=20 >>>> has indicated its ability to do so earlier in either a contractual=20 >>>> agreement or in the capability interface." >>>>>>=20 >>>>>> This is not what we have written. >>>>>> Let me try to rephrase simply. >>>>>>=20 >>>>>> A contractual agreement is a contractual agreement. >>>>>> It put in writings the respective obligations of the uCDN and of=20 >>>>>> the >>>> dCDN. >>>>>> The uCDN may redirect any content request to the dCDN as long as=20 >>>>>> it is >>>> in full conformance with the terms of this contractual agreement=20 >>>> (the type of the content request is in full conformance, the=20 >>>> maximum number of content requests per second is respected, etc.). >>>>>> In this case the dCDN may not say "Sorry, but I decide=20 >>>>>> unilaterally to >>>> refuse this content request". >>>>>>=20 >>>>>> [RvB]: This is where we disagree. IMHO, the type of behavior you >>>> describe (the dCDN not living up to its obligation) should not be=20 >>>> enforced by the CDNI Interfaces. If a dCDN does not live up to its=20 >>>> contractual agreement, this should be something that is handled on=20 >>>> a business level, not on a protocol level. >>>>>>=20 >>>>>> Why? Because this is the deal, a contractual agreement is a=20 >>>>>> contractual >>>> agreement! >>>>>> Yet the dCDN may say "I do apologize, but at this time I cannot=20 >>>>>> handle >>>> correctly a certain class of content requests specified in our=20 >>>> contractual agreement" (for example the class of the HTTP content=20 >>>> requests with token from French end users, because of overload=20 >>>> situation, failure, etc.) This is the role of the CDNI routing=20 >>>> interface to provide the uCDN with such information. >>>>>>=20 >>>>>> (And the dCDN may be given a penalty for example if this was=20 >>>>>> agreed in >>>> the terms of the contractual agreement.) >>>>>>=20 >>>>>>=20 >>>>>> 2) Ray, Quoting your mail: "I understand that in most cases, the >>>> contractual agreement might indeed impose this behavior on the dCDN" >>>>>>=20 >>>>>> Please provide the description of an example where this is not=20 >>>>>> the >>>> case. >>>>>> Otherwise the IETF CDNI WG shall indeed consider this is ALWAYS=20 >>>>>> the >>>> case. >>>>>>=20 >>>>>> [RvB]: I can't remember ever seeing such a discussion on the WG list. >>>> Anyway: one example of a contractual agreement between two CDNs is=20 >>>> one in which the uCDN and dCDN have agreed that the dCDN will=20 >>>> deliver some content on behalf of a uCDN, but decide on a=20 >>>> per-request basis whether it wants to do so (and is for example=20 >>>> paid per request). In these cases, the dCDN needs to have the=20 >>>> ability to deny delivery on a per- >> request basis. >>>>>>=20 >>>>>> And this is an important point to be able to progress in the CDNI >>>> interfaces' specification works. >>>>>>=20 >>>>>> If the contractual agreement does not define clearly the=20 >>>>>> obligations of >>>> the uCDN, it is impossible to dimension adequately the dCDN,=20 >>>> neither to define correctly the CDNI contractual agreements between=20 >>>> the dCDN and the dCDNs of this dCDN. >>>>>> If the contractual agreement does not define clearly the=20 >>>>>> obligations of >>>> the dCDN, the dCDN may do what it wants... even to put in the trash=20 >>>> can any content request it accepted to handle. >>>>>>=20 >>>>>> [RvB]: Exactly, this is something that needs to be discussed on a >>>> business/contractual level and not on a technical level. That is=20 >>>> way IMHO the CDNI Interfaces should not make ANY assumptions on=20 >>>> what was agreed on a contractual level. >>>>>>=20 >>>>>> In both situations it is impossible to ensure any quality of=20 >>>>>> experience >>>> to the end user. >>>>>>=20 >>>>>>=20 >>>>>> 3) Ray, Quoting your mail: "I don't think this type of behavior=20 >>>>>> should >>>> be imposed by the protocol we're developing here." >>>>>>=20 >>>>>> I do not sure I understand this sentence. >>>>>> Every routing protocol has been defined (or at least configured)=20 >>>>>> so far >>>> by considering the expected behavior of the interconnected=20 >>>> elements/networks. >>>>>>=20 >>>>>> [RvB]: Every routing protocol defines the expected behavior of >>>> interconnected elements/networks on a technical level, not on a=20 >>>> business level. Having a dCDN say 'I'm not willing to deliver this=20 >>>> content' is perfectly fine from a technical perspective, although=20 >>>> it could be problematic from a contractual perspective. >>>>>>=20 >>>>>> But maybe I will understand if you provide an example on the=20 >>>>>> point >>>>>> 2 >>>> above. >>>>>>=20 >>>>>>=20 >>>>>> Best regards, >>>>>>=20 >>>>>> Yannick Le Lou=E9dec. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >>>>>> Envoy=E9 : mardi 10 juillet 2012 09:20 =C0 : Ben Niven-Jenkins; LE= =20 >>>>>> LOUEDEC Yannick RD-CORE Cc : Pilarski Marcin >>>> - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR: >>>> I-D >>>> Action: draft-lelouedec-cdni-request-routing-00.txt >>>>>>=20 >>>>>> Hi Yannick, Ben, >>>>>>=20 >>>>>> I tend to agree with Ben here. When reading the draft, I got the >>>> feeling that the draft seems to assume a lot about the relationship=20 >>>> between the uCDN and dCDN. For example, I don't see why the CDNI=20 >>>> Request Routing interface should state that a dCDN MUST deliver the=20 >>>> content if it has indicated its ability to do so earlier in either=20 >>>> a contractual agreement or in the capability interface. I=20 >>>> understand that in most cases, the contractual agreement might=20 >>>> indeed impose this behavior on the dCDN, but I don't think this=20 >>>> type of behavior should be imposed by the protocol we're developing he= re. >>>>>>=20 >>>>>> It was always my assumption that the Request Routing Interface=20 >>>>>> would at >>>> least include the option of allowing the uCDN to query the dCDN for=20 >>>> every content request whether the dCDN is willing to deliver that=20 >>>> particular request. >>>>>>=20 >>>>>> I will send my full review of the draft later. >>>>>>=20 >>>>>> Ray >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On=20 >>>>>> Behalf Of >>>> Ben Niven-Jenkins >>>>>> Sent: dinsdag 10 juli 2012 7:38 >>>>>> To: yannick.lelouedec@orange.com >>>>>> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne=20 >>>>>> RD-CORE >>>>>> Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- >>>> routing-00.txt >>>>>>=20 >>>>>> Yannick, >>>>>>=20 >>>>>> Please see inline. >>>>>>=20 >>>>>> On 9 Jul 2012, at 20:05, wrote: >>>>>>=20 >>>>>>> Hi Ben, all, >>>>>>>=20 >>>>>>> Ben, quoting you mail below, "... the downstream CDN could reply=20 >>>>>>> with either "here is how to redirect it"", >>>>>>>=20 >>>>>>> =3D> This is the role of the CDNI DRIS interface to provide the=20 >>>>>>> uCDN >>>> with this information, and we target to make its specification=20 >>>> public before Vancouver meeting so that everyone may read it before=20 >>>> the meeting and get full knowledge of our proposal about this part=20 >>>> of CDNI request routing. >>>>>>>=20 >>>>>>> Ben, quoting you mail below, "... or "no I can't/won't take that >>>> content delivery right now", reasons may include the uCDN has=20 >>>> requested a delivery of a protocol the dCDN does not support=20 >>>> (possibly >> in error). >>>>>>>=20 >>>>>>> =3D> This is the role of the CDNI logging interface to provide the= =20 >>>>>>> uCDN >>>> with this information. >>>>>> I agree this information should be logged but the Request Routing >>>> interface (what you call the DRIS) also needs to be able to=20 >>>> indicate a failure. >>>>>>=20 >>>>>> Otherwise the uCDN will 'blindly' redirect the the dCDN and the >>>> delivery will fail leading to poor end user experience. >>>>>>=20 >>>>>>> Ben, quoting you mail below, "... or "no I can't/won't take that >>>> content delivery right now", reasons may include ... the dCDN has=20 >>>> no capacity right now etc." >>>>>>>=20 >>>>>>> =3D> This is the role of the CDNI routing interface to provide the= =20 >>>>>>> uCDN >>>> with this information. >>>>>> It is the role of the CDN capability/routing interface to=20 >>>>>> advertise >>>> broad capabilities etc not to give extremely fine grained real-time=20 >>>> information on exactly the state of the dCDN. >>>>>>=20 >>>>>> Even if the capability/routing interface is real-time there are=20 >>>>>> likely >>>> to still be race conditions where we need the dCDN to be about to=20 >>>> indicate a failure to accept a redirect through the request=20 >>>> routing/DRIS interface >>>>>>=20 >>>>>>> So we may conclude we are in line basically, which is a good point. >>>>>>> We just aimed at checking there was a common understanding on=20 >>>>>>> this >>>> point. >>>>>>>=20 >>>>>>> The key point for us here is that we don't want this sentence >>>> extracted from draft-ietf-cdni-problem-statement be interpreted as: ". >>>> and the dCDN MUST accept the content request except when it has not=20 >>>> the "ability" to do so." >>>>>> Why not? IMO that is a valid scenario for some use cases. >>>>>>=20 >>>>>>> The fact that the dCDN is temporary unable to handle content=20 >>>>>>> request >>>> correctly is not a valid reason for the dCDN to be discharged of=20 >>>> its obligations to the uCDN. >>>>>>> The contract set between the uCDN and the dCDN remains valid=20 >>>>>>> anyway, >>>> and the obligations of the dCDN as well. >>>>>> Correct, but that contract may not be the same for all uCDNs &=20 >>>>>> dCDNs, >>>> for example a uCDN may not have a guarantee that a dCDN can handle=20 >>>> everything it is requested to handle but the contract may only be=20 >>>> that the dCDN guarantees to handle up to a certain volume of traffic. >>>>>>=20 >>>>>>> The dCDN must announce to the uCDN that it is temporary unable,=20 >>>>>>> as >>>> soon as possible, via the CDNI routing interface. >>>>>>> And the uCDN must take this information into account in its CDN >>>> selection process as soon as possible. >>>>>>> Then if the uCDN decides to continue to redirect content=20 >>>>>>> requests to >>>> the dCDN, the uCDN MAY perfectly do it, but the uCDN knows these=20 >>>> content requests will be lost. >>>>>> What happens in the period between the dCDN being unable to=20 >>>>>> handle >>>> requests and the time it takes to advertise that to the uCDN and=20 >>>> for the uCDN to process & incorporate that new knowledge? Are=20 >>>> requests blindly forwarded to the dCDN which is unable to handle=20 >>>> them leading to poor user experience? >>>>>>=20 >>>>>>> We could even imagine the situation where the uCDN continues to=20 >>>>>>> do it >>>> intentionally, because it has no better option and the content=20 >>>> request will be lost anyway. For example in the case where neither=20 >>>> the uCDN nor the other downstream CDNs of the uCDN cannot manage=20 >>>> correctly the content request, the uCDN could do it intentionally=20 >>>> so as to be able to clearly prove (with CDNI logging information)=20 >>>> that it is the dCDN, not the uCDN, who is at fault. >>>>>>> But, of course, if there are alternative backup options, the=20 >>>>>>> normal >>>> reaction of the uCDN is to stop as soon as possible to redirect=20 >>>> content requests to the dCDN when the uCDN knows that the dCDN is=20 >>>> unable to handle them correctly. >>>>>>>=20 >>>>>>> So, to be clear, we would prefer the sentence to be understood as: >>>>>>> ". and the dCDN MUST accept the content request. >>>>>>> And if it cannot handle correctly the redirected content request=20 >>>>>>> it >>>> receives, the content request is lost. >>>>>> What about scenarios where the uCDN has a choice of dCDNs (e.g.=20 >>>>>> two >>>> national-wide CDNs offering services at different costs), the uCDN=20 >>>> may elect to query both dCDNs and decide based on their responses=20 >>>> which one to choose. If the dCDN is unable to satisfy the request=20 >>>> the uCDN needs to know that so that it can fallback to the (more=20 >>>> expensive in this example) dCDN. >>>>>>=20 >>>>>>> For example the dCDN generates a response to the content request=20 >>>>>>> with >>>> an error message, or no response at all. And in parallel the CDNI=20 >>>> logging interface may be used to exchange logs corresponding to=20 >>>> this >> problem. >>>> Anyway the dCDN MAY NOT redirect that content request back towards=20 >>>> the uCDN." >>>>>>>=20 >>>>>>> Exactly as in IP networks: IP packets are not sent back towards=20 >>>>>>> the >>>> origin by a downstream router under failure or congestion. >>>>>> In a routed IP network, there is often a small packet loss while=20 >>>>>> the >>>> network re-converges, by enabling the dCDN to refuse a redirection=20 >>>> at CDNI Request Routing/DRIS query time we can reduce that window=20 >>>> by giving the uCDN the option to take an alternative action (e.g.=20 >>>> try another dCDN) while the routing/capability information re-converge= s. >>>>>>=20 >>>>>>> In both networks (IP and CDN), the reason is the same. >>>>>>> If the dCDN redirects back a content request to the uCDN, this >>>> generates a loop. >>>>>> Loop avoidance is a separate issue IMO to whether we should allow=20 >>>>>> a >>>> dCDN to be able to communicate "I am unable/unwilling to take that=20 >>>> content delivery at this time". >>>>>>=20 >>>>>> Regards >>>>>> Ben >>>>>>=20 >>>>>>> To manage this would introduce a very high complexity. >>>>>>> And this would be just to try to save the content requests=20 >>>>>>> redirected >>>> by the uCDN to the dCDN in the timeslot between the time the dCDN=20 >>>> gets down and the time the uCDN takes this failure into account in=20 >>>> its CDN selection process. >>>>>>> It is much better to try to reduce this timeslot as much as=20 >>>>>>> possible, >>>> with routing optimizations (we will propose as soon as possible). >>>>>>> Rather than introducing additional complexities (to manage=20 >>>>>>> redirection >>>> to the uCDN) in the framework. >>>>>>>=20 >>>>>>>=20 >>>>>>> By the way, as you know, the IESG has just approved today the=20 >>>>>>> 'Content >>>> Distribution Network Interconnection (CDNI) Problem Statement'=20 >>>> draft as informational RFC. This is a good point. >>>>>>> And, as you may see in the draft "CDNI request routing", we do=20 >>>>>>> not >>>> propose to modify this problem statement draft. >>>>>>> We want know to focus now on getting the specifications of all=20 >>>>>>> CDNI >>>> interfaces ready as soon as possible. >>>>>>>=20 >>>>>>> Best regards, >>>>>>>=20 >>>>>>> Yannick Le Lou=E9dec. >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Message d'origine----- >>>>>>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la=20 >>>>>>> part de Ben Niven-Jenkins Envoy=E9 : lundi 9 juillet 2012 20:41 =C0= : >>>>>>> BERTRAND Gilles RD-CORE Cc : cdni@ietf.org; Pilarski Marcin -=20 >>>>>>> Korpo TP; MARREC Anne RD-CORE Objet : Re: [CDNi] TR: I-D Action: >>>>>>> draft-lelouedec-cdni-request-routing-00.txt >>>>>>>=20 >>>>>>> Colleagues, >>>>>>>=20 >>>>>>> I started reading draft-lelouedec-cdni-request-routing-00 and=20 >>>>>>> this >>>> text caught my eye: >>>>>>>=20 >>>>>>> Quoting [I-D.ietf-cdni-problem-statement ], "The CDNI Request=20 >>>>>>> Routing interface enables a Request Routing function in an=20 >>>>>>> upstream CDN to query a Request Routing function in a downstream=20 >>>>>>> CDN to determine >> if >>>>>>> the downstream CDN is able (and willing) to accept the delegated=20 >>>>>>> content request". >>>>>>>=20 >>>>>>> The "ability" and the "willingness" of the downstream CDN to=20 >>>>>>> accept the delegated content request match two fully different=20 >>>>>>> processes >> in >>>>>>> CDN interconnection. And the description of both these=20 >>>>>>> processes should be reviewed and clarified for the following reason= s: >>>>>>>=20 >>>>>>> o Regarding the former process, i.e. related to the "ability" >>>>>>> ("enables a Request Routing function in an upstream CDN to=20 >>>>>>> query >>>> a >>>>>>> Request Routing function in a downstream CDN to determine if the >>>>>>> downstream CDN is able (...) to accept the delegated content >>>>>>> request"), a routing protocol is used to achieve such a process, >>>>>>> called routing process, in many other technologies and networks >>>>>>> (IP, ATM, etc.). In all these technologies, it is the >> downstream >>>>>>> entity that provides routing information to the upstream entity. >>>>>>> The same approach should be applied to CDN interconnection. The >>>>>>> reverse approach ("uCDN queries it downstream CDNs dCDN 1,=20 >>>>>>> dCDN >>>> 2, >>>>>>> dCDN 3, and then it selects one of them based on their >>>> responses") >>>>>>> would suffer from latency, signaling overhead and/or lack of >>>>>>> reactivity to events that impact the ability of the downstream >>>>>>> CDNs to accept delegated content requests. >>>>>>>=20 >>>>>>> o Regarding the latter process, i.e. related to the "willingness" >>>>>>> ("enables a Request Routing function in an upstream CDN to=20 >>>>>>> query >>>> a >>>>>>> Request Routing function in a downstream CDN to determine if the >>>>>>> downstream CDN (...) is willing (...)to accept the delegated >>>>>>> content request"), it is to be noted that the relationship >>>> between >>>>>>> a uCDN and a dCDN is always in the frame of a contractual >>>>>>> agreement between the administrative entity owning the uCDN, >>>>>>> acting as the customer, and the administrative entity owning the >>>>>>> dCDN, acting as the service provider. Therefore, consider a >> case >>>>>>> where >>>>>>>=20 >>>>>>> * the uCDN has a content request to redirect which is in full >>>>>>> conformance with the terms of this contractual agreement,=20 >>>>>>> and >>>>>>>=20 >>>>>>> * the uCDN has selected this dCDN. >>>>>>>=20 >>>>>>> As the uCDN knows, thanks to the routing information=20 >>>>>>> exchanged >>>> via >>>>>>> the aforementioned routing process, that the dCDN is able to >>>>>>> accept this content request, the uCDN MAY redirect the content >>>>>>> request to the dCDN and the dCDN MUST accept the content >> request. >>>>>>> Exchanging over the CDNI Request Routing interface information >>>>>>> about the "willingness" of the dCDN to accept the content >> request >>>>>>> is not relevant. >>>>>>>=20 >>>>>>> I think you might be over thinking what we wrote in the problem >>>> statement. >>>>>>>=20 >>>>>>> What was in the problem statement was meant to convey that an=20 >>>>>>> upstream >>>> CDN could make a request to a downstream CDN to say "how do I=20 >>>> redirect this request to you" and the downstream CDN could reply=20 >>>> with either "her is how to redirect it", or "no I can't/won't take=20 >>>> that content delivery right now", reasons may include the uCDN has=20 >>>> requested a delivery of a protocol the dCDN does not support=20 >>>> (possibly in error) or the dCDN has no capacity right now etc. >>>>>>>=20 >>>>>>> Ben >>>>>>>=20 >>>>>>> On 9 Jul 2012, at 18:00, wrote: >>>>>>>=20 >>>>>>>> Hi everyone, >>>>>>>>=20 >>>>>>>> We have just submitted the draft below. We are convinced that=20 >>>>>>>> it will >>>> help the WG to progress on the CDNI routing issues. >>>>>>>>=20 >>>>>>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing >>>>>>>> -0 >>>>>>>> 0 >>>>>>>>=20 >>>>>>>> Any feedback is very welcome. >>>>>>>>=20 >>>>>>>> Best regards, >>>>>>>>=20 >>>>>>>> Gilles >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Message d'origine----- >>>>>>>> De : i-d-announce-bounces@ietf.org=20 >>>>>>>> [mailto:i-d-announce-bounces@ietf.org] De la part de=20 >>>>>>>> internet-drafts@ietf.org Envoy=E9 : lundi 9 juillet 2012 18:55 =C0= : >>>>>>>> i-d-announce@ietf.org Objet : I-D Action: >>>>>>>> draft-lelouedec-cdni-request-routing-00.txt >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> A New Internet-Draft is available from the on-line=20 >>>>>>>> Internet-Drafts >>>> directories. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Title : CDNI Request Routing >>>>>>>> Author(s) : Yannick Le Louedec >>>>>>>> Anne Marrec >>>>>>>> Gilles Bertrand >>>>>>>> Marcin Pilarski >>>>>>>> Filename : draft-lelouedec-cdni-request-routing-00.txt >>>>>>>> Pages : 30 >>>>>>>> Date : 2012-07-09 >>>>>>>>=20 >>>>>>>> Abstract: >>>>>>>> The present document proposes to clarify the CDNI Request=20 >>>>>>>> Routing interface introduced in [I-D.ietf-cdni-framework] and >>>>>>>> [I-D.ietf-cdni- problem-statement], as well as related terminology. >>>>>>>>=20 >>>>>>>> In particular the present document proposes to split the CDNI=20 >>>>>>>> Request Routing interface into two separate interfaces with=20 >>>>>>>> clearer roles, named respectively CDNI Routing interface and=20 >>>>>>>> CDNI Downstream Resource Identifier Signaling interface (CDNI=20 >>>>>>>> DRIS >> interface). >>>>>>>>=20 >>>>>>>> This part of the CDN interconnection framework the IETF has=20 >>>>>>>> been referring to so far with the term "CDNI Request Routing"=20 >>>>>>>> is just another routing, signaling and forwarding problem in a=20 >>>>>>>> long series of the telecommunication history. For example, one=20 >>>>>>>> can draw a direct analogy between the IP/MPLS-TE framework and=20 >>>>>>>> the CDN interconnection framework. >>>>>>>>=20 >>>>>>>> In addition, this document recommends that the specification of=20 >>>>>>>> ALL CDN interconnection interfaces in the scope of the CDNI=20 >>>>>>>> IETF WG relies on the equivalent concept to IP prefix for CDN=20 >>>>>>>> interconnection, named 'contentRequestScope'. This highly=20 >>>>>>>> useful and powerful concept SHALL be used to simplify the=20 >>>>>>>> specification of ALL CDN interconnection interfaces, as well as=20 >>>>>>>> to ensure performance and scalability in CDN interconnection. >>>>>>>>=20 >>>>>>>> All these proposals can be smoothly integrated in the WG=20 >>>>>>>> drafts, especially [I-D.ietf-cdni-framework] and=20 >>>>>>>> [I-D.ietf-cdni-requirements], as they essentially propose >>>>>>>> (useful) clarifications of the existing framework. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>> https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-r >>>>>>>> ou >>>>>>>> ting >>>>>>>>=20 >>>>>>>> There's also a htmlized version available at: >>>>>>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing >>>>>>>> -0 >>>>>>>> 0 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> 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=20 >>>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>>>=20 >>>>>>>> _______________________________________________________________ >>>>>>>> __ ____ ____________________________________________________ >>>>>>>>=20 >>>>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>>>> informations confidentielles ou privilegiees et ne doivent donc=20 >>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si=20 >>>>>>>> vous avez recu ce message par erreur, veuillez le signaler a=20 >>>>>>>> l'expediteur et le detruire ainsi >>>> que les pieces jointes. Les messages electroniques etant=20 >>>> susceptibles d'alteration, France Telecom - Orange decline toute=20 >>>> responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>>=20 >>>>>>>> This message and its attachments may contain confidential or=20 >>>>>>>> privileged information that may be protected by law; they=20 >>>>>>>> should not >>>> be distributed, used or copied without authorisation. >>>>>>>> If you have received this email in error, please notify the=20 >>>>>>>> sender >>>> and delete this message and its attachments. >>>>>>>> As emails may be altered, France Telecom - Orange is not liable=20 >>>>>>>> for >>>> messages that have been modified, changed or falsified. >>>>>>>> Thank you. >>>>>>>>=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 >>>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>>> informations confidentielles ou privilegiees et ne doivent donc=20 >>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si=20 >>>>>>> vous avez recu ce message par erreur, veuillez le signaler a=20 >>>>>>> l'expediteur et le detruire ainsi >>>> que les pieces jointes. Les messages electroniques etant=20 >>>> susceptibles d'alteration, France Telecom - Orange decline toute=20 >>>> responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>=20 >>>>>>> This message and its attachments may contain confidential or=20 >>>>>>> privileged information that may be protected by law; they should=20 >>>>>>> not >>>> be distributed, used or copied without authorisation. >>>>>>> If you have received this email in error, please notify the=20 >>>>>>> sender and >>>> delete this message and its attachments. >>>>>>> As emails may be altered, France Telecom - Orange is not liable=20 >>>>>>> for >>>> messages that have been modified, changed or falsified. >>>>>>> Thank you. >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> CDNi mailing list >>>>>> CDNi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>> This e-mail and its contents are subject to the DISCLAIMER at >>>> http://www.tno.nl/emaildisclaimer >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>> ___________________________________________________________________ >>>> ___ ____ _______________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>> informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>>> ce message par erreur, veuillez le signaler a l'expediteur et le=20 >>>> detruire ainsi que les pieces jointes. Les messages electroniques=20 >>>> etant susceptibles d'alteration, France Telecom - Orange decline=20 >>>> toute responsabilite si ce message a ete altere, deforme ou falsifie. = Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or=20 >>>>>> privileged >>>> information that may be protected by law; they should not be=20 >>>> distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the=20 >>>>>> sender and >>>> delete this message and its attachments. >>>>>> As emails may be altered, France Telecom - Orange is not liable=20 >>>>>> for >>>> messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>> ___________________________________________________________________ >>>> ___ ____ _______________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>> informations >>>> confidentielles ou privilegiees et ne doivent donc >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 >>>>>> avez >>>> recu ce message par erreur, veuillez le signaler >>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les >>>> messages electroniques etant susceptibles d'alteration, >>>>>> France Telecom - Orange decline toute responsabilite si ce=20 >>>>>> message a >>>> ete altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or=20 >>>>>> privileged >>>> information that may be protected by law; >>>>>> they should not be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the=20 >>>>>> sender and >>>> delete this message and its attachments. >>>>>> As emails may be altered, France Telecom - Orange is not liable=20 >>>>>> for >>>> messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>>=20 >>>=20 >> _____________________________________________________________________ >> _____ _______________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 >>> avez >> recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les=20 >>> messages >> electroniques etant susceptibles d'alteration, >>> France Telecom - Orange decline toute responsabilite si ce message a=20 >>> ete >> altere, deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or=20 >>> privileged >> information that may be protected by law; >>> they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender=20 >>> and >> delete this message and its attachments. >>> As emails may be altered, France Telecom - Orange is not liable for >> messages that have been modified, changed or falsified. >>> Thank you. >>>=20 >>> _______________________________________________ >>> 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 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From yannick.lelouedec@orange.com Fri Jul 27 04:44:36 2012 Return-Path: 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 CC8CC21F8647 for ; Fri, 27 Jul 2012 04:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, UNPARSEABLE_RELAY=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 Exs5gD9RSXXP for ; Fri, 27 Jul 2012 04:44:33 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2B49121F863E for ; Fri, 27 Jul 2012 04:44:33 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 18FA03B42E9; Fri, 27 Jul 2012 13:44:32 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 01A1C238056; Fri, 27 Jul 2012 13:44:32 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Fri, 27 Jul 2012 13:44:28 +0200 From: To: "Francois Le Faucheur (flefauch)" , "BERTRAND Gilles RD-CORE" Thread-Topic: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.txt Thread-Index: AQHNamIDDt5/WFxTGUOr3GgzYrRzfJc8+0cA Date: Fri, 27 Jul 2012 11:44:27 +0000 Message-ID: <32094_1343389472_50127F20_32094_400_1_b1bdf24e-f0df-4181-88b6-137751b0f1fa@PEXCVZYH01.corporate.adroot.infra.ftgroup> References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> <2040_1341930789_4FFC3D24_2040_2504_1_b86bff40-ae68-40c0-b8e5-060f51be6864@PEXCVZYH02.corporate.adroot.infra.ftgroup> <3A7EA7EE-F8D4-4094-83F2-12CD3826B662@tno.nl> <5004079D.4000406@cisco.com> <29661_1343216353_500FDAE1_29661_643_1_2AC63C9F27AF8446B0C064C50FC0A89305D959@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AF54F9B-B4FF-4043-A9DE-36C0417F9EAC@cisco.com> In-Reply-To: <2AF54F9B-B4FF-4043-A9DE-36C0417F9EAC@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 11:44:37 -0000 Dear Fran=E7ois, all, I have another comment about the mail from Fran=E7ois below. About the modes A and B and about latency. I don't see why the CDNI iterative and (semi- and full-) recursive request = redirection modes should not be compatible a priori with both the modes A a= nd B described below. (I mean everything is possible, even if some combinations do not necessaril= y match all the requirements of every real deployment one may envision). For example,=20 Mode A can be compatible with the CDNI iterative request redirection mode (= as well as with what we call the semi-recursive mode in draft http://tools.= ietf.org/html/draft-lelouedec-cdni-request-routing-00) : In normal situations where dCDN can handle the request, The uCDN uses the Footprint&Cap information (advertised by dCDN) to select = a dCDN The uCDN uses the information provided by this dCDN via the CDNI Request Ro= uting/Redirection interface (especially the distinguished CDN-domain to use= ) to redirect the client request to the dCDN. Then the client request (which has been redirected to the request routing s= ystem of the dCDN) has to redirect afterwards to one delivery node of the d= CDN. In this sub-mode, there are indeed 2 RTTs (user-->uCDN, uCDN-->user, user--= >dCDN, dCDN-->user). But Mode B can also be compatible with what we call the CDNI full-recursive= request redirection mode in draft http://tools.ietf.org/html/draft-leloued= ec-cdni-request-routing-00 : In normal situations where dCDN can handle the request, The uCDN uses the Footprint&Cap information (advertised by dCDN) to select = a dCDN The uCDN uses the information provided by this dCDN via the CDNI Request Ro= uting/Redirection interface to redirect the client request to the dCDN.=20 And in this case the information provided by the dCDN via this CDNI Request= Routing/Redirection interface points in fact directly to a delivery node w= ithin the dCDN. (Or one could maybe also even imagine specific cases where all the delivery= nodes of the dCDN have the same IP anycast address, etc. (?)) Anyway the client request is redirected here directly to a delivery node of= the dCDN. In this case, there is only 1 RTT with Mode A (user-->uCDN, uCDN-->user). Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de F= rancois Le Faucheur (flefauch) Envoy=E9=A0: mercredi 25 juillet 2012 14:36 =C0=A0: BERTRAND Gilles RD-CORE Cc=A0: cdni@ietf.org Objet=A0: Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.txt All, To help the discussion, we may need to distinguish three (main) modes: *A* the uCDN uses the Footprint&Cap information (advertised by dCDN) to sel= ect a dCDN. The uCDN redirects to the selected dCDN and considers that he i= s done with request routing. *B* the uCDN uses the Footprint&Cap information (advertised by dCDN) to sel= ect a dCDN candidate. The uCDN queries the dCDN before redirecting.=20 Querying dCDN optionally allows the dCDN to provide to uCDN the final redir= ection information so the the enduser experiences a single redirect. Querying dCDN optionally allows the uCDN to pick an alternate dCDN if the i= nitially selected dCDN cannot handle the request. *C* the uCDN queries multiple dCDNs on a per-request basis and selects dCDN= based on their responses. In other words, the Footprint&Cap advertisement = is performed via on-demand per-request queries.=20 I think: * Scott pointed out that fundamentatly both *A* and *B* have to deal with = (typically transient) situations where uCDN thinks dCDN can take a request = and dCDN actually cannot handle it. And pointed out that with *A* the trans= ient period is dictated by the Footprint&Cap advertisement "update speed" w= hile with *B* it is not. * Allan was saying *A* is all he needs and *B* is extra complexity that he= doesn't need. * Gilles and lelouedec-cdni-request-routing were saying *C* is bad.=20 My impression is that there is violent agreement that *A* is to be supporte= d. I think Allan and Gilles message indicate so. I personally support that.= I think many people have been discussing that approach. If someone feels t= his is NOT to be supported by CDNI, do let us know.=20 I think Gilles message below is primarily arguing against *C*. I personally= agree that this need not be supported in our initial deliverables. Are the= re people arguing this approach is to be supported in the initial deliverab= les?=20 Regarding *B*, I personally see it as quite useful and worth supporting in = Phase 1 (possibly as an option).=20 Regarding Allan's points: * I agree there is some "scalability" argument (i.e. state+wait-for-dCDN-r= esponse) but it amounts to a web-services call out per request and buys you= reliability of request routing, so I see that as a trade-off that some CDN= s should be able to exercise.=20 * I don't buy the latency argument because you end up with 2 RTTs in both = *A* and *B* (in normal situations where dCDN can handle the request) (i.e. = user-->uCDN, uCDN-->user, user-->dCDN, dCDN-->user versus user-->uCDN, uCDN= -->dCDN, dCDN-->uCDN, uCDN-->user) and in the transient cases where dCDN ca= nnot handle the request *B* can do as well as *A* (drop the request) or has= the option to differently i.e. re-redirect at the cost of an extra RTT.=20 * I don't buy the "loop free mechanism" argument. In *B*, it is easy to im= plement a loop detection and even loop prevention (if you want). In *A*, yo= u have no loop prevention (other than the inherent HTTP/DNS max redirect/ma= x CNAMEs) Other opinions on *B* are sought. Cheers Francois On 25 Jul 2012, at 13:39, wrote: > Hi everyone, >=20 > I fully agree with Allan's comments. Putting aside the vocabulary ('recur= sive model' etc), Allan's comment are consistent with the messages that htt= p://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 tries to co= nvey. >=20 > " o Regarding the former process, i.e. related to the "ability" > ("enables a Request Routing function in an upstream CDN to query a > Request Routing function in a downstream CDN to determine if the > downstream CDN is able (...) to accept the delegated content > request"), a routing protocol is used to achieve such a process, > called routing process, in many other technologies and networks > (IP, ATM, etc.). In all these technologies, it is the downstream > entity that provides routing information to the upstream entity. > The same approach should be applied to CDN interconnection. The > reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2, > dCDN 3, and then it selects one of them based on their responses") > would suffer from latency, signaling overhead and/or lack of > reactivity to events that impact the ability of the downstream > CDNs to accept delegated content requests." >=20 > Best regards, > -- > Gilles >=20 >=20 > -----Message d'origine----- > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part=20 > de GUILLOU, Allan Envoy=E9 : mercredi 25 juillet 2012 12:23 =C0 : Scott= =20 > Wainner; cdni@ietf.org Objet : Re: [CDNi] TR: I-D Action:=20 > draft-lelouedec-cdni-request-routing-00.txt >=20 > Hi, >=20 > With a "recusive model" as you ask if I understand, you expect the dCDN t= o send like an "ack" for each request, and if not the uCDN will try to find= the second best dCDN and do the same thing. >=20 > I think that this model may add complexity and may cause some scalability= problem. You will have to implement timers between request and ack, retran= smission mechanism to make sure that request has not been lost, loop free m= echanism, And all this may add latency on all requests and performances pro= blems. >=20 > In the iterative model, if the dCDN is not able to handle the request, th= is request will be lost. It is the same thing in IP network today we do not= ask the routing protocol to change when there is saturation somewhere. It = is the responsibility of each ISP to choose another route to join this dest= ination if he want to keep a good quality of service. If a dCDN is overload= ed, it will stop announcing part of its footprint or uCDN may apply some po= licy to force choosing another dCDN. >=20 > It is right that this second model may not in case of dCDN saturation hav= e the best reactivity, but it is exactly the same thing on the internet tod= ay. We can imagine that a poor dCDN which have saturation will be "black li= sted" by all the uCDN and the regulation will be done like this. > I think recursive model will add complexity all the time for a gain witch= is not in my opinion so important and that will not be seen so often. >=20 > Allan >=20 >> -----Message d'origine----- >> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part=20 >> de Scott Wainner Envoy=E9 : lundi 16 juillet 2012 14:23 =C0 : >> cdni@ietf.org Objet : Re: [CDNi] TR: I-D Action:=20 >> draft-lelouedec-cdni-request-routing- >> 00.txt >>=20 >> On 7/10/12 11:39 AM, Brandenburg, R. (Ray) van wrote: >>> Hi Yannick, >>>=20 >>> We seem to be misunderstanding each other. Maybe this will help=20 >>> clarify >> my point: >>>=20 >>>> Let me try to fully understand your point: >>>> Are you really meaning that in this case the dCDN has in reality >> absolutely no obligation with regards to the uCDN? >>>> Are you really meaning that in this case the dCDN decides alone, in >> real time, and for each content request, whether it denies or accepts=20 >> to ensure delivery? >>> What I mean is that I would like to have a RR Interface at least=20 >>> support >> a model where for every content request the uCDN asks the dCDN=20 >> whether it wants to deliver that particular content item (I believe=20 >> you call this a PULL approach). And I would like to allow the dCDN to be= able to say 'No' >> on this request (whether it is for purposes or failure, overload, or=20 >> any other reason). >>>=20 >>>> Are you really meaning that in this case the dCDN decides alone, in >> real time, and for each content request, whether it denies or accepts=20 >> to ensure delivery, and this even if the dCDN has the capability to=20 >> deliver the content? >>> Yes. >> I think we have to delineate between the iterative and recursive model. >>=20 >> The recursive model assumes that the client request to the uCDN will=20 >> be recursive and the CDN-I RR interface will be used to provide an=20 >> answer for each client request. The choice to initiate the recursion=20 >> would be determined by the footprint / capabilities. The ability of=20 >> the dCDN to execute the specific request would provide immediate=20 >> feedback to the uCDN. A dCDN that continues to advertise the=20 >> footprint / capability, but frequently or continually rejects the=20 >> request via CDN-I RR would be a poor candidate. The opportunity now=20 >> arises where the uCDN may elect to choose an alternate dCDN because=20 >> its preferred dCDN (according to footprint / capabilities) is 'under-per= forming'. >>=20 >> The iterative model, the uCDN blindly redirects the client to the=20 >> dCDN based on the footprint / capabilities. What the dCDN does with=20 >> the request is somewhat transparent to the uCDN. With the exception=20 >> of the CDN-I logging, the uCDN assumes the dCDN is properly handling=20 >> the requests that were delegated to the dCDN. If you are trying to=20 >> 'tighten' up the case of blind rejections, then the frequency of the=20 >> footprint / capabilities advertisements would have to be accelerated. >> For the case where the dCDN repeatedly sees requests from the uCDN=20 >> that the dCDN can't handle, it should retract its footprint /=20 >> capabilities advertisement. Failing to do so would continually=20 >> black-hole routing requests which would be indicated in the logging info= rmation. >>=20 >> Either way, you need a feedback loop to avoid dumping routing requests. >>=20 >> With any feedback loop (recursive routing request or footprint /=20 >> capabilities advertisement), you have to be careful about rapid=20 >> oscillations and dampening the responses. >>=20 >> Scott >>>=20 >>>> Are you really meaning that in this case the dCDN may possibly=20 >>>> response >> negatively to all requests for content request redirection submitted=20 >> by the uCDN over the CDNI request routing interface? (i.e. that=20 >> possibly the uCDN will never be allowed/invited to redirect a content=20 >> request to the >> dCDN?) >>>=20 >>> Yes. Any negative effect this may have on the business relationship >> between uCDN and dCDN should be handled on the business level. >>>=20 >>> Ray >>>=20 >>>=20 >>> On Jul 10, 2012, at 4:33 PM, >>> wrote: >>>=20 >>>> Hi Ray, >>>>=20 >>>>=20 >>>> 1) Ray, quoting your mail: "The current drafts seems to assume some >> particular type of contractual agreement between CDNs that might not=20 >> always be the case." >>>>=20 >>>> Please quote the draft. >>>> Please let us know exactly to which sentence(s) of the draft you=20 >>>> are >> referring to. >>>> Otherwise it is hard to discuss and comment on your email. >>>>=20 >>>>=20 >>>> 2) Ray, Quoting your mail: "If a dCDN does not live up to its >> contractual agreement, this should be something that is handled on a=20 >> business level, not on a protocol level." >>>>=20 >>>> Maybe there is a deep misunderstanding. >>>> So I will try to be clear again. >>>> We do not propose the CDNI routing interface to be used by the dCDN=20 >>>> to >> send a message saying "Sorry, but I decide unilaterally to refuse=20 >> this content request". >>>> We do not propose the CDNI routing interface to be used to handle=20 >>>> any >> aspect relating to a dCDN deciding unilaterally to stop living up to=20 >> its contractual agreement. >>>>=20 >>>> Please let us know where you saw such an idea in this IETF draft=20 >>>> "CDNI >> request routing". >>>>=20 >>>> The only role of the CDNI routing interface is to be used to=20 >>>> advertise >> CDNI routing information from the downstream CDN to the upstream CDN. >>>> And this is the description given in this IETF draft. >>>>=20 >>>>=20 >>>> 3) Ray, quoting your mail: "one example of a contractual agreement >> between two CDNs is one in which the uCDN and dCDN have agreed that=20 >> the dCDN will deliver some content on behalf of a uCDN, but decide on=20 >> a per- request basis whether it wants to do so (and is for example=20 >> paid per request). In these cases, the dCDN needs to have the ability=20 >> to deny delivery on a per-request basis." >>>>=20 >>>> Let me try to fully understand your point: >>>> Are you really meaning that in this case the dCDN has in reality >> absolutely no obligation with regards to the uCDN? >>>> Are you really meaning that in this case the dCDN decides alone, in >> real time, and for each content request, whether it denies or accepts=20 >> to ensure delivery? >>>> Are you really meaning that in this case the dCDN decides alone, in >> real time, and for each content request, whether it denies or accepts=20 >> to ensure delivery, and this even if the dCDN has the capability to=20 >> deliver the content? >>>> Are you really meaning that in this case the dCDN may possibly=20 >>>> response >> negatively to all requests for content request redirection submitted=20 >> by the uCDN over the CDNI request routing interface? (i.e. that=20 >> possibly the uCDN will never be allowed/invited to redirect a content=20 >> request to the >> dCDN?) >>>>=20 >>>>=20 >>>> 4) Ray, quoting your mail: "Every routing protocol defines the=20 >>>> expected >> behavior of interconnected elements/networks on a technical level,=20 >> not on a business level." >>>>=20 >>>> Again, this is not what I have written, and this is not the idea we >> want to share. >>>> I wrote "Every routing protocol has been defined (or at least >> configured) so far by considering the expected behavior of the=20 >> interconnected elements/networks." >>>> That's all. >>>> I can rephrase this sentence the following way: "we must know what=20 >>>> we >> expect to do with a protocol to design it correctly." >>>> And IHMO this is an evidence; I don't know any other way to proceed. >>>>=20 >>>> Besides, let us consider BGP (which is by the way an option=20 >>>> proposed by >> some IETF members to implement this CDNI routing interface). >>>> In IP networks, BGP configurations in IP routers are defined as per=20 >>>> the >> business relationships (valley free policy, etc.). >>>> Of course the business relationships determine the BGP configurations. >>>> And of course BGP has been designed so as to allow to configure IP >> interconnections adequately depending on the corresponding=20 >> Customer/provider, sibling and peering contractual agreements. >>>> But this does not mean that BGP "defines the expected behavior of >> interconnected elements/networks... on a business level." >>>> Even if we can indeed infer quite accurately the business=20 >>>> relationships >> between ISP from the BGP configuration of their IP routers (see CAIDA=20 >> project), but this is another story. >>>>=20 >>>>=20 >>>> Best regards, >>>>=20 >>>> Yannick Le Lou=E9dec. >>>>=20 >>>>=20 >>>>=20 >>>> -----Message d'origine----- >>>> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >>>> Envoy=E9 : mardi 10 juillet 2012 15:13 =C0 : LE LOUEDEC Yannick=20 >>>> RD-CORE; Ben Niven-Jenkins Cc : Pilarski Marcin - Korpo TP;=20 >>>> cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR: I-D >>>> Action: draft-lelouedec-cdni-request- >> routing-00.txt >>>>=20 >>>> Hi Yannick, >>>>=20 >>>> See comments inline. >>>>=20 >>>> In general: IMO the CDNI interfaces should be abstracted from any=20 >>>> kind >> of contractual/business agreement that might or might not exist=20 >> between a dCDN and uCDN. The current drafts seems to assume some=20 >> particular type of contractual agreement between CDNs that might not alw= ays be the case. >>>>=20 >>>> Ray >>>>=20 >>>> -----Original Message----- >>>> From: yannick.lelouedec@orange.com >> [mailto:yannick.lelouedec@orange.com] >>>> Sent: dinsdag 10 juli 2012 12:01 >>>> To: Brandenburg, R. (Ray) van; Ben Niven-Jenkins >>>> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE >>>> Subject: RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- >> routing-00.txt >>>>=20 >>>> Hi Ray, all, >>>>=20 >>>>=20 >>>> 1) Ray, Quoting your mail: "I don't see why the CDNI Request=20 >>>> Routing >> interface should state that a dCDN MUST deliver the content if it has=20 >> indicated its ability to do so earlier in either a contractual=20 >> agreement or in the capability interface." >>>>=20 >>>> This is not what we have written. >>>> Let me try to rephrase simply. >>>>=20 >>>> A contractual agreement is a contractual agreement. >>>> It put in writings the respective obligations of the uCDN and of=20 >>>> the >> dCDN. >>>> The uCDN may redirect any content request to the dCDN as long as it=20 >>>> is >> in full conformance with the terms of this contractual agreement (the=20 >> type of the content request is in full conformance, the maximum=20 >> number of content requests per second is respected, etc.). >>>> In this case the dCDN may not say "Sorry, but I decide unilaterally=20 >>>> to >> refuse this content request". >>>>=20 >>>> [RvB]: This is where we disagree. IMHO, the type of behavior you >> describe (the dCDN not living up to its obligation) should not be=20 >> enforced by the CDNI Interfaces. If a dCDN does not live up to its=20 >> contractual agreement, this should be something that is handled on a=20 >> business level, not on a protocol level. >>>>=20 >>>> Why? Because this is the deal, a contractual agreement is a=20 >>>> contractual >> agreement! >>>> Yet the dCDN may say "I do apologize, but at this time I cannot=20 >>>> handle >> correctly a certain class of content requests specified in our=20 >> contractual agreement" (for example the class of the HTTP content=20 >> requests with token from French end users, because of overload=20 >> situation, failure, etc.) This is the role of the CDNI routing=20 >> interface to provide the uCDN with such information. >>>>=20 >>>> (And the dCDN may be given a penalty for example if this was agreed=20 >>>> in >> the terms of the contractual agreement.) >>>>=20 >>>>=20 >>>> 2) Ray, Quoting your mail: "I understand that in most cases, the >> contractual agreement might indeed impose this behavior on the dCDN" >>>>=20 >>>> Please provide the description of an example where this is not the >> case. >>>> Otherwise the IETF CDNI WG shall indeed consider this is ALWAYS the >> case. >>>>=20 >>>> [RvB]: I can't remember ever seeing such a discussion on the WG list. >> Anyway: one example of a contractual agreement between two CDNs is=20 >> one in which the uCDN and dCDN have agreed that the dCDN will deliver=20 >> some content on behalf of a uCDN, but decide on a per-request basis=20 >> whether it wants to do so (and is for example paid per request). In=20 >> these cases, the dCDN needs to have the ability to deny delivery on a pe= r-request basis. >>>>=20 >>>> And this is an important point to be able to progress in the CDNI >> interfaces' specification works. >>>>=20 >>>> If the contractual agreement does not define clearly the=20 >>>> obligations of >> the uCDN, it is impossible to dimension adequately the dCDN, neither=20 >> to define correctly the CDNI contractual agreements between the dCDN=20 >> and the dCDNs of this dCDN. >>>> If the contractual agreement does not define clearly the=20 >>>> obligations of >> the dCDN, the dCDN may do what it wants... even to put in the trash=20 >> can any content request it accepted to handle. >>>>=20 >>>> [RvB]: Exactly, this is something that needs to be discussed on a >> business/contractual level and not on a technical level. That is way=20 >> IMHO the CDNI Interfaces should not make ANY assumptions on what was=20 >> agreed on a contractual level. >>>>=20 >>>> In both situations it is impossible to ensure any quality of=20 >>>> experience >> to the end user. >>>>=20 >>>>=20 >>>> 3) Ray, Quoting your mail: "I don't think this type of behavior=20 >>>> should >> be imposed by the protocol we're developing here." >>>>=20 >>>> I do not sure I understand this sentence. >>>> Every routing protocol has been defined (or at least configured) so=20 >>>> far >> by considering the expected behavior of the interconnected=20 >> elements/networks. >>>>=20 >>>> [RvB]: Every routing protocol defines the expected behavior of >> interconnected elements/networks on a technical level, not on a=20 >> business level. Having a dCDN say 'I'm not willing to deliver this=20 >> content' is perfectly fine from a technical perspective, although it=20 >> could be problematic from a contractual perspective. >>>>=20 >>>> But maybe I will understand if you provide an example on the point >>>> 2 >> above. >>>>=20 >>>>=20 >>>> Best regards, >>>>=20 >>>> Yannick Le Lou=E9dec. >>>>=20 >>>>=20 >>>>=20 >>>> -----Message d'origine----- >>>> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >>>> Envoy=E9 : mardi 10 juillet 2012 09:20 =C0 : Ben Niven-Jenkins; LE=20 >>>> LOUEDEC Yannick RD-CORE Cc : Pilarski Marcin >> - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR:=20 >> I-D >> Action: draft-lelouedec-cdni-request-routing-00.txt >>>>=20 >>>> Hi Yannick, Ben, >>>>=20 >>>> I tend to agree with Ben here. When reading the draft, I got the >> feeling that the draft seems to assume a lot about the relationship=20 >> between the uCDN and dCDN. For example, I don't see why the CDNI=20 >> Request Routing interface should state that a dCDN MUST deliver the=20 >> content if it has indicated its ability to do so earlier in either a=20 >> contractual agreement or in the capability interface. I understand=20 >> that in most cases, the contractual agreement might indeed impose=20 >> this behavior on the dCDN, but I don't think this type of behavior=20 >> should be imposed by the protocol we're developing here. >>>>=20 >>>> It was always my assumption that the Request Routing Interface=20 >>>> would at >> least include the option of allowing the uCDN to query the dCDN for=20 >> every content request whether the dCDN is willing to deliver that=20 >> particular request. >>>>=20 >>>> I will send my full review of the draft later. >>>>=20 >>>> Ray >>>>=20 >>>> -----Original Message----- >>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On=20 >>>> Behalf Of >> Ben Niven-Jenkins >>>> Sent: dinsdag 10 juli 2012 7:38 >>>> To: yannick.lelouedec@orange.com >>>> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE >>>> Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- >> routing-00.txt >>>>=20 >>>> Yannick, >>>>=20 >>>> Please see inline. >>>>=20 >>>> On 9 Jul 2012, at 20:05, wrote: >>>>=20 >>>>> Hi Ben, all, >>>>>=20 >>>>> Ben, quoting you mail below, "... the downstream CDN could reply=20 >>>>> with either "here is how to redirect it"", >>>>>=20 >>>>> =3D> This is the role of the CDNI DRIS interface to provide the uCDN >> with this information, and we target to make its specification public=20 >> before Vancouver meeting so that everyone may read it before the=20 >> meeting and get full knowledge of our proposal about this part of=20 >> CDNI request routing. >>>>>=20 >>>>> Ben, quoting you mail below, "... or "no I can't/won't take that >> content delivery right now", reasons may include the uCDN has=20 >> requested a delivery of a protocol the dCDN does not support (possibly i= n error). >>>>>=20 >>>>> =3D> This is the role of the CDNI logging interface to provide the=20 >>>>> uCDN >> with this information. >>>> I agree this information should be logged but the Request Routing >> interface (what you call the DRIS) also needs to be able to indicate=20 >> a failure. >>>>=20 >>>> Otherwise the uCDN will 'blindly' redirect the the dCDN and the >> delivery will fail leading to poor end user experience. >>>>=20 >>>>> Ben, quoting you mail below, "... or "no I can't/won't take that >> content delivery right now", reasons may include ... the dCDN has no=20 >> capacity right now etc." >>>>>=20 >>>>> =3D> This is the role of the CDNI routing interface to provide the=20 >>>>> uCDN >> with this information. >>>> It is the role of the CDN capability/routing interface to advertise >> broad capabilities etc not to give extremely fine grained real-time=20 >> information on exactly the state of the dCDN. >>>>=20 >>>> Even if the capability/routing interface is real-time there are=20 >>>> likely >> to still be race conditions where we need the dCDN to be about to=20 >> indicate a failure to accept a redirect through the request=20 >> routing/DRIS interface >>>>=20 >>>>> So we may conclude we are in line basically, which is a good point. >>>>> We just aimed at checking there was a common understanding on this >> point. >>>>>=20 >>>>> The key point for us here is that we don't want this sentence >> extracted from draft-ietf-cdni-problem-statement be interpreted as: ".= =20 >> and the dCDN MUST accept the content request except when it has not=20 >> the "ability" to do so." >>>> Why not? IMO that is a valid scenario for some use cases. >>>>=20 >>>>> The fact that the dCDN is temporary unable to handle content=20 >>>>> request >> correctly is not a valid reason for the dCDN to be discharged of its=20 >> obligations to the uCDN. >>>>> The contract set between the uCDN and the dCDN remains valid=20 >>>>> anyway, >> and the obligations of the dCDN as well. >>>> Correct, but that contract may not be the same for all uCDNs &=20 >>>> dCDNs, >> for example a uCDN may not have a guarantee that a dCDN can handle=20 >> everything it is requested to handle but the contract may only be=20 >> that the dCDN guarantees to handle up to a certain volume of traffic. >>>>=20 >>>>> The dCDN must announce to the uCDN that it is temporary unable, as >> soon as possible, via the CDNI routing interface. >>>>> And the uCDN must take this information into account in its CDN >> selection process as soon as possible. >>>>> Then if the uCDN decides to continue to redirect content requests=20 >>>>> to >> the dCDN, the uCDN MAY perfectly do it, but the uCDN knows these=20 >> content requests will be lost. >>>> What happens in the period between the dCDN being unable to handle >> requests and the time it takes to advertise that to the uCDN and for=20 >> the uCDN to process & incorporate that new knowledge? Are requests=20 >> blindly forwarded to the dCDN which is unable to handle them leading=20 >> to poor user experience? >>>>=20 >>>>> We could even imagine the situation where the uCDN continues to do=20 >>>>> it >> intentionally, because it has no better option and the content=20 >> request will be lost anyway. For example in the case where neither=20 >> the uCDN nor the other downstream CDNs of the uCDN cannot manage=20 >> correctly the content request, the uCDN could do it intentionally so=20 >> as to be able to clearly prove (with CDNI logging information) that=20 >> it is the dCDN, not the uCDN, who is at fault. >>>>> But, of course, if there are alternative backup options, the=20 >>>>> normal >> reaction of the uCDN is to stop as soon as possible to redirect=20 >> content requests to the dCDN when the uCDN knows that the dCDN is=20 >> unable to handle them correctly. >>>>>=20 >>>>> So, to be clear, we would prefer the sentence to be understood as: >>>>> ". and the dCDN MUST accept the content request. >>>>> And if it cannot handle correctly the redirected content request=20 >>>>> it >> receives, the content request is lost. >>>> What about scenarios where the uCDN has a choice of dCDNs (e.g. two >> national-wide CDNs offering services at different costs), the uCDN=20 >> may elect to query both dCDNs and decide based on their responses=20 >> which one to choose. If the dCDN is unable to satisfy the request the=20 >> uCDN needs to know that so that it can fallback to the (more=20 >> expensive in this example) dCDN. >>>>=20 >>>>> For example the dCDN generates a response to the content request=20 >>>>> with >> an error message, or no response at all. And in parallel the CDNI=20 >> logging interface may be used to exchange logs corresponding to this pro= blem. >> Anyway the dCDN MAY NOT redirect that content request back towards=20 >> the uCDN." >>>>>=20 >>>>> Exactly as in IP networks: IP packets are not sent back towards=20 >>>>> the >> origin by a downstream router under failure or congestion. >>>> In a routed IP network, there is often a small packet loss while=20 >>>> the >> network re-converges, by enabling the dCDN to refuse a redirection at=20 >> CDNI Request Routing/DRIS query time we can reduce that window by=20 >> giving the uCDN the option to take an alternative action (e.g. try=20 >> another dCDN) while the routing/capability information re-converges. >>>>=20 >>>>> In both networks (IP and CDN), the reason is the same. >>>>> If the dCDN redirects back a content request to the uCDN, this >> generates a loop. >>>> Loop avoidance is a separate issue IMO to whether we should allow a >> dCDN to be able to communicate "I am unable/unwilling to take that=20 >> content delivery at this time". >>>>=20 >>>> Regards >>>> Ben >>>>=20 >>>>> To manage this would introduce a very high complexity. >>>>> And this would be just to try to save the content requests=20 >>>>> redirected >> by the uCDN to the dCDN in the timeslot between the time the dCDN=20 >> gets down and the time the uCDN takes this failure into account in=20 >> its CDN selection process. >>>>> It is much better to try to reduce this timeslot as much as=20 >>>>> possible, >> with routing optimizations (we will propose as soon as possible). >>>>> Rather than introducing additional complexities (to manage=20 >>>>> redirection >> to the uCDN) in the framework. >>>>>=20 >>>>>=20 >>>>> By the way, as you know, the IESG has just approved today the=20 >>>>> 'Content >> Distribution Network Interconnection (CDNI) Problem Statement' draft=20 >> as informational RFC. This is a good point. >>>>> And, as you may see in the draft "CDNI request routing", we do not >> propose to modify this problem statement draft. >>>>> We want know to focus now on getting the specifications of all=20 >>>>> CDNI >> interfaces ready as soon as possible. >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Yannick Le Lou=E9dec. >>>>>=20 >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la=20 >>>>> part de Ben Niven-Jenkins Envoy=E9 : lundi 9 juillet 2012 20:41 =C0 : >>>>> BERTRAND Gilles RD-CORE Cc : cdni@ietf.org; Pilarski Marcin -=20 >>>>> Korpo TP; MARREC Anne RD-CORE Objet : Re: [CDNi] TR: I-D Action: >>>>> draft-lelouedec-cdni-request-routing-00.txt >>>>>=20 >>>>> Colleagues, >>>>>=20 >>>>> I started reading draft-lelouedec-cdni-request-routing-00 and this >> text caught my eye: >>>>>=20 >>>>> Quoting [I-D.ietf-cdni-problem-statement ], "The CDNI Request=20 >>>>> Routing interface enables a Request Routing function in an=20 >>>>> upstream CDN to query a Request Routing function in a downstream=20 >>>>> CDN to determine if the downstream CDN is able (and willing) to=20 >>>>> accept the delegated content request". >>>>>=20 >>>>> The "ability" and the "willingness" of the downstream CDN to=20 >>>>> accept the delegated content request match two fully different=20 >>>>> processes in CDN interconnection. And the description of both=20 >>>>> these processes should be reviewed and clarified for the following r= easons: >>>>>=20 >>>>> o Regarding the former process, i.e. related to the "ability" >>>>> ("enables a Request Routing function in an upstream CDN to=20 >>>>> query >> a >>>>> Request Routing function in a downstream CDN to determine if the >>>>> downstream CDN is able (...) to accept the delegated content >>>>> request"), a routing protocol is used to achieve such a process, >>>>> called routing process, in many other technologies and networks >>>>> (IP, ATM, etc.). In all these technologies, it is the downstream >>>>> entity that provides routing information to the upstream entity. >>>>> The same approach should be applied to CDN interconnection. The >>>>> reverse approach ("uCDN queries it downstream CDNs dCDN 1,=20 >>>>> dCDN >> 2, >>>>> dCDN 3, and then it selects one of them based on their >> responses") >>>>> would suffer from latency, signaling overhead and/or lack of >>>>> reactivity to events that impact the ability of the downstream >>>>> CDNs to accept delegated content requests. >>>>>=20 >>>>> o Regarding the latter process, i.e. related to the "willingness" >>>>> ("enables a Request Routing function in an upstream CDN to=20 >>>>> query >> a >>>>> Request Routing function in a downstream CDN to determine if the >>>>> downstream CDN (...) is willing (...)to accept the delegated >>>>> content request"), it is to be noted that the relationship >> between >>>>> a uCDN and a dCDN is always in the frame of a contractual >>>>> agreement between the administrative entity owning the uCDN, >>>>> acting as the customer, and the administrative entity owning the >>>>> dCDN, acting as the service provider. Therefore, consider a case >>>>> where >>>>>=20 >>>>> * the uCDN has a content request to redirect which is in full >>>>> conformance with the terms of this contractual agreement,=20 >>>>> and >>>>>=20 >>>>> * the uCDN has selected this dCDN. >>>>>=20 >>>>> As the uCDN knows, thanks to the routing information exchanged >> via >>>>> the aforementioned routing process, that the dCDN is able to >>>>> accept this content request, the uCDN MAY redirect the content >>>>> request to the dCDN and the dCDN MUST accept the content request. >>>>> Exchanging over the CDNI Request Routing interface information >>>>> about the "willingness" of the dCDN to accept the content request >>>>> is not relevant. >>>>>=20 >>>>> I think you might be over thinking what we wrote in the problem >> statement. >>>>>=20 >>>>> What was in the problem statement was meant to convey that an=20 >>>>> upstream >> CDN could make a request to a downstream CDN to say "how do I=20 >> redirect this request to you" and the downstream CDN could reply with=20 >> either "her is how to redirect it", or "no I can't/won't take that=20 >> content delivery right now", reasons may include the uCDN has=20 >> requested a delivery of a protocol the dCDN does not support=20 >> (possibly in error) or the dCDN has no capacity right now etc. >>>>>=20 >>>>> Ben >>>>>=20 >>>>> On 9 Jul 2012, at 18:00, wrote: >>>>>=20 >>>>>> Hi everyone, >>>>>>=20 >>>>>> We have just submitted the draft below. We are convinced that it=20 >>>>>> will >> help the WG to progress on the CDNI routing issues. >>>>>>=20 >>>>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-0 >>>>>> 0 >>>>>>=20 >>>>>> Any feedback is very welcome. >>>>>>=20 >>>>>> Best regards, >>>>>>=20 >>>>>> Gilles >>>>>>=20 >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : i-d-announce-bounces@ietf.org=20 >>>>>> [mailto:i-d-announce-bounces@ietf.org] De la part de=20 >>>>>> internet-drafts@ietf.org Envoy=E9 : lundi 9 juillet 2012 18:55 =C0 : >>>>>> i-d-announce@ietf.org Objet : I-D Action: >>>>>> draft-lelouedec-cdni-request-routing-00.txt >>>>>>=20 >>>>>>=20 >>>>>> A New Internet-Draft is available from the on-line=20 >>>>>> Internet-Drafts >> directories. >>>>>>=20 >>>>>>=20 >>>>>> Title : CDNI Request Routing >>>>>> Author(s) : Yannick Le Louedec >>>>>> Anne Marrec >>>>>> Gilles Bertrand >>>>>> Marcin Pilarski >>>>>> Filename : draft-lelouedec-cdni-request-routing-00.txt >>>>>> Pages : 30 >>>>>> Date : 2012-07-09 >>>>>>=20 >>>>>> Abstract: >>>>>> The present document proposes to clarify the CDNI Request Routing=20 >>>>>> interface introduced in [I-D.ietf-cdni-framework] and >>>>>> [I-D.ietf-cdni- problem-statement], as well as related terminology. >>>>>>=20 >>>>>> In particular the present document proposes to split the CDNI=20 >>>>>> Request Routing interface into two separate interfaces with=20 >>>>>> clearer roles, named respectively CDNI Routing interface and=20 >>>>>> CDNI Downstream Resource Identifier Signaling interface (CDNI DRIS i= nterface). >>>>>>=20 >>>>>> This part of the CDN interconnection framework the IETF has been=20 >>>>>> referring to so far with the term "CDNI Request Routing" is just=20 >>>>>> another routing, signaling and forwarding problem in a long=20 >>>>>> series of the telecommunication history. For example, one can=20 >>>>>> draw a direct analogy between the IP/MPLS-TE framework and the=20 >>>>>> CDN interconnection framework. >>>>>>=20 >>>>>> In addition, this document recommends that the specification of=20 >>>>>> ALL CDN interconnection interfaces in the scope of the CDNI IETF=20 >>>>>> WG relies on the equivalent concept to IP prefix for CDN=20 >>>>>> interconnection, named 'contentRequestScope'. This highly useful=20 >>>>>> and powerful concept SHALL be used to simplify the specification=20 >>>>>> of ALL CDN interconnection interfaces, as well as to ensure=20 >>>>>> performance and scalability in CDN interconnection. >>>>>>=20 >>>>>> All these proposals can be smoothly integrated in the WG drafts,=20 >>>>>> especially [I-D.ietf-cdni-framework] and=20 >>>>>> [I-D.ietf-cdni-requirements], as they essentially propose >>>>>> (useful) clarifications of the existing framework. >>>>>>=20 >>>>>>=20 >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-rou >>>>>> ting >>>>>>=20 >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-0 >>>>>> 0 >>>>>>=20 >>>>>>=20 >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>=20 >>>>>> _______________________________________________ >>>>>> 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=20 >>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>=20 >>>>>> _________________________________________________________________ >>>>>> ____ ____________________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>> informations confidentielles ou privilegiees et ne doivent donc=20 >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 >>>>>> avez recu ce message par erreur, veuillez le signaler a=20 >>>>>> l'expediteur et le detruire ainsi >> que les pieces jointes. Les messages electroniques etant susceptibles=20 >> d'alteration, France Telecom - Orange decline toute responsabilite si=20 >> ce message a ete altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or=20 >>>>>> privileged information that may be protected by law; they should=20 >>>>>> not >> be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the=20 >>>>>> sender >> and delete this message and its attachments. >>>>>> As emails may be altered, France Telecom - Orange is not liable=20 >>>>>> for >> messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=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 >>>>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>>>> ce message par erreur, veuillez le signaler a l'expediteur et le=20 >>>>> detruire ainsi >> que les pieces jointes. Les messages electroniques etant susceptibles=20 >> d'alteration, France Telecom - Orange decline toute responsabilite si=20 >> ce message a ete altere, deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or=20 >>>>> privileged information that may be protected by law; they should=20 >>>>> not >> be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender=20 >>>>> and >> delete this message and its attachments. >>>>> As emails may be altered, France Telecom - Orange is not liable=20 >>>>> for >> messages that have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >>>> This e-mail and its contents are subject to the DISCLAIMER at >> http://www.tno.nl/emaildisclaimer >>>>=20 >>>>=20 >>>>=20 >> _____________________________________________________________________ >> _ ____ _______________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 >> que les pieces jointes. Les messages electroniques etant susceptibles=20 >> d'alteration, France Telecom - Orange decline toute responsabilite si=20 >> ce message a ete altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or=20 >>>> privileged >> information that may be protected by law; they should not be=20 >> distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender=20 >>>> and >> delete this message and its attachments. >>>> As emails may be altered, France Telecom - Orange is not liable for >> messages that have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>>=20 >>>>=20 >> _____________________________________________________________________ >> _ ____ _______________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 >>>> avez >> recu ce message par erreur, veuillez le signaler >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les >> messages electroniques etant susceptibles d'alteration, >>>> France Telecom - Orange decline toute responsabilite si ce message=20 >>>> a >> ete altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or=20 >>>> privileged >> information that may be protected by law; >>>> they should not be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender=20 >>>> and >> delete this message and its attachments. >>>> As emails may be altered, France Telecom - Orange is not liable for >> messages that have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>> _______________________________________________ >>> 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 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, France Telecom - Orange decline toute responsabilite si ce message a e= te altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From flefauch@cisco.com Fri Jul 27 05:38:33 2012 Return-Path: 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 678EE21F84FE for ; Fri, 27 Jul 2012 05:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.276 X-Spam-Level: X-Spam-Status: No, score=-10.276 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, J_CHICKENPOX_93=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 RFGac9Xeb9TC for ; Fri, 27 Jul 2012 05:38:30 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 372EC21F84E1 for ; Fri, 27 Jul 2012 05:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=55306; q=dns/txt; s=iport; t=1343392706; x=1344602306; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6SmWygVXgmjLwUsFT+5EZ9j0fYab1xHFpBIcHJ8g0NY=; b=XZJbVq8+XieujhCfddVkBSzzkZGWffxm8QV4tqfjlCQgLDxImtFOVmWn tYuSz9soY/il+88UU/n6iqCs9dAymhWTmTuJyN2oKeNWpmgjM3YLKfr5L P/3taiP9vZ/JjfaGNGg6lLM7jjTcueL2pX9hUI3RlMTxmSkTyvpoqg342 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngGAJGKElCQ/khN/2dsb2JhbABFuGJWgQeCIAEBAQMBAQEBDwEHAQwgJQIEBAMFBwQCAQgRBAEBARUSBycLFAkIAgQOBQkZh2UGC5lokQWPRItQAggQgzKCSGADlUiBFIl5gxqBZoJfgVYJGg X-IronPort-AV: E=Sophos;i="4.77,666,1336348800"; d="scan'208";a="141692750" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 27 Jul 2012 12:38:22 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6RCcKWN006945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jul 2012 12:38:22 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.17]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Fri, 27 Jul 2012 07:38:20 -0500 From: "Francois Le Faucheur (flefauch)" To: " " Thread-Topic: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.txt Thread-Index: AQHNa+0ySeCVhvI2oUOW1yCxBqg+/5c9ZVMA Date: Fri, 27 Jul 2012 12:38:19 +0000 Message-ID: References: <23908_1341853266_4FFB0E52_23908_8685_1_f37870f2-1510-42f5-8fc3-cd1f16675c52@PEXCVZYH01.corporate.adroot.infra.ftgroup> <30ACC898-8E44-44E1-93BD-2A9405BDDA81@niven-jenkins.co.uk> <15156_1341860709_4FFB2B65_15156_4416_1_d5f155ab-4c4b-4df2-889f-38b1060b0d32@PEXCVZYH01.corporate.adroot.infra.ftgroup> <16337_1341914436_4FFBFD43_16337_8181_1_156585fb-0991-4f86-bd8c-7824b18d1cbc@PEXCVZYH01.corporate.adroot.infra.ftgroup> <2040_1341930789_4FFC3D24_2040_2504_1_b86bff40-ae68-40c0-b8e5-060f51be6864@PEXCVZYH02.corporate.adroot.infra.ftgroup> <3A7EA7EE-F8D4-4094-83F2-12CD3826B662@tno.nl> <5004079D.4000406@cisco.com> <29661_1343216353_500FDAE1_29661_643_1_2AC63C9F27AF8446B0C064C50FC0A89305D959@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AF54F9B-B4FF-4043-A9DE-36C0417F9EAC@cisco.com> <32094_1343389472_50127F20_32094_400_1_b1bdf24e-f0df-4181-88b6-137751b0f1fa@PEXCVZYH01.corporate.adroot.infra.ftgroup> In-Reply-To: <32094_1343389472_50127F20_32094_400_1_b1bdf24e-f0df-4181-88b6-137751b0f1fa@PEXCVZYH01.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19066.004 x-tm-as-result: No--68.701800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 12:38:33 -0000 Yannick and all, Regarding the latency point: " > But Mode B can also be compatible with what we call the CDNI full-recursi= ve request redirection mode in draft http://tools.ietf.org/html/draft-lelou= edec-cdni-request-routing-00 : > In normal situations where dCDN can handle the request, > The uCDN uses the Footprint&Cap information (advertised by dCDN) to selec= t a dCDN > The uCDN uses the information provided by this dCDN via the CDNI Request = Routing/Redirection interface to redirect the client request to the dCDN.=20 > And in this case the information provided by the dCDN via this CDNI Reque= st Routing/Redirection interface points in fact directly to a delivery node= within the dCDN. > (Or one could maybe also even imagine specific cases where all the delive= ry nodes of the dCDN have the same IP anycast address, etc. (?)) > Anyway the client request is redirected here directly to a delivery node = of the dCDN. > In this case, there is only 1 RTT with Mode A (user-->uCDN, uCDN-->user). " I think you meant to say "In this case, there is only 1 RTT with Mode B (us= er-->uCDN, uCDN-->user)." In any case, with mode B I still see 2 RTTs involved in the overall request= routing redirection process: (user-->uCDN, uCDN-->dCDN, dCDN-->uCDN, uCDN-= ->user). Only one of those is a slightly different RTT. Regarding your other points: " I don't see why the CDNI iterative and (semi- and full-) recursive request = redirection modes should not be compatible a priori with both the modes A a= nd B described below": " I don't quite understand what you mean. But I don't think there is any issu= e here. So let's recap: As per the current CDNI documents (in particular cdni-framework) we have de= fined : * recursive CDNI request routing redirection for the case where the uCDN q= ueries the dCDN (using the RRI/Redirection interface) before redirecting * iterative CDNI request routing redirection for the case where the uCDN d= oes not query the dCDN (using the RRI/Redirection interface) before redirec= ting. (in cdni-framework it currently says "recursive/iterative request routing" = instead of "recursive/iterative request routing redirection" because it has= not yet been fully brought in line with the latest vocabulary, but that do= es not matter) Bottom line is: * The uCDN can select a dCDN (possibly using the RRI/Footprint&Cap interfa= ce) and then decide to not use the RRI/Redirection interface. This is a cas= e of iterative CDNI request routing redirection. This is mode A below. * The uCDN can select a dCDN (possibly using the RRI/Footprint&Cap interfa= ce) and then query that dCDN using the RRI/Redirection interface. This is a= case of recursive CDN request routing redirection. This is mode B below. * The uCDN can query multiple dCDNs using the RRI/Redirection interface an= d then select a dCDN (possibly also using some of the RRI/Footprint&Cap int= erface). This is a case of recursive CDN request routing redirection. This = is mode C below. As pointed by Ray and Scott, the same RRI/Redirection inte= rface should be usable for both B and C. Do you still have any issue or concerns with the above statements? As per the current CDNI documents (in particular cdni-framework) we have de= fined that, in the case of recursive request routing redirection, there are= multiple variations in how the dCDN may answer the query (e.g. it may poin= t to the final Surrogate, it may point to the dCDN Request Router, it may p= oint to a regional/specialised Request Router, it may point to a set of Sur= rogates identifies by an Anycast address, it may point to a 3rd CDN request= router=85). Because there is such a continuum in how recursive request rou= ting redirection can be used by the dCDN, I am not sure it is worth trying = to further define finer-grain terminology such as "full/partial" recursive = redirection. I am not opposed to it as long as (i) there is value in doing = it and (ii) it can be done unambiguously. I am still wondering about (i). W= hat is the value of defining a specific term for "full" vs "partial" (as op= posed to explicitly sating the continuum of options in case of recursive). Cheers Francois On 27 Jul 2012, at 13:44, wrote: > Dear Fran=E7ois, all, >=20 > I have another comment about the mail from Fran=E7ois below. > About the modes A and B and about latency. >=20 > I don't see why the CDNI iterative and (semi- and full-) recursive reques= t redirection modes should not be compatible a priori with both the modes A= and B described below. > (I mean everything is possible, even if some combinations do not necessar= ily match all the requirements of every real deployment one may envision). >=20 > For example,=20 > Mode A can be compatible with the CDNI iterative request redirection mode= (as well as with what we call the semi-recursive mode in draft http://tool= s.ietf.org/html/draft-lelouedec-cdni-request-routing-00) : > In normal situations where dCDN can handle the request, > The uCDN uses the Footprint&Cap information (advertised by dCDN) to selec= t a dCDN > The uCDN uses the information provided by this dCDN via the CDNI Request = Routing/Redirection interface (especially the distinguished CDN-domain to u= se) to redirect the client request to the dCDN. > Then the client request (which has been redirected to the request routing= system of the dCDN) has to redirect afterwards to one delivery node of the= dCDN. > In this sub-mode, there are indeed 2 RTTs (user-->uCDN, uCDN-->user, user= -->dCDN, dCDN-->user). >=20 > But Mode B can also be compatible with what we call the CDNI full-recursi= ve request redirection mode in draft http://tools.ietf.org/html/draft-lelou= edec-cdni-request-routing-00 : > In normal situations where dCDN can handle the request, > The uCDN uses the Footprint&Cap information (advertised by dCDN) to selec= t a dCDN > The uCDN uses the information provided by this dCDN via the CDNI Request = Routing/Redirection interface to redirect the client request to the dCDN.=20 > And in this case the information provided by the dCDN via this CDNI Reque= st Routing/Redirection interface points in fact directly to a delivery node= within the dCDN. > (Or one could maybe also even imagine specific cases where all the delive= ry nodes of the dCDN have the same IP anycast address, etc. (?)) > Anyway the client request is redirected here directly to a delivery node = of the dCDN. > In this case, there is only 1 RTT with Mode A (user-->uCDN, uCDN-->user). >=20 > Yannick Le Lou=E9dec. >=20 >=20 > -----Message d'origine----- > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de F= rancois Le Faucheur (flefauch) > Envoy=E9 : mercredi 25 juillet 2012 14:36 > =C0 : BERTRAND Gilles RD-CORE > Cc : cdni@ietf.org > Objet : Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.tx= t >=20 > All, >=20 > To help the discussion, we may need to distinguish three (main) modes: >=20 > *A* the uCDN uses the Footprint&Cap information (advertised by dCDN) to s= elect a dCDN. The uCDN redirects to the selected dCDN and considers that he= is done with request routing. >=20 > *B* the uCDN uses the Footprint&Cap information (advertised by dCDN) to s= elect a dCDN candidate. The uCDN queries the dCDN before redirecting.=20 > Querying dCDN optionally allows the dCDN to provide to uCDN the final red= irection information so the the enduser experiences a single redirect. > Querying dCDN optionally allows the uCDN to pick an alternate dCDN if the= initially selected dCDN cannot handle the request. >=20 > *C* the uCDN queries multiple dCDNs on a per-request basis and selects dC= DN based on their responses. In other words, the Footprint&Cap advertisemen= t is performed via on-demand per-request queries.=20 >=20 >=20 > I think: > * Scott pointed out that fundamentatly both *A* and *B* have to deal wit= h (typically transient) situations where uCDN thinks dCDN can take a reques= t and dCDN actually cannot handle it. And pointed out that with *A* the tra= nsient period is dictated by the Footprint&Cap advertisement "update speed"= while with *B* it is not. > * Allan was saying *A* is all he needs and *B* is extra complexity that = he doesn't need. > * Gilles and lelouedec-cdni-request-routing were saying *C* is bad.=20 >=20 > My impression is that there is violent agreement that *A* is to be suppor= ted. I think Allan and Gilles message indicate so. I personally support tha= t. I think many people have been discussing that approach. If someone feels= this is NOT to be supported by CDNI, do let us know.=20 >=20 > I think Gilles message below is primarily arguing against *C*. I personal= ly agree that this need not be supported in our initial deliverables. Are t= here people arguing this approach is to be supported in the initial deliver= ables?=20 >=20 > Regarding *B*, I personally see it as quite useful and worth supporting i= n Phase 1 (possibly as an option).=20 > Regarding Allan's points: > * I agree there is some "scalability" argument (i.e. state+wait-for-dCDN= -response) but it amounts to a web-services call out per request and buys y= ou reliability of request routing, so I see that as a trade-off that some C= DNs should be able to exercise.=20 >=20 > * I don't buy the latency argument because you end up with 2 RTTs in bot= h *A* and *B* (in normal situations where dCDN can handle the request) (i.e= . user-->uCDN, uCDN-->user, user-->dCDN, dCDN-->user versus user-->uCDN, uC= DN-->dCDN, dCDN-->uCDN, uCDN-->user) and in the transient cases where dCDN = cannot handle the request *B* can do as well as *A* (drop the request) or h= as the option to differently i.e. re-redirect at the cost of an extra RTT.= =20 > * I don't buy the "loop free mechanism" argument. In *B*, it is easy to = implement a loop detection and even loop prevention (if you want). In *A*, = you have no loop prevention (other than the inherent HTTP/DNS max redirect/= max CNAMEs) Other opinions on *B* are sought. >=20 >=20 > Cheers >=20 > Francois >=20 >=20 > On 25 Jul 2012, at 13:39, wrote: >=20 >> Hi everyone, >>=20 >> I fully agree with Allan's comments. Putting aside the vocabulary ('recu= rsive model' etc), Allan's comment are consistent with the messages that ht= tp://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 tries to c= onvey. >>=20 >> " o Regarding the former process, i.e. related to the "ability" >> ("enables a Request Routing function in an upstream CDN to query a >> Request Routing function in a downstream CDN to determine if the >> downstream CDN is able (...) to accept the delegated content >> request"), a routing protocol is used to achieve such a process, >> called routing process, in many other technologies and networks >> (IP, ATM, etc.). In all these technologies, it is the downstream >> entity that provides routing information to the upstream entity. >> The same approach should be applied to CDN interconnection. The >> reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2, >> dCDN 3, and then it selects one of them based on their responses") >> would suffer from latency, signaling overhead and/or lack of >> reactivity to events that impact the ability of the downstream >> CDNs to accept delegated content requests." >>=20 >> Best regards, >> -- >> Gilles >>=20 >>=20 >> -----Message d'origine----- >> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part=20 >> de GUILLOU, Allan Envoy=E9 : mercredi 25 juillet 2012 12:23 =C0 : Scott= =20 >> Wainner; cdni@ietf.org Objet : Re: [CDNi] TR: I-D Action:=20 >> draft-lelouedec-cdni-request-routing-00.txt >>=20 >> Hi, >>=20 >> With a "recusive model" as you ask if I understand, you expect the dCDN = to send like an "ack" for each request, and if not the uCDN will try to fin= d the second best dCDN and do the same thing. >>=20 >> I think that this model may add complexity and may cause some scalabilit= y problem. You will have to implement timers between request and ack, retra= nsmission mechanism to make sure that request has not been lost, loop free = mechanism, And all this may add latency on all requests and performances pr= oblems. >>=20 >> In the iterative model, if the dCDN is not able to handle the request, t= his request will be lost. It is the same thing in IP network today we do no= t ask the routing protocol to change when there is saturation somewhere. It= is the responsibility of each ISP to choose another route to join this des= tination if he want to keep a good quality of service. If a dCDN is overloa= ded, it will stop announcing part of its footprint or uCDN may apply some p= olicy to force choosing another dCDN. >>=20 >> It is right that this second model may not in case of dCDN saturation ha= ve the best reactivity, but it is exactly the same thing on the internet to= day. We can imagine that a poor dCDN which have saturation will be "black l= isted" by all the uCDN and the regulation will be done like this. >> I think recursive model will add complexity all the time for a gain witc= h is not in my opinion so important and that will not be seen so often. >>=20 >> Allan >>=20 >>> -----Message d'origine----- >>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part=20 >>> de Scott Wainner Envoy=E9 : lundi 16 juillet 2012 14:23 =C0 : >>> cdni@ietf.org Objet : Re: [CDNi] TR: I-D Action:=20 >>> draft-lelouedec-cdni-request-routing- >>> 00.txt >>>=20 >>> On 7/10/12 11:39 AM, Brandenburg, R. (Ray) van wrote: >>>> Hi Yannick, >>>>=20 >>>> We seem to be misunderstanding each other. Maybe this will help=20 >>>> clarify >>> my point: >>>>=20 >>>>> Let me try to fully understand your point: >>>>> Are you really meaning that in this case the dCDN has in reality >>> absolutely no obligation with regards to the uCDN? >>>>> Are you really meaning that in this case the dCDN decides alone, in >>> real time, and for each content request, whether it denies or accepts=20 >>> to ensure delivery? >>>> What I mean is that I would like to have a RR Interface at least=20 >>>> support >>> a model where for every content request the uCDN asks the dCDN=20 >>> whether it wants to deliver that particular content item (I believe=20 >>> you call this a PULL approach). And I would like to allow the dCDN to b= e able to say 'No' >>> on this request (whether it is for purposes or failure, overload, or=20 >>> any other reason). >>>>=20 >>>>> Are you really meaning that in this case the dCDN decides alone, in >>> real time, and for each content request, whether it denies or accepts=20 >>> to ensure delivery, and this even if the dCDN has the capability to=20 >>> deliver the content? >>>> Yes. >>> I think we have to delineate between the iterative and recursive model. >>>=20 >>> The recursive model assumes that the client request to the uCDN will=20 >>> be recursive and the CDN-I RR interface will be used to provide an=20 >>> answer for each client request. The choice to initiate the recursion=20 >>> would be determined by the footprint / capabilities. The ability of=20 >>> the dCDN to execute the specific request would provide immediate=20 >>> feedback to the uCDN. A dCDN that continues to advertise the=20 >>> footprint / capability, but frequently or continually rejects the=20 >>> request via CDN-I RR would be a poor candidate. The opportunity now=20 >>> arises where the uCDN may elect to choose an alternate dCDN because=20 >>> its preferred dCDN (according to footprint / capabilities) is 'under-pe= rforming'. >>>=20 >>> The iterative model, the uCDN blindly redirects the client to the=20 >>> dCDN based on the footprint / capabilities. What the dCDN does with=20 >>> the request is somewhat transparent to the uCDN. With the exception=20 >>> of the CDN-I logging, the uCDN assumes the dCDN is properly handling=20 >>> the requests that were delegated to the dCDN. If you are trying to=20 >>> 'tighten' up the case of blind rejections, then the frequency of the=20 >>> footprint / capabilities advertisements would have to be accelerated. >>> For the case where the dCDN repeatedly sees requests from the uCDN=20 >>> that the dCDN can't handle, it should retract its footprint /=20 >>> capabilities advertisement. Failing to do so would continually=20 >>> black-hole routing requests which would be indicated in the logging inf= ormation. >>>=20 >>> Either way, you need a feedback loop to avoid dumping routing requests. >>>=20 >>> With any feedback loop (recursive routing request or footprint /=20 >>> capabilities advertisement), you have to be careful about rapid=20 >>> oscillations and dampening the responses. >>>=20 >>> Scott >>>>=20 >>>>> Are you really meaning that in this case the dCDN may possibly=20 >>>>> response >>> negatively to all requests for content request redirection submitted=20 >>> by the uCDN over the CDNI request routing interface? (i.e. that=20 >>> possibly the uCDN will never be allowed/invited to redirect a content=20 >>> request to the >>> dCDN?) >>>>=20 >>>> Yes. Any negative effect this may have on the business relationship >>> between uCDN and dCDN should be handled on the business level. >>>>=20 >>>> Ray >>>>=20 >>>>=20 >>>> On Jul 10, 2012, at 4:33 PM, >>>> wrote: >>>>=20 >>>>> Hi Ray, >>>>>=20 >>>>>=20 >>>>> 1) Ray, quoting your mail: "The current drafts seems to assume some >>> particular type of contractual agreement between CDNs that might not=20 >>> always be the case." >>>>>=20 >>>>> Please quote the draft. >>>>> Please let us know exactly to which sentence(s) of the draft you=20 >>>>> are >>> referring to. >>>>> Otherwise it is hard to discuss and comment on your email. >>>>>=20 >>>>>=20 >>>>> 2) Ray, Quoting your mail: "If a dCDN does not live up to its >>> contractual agreement, this should be something that is handled on a=20 >>> business level, not on a protocol level." >>>>>=20 >>>>> Maybe there is a deep misunderstanding. >>>>> So I will try to be clear again. >>>>> We do not propose the CDNI routing interface to be used by the dCDN=20 >>>>> to >>> send a message saying "Sorry, but I decide unilaterally to refuse=20 >>> this content request". >>>>> We do not propose the CDNI routing interface to be used to handle=20 >>>>> any >>> aspect relating to a dCDN deciding unilaterally to stop living up to=20 >>> its contractual agreement. >>>>>=20 >>>>> Please let us know where you saw such an idea in this IETF draft=20 >>>>> "CDNI >>> request routing". >>>>>=20 >>>>> The only role of the CDNI routing interface is to be used to=20 >>>>> advertise >>> CDNI routing information from the downstream CDN to the upstream CDN. >>>>> And this is the description given in this IETF draft. >>>>>=20 >>>>>=20 >>>>> 3) Ray, quoting your mail: "one example of a contractual agreement >>> between two CDNs is one in which the uCDN and dCDN have agreed that=20 >>> the dCDN will deliver some content on behalf of a uCDN, but decide on=20 >>> a per- request basis whether it wants to do so (and is for example=20 >>> paid per request). In these cases, the dCDN needs to have the ability=20 >>> to deny delivery on a per-request basis." >>>>>=20 >>>>> Let me try to fully understand your point: >>>>> Are you really meaning that in this case the dCDN has in reality >>> absolutely no obligation with regards to the uCDN? >>>>> Are you really meaning that in this case the dCDN decides alone, in >>> real time, and for each content request, whether it denies or accepts=20 >>> to ensure delivery? >>>>> Are you really meaning that in this case the dCDN decides alone, in >>> real time, and for each content request, whether it denies or accepts=20 >>> to ensure delivery, and this even if the dCDN has the capability to=20 >>> deliver the content? >>>>> Are you really meaning that in this case the dCDN may possibly=20 >>>>> response >>> negatively to all requests for content request redirection submitted=20 >>> by the uCDN over the CDNI request routing interface? (i.e. that=20 >>> possibly the uCDN will never be allowed/invited to redirect a content=20 >>> request to the >>> dCDN?) >>>>>=20 >>>>>=20 >>>>> 4) Ray, quoting your mail: "Every routing protocol defines the=20 >>>>> expected >>> behavior of interconnected elements/networks on a technical level,=20 >>> not on a business level." >>>>>=20 >>>>> Again, this is not what I have written, and this is not the idea we >>> want to share. >>>>> I wrote "Every routing protocol has been defined (or at least >>> configured) so far by considering the expected behavior of the=20 >>> interconnected elements/networks." >>>>> That's all. >>>>> I can rephrase this sentence the following way: "we must know what=20 >>>>> we >>> expect to do with a protocol to design it correctly." >>>>> And IHMO this is an evidence; I don't know any other way to proceed. >>>>>=20 >>>>> Besides, let us consider BGP (which is by the way an option=20 >>>>> proposed by >>> some IETF members to implement this CDNI routing interface). >>>>> In IP networks, BGP configurations in IP routers are defined as per=20 >>>>> the >>> business relationships (valley free policy, etc.). >>>>> Of course the business relationships determine the BGP configurations= . >>>>> And of course BGP has been designed so as to allow to configure IP >>> interconnections adequately depending on the corresponding=20 >>> Customer/provider, sibling and peering contractual agreements. >>>>> But this does not mean that BGP "defines the expected behavior of >>> interconnected elements/networks... on a business level." >>>>> Even if we can indeed infer quite accurately the business=20 >>>>> relationships >>> between ISP from the BGP configuration of their IP routers (see CAIDA=20 >>> project), but this is another story. >>>>>=20 >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Yannick Le Lou=E9dec. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >>>>> Envoy=E9 : mardi 10 juillet 2012 15:13 =C0 : LE LOUEDEC Yannick=20 >>>>> RD-CORE; Ben Niven-Jenkins Cc : Pilarski Marcin - Korpo TP;=20 >>>>> cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR: I-D >>>>> Action: draft-lelouedec-cdni-request- >>> routing-00.txt >>>>>=20 >>>>> Hi Yannick, >>>>>=20 >>>>> See comments inline. >>>>>=20 >>>>> In general: IMO the CDNI interfaces should be abstracted from any=20 >>>>> kind >>> of contractual/business agreement that might or might not exist=20 >>> between a dCDN and uCDN. The current drafts seems to assume some=20 >>> particular type of contractual agreement between CDNs that might not al= ways be the case. >>>>>=20 >>>>> Ray >>>>>=20 >>>>> -----Original Message----- >>>>> From: yannick.lelouedec@orange.com >>> [mailto:yannick.lelouedec@orange.com] >>>>> Sent: dinsdag 10 juli 2012 12:01 >>>>> To: Brandenburg, R. (Ray) van; Ben Niven-Jenkins >>>>> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE >>>>> Subject: RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- >>> routing-00.txt >>>>>=20 >>>>> Hi Ray, all, >>>>>=20 >>>>>=20 >>>>> 1) Ray, Quoting your mail: "I don't see why the CDNI Request=20 >>>>> Routing >>> interface should state that a dCDN MUST deliver the content if it has=20 >>> indicated its ability to do so earlier in either a contractual=20 >>> agreement or in the capability interface." >>>>>=20 >>>>> This is not what we have written. >>>>> Let me try to rephrase simply. >>>>>=20 >>>>> A contractual agreement is a contractual agreement. >>>>> It put in writings the respective obligations of the uCDN and of=20 >>>>> the >>> dCDN. >>>>> The uCDN may redirect any content request to the dCDN as long as it=20 >>>>> is >>> in full conformance with the terms of this contractual agreement (the=20 >>> type of the content request is in full conformance, the maximum=20 >>> number of content requests per second is respected, etc.). >>>>> In this case the dCDN may not say "Sorry, but I decide unilaterally=20 >>>>> to >>> refuse this content request". >>>>>=20 >>>>> [RvB]: This is where we disagree. IMHO, the type of behavior you >>> describe (the dCDN not living up to its obligation) should not be=20 >>> enforced by the CDNI Interfaces. If a dCDN does not live up to its=20 >>> contractual agreement, this should be something that is handled on a=20 >>> business level, not on a protocol level. >>>>>=20 >>>>> Why? Because this is the deal, a contractual agreement is a=20 >>>>> contractual >>> agreement! >>>>> Yet the dCDN may say "I do apologize, but at this time I cannot=20 >>>>> handle >>> correctly a certain class of content requests specified in our=20 >>> contractual agreement" (for example the class of the HTTP content=20 >>> requests with token from French end users, because of overload=20 >>> situation, failure, etc.) This is the role of the CDNI routing=20 >>> interface to provide the uCDN with such information. >>>>>=20 >>>>> (And the dCDN may be given a penalty for example if this was agreed=20 >>>>> in >>> the terms of the contractual agreement.) >>>>>=20 >>>>>=20 >>>>> 2) Ray, Quoting your mail: "I understand that in most cases, the >>> contractual agreement might indeed impose this behavior on the dCDN" >>>>>=20 >>>>> Please provide the description of an example where this is not the >>> case. >>>>> Otherwise the IETF CDNI WG shall indeed consider this is ALWAYS the >>> case. >>>>>=20 >>>>> [RvB]: I can't remember ever seeing such a discussion on the WG list. >>> Anyway: one example of a contractual agreement between two CDNs is=20 >>> one in which the uCDN and dCDN have agreed that the dCDN will deliver=20 >>> some content on behalf of a uCDN, but decide on a per-request basis=20 >>> whether it wants to do so (and is for example paid per request). In=20 >>> these cases, the dCDN needs to have the ability to deny delivery on a p= er-request basis. >>>>>=20 >>>>> And this is an important point to be able to progress in the CDNI >>> interfaces' specification works. >>>>>=20 >>>>> If the contractual agreement does not define clearly the=20 >>>>> obligations of >>> the uCDN, it is impossible to dimension adequately the dCDN, neither=20 >>> to define correctly the CDNI contractual agreements between the dCDN=20 >>> and the dCDNs of this dCDN. >>>>> If the contractual agreement does not define clearly the=20 >>>>> obligations of >>> the dCDN, the dCDN may do what it wants... even to put in the trash=20 >>> can any content request it accepted to handle. >>>>>=20 >>>>> [RvB]: Exactly, this is something that needs to be discussed on a >>> business/contractual level and not on a technical level. That is way=20 >>> IMHO the CDNI Interfaces should not make ANY assumptions on what was=20 >>> agreed on a contractual level. >>>>>=20 >>>>> In both situations it is impossible to ensure any quality of=20 >>>>> experience >>> to the end user. >>>>>=20 >>>>>=20 >>>>> 3) Ray, Quoting your mail: "I don't think this type of behavior=20 >>>>> should >>> be imposed by the protocol we're developing here." >>>>>=20 >>>>> I do not sure I understand this sentence. >>>>> Every routing protocol has been defined (or at least configured) so=20 >>>>> far >>> by considering the expected behavior of the interconnected=20 >>> elements/networks. >>>>>=20 >>>>> [RvB]: Every routing protocol defines the expected behavior of >>> interconnected elements/networks on a technical level, not on a=20 >>> business level. Having a dCDN say 'I'm not willing to deliver this=20 >>> content' is perfectly fine from a technical perspective, although it=20 >>> could be problematic from a contractual perspective. >>>>>=20 >>>>> But maybe I will understand if you provide an example on the point >>>>> 2 >>> above. >>>>>=20 >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Yannick Le Lou=E9dec. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] >>>>> Envoy=E9 : mardi 10 juillet 2012 09:20 =C0 : Ben Niven-Jenkins; LE=20 >>>>> LOUEDEC Yannick RD-CORE Cc : Pilarski Marcin >>> - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE Objet : RE: [CDNi] TR:=20 >>> I-D >>> Action: draft-lelouedec-cdni-request-routing-00.txt >>>>>=20 >>>>> Hi Yannick, Ben, >>>>>=20 >>>>> I tend to agree with Ben here. When reading the draft, I got the >>> feeling that the draft seems to assume a lot about the relationship=20 >>> between the uCDN and dCDN. For example, I don't see why the CDNI=20 >>> Request Routing interface should state that a dCDN MUST deliver the=20 >>> content if it has indicated its ability to do so earlier in either a=20 >>> contractual agreement or in the capability interface. I understand=20 >>> that in most cases, the contractual agreement might indeed impose=20 >>> this behavior on the dCDN, but I don't think this type of behavior=20 >>> should be imposed by the protocol we're developing here. >>>>>=20 >>>>> It was always my assumption that the Request Routing Interface=20 >>>>> would at >>> least include the option of allowing the uCDN to query the dCDN for=20 >>> every content request whether the dCDN is willing to deliver that=20 >>> particular request. >>>>>=20 >>>>> I will send my full review of the draft later. >>>>>=20 >>>>> Ray >>>>>=20 >>>>> -----Original Message----- >>>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On=20 >>>>> Behalf Of >>> Ben Niven-Jenkins >>>>> Sent: dinsdag 10 juli 2012 7:38 >>>>> To: yannick.lelouedec@orange.com >>>>> Cc: Pilarski Marcin - Korpo TP; cdni@ietf.org; MARREC Anne RD-CORE >>>>> Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request- >>> routing-00.txt >>>>>=20 >>>>> Yannick, >>>>>=20 >>>>> Please see inline. >>>>>=20 >>>>> On 9 Jul 2012, at 20:05, wrote: >>>>>=20 >>>>>> Hi Ben, all, >>>>>>=20 >>>>>> Ben, quoting you mail below, "... the downstream CDN could reply=20 >>>>>> with either "here is how to redirect it"", >>>>>>=20 >>>>>> =3D> This is the role of the CDNI DRIS interface to provide the uCDN >>> with this information, and we target to make its specification public=20 >>> before Vancouver meeting so that everyone may read it before the=20 >>> meeting and get full knowledge of our proposal about this part of=20 >>> CDNI request routing. >>>>>>=20 >>>>>> Ben, quoting you mail below, "... or "no I can't/won't take that >>> content delivery right now", reasons may include the uCDN has=20 >>> requested a delivery of a protocol the dCDN does not support (possibly = in error). >>>>>>=20 >>>>>> =3D> This is the role of the CDNI logging interface to provide the=20 >>>>>> uCDN >>> with this information. >>>>> I agree this information should be logged but the Request Routing >>> interface (what you call the DRIS) also needs to be able to indicate=20 >>> a failure. >>>>>=20 >>>>> Otherwise the uCDN will 'blindly' redirect the the dCDN and the >>> delivery will fail leading to poor end user experience. >>>>>=20 >>>>>> Ben, quoting you mail below, "... or "no I can't/won't take that >>> content delivery right now", reasons may include ... the dCDN has no=20 >>> capacity right now etc." >>>>>>=20 >>>>>> =3D> This is the role of the CDNI routing interface to provide the=20 >>>>>> uCDN >>> with this information. >>>>> It is the role of the CDN capability/routing interface to advertise >>> broad capabilities etc not to give extremely fine grained real-time=20 >>> information on exactly the state of the dCDN. >>>>>=20 >>>>> Even if the capability/routing interface is real-time there are=20 >>>>> likely >>> to still be race conditions where we need the dCDN to be about to=20 >>> indicate a failure to accept a redirect through the request=20 >>> routing/DRIS interface >>>>>=20 >>>>>> So we may conclude we are in line basically, which is a good point. >>>>>> We just aimed at checking there was a common understanding on this >>> point. >>>>>>=20 >>>>>> The key point for us here is that we don't want this sentence >>> extracted from draft-ietf-cdni-problem-statement be interpreted as: ".= =20 >>> and the dCDN MUST accept the content request except when it has not=20 >>> the "ability" to do so." >>>>> Why not? IMO that is a valid scenario for some use cases. >>>>>=20 >>>>>> The fact that the dCDN is temporary unable to handle content=20 >>>>>> request >>> correctly is not a valid reason for the dCDN to be discharged of its=20 >>> obligations to the uCDN. >>>>>> The contract set between the uCDN and the dCDN remains valid=20 >>>>>> anyway, >>> and the obligations of the dCDN as well. >>>>> Correct, but that contract may not be the same for all uCDNs &=20 >>>>> dCDNs, >>> for example a uCDN may not have a guarantee that a dCDN can handle=20 >>> everything it is requested to handle but the contract may only be=20 >>> that the dCDN guarantees to handle up to a certain volume of traffic. >>>>>=20 >>>>>> The dCDN must announce to the uCDN that it is temporary unable, as >>> soon as possible, via the CDNI routing interface. >>>>>> And the uCDN must take this information into account in its CDN >>> selection process as soon as possible. >>>>>> Then if the uCDN decides to continue to redirect content requests=20 >>>>>> to >>> the dCDN, the uCDN MAY perfectly do it, but the uCDN knows these=20 >>> content requests will be lost. >>>>> What happens in the period between the dCDN being unable to handle >>> requests and the time it takes to advertise that to the uCDN and for=20 >>> the uCDN to process & incorporate that new knowledge? Are requests=20 >>> blindly forwarded to the dCDN which is unable to handle them leading=20 >>> to poor user experience? >>>>>=20 >>>>>> We could even imagine the situation where the uCDN continues to do=20 >>>>>> it >>> intentionally, because it has no better option and the content=20 >>> request will be lost anyway. For example in the case where neither=20 >>> the uCDN nor the other downstream CDNs of the uCDN cannot manage=20 >>> correctly the content request, the uCDN could do it intentionally so=20 >>> as to be able to clearly prove (with CDNI logging information) that=20 >>> it is the dCDN, not the uCDN, who is at fault. >>>>>> But, of course, if there are alternative backup options, the=20 >>>>>> normal >>> reaction of the uCDN is to stop as soon as possible to redirect=20 >>> content requests to the dCDN when the uCDN knows that the dCDN is=20 >>> unable to handle them correctly. >>>>>>=20 >>>>>> So, to be clear, we would prefer the sentence to be understood as: >>>>>> ". and the dCDN MUST accept the content request. >>>>>> And if it cannot handle correctly the redirected content request=20 >>>>>> it >>> receives, the content request is lost. >>>>> What about scenarios where the uCDN has a choice of dCDNs (e.g. two >>> national-wide CDNs offering services at different costs), the uCDN=20 >>> may elect to query both dCDNs and decide based on their responses=20 >>> which one to choose. If the dCDN is unable to satisfy the request the=20 >>> uCDN needs to know that so that it can fallback to the (more=20 >>> expensive in this example) dCDN. >>>>>=20 >>>>>> For example the dCDN generates a response to the content request=20 >>>>>> with >>> an error message, or no response at all. And in parallel the CDNI=20 >>> logging interface may be used to exchange logs corresponding to this pr= oblem. >>> Anyway the dCDN MAY NOT redirect that content request back towards=20 >>> the uCDN." >>>>>>=20 >>>>>> Exactly as in IP networks: IP packets are not sent back towards=20 >>>>>> the >>> origin by a downstream router under failure or congestion. >>>>> In a routed IP network, there is often a small packet loss while=20 >>>>> the >>> network re-converges, by enabling the dCDN to refuse a redirection at=20 >>> CDNI Request Routing/DRIS query time we can reduce that window by=20 >>> giving the uCDN the option to take an alternative action (e.g. try=20 >>> another dCDN) while the routing/capability information re-converges. >>>>>=20 >>>>>> In both networks (IP and CDN), the reason is the same. >>>>>> If the dCDN redirects back a content request to the uCDN, this >>> generates a loop. >>>>> Loop avoidance is a separate issue IMO to whether we should allow a >>> dCDN to be able to communicate "I am unable/unwilling to take that=20 >>> content delivery at this time". >>>>>=20 >>>>> Regards >>>>> Ben >>>>>=20 >>>>>> To manage this would introduce a very high complexity. >>>>>> And this would be just to try to save the content requests=20 >>>>>> redirected >>> by the uCDN to the dCDN in the timeslot between the time the dCDN=20 >>> gets down and the time the uCDN takes this failure into account in=20 >>> its CDN selection process. >>>>>> It is much better to try to reduce this timeslot as much as=20 >>>>>> possible, >>> with routing optimizations (we will propose as soon as possible). >>>>>> Rather than introducing additional complexities (to manage=20 >>>>>> redirection >>> to the uCDN) in the framework. >>>>>>=20 >>>>>>=20 >>>>>> By the way, as you know, the IESG has just approved today the=20 >>>>>> 'Content >>> Distribution Network Interconnection (CDNI) Problem Statement' draft=20 >>> as informational RFC. This is a good point. >>>>>> And, as you may see in the draft "CDNI request routing", we do not >>> propose to modify this problem statement draft. >>>>>> We want know to focus now on getting the specifications of all=20 >>>>>> CDNI >>> interfaces ready as soon as possible. >>>>>>=20 >>>>>> Best regards, >>>>>>=20 >>>>>> Yannick Le Lou=E9dec. >>>>>>=20 >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la=20 >>>>>> part de Ben Niven-Jenkins Envoy=E9 : lundi 9 juillet 2012 20:41 =C0 = : >>>>>> BERTRAND Gilles RD-CORE Cc : cdni@ietf.org; Pilarski Marcin -=20 >>>>>> Korpo TP; MARREC Anne RD-CORE Objet : Re: [CDNi] TR: I-D Action: >>>>>> draft-lelouedec-cdni-request-routing-00.txt >>>>>>=20 >>>>>> Colleagues, >>>>>>=20 >>>>>> I started reading draft-lelouedec-cdni-request-routing-00 and this >>> text caught my eye: >>>>>>=20 >>>>>> Quoting [I-D.ietf-cdni-problem-statement ], "The CDNI Request=20 >>>>>> Routing interface enables a Request Routing function in an=20 >>>>>> upstream CDN to query a Request Routing function in a downstream=20 >>>>>> CDN to determine if the downstream CDN is able (and willing) to=20 >>>>>> accept the delegated content request". >>>>>>=20 >>>>>> The "ability" and the "willingness" of the downstream CDN to=20 >>>>>> accept the delegated content request match two fully different=20 >>>>>> processes in CDN interconnection. And the description of both=20 >>>>>> these processes should be reviewed and clarified for the following = reasons: >>>>>>=20 >>>>>> o Regarding the former process, i.e. related to the "ability" >>>>>> ("enables a Request Routing function in an upstream CDN to=20 >>>>>> query >>> a >>>>>> Request Routing function in a downstream CDN to determine if the >>>>>> downstream CDN is able (...) to accept the delegated content >>>>>> request"), a routing protocol is used to achieve such a process, >>>>>> called routing process, in many other technologies and networks >>>>>> (IP, ATM, etc.). In all these technologies, it is the downstream >>>>>> entity that provides routing information to the upstream entity. >>>>>> The same approach should be applied to CDN interconnection. The >>>>>> reverse approach ("uCDN queries it downstream CDNs dCDN 1,=20 >>>>>> dCDN >>> 2, >>>>>> dCDN 3, and then it selects one of them based on their >>> responses") >>>>>> would suffer from latency, signaling overhead and/or lack of >>>>>> reactivity to events that impact the ability of the downstream >>>>>> CDNs to accept delegated content requests. >>>>>>=20 >>>>>> o Regarding the latter process, i.e. related to the "willingness" >>>>>> ("enables a Request Routing function in an upstream CDN to=20 >>>>>> query >>> a >>>>>> Request Routing function in a downstream CDN to determine if the >>>>>> downstream CDN (...) is willing (...)to accept the delegated >>>>>> content request"), it is to be noted that the relationship >>> between >>>>>> a uCDN and a dCDN is always in the frame of a contractual >>>>>> agreement between the administrative entity owning the uCDN, >>>>>> acting as the customer, and the administrative entity owning the >>>>>> dCDN, acting as the service provider. Therefore, consider a case >>>>>> where >>>>>>=20 >>>>>> * the uCDN has a content request to redirect which is in full >>>>>> conformance with the terms of this contractual agreement,=20 >>>>>> and >>>>>>=20 >>>>>> * the uCDN has selected this dCDN. >>>>>>=20 >>>>>> As the uCDN knows, thanks to the routing information exchanged >>> via >>>>>> the aforementioned routing process, that the dCDN is able to >>>>>> accept this content request, the uCDN MAY redirect the content >>>>>> request to the dCDN and the dCDN MUST accept the content request. >>>>>> Exchanging over the CDNI Request Routing interface information >>>>>> about the "willingness" of the dCDN to accept the content request >>>>>> is not relevant. >>>>>>=20 >>>>>> I think you might be over thinking what we wrote in the problem >>> statement. >>>>>>=20 >>>>>> What was in the problem statement was meant to convey that an=20 >>>>>> upstream >>> CDN could make a request to a downstream CDN to say "how do I=20 >>> redirect this request to you" and the downstream CDN could reply with=20 >>> either "her is how to redirect it", or "no I can't/won't take that=20 >>> content delivery right now", reasons may include the uCDN has=20 >>> requested a delivery of a protocol the dCDN does not support=20 >>> (possibly in error) or the dCDN has no capacity right now etc. >>>>>>=20 >>>>>> Ben >>>>>>=20 >>>>>> On 9 Jul 2012, at 18:00, wrote: >>>>>>=20 >>>>>>> Hi everyone, >>>>>>>=20 >>>>>>> We have just submitted the draft below. We are convinced that it=20 >>>>>>> will >>> help the WG to progress on the CDNI routing issues. >>>>>>>=20 >>>>>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-0 >>>>>>> 0 >>>>>>>=20 >>>>>>> Any feedback is very welcome. >>>>>>>=20 >>>>>>> Best regards, >>>>>>>=20 >>>>>>> Gilles >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Message d'origine----- >>>>>>> De : i-d-announce-bounces@ietf.org=20 >>>>>>> [mailto:i-d-announce-bounces@ietf.org] De la part de=20 >>>>>>> internet-drafts@ietf.org Envoy=E9 : lundi 9 juillet 2012 18:55 =C0 = : >>>>>>> i-d-announce@ietf.org Objet : I-D Action: >>>>>>> draft-lelouedec-cdni-request-routing-00.txt >>>>>>>=20 >>>>>>>=20 >>>>>>> A New Internet-Draft is available from the on-line=20 >>>>>>> Internet-Drafts >>> directories. >>>>>>>=20 >>>>>>>=20 >>>>>>> Title : CDNI Request Routing >>>>>>> Author(s) : Yannick Le Louedec >>>>>>> Anne Marrec >>>>>>> Gilles Bertrand >>>>>>> Marcin Pilarski >>>>>>> Filename : draft-lelouedec-cdni-request-routing-00.txt >>>>>>> Pages : 30 >>>>>>> Date : 2012-07-09 >>>>>>>=20 >>>>>>> Abstract: >>>>>>> The present document proposes to clarify the CDNI Request Routing=20 >>>>>>> interface introduced in [I-D.ietf-cdni-framework] and >>>>>>> [I-D.ietf-cdni- problem-statement], as well as related terminology. >>>>>>>=20 >>>>>>> In particular the present document proposes to split the CDNI=20 >>>>>>> Request Routing interface into two separate interfaces with=20 >>>>>>> clearer roles, named respectively CDNI Routing interface and=20 >>>>>>> CDNI Downstream Resource Identifier Signaling interface (CDNI DRIS = interface). >>>>>>>=20 >>>>>>> This part of the CDN interconnection framework the IETF has been=20 >>>>>>> referring to so far with the term "CDNI Request Routing" is just=20 >>>>>>> another routing, signaling and forwarding problem in a long=20 >>>>>>> series of the telecommunication history. For example, one can=20 >>>>>>> draw a direct analogy between the IP/MPLS-TE framework and the=20 >>>>>>> CDN interconnection framework. >>>>>>>=20 >>>>>>> In addition, this document recommends that the specification of=20 >>>>>>> ALL CDN interconnection interfaces in the scope of the CDNI IETF=20 >>>>>>> WG relies on the equivalent concept to IP prefix for CDN=20 >>>>>>> interconnection, named 'contentRequestScope'. This highly useful=20 >>>>>>> and powerful concept SHALL be used to simplify the specification=20 >>>>>>> of ALL CDN interconnection interfaces, as well as to ensure=20 >>>>>>> performance and scalability in CDN interconnection. >>>>>>>=20 >>>>>>> All these proposals can be smoothly integrated in the WG drafts,=20 >>>>>>> especially [I-D.ietf-cdni-framework] and=20 >>>>>>> [I-D.ietf-cdni-requirements], as they essentially propose >>>>>>> (useful) clarifications of the existing framework. >>>>>>>=20 >>>>>>>=20 >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-rou >>>>>>> ting >>>>>>>=20 >>>>>>> There's also a htmlized version available at: >>>>>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-0 >>>>>>> 0 >>>>>>>=20 >>>>>>>=20 >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> 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=20 >>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>>=20 >>>>>>> _________________________________________________________________ >>>>>>> ____ ____________________________________________________ >>>>>>>=20 >>>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>>> informations confidentielles ou privilegiees et ne doivent donc=20 >>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 >>>>>>> avez recu ce message par erreur, veuillez le signaler a=20 >>>>>>> l'expediteur et le detruire ainsi >>> que les pieces jointes. Les messages electroniques etant susceptibles=20 >>> d'alteration, France Telecom - Orange decline toute responsabilite si=20 >>> ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>=20 >>>>>>> This message and its attachments may contain confidential or=20 >>>>>>> privileged information that may be protected by law; they should=20 >>>>>>> not >>> be distributed, used or copied without authorisation. >>>>>>> If you have received this email in error, please notify the=20 >>>>>>> sender >>> and delete this message and its attachments. >>>>>>> As emails may be altered, France Telecom - Orange is not liable=20 >>>>>>> for >>> messages that have been modified, changed or falsified. >>>>>>> Thank you. >>>>>>>=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 >>>>>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>>>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le=20 >>>>>> detruire ainsi >>> que les pieces jointes. Les messages electroniques etant susceptibles=20 >>> d'alteration, France Telecom - Orange decline toute responsabilite si=20 >>> ce message a ete altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or=20 >>>>>> privileged information that may be protected by law; they should=20 >>>>>> not >>> be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the sender=20 >>>>>> and >>> delete this message and its attachments. >>>>>> As emails may be altered, France Telecom - Orange is not liable=20 >>>>>> for >>> messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>> _______________________________________________ >>>>> CDNi mailing list >>>>> CDNi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>> This e-mail and its contents are subject to the DISCLAIMER at >>> http://www.tno.nl/emaildisclaimer >>>>>=20 >>>>>=20 >>>>>=20 >>> _____________________________________________________________________ >>> _ ____ _______________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >>> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 >>> que les pieces jointes. Les messages electroniques etant susceptibles=20 >>> d'alteration, France Telecom - Orange decline toute responsabilite si=20 >>> ce message a ete altere, deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or=20 >>>>> privileged >>> information that may be protected by law; they should not be=20 >>> distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender=20 >>>>> and >>> delete this message and its attachments. >>>>> As emails may be altered, France Telecom - Orange is not liable for >>> messages that have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>>>=20 >>>>>=20 >>> _____________________________________________________________________ >>> _ ____ _______________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc >>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 >>>>> avez >>> recu ce message par erreur, veuillez le signaler >>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les >>> messages electroniques etant susceptibles d'alteration, >>>>> France Telecom - Orange decline toute responsabilite si ce message=20 >>>>> a >>> ete altere, deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or=20 >>>>> privileged >>> information that may be protected by law; >>>>> they should not be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender=20 >>>>> and >>> delete this message and its attachments. >>>>> As emails may be altered, France Telecom - Orange is not liable for >>> messages that have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >>=20 >> ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for mess= ages that have been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> 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 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 From yry@cs.yale.edu Mon Jul 30 14:05:20 2012 Return-Path: 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 0C2FF11E817A for ; Mon, 30 Jul 2012 14:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599] 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 PVQjPq6+eQWn for ; Mon, 30 Jul 2012 14:05:19 -0700 (PDT) Received: from vm-emlprdomr-05.its.yale.edu (vm-emlprdomr-05.its.yale.edu [130.132.50.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0A711E8155 for ; Mon, 30 Jul 2012 14:05:11 -0700 (PDT) Received: from Faculty-Supports-MacBook-Pro-2.local ([67.21.202.20]) (authenticated bits=0) by vm-emlprdomr-05.its.yale.edu (8.14.4/8.14.4) with ESMTP id q6UL4woX005266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Jul 2012 17:05:08 -0400 Message-ID: <5016F6FA.3070300@cs.yale.edu> Date: Tue, 31 Jul 2012 05:04:58 +0800 From: "Y. Richard Yang" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.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.71 on 130.132.50.146 Subject: [CDNi] Service Access/Anchor Point Based Footprint/Capability advertisement 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 21:05:20 -0000 Hi all, It was suggested that I post this draft to the broader general list to get feedback: http://www.ietf.org/internet-drafts/draft-yang-cdni-rr-foot-cap-00.txt The objective of introducing service access (or anchor) point (SAP) based advertisement is to address the following issues in (asynchronous) footrptint/capability advertisement: - allow advertisement to provide shortcut in the advertisement; - allow multiple paths to the same End User (IP) to be advertised and *used*; - allow flexible advertisements of different levels of quality of services to be advertised. The SAP approach can be considered as a flexible mechanism to encode both resource centric advertisement, end-user QoE/performance centric advertisement, or a combination. For example, service access points (e.g., DNS load balancer address, cluster VIP, http load balancer, each represents a cluster of resources) provide an encoding of resources. On the other hand, if only one single high level service access point is provided, and the QoE table indicates QoE/servicability, then it is an end-user centric encoding. The proposal does not specify specific QoE attributes (e.g., latency, bandwidth, frame loss rate at a given streaming rate) that will be advertised. There is a good on-going discussion on the semantics in the Footprint/Capability design team. This is, in particular, related with business models of CDNi. Jon/Stefano/Jan will provide a summary tomorrow. The discussion on what to advertise (or not to advertise) may have an impact on the proposed information base structure, but hopefully the information structure is robust and flexible to handle the outcome. Any feedback/comments, in particular shortcomings of the proposal, will be greatly appreciated, as I do not run a CDN and hence the thinking is totally second hand. Thanks! Richard From yannick.lelouedec@orange.com Mon Jul 30 15:41:15 2012 Return-Path: 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 54A8421F854F for ; Mon, 30 Jul 2012 15:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 PUvE8WFqBg6Y for ; Mon, 30 Jul 2012 15:41:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id EC43E21F8543 for ; Mon, 30 Jul 2012 15:41:13 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 520C732426A; Tue, 31 Jul 2012 00:41:13 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 2F149238048; Tue, 31 Jul 2012 00:41:13 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Tue, 31 Jul 2012 00:41:11 +0200 From: To: LE LOUEDEC Yannick RD-CORE , "Woundy, Richard" , "Francois Le Faucheur (flefauch@cisco.com)" , Scott Wainner , Ben Niven-Jenkins , "Brandenburg, R. (Ray) van" , "cdni@ietf.org" Thread-Topic: IETF #84 - CDNI request meeting Side meeting in a meeting room Thread-Index: Ac1uo4OZhZPtjVs+QCquqt4EElPFvA== Date: Mon, 30 Jul 2012 22:41:10 +0000 Message-ID: <22907_1343688073_50170D89_22907_1879_1_3e4097d5-3be2-4365-ba64-207cd66e1833@PEXCVZYH02.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Subject: [CDNi] IETF #84 - CDNI request meeting Side meeting in a meeting room 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 22:41:15 -0000 Dear all, This mail is to let you know that our side meeting about CDNI request routi= ng will be held in a meeting room at Hyatt. I mean it would not be in a restaurant. So you should diner before the meeting if you fear to be hungry. Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de y= annick.lelouedec@orange.com Envoy=E9=A0: jeudi 26 juillet 2012 07:54 =C0=A0: Woundy, Richard; Francois Le Faucheur (flefauch@cisco.com); Scott W= ainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.org Objet=A0: [CDNi] IETF #84 - CDNI Side meetings Dear all, In my mail below I mentioned (a bit too early) that the "footprint / capabi= lities advertisement" design team meeting would be held on Monday from 18:0= 0 to 20:00. Please note, if you have not done it yet, that the "footprint / capabilitie= s advertisement" design team meeting will be on Monday from 9:00-11:00 (Mee= ting point at the IETF registration desk). (See the mails from Jan Seedorf on the CDNI mailing list). Besides we do confirm the side meeting on CDNI request routing will be on = Monday 30 from 20:30 to 22:00 @ Hyatt Regency Hotel (Meeting point at the I= ETF registration desk). Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de y= annick.lelouedec@orange.com Envoy=E9=A0: mardi 24 juillet 2012 15:16 =C0=A0= : Woundy, Richard; Francois Le Faucheur (flefauch@cisco.com); Scott Wainner= ; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.org Objet=A0: [CD= Ni] IETF #84 - Side meeting on the CDNI request routing interface - Monday = 30 from 20:30 to 22:00 @ Hyatt Regency Hotel. Dear all, We propose to arrange the side meeting on CDNI request routing on Monday 30= from 20:30 to 22:00 at Hyatt Regency Hotel. The "footprint / capabilities advertisement" design team meeting will be he= ld just before, the same day, from 18:00 to 20:00. These slots seemed to be the ones that suit most people who wish to attend. Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: LE LOUEDEC Yannick RD-CORE Envoy=E9=A0: vendredi 20 juillet 2012 14:28 =C0=A0: 'Woundy, Richard'; Francois Le Faucheur (flefauch@cisco.com); Scott= Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.org Cc=A0= : STEPHAN Emile RD-CORE; BERTRAND Gilles RD-CORE Objet=A0: RE: [CDNi] IETF = #84 - Proposal for a side meeting on the CDNI request routing interface Dear all, The doodle for the side meeting in Vancouver on CDNI request routing is her= e: http://www.doodle.com/n552qchpurfcpckn Please fill it in as soon as possible if you intend to attend. Ideally we would like to arrange this meeting at Hyatt Regency Hotel, on Mo= nday evening, after the welcoming session. Best regards, Yannick Le Lou=E9dec. -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de y= annick.lelouedec@orange.com Envoy=E9=A0: lundi 16 juillet 2012 16:35 =C0=A0= : Scott Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; cdni@ietf.or= g Objet=A0: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI reque= st routing interface Dear all, We propose to arrange a side meeting on Sunday evening during IETF #84 (i.e= . on July 29th) on the CDNI request routing interface. The objective is to clear the discussion we had these last days via the IET= F CDNI mailing list, and to ease an efficient meeting on Tuesday 31. If everybody agrees that this is a good idea, we will set up a doodle. Best regards, Yannick Le Lou=E9dec, Orange OLNC. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, France Telecom - = Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, France Telecom - = Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, France Telecom - = Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From richard_woundy@cable.comcast.com Tue Jul 31 08:54:54 2012 Return-Path: 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 1427621F86B8 for ; Tue, 31 Jul 2012 08:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.064 X-Spam-Level: X-Spam-Status: No, score=-103.064 tagged_above=-999 required=5 tests=[AWL=2.167, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 AMX+XGL9lo65 for ; Tue, 31 Jul 2012 08:54:53 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 5843021F86AA for ; Tue, 31 Jul 2012 08:54:53 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.27383503; Tue, 31 Jul 2012 09:35:43 -0600 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.152]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0309.002; Tue, 31 Jul 2012 11:54:49 -0400 From: "Woundy, Richard" To: "cdni@ietf.org" Thread-Topic: Reminder about CDNI remote participation Thread-Index: Ac1vNNA1yp41Vjf4Sbu6Ea69AuPVvg== Date: Tue, 31 Jul 2012 15:54:48 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD138732FCD@PACDCEXMB01.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.165] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD138732FCDPACDCEXMB01cabl_" MIME-Version: 1.0 Subject: [CDNi] Reminder about CDNI remote participation 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 15:54:54 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD138732FCDPACDCEXMB01cabl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, We are using WebEx as our remote participation tool today for both of our s= essions. -- Rich --_000_1CA25301D2219F40B3AA37201F0EACD138732FCDPACDCEXMB01cabl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Folks,

    We are using WebEx as our remote participation tool today for both of our s= essions.

    <http://www.ietf.org/meeting/84/remote-participation.h= tml#webex>

    -- Rich
    --_000_1CA25301D2219F40B3AA37201F0EACD138732FCDPACDCEXMB01cabl_-- From vumip1@gmail.com Tue Jul 31 10:43:38 2012 Return-Path: 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 A60B021F8842 for ; Tue, 31 Jul 2012 10:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 pSrxsHSrLEgG for ; Tue, 31 Jul 2012 10:43:37 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 78D9121F883F for ; Tue, 31 Jul 2012 10:43:37 -0700 (PDT) Received: by weyu54 with SMTP id u54so5094083wey.31 for ; Tue, 31 Jul 2012 10:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ZPzdyXGmNVfLnjTOVd/cDv/9e0swGoDIEkj8r7kZgYc=; b=04GxTMEhEpNO1wKDEq7gjhjY+rQ0YDy2wSXRqndxZq/+vUHtQJ1uJsZJDB0RzAa1CB rDbX3BGKcsKjP9brM3cLmP9g1EgOTuKsXppjo4mIXLmCLtvja31BXgK/xOmmJOhwifnx r7o/4Gu6iKsyCmFCh/4fhKdPkxWDG8hujZaEiLwnuAbRbMjzpKOgZlYRXmXu19+wJ9K3 R5760pmb5dgFt24Pf/+u2QTdIuQdxMznP+ZIoSA1R0mJPVHsD/46HWYir8SAxk9844Vr rDkIQxup6QCa/PcveJC2wDyImcwcoJNdjY9oJ5qiDnUbUaV7Jn3CE9LNMxIT1Nljwoax Pz3w== MIME-Version: 1.0 Received: by 10.180.87.232 with SMTP id bb8mr4424232wib.0.1343756616477; Tue, 31 Jul 2012 10:43:36 -0700 (PDT) Received: by 10.227.13.79 with HTTP; Tue, 31 Jul 2012 10:43:36 -0700 (PDT) Date: Tue, 31 Jul 2012 13:43:36 -0400 Message-ID: From: Bhumip Khasnabish To: cdni@ietf.org Content-Type: multipart/alternative; boundary=f46d0444e991ca2d1304c623b7c8 Subject: [CDNi] Fwd: draft-jin-cdni-content-deduplication-optimization-02.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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 17:43:38 -0000 --f46d0444e991ca2d1304c623b7c8 Content-Type: text/plain; charset=ISO-8859-1 - *To*: i-d-announce at ietf.org - *Subject*: I-D Action: draft-jin-cdni-content-deduplication-optimization-02.txt - *From*: internet-drafts at ietf.org - *Date*: Sun, 29 Jul 2012 19:29:14 -0700 - *Delivered-to*: i-d-announce at ietfa.amsl.com - *List-archive*: - *List-help*: > - *List-id*: Internet Draft Announcements only - *List-post*: > - *List-subscribe*: , > - *List-unsubscribe*: , > - *Reply-to*: internet-drafts at ietf.org ------------------------------ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Content De-duplication for CDNi Optimization Author(s) : WeiYi Jin Mian Li Bhumip Khasnabish Filename : draft-jin-cdni-content-deduplication-optimization-02.txt Pages : 17 Date : 2012-07-29 Abstract: Recent explosive growth of content delivery/distribution networks (CDNs) and their interconnection are causing unintended repetition of content storage in the same dCDN. This can be avoided by using a suitable de-duplication mechanism. This document explores the scenarios which create the problems, and then discusses the approaches to eliminate the duplicated transmission of the same content from uCDN(s) to dCDN in CDNi networks. To implement the optimization, some enhancements to the CDNi metadata model and interface are required. The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-jin-cdni-content-deduplication-optimization There's also a htmlized version available at:http://tools.ietf.org/html/draft-jin-cdni-content-deduplication-optimization-02 A diff from previous version is available at:http://tools.ietf.org/rfcdiff?url2=draft-jin-cdni-content-deduplication-optimization-02 Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/ --f46d0444e991ca2d1304c623b7c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 
    A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.


	Title           : Content De-duplication for CDNi Optimization
	Author(s)       : WeiYi Jin
                          Mian Li
                          Bhumip Khasnabish
	Filename        : draft-jin-cdni-content-deduplication-optimization-02.txt
	Pages           : 17
	Date            : 2012-07-29

Abstract:
   Recent explosive growth of content delivery/distribution networks
   (CDNs) and their interconnection are causing unintended repetition of
   content storage in the same dCDN.  This can be avoided by using a
   suitable de-duplication mechanism.  This document explores the
   scenarios which create the problems, and then discusses the
   approaches to eliminate the duplicated transmission of the same
   content from uCDN(s) to dCDN in CDNi networks.  To implement the
   optimization, some enhancements to the CDNi metadata model and
   interface are required.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft=
-jin-cdni-content-deduplication-optimization

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-jin-cdni=
-content-deduplication-optimization-02

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?u=
rl2=3Ddraft-jin-cdni-content-deduplication-optimization-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.=
ietf.org/internet-drafts/
    --f46d0444e991ca2d1304c623b7c8-- From vumip1@gmail.com Tue Jul 31 10:54:57 2012 Return-Path: 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 990C121F8876 for ; Tue, 31 Jul 2012 10:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 NgBZHDhFb-KS for ; Tue, 31 Jul 2012 10:54:53 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1C321F8872 for ; Tue, 31 Jul 2012 10:54:51 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so2460745wib.13 for ; Tue, 31 Jul 2012 10:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=yXamigupwykQ9ZwBMLoILn3kfZxE/Pspjq7OI/M1EJM=; b=cgZ0iqFvuNSQ5KInVkB0ZVBC9OboFcGbJ6zR8vzZKyk7C8fteCDafWIbxMuUtjst/6 ksx3m9yQyVhAILDmxXGMmMbIGLW7HPCAOEpHCROYXHubusWuzxFYe5UjZpGDkKEYwFpO 1c1cDaJNrcfCUc2GarQOATK9aTnQa03yqTguMy69CYXKhKNrveard8L0RxqqBkYJ0Umr XkXeFXTN78N+NdEgwsEU43JBrhqiiOe/9LB5/hcQoTEFO+7UPjyZi+mYtM25kxAd0hA1 MTgq3JeCI6H9hfuDFRqD8wVk6dD+S60Ffu+cpvu33hl+okK6tHPk0P6w7AWi/6wGYw6j ZICA== MIME-Version: 1.0 Received: by 10.180.109.166 with SMTP id ht6mr9017472wib.11.1343757291291; Tue, 31 Jul 2012 10:54:51 -0700 (PDT) Received: by 10.227.13.79 with HTTP; Tue, 31 Jul 2012 10:54:51 -0700 (PDT) Date: Tue, 31 Jul 2012 13:54:51 -0400 Message-ID: From: Bhumip Khasnabish To: cdni@ietf.org Content-Type: multipart/alternative; boundary=e89a8f2349130305ec04c623e093 Cc: ramki Krishnan , Ram Krishnan Subject: [CDNi] Fwd: Long Tail personalized content delivery over CDN Interconnections 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 17:54:57 -0000 --e89a8f2349130305ec04c623e093 Content-Type: text/plain; charset=ISO-8859-1 FYI.. looking for comments and suggestions on delivery of the most popular to long tail personalized content over CDNI. This document presents the issues and suggests solutions in delivering long tail personalized content in CDN Interconnection scenarios. Thanks a lot. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I-D Action: draft-krishnan-cdni-long-tail-00.txt ------------------------------ - *To*: i-d-announce at ietf.org - *Subject*: I-D Action: draft-krishnan-cdni-long-tail-00.txt - *From*: internet-drafts at ietf.org - *Date*: Mon, 30 Jul 2012 16:49:30 -0700 - *Delivered-to*: i-d-announce at ietfa.amsl.com - *List-archive*: - *List-help*: > - *List-id*: Internet Draft Announcements only - *List-post*: > - *List-subscribe*: , > - *List-unsubscribe*: , > - *Reply-to*: internet-drafts at ietf.org ------------------------------ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Long Tail personalized content delivery over CDN Interconnections Author(s) : Ram Krishnan Mian Li Bhumip Khasnabish Filename : draft-krishnan-cdni-long-tail-00.txt Pages : 7 Date : 2012-07-30 Abstract: The content desire of users is evolving from most popular to long tail personalized content. This document presents the issues and suggests solutions in delivering long tail personalized content in CDN Interconnection scenarios. The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-krishnan-cdni-long-tail There's also a htmlized version available at:http://tools.ietf.org/html/draft-krishnan-cdni-long-tail-00 Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/ --e89a8f2349130305ec04c623e093 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    =A0
    FYI.. looking for comments and suggestions on = delivery of
    the most popular to long tail personalized con= tent over CDNI.
    =A0
    This document presents the issues and suggests= solutions in delivering long tail
    personalized content i= n CDN Interconnection scenarios. Thanks a lot.

    ++++++++++++++++++++++++++++++++++++++++++++++++++++= +++++++++++++++++++++++++++++++++++++++++++

    I-D Action: draft-krishnan-cdni-long-tail-00.txt

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


	Title           : Long Tail personalized content delivery over CDN Interco=
nnections
	Author(s)       : Ram Krishnan
                          Mian Li
                          Bhumip Khasnabish
	Filename        : draft-krishnan-cdni-long-tail-00.txt
	Pages           : 7
	Date            : 2012-07-30

Abstract:
   The content desire of users is evolving from most popular to long
   tail personalized content. This document presents the issues and
   suggests solutions in delivering long tail personalized content in
   CDN Interconnection scenarios.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-k=
rishnan-cdni-long-tail

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-krishnan-c=
dni-long-tail-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
    --e89a8f2349130305ec04c623e093-- From zahariad@synelixis.com Tue Jul 31 11:00:32 2012 Return-Path: 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 9F93D21F851E for ; Tue, 31 Jul 2012 11:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 XEV90jenqkxW for ; Tue, 31 Jul 2012 11:00:29 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id D87ED21F85CD for ; Tue, 31 Jul 2012 11:00:28 -0700 (PDT) Received: (qmail 27365 invoked by uid 0); 31 Jul 2012 18:00:28 -0000 Received: from unknown (HELO box521.bluehost.com) (74.220.219.121) by oproxy8.bluehost.com with SMTP; 31 Jul 2012 18:00:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=synelixis.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From:Reply-To; bh=ZQEEeYTBobpjZYavtdq61SPgkKh1JeRq9BXFl2qob0U=; b=m7Cnk5ackLEXBIzbfntq+60ZA31A/u7cI2LBqEh4/nFb5I212aPgtS3GKIEwoSAJrk/BAxV3PyO4jwGN8Ocz9dmj1Ek8bxsf3VpdZvYiH08JkR2mDl9PAq9YZBRRTUx0; Received: from [94.66.50.238] (port=51786 helo=acer) by box521.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1SwGk7-0005Ny-2t; Tue, 31 Jul 2012 12:00:28 -0600 From: "Theodore Zahariadis" To: "'Bhumip Khasnabish'" , References: In-Reply-To: Date: Tue, 31 Jul 2012 21:00:23 +0300 Organization: Synelixis Solutions Ltd Message-ID: <005f01cd6f46$5ce667d0$16b33770$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0060_01CD6F5F.82339FD0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1vRAXW5atMmgQtQTiO8ZVo50aZxgAAMANA Content-Language: el X-Identified-User: {712:box521.bluehost.com:synelixi:synelixis.com} {sentby:smtp auth 94.66.50.238 authed with zahariad@synelixis.com} Subject: Re: [CDNi] Fwd: draft-jin-cdni-content-deduplication-optimization-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zahariad@synelixis.com List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 18:00:32 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0060_01CD6F5F.82339FD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Bhumip, Some ideas and considerations on the draft. We have done some work in the area of de-duplication of content (Please see Th. Zahariadis, E. Quacchio, "Fast content-aware delivery in overlay networks," IEEE COMSOC MMTC E-Letter, Vol.6, No.7, July 2011, pp. 44-47)) Actually, we believe that it is needed to define Unique IDs (UID) per content object/chunk in order to: a) Avoid extended data replications at the CDN level and minimize the load to find the correct object. b) Detect and retrieve very fast the content. This should be fast enough to allow even seamless real-time video streaming by retrieving video chunks c) Be backwards compatible with todays' URLs (in case the content/chunk is not found, you should be able to go to the original site). In order to meet the (a), UID should be always associated with the content object itself (e.g. encapsulated in the object) or be based on unique characteristics of the content object (e.g. a set of low level descriptors). However, (b), poses that this could be calculated once (or sometimes), but should not be calculated or generated each time the object is requested; instead it should be "carried" and "extracted" in most cases. On the other hand, due to backwards compatibility needs (c), we should not change the standard file format (e.g. we could not encapsulate UID or low level descriptor in the content object). One solution could be to create a wrapper that would encapsulate the UID whenever the content object enters the CDN and extracts that at the time that the content object leaves the CDN, but this would increase the complexity and processing time. Instead, we propose to use as UID a formal file name format. UID will be a string concatenation in the format: CM-CID-filename.ext where: . CM is a "Content Marker" . CID is a content signature, which could be a self-certifying identifier e.g. MD5 or SHA-1 based-hash function on the file's content or even a combination of searchable low level descriptors. , which guarantees an easy and fast detection that this name is a UID . the original filename, which is used for making UID easily recognized by humans and avoid complex self-certifying names. Whenever new content is published or stored at the CDN, the object filename could be renamed to a UID and the URL to a Content URL (CURL) with the following format: http://www. website.com/./CM-CID-filename.ext The CURL is a URI, which is designed to enable caching mechanisms and trigger CDN-related functionality (e.g. accessing the CDN overlay network and querying for locally or "nearby" cached content). It should also be emphasized that from the CURL, the original URL and the UID may be easily extracted, while on the other hand it is fully backwards compatible with existing browsers and no modifications are needed. In this way, we may seamlessly support any kind of data available in the Internet (text, images, various types of audio or video), while in case the content object is not cached in the CDN, we can always go back to the original source URL. Best regards, Theodore From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Bhumip Khasnabish Sent: Tuesday, July 31, 2012 8:44 PM To: cdni@ietf.org Subject: [CDNi] Fwd: draft-jin-cdni-content-deduplication-optimization-02.txt * To: i-d-announce at ietf.org * Subject: I-D Action: draft-jin-cdni-content-deduplication-optimization-02.txt * From: internet-drafts at ietf.org * Date: Sun, 29 Jul 2012 19:29:14 -0700 * Delivered-to: i-d-announce at ietfa.amsl.com * List-archive: * List-help: * List-id: Internet Draft Announcements only * List-post: * List-subscribe: , * List-unsubscribe: , * Reply-to: internet-drafts at ietf.org _____ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Content De-duplication for CDNi Optimization Author(s) : WeiYi Jin Mian Li Bhumip Khasnabish Filename : draft-jin-cdni-content-deduplication-optimization-02.txt Pages : 17 Date : 2012-07-29 Abstract: Recent explosive growth of content delivery/distribution networks (CDNs) and their interconnection are causing unintended repetition of content storage in the same dCDN. This can be avoided by using a suitable de-duplication mechanism. This document explores the scenarios which create the problems, and then discusses the approaches to eliminate the duplicated transmission of the same content from uCDN(s) to dCDN in CDNi networks. To implement the optimization, some enhancements to the CDNi metadata model and interface are required. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-jin-cdni-content-deduplication-optimi zation There's also a htmlized version available at: http://tools.ietf.org/html/draft-jin-cdni-content-deduplication-optimization -02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-jin-cdni-content-deduplication-opti mization-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ------=_NextPart_000_0060_01CD6F5F.82339FD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Dear Bhumip,

     

    Some ideas and considerations on the draft.

     

    We have done some work in the area of de-duplication of content = (Please see Th. Zahariadis, E. Quacchio, “Fast content-aware = delivery in overlay networks,” IEEE COMSOC MMTC E-Letter, Vol.6, = No.7, July 2011, pp. 44-47))

     

    Actually, we believe that it is needed to define Unique IDs (UID) per = content object/chunk in order to:

    a) Avoid extended data replications at the CDN level and minimize the = load to find the correct object.

    b) Detect and retrieve very fast the content. This should be fast = enough to allow even seamless real-time video streaming by retrieving = video chunks

    c) Be backwards compatible with todays’ URLs (in case the = content/chunk is not found, you should be able to go to the original = site).

     

    In order to meet the (a), UID should be always associated with the = content object itself (e.g. encapsulated in the object) or be based on = unique characteristics of the content object (e.g. a set of low level = descriptors). However, (b), poses that this could be calculated once (or = sometimes), but should not be calculated or generated each time the = object is requested; instead it should be “carried” and = “extracted” in most cases.  On the other hand, due to = backwards compatibility needs (c), we should not change the standard = file format (e.g. we could not encapsulate UID or low level descriptor = in the content object).

     

    One solution could be to create a wrapper that would encapsulate the = UID whenever the content object enters the CDN and extracts that at the = time that the content object leaves the CDN, but this would increase the = complexity and processing time.

     

    Instead, we propose to use as UID a formal file name format. UID will = be a string concatenation in the format:

     

    CM-CID-filename.ext

     

    where:

    • CM is a “Content Marker”

    • CID is a content signature, which could be a self-certifying = identifier e.g. MD5 or SHA-1 based-hash function on the file's content = or even a combination of searchable low level descriptors. , which = guarantees an easy and fast detection that this name is a = UID

    • the original filename, which is used for making UID easily = recognized by humans and avoid complex self-certifying = names.

     

    Whenever new content is published or stored at the CDN, the object = filename could be renamed to a UID and the URL to a Content URL (CURL) = with the

    following format:

     

    http://www. = website.com/…/CM-CID-filename.ext

     

    The CURL is a URI, which is designed to enable caching mechanisms and = trigger CDN-related functionality (e.g. accessing the CDN overlay = network and querying for locally or “nearby” cached = content). It should also be emphasized that from the CURL, the original = URL and the UID may be easily extracted, while on the other hand it is = fully backwards compatible with existing browsers and no modifications = are needed. In this way, we may seamlessly support any kind of data = available in the Internet (text, images, various types of audio or = video), while in case the content object is not cached in the CDN, we = can always go back to the original source URL.

     

    Best regards,

    Theodore

     

    From:= = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Bhumip Khasnabish
    Sent: Tuesday, July 31, 2012 8:44 = PM
    To: cdni@ietf.org
    Subject: [CDNi] Fwd: = draft-jin-cdni-content-deduplication-optimization-02.txt

     


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

            =
Title           : =
Content De-duplication for CDNi =
Optimization
          &nb=
sp; Author(s)       : WeiYi =
Jin
            =
            &=
nbsp;     Mian =
Li
            &=
nbsp;           &n=
bsp;     Bhumip =
Khasnabish
           =
; Filename        : =
draft-jin-cdni-content-deduplication-optimization-02.txt
    = 
            =
Pages           : =
17
            =
Date            : =
2012-07-29
     
    Abstract:
       Recent explosive growth of content =
delivery/distribution networks
       (CDNs) =
and their interconnection are causing unintended repetition =
of
       content storage in the same =
dCDN.  This can be avoided by using =
a
       suitable de-duplication =
mechanism.  This document explores =
the
       scenarios which create the =
problems, and then discusses the
       =
approaches to eliminate the duplicated transmission of the =
same
       content from uCDN(s) to dCDN in =
CDNi networks.  To implement the
       =
optimization, some enhancements to the CDNi metadata model =
and
       interface are =
required.
     
     
    The IETF datatracker status page for this draft =
is:
    https://datatracker.ietf.org/doc/draft-jin-cdni-conten=
t-deduplication-optimization
     
    There's also a htmlized version available =
at:
    http://tools.ietf.org/html/draft-jin-cdni-content-dedupli=
cation-optimization-02
     
    A diff from previous version is available at:
    http://tools.ietf.org/rfcdiff?url2=3Ddraft-jin-=
cdni-content-deduplication-optimization-02
    =
 
     
    Internet-Drafts are =
also available by anonymous FTP at:
    ftp://ftp.ietf.org/internet-=
drafts/
     
    ------=_NextPart_000_0060_01CD6F5F.82339FD0-- From haibin.song@huawei.com Tue Jul 31 17:22:05 2012 Return-Path: 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 06D9621F88C5 for ; Tue, 31 Jul 2012 17:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.093 X-Spam-Level: X-Spam-Status: No, score=-6.093 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, J_CHICKENPOX_35=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 gPgJLSQdJ4FT for ; Tue, 31 Jul 2012 17:22:04 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2943321F888F for ; Tue, 31 Jul 2012 17:22:04 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIG18393; Tue, 31 Jul 2012 20:22:03 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 31 Jul 2012 17:20:00 -0700 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 31 Jul 2012 17:19:59 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.243]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0323.003; Wed, 1 Aug 2012 08:19:54 +0800 From: Songhaibin To: "Francois Le Faucheur (flefauch)" Thread-Topic: [CDNi] New Version Notification for draft-song-cdni-slr-based-footprint-01.txt Thread-Index: AQHNauuJIhX7uHQIwEeA+T3442FnspdEHTGl Date: Wed, 1 Aug 2012 00:19:53 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "cdni@ietf.org" Subject: Re: [CDNi] New Version Notification for draft-song-cdni-slr-based-footprint-01.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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 00:22:05 -0000 I just lost my chance to present this draft with my bad English. It reserve= d my energy:) Someone asked me, why do not you call it SLA based footprint?= The answer is, the upstream CDN needs to sign SLA with each application fo= r the content distribution, but I do not know if the upstream CDN needs to = sign SLA with the downstream CDN for each application, probably not. In tha= t case, the upstream CDN has to translate the performance and other require= ments to the technical parameters and tells the downstream CDN. And the dow= nstream CDN just tells the upstream CDN its footprint which can satisfy the= se requirements. Besides that, SLA is out of scope for IETF. We do not talk in the document about the issue when some downstream CDNs ca= n cover the same area (while satisfies the application requirements). It is= reasonable to choose one with even better performance (needs a lot of work= ), or just choose the cheaper one(saves energe for this WG). BR, -Haibin ________________________________________ From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] on behalf of Songhaibin= [haibin.song@huawei.com] Sent: Thursday, July 26, 2012 12:55 PM To: Francois Le Faucheur (flefauch) Cc: cdni@ietf.org Subject: Re: [CDNi] New Version Notification for draft-song-cdni-slr= -based-footprint-01.txt OK. Thanks for the good suggestion. I notice there will be side meeting on = footprint and cap advertisement. I will try to join the discussion. -Haibin > -----Original Message----- > From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > Sent: Wednesday, July 25, 2012 3:53 PM > To: Songhaibin > Cc: cdni@ietf.org; Jan Seedorf; Jon Peterson (jon.peterson@neustar.biz); > Stefano Previdi (sprevidi) > Subject: Re: [CDNi] New Version Notification for > draft-song-cdni-slr-based-footprint-01.txt > > Hello Haibin, > > As per your request, you'll have a 5 min slot in Vancouver to introduce t= his notion > of service level requirements based footprint. > Moving forward, I strongly recommend you input your ideas directly into t= he > work of the "CDNI Footprint and Capabilities Advertisement" Design Team t= hat is > chartered with defining the semantics of the information that is to be ad= vertised. > > Thanks > > Francois > > On 16 Jul 2012, at 12:36, Songhaibin wrote: > > > Hi, > > > > We just submitted a draft about service level requirements based footpr= int. > This draft is mainly used to generate the discussion on this aspect and i= t is still on > a high level idea stage. We have not given deep thought on the details in= this > document. So any discussion and comments are welcome! > > > > http://www.ietf.org/internet-drafts/draft-song-cdni-slr-based-footprint= -01.txt > > > > BR, > > -Haibin > > > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Monday, July 16, 2012 6:31 PM > >> To: Songhaibin > >> Cc: zhangyunfei@chinamobile.com > >> Subject: New Version Notification for > draft-song-cdni-slr-based-footprint-01.txt > >> > >> > >> A new version of I-D, draft-song-cdni-slr-based-footprint-01.txt > >> has been successfully submitted by Haibin Song and posted to the > >> IETF repository. > >> > >> Filename: draft-song-cdni-slr-based-footprint > >> Revision: 01 > >> Title: A SLR (Service Level Requirements) based footprint= for CDNI > >> Creation date: 2012-07-16 > >> WG ID: Individual Submission > >> Number of pages: 7 > >> URL: > >> > http://www.ietf.org/internet-drafts/draft-song-cdni-slr-based-footprint-0= 1.txt > >> Status: > >> http://datatracker.ietf.org/doc/draft-song-cdni-slr-based-footprint > >> Htmlized: > >> http://tools.ietf.org/html/draft-song-cdni-slr-based-footprint-01 > >> Diff: > >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-song-cdni-slr-based-footpri= nt-01 > >> > >> Abstract: > >> Footprint advertisement is a very important step for CDN > >> interconnection and generates a lot of discussion. Actually, each > >> CDN can serve the whole world if its surrogates are publicly > >> reachable by IP addresses. But if a CDN does that, it can not > >> satisfy the requirements from the applications. So CDNs deliver > >> contents for applications, and the basic requirements should be from > >> the applications, but there is rare discussion on service level > >> requirements based footprint. This document is used to generate the > >> discussion on this aspect. > >> > >> > >> > >> > >> 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= From zhangyunfei@chinamobile.com Tue Jul 31 17:47:27 2012 Return-Path: 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 9D69B11E80F1 for ; Tue, 31 Jul 2012 17:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.926 X-Spam-Level: X-Spam-Status: No, score=-97.926 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, 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 Kg74tWChjzNg for ; Tue, 31 Jul 2012 17:47:26 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 067C211E809B for ; Tue, 31 Jul 2012 17:47:21 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 3B609E62E; Wed, 1 Aug 2012 08:47:21 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 12171E62A; Wed, 1 Aug 2012 08:47:21 +0800 (CST) Received: from zyf-PC ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012080108471753-1230 ; Wed, 1 Aug 2012 08:47:17 +0800 Date: Wed, 1 Aug 2012 08:47:10 +0800 From: zhangyunfei To: Songhaibin , "Francois Le Faucheur (flefauch)" References: , , X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012080108471006917955@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-08-01 08:47:19, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-08-01 08:47:20, Serialize complete at 2012-08-01 08:47:20 Content-Type: multipart/alternative; boundary="----=_001_NextPart656444263201_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19076.003 X-TM-AS-Result: No--36.366-7.0-31-10 X-imss-scan-details: No--36.366-7.0-31-10;No--36.366-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: "cdni@ietf.org" Subject: Re: [CDNi] New Version Notification for draft-song-cdni-slr-based-footprint-01.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 00:47:27 -0000 This is a multi-part message in MIME format. ------=_001_NextPart656444263201_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" RG9lcyB0aGlzIGludm9sdmVzIHJlcXVlc3QgcmVkaXJlY3Rpb24gaW50ZXJmYWNlIGludGVyYWN0 aW9ucz8gSSBtZWFuLCBtYXliZSB0aGUgcmVxdWVzdCByZWRpcmVjdGVkIGJ5IHVDRE4gY2FuIGZl dGNoIHRoZSBTTEEgaW5mb3JtYXRpb24gKGFmdGVyIHRyYW5zbGF0aW9uIHRvIHBhcmFtZXRlcnMp LiBJbiB0aGlzIHNlbnNlLCBpdCBzaG91bGQgYmUgdHJhbnNmZXJyZWQgaW4gdGhlIHJlcXVlc3Qg cm91dGluZyBpbnRlcmZhY2UuDQoNCkJSDQpZdW5mZWkNCg0KDQoNCg0Kemhhbmd5dW5mZWkNCg0K RnJvbTogU29uZ2hhaWJpbg0KRGF0ZTogMjAxMi0wOC0wMSAwODoxOQ0KVG86IEZyYW5jb2lzIExl IEZhdWNoZXVyIChmbGVmYXVjaCkNCkNDOiBjZG5pQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0NE TmldIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc29uZy1jZG5pLXNsci1iYXNl ZC1mb290cHJpbnQtMDEudHh0DQpJIGp1c3QgbG9zdCBteSBjaGFuY2UgdG8gcHJlc2VudCB0aGlz IGRyYWZ0IHdpdGggbXkgYmFkIEVuZ2xpc2guIEl0IHJlc2VydmVkIG15IGVuZXJneTopIFNvbWVv bmUgYXNrZWQgbWUsIHdoeSBkbyBub3QgeW91IGNhbGwgaXQgU0xBIGJhc2VkIGZvb3RwcmludD8g VGhlIGFuc3dlciBpcywgdGhlIHVwc3RyZWFtIENETiBuZWVkcyB0byBzaWduIFNMQSB3aXRoIGVh Y2ggYXBwbGljYXRpb24gZm9yIHRoZSBjb250ZW50IGRpc3RyaWJ1dGlvbiwgYnV0IEkgZG8gbm90 IGtub3cgaWYgdGhlIHVwc3RyZWFtIENETiBuZWVkcyB0byBzaWduIFNMQSB3aXRoIHRoZSBkb3du c3RyZWFtIENETiBmb3IgZWFjaCBhcHBsaWNhdGlvbiwgcHJvYmFibHkgbm90LiBJbiB0aGF0IGNh c2UsIHRoZSB1cHN0cmVhbSBDRE4gaGFzIHRvIHRyYW5zbGF0ZSB0aGUgcGVyZm9ybWFuY2UgYW5k IG90aGVyIHJlcXVpcmVtZW50cyB0byB0aGUgdGVjaG5pY2FsIHBhcmFtZXRlcnMgYW5kIHRlbGxz IHRoZSBkb3duc3RyZWFtIENETi4gQW5kIHRoZSBkb3duc3RyZWFtIENETiBqdXN0IHRlbGxzIHRo ZSB1cHN0cmVhbSBDRE4gaXRzIGZvb3RwcmludCB3aGljaCBjYW4gc2F0aXNmeSB0aGVzZSByZXF1 aXJlbWVudHMuIEJlc2lkZXMgdGhhdCwgICBTTEEgaXMgb3V0IG9mIHNjb3BlIGZvciBJRVRGLg0K DQpXZSBkbyBub3QgdGFsayBpbiB0aGUgZG9jdW1lbnQgYWJvdXQgdGhlIGlzc3VlIHdoZW4gc29t ZSBkb3duc3RyZWFtIENETnMgY2FuIGNvdmVyIHRoZSBzYW1lIGFyZWEgKHdoaWxlIHNhdGlzZmll cyB0aGUgYXBwbGljYXRpb24gcmVxdWlyZW1lbnRzKS4gSXQgaXMgcmVhc29uYWJsZSB0byBjaG9v c2Ugb25lIHdpdGggZXZlbiBiZXR0ZXIgcGVyZm9ybWFuY2UgKG5lZWRzIGEgbG90IG9mIHdvcmsp LCBvciBqdXN0IGNob29zZSB0aGUgY2hlYXBlciBvbmUoc2F2ZXMgZW5lcmdlIGZvciB0aGlzIFdH KS4NCg0KQlIsDQotSGFpYmluDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpGcm9tOiBjZG5pLWJvdW5jZXNAaWV0Zi5vcmcgW2NkbmktYm91bmNlc0BpZXRmLm9yZ10g b24gYmVoYWxmIG9mIFNvbmdoYWliaW4gW2hhaWJpbi5zb25nQGh1YXdlaS5jb21dDQpTZW50OiBU aHVyc2RheSwgSnVseSAyNiwgMjAxMiAxMjo1NSBQTQ0KVG86IEZyYW5jb2lzIExlIEZhdWNoZXVy IChmbGVmYXVjaCkNCkNjOiBjZG5pQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0NETmldIE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiAgICBmb3IgICAgIGRyYWZ0LXNvbmctY2RuaS1zbHItYmFzZWQt Zm9vdHByaW50LTAxLnR4dA0KDQpPSy4gVGhhbmtzIGZvciB0aGUgZ29vZCBzdWdnZXN0aW9uLiBJ IG5vdGljZSB0aGVyZSB3aWxsIGJlIHNpZGUgbWVldGluZyBvbiBmb290cHJpbnQgYW5kIGNhcCBh ZHZlcnRpc2VtZW50LiBJIHdpbGwgdHJ5IHRvIGpvaW4gdGhlIGRpc2N1c3Npb24uDQoNCi1IYWli aW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBGcmFuY29pcyBMZSBG YXVjaGV1ciAoZmxlZmF1Y2gpIFttYWlsdG86ZmxlZmF1Y2hAY2lzY28uY29tXQ0KPiBTZW50OiBX ZWRuZXNkYXksIEp1bHkgMjUsIDIwMTIgMzo1MyBQTQ0KPiBUbzogU29uZ2hhaWJpbg0KPiBDYzog Y2RuaUBpZXRmLm9yZzsgSmFuIFNlZWRvcmY7IEpvbiBQZXRlcnNvbiAoam9uLnBldGVyc29uQG5l dXN0YXIuYml6KTsNCj4gU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkNCj4gU3ViamVjdDogUmU6 IFtDRE5pXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+IGRyYWZ0LXNvbmctY2RuaS1z bHItYmFzZWQtZm9vdHByaW50LTAxLnR4dA0KPg0KPiBIZWxsbyBIYWliaW4sDQo+DQo+IEFzIHBl ciB5b3VyIHJlcXVlc3QsIHlvdSdsbCBoYXZlIGEgNSBtaW4gc2xvdCBpbiBWYW5jb3V2ZXIgdG8g aW50cm9kdWNlIHRoaXMgbm90aW9uDQo+IG9mIHNlcnZpY2UgbGV2ZWwgcmVxdWlyZW1lbnRzIGJh c2VkIGZvb3RwcmludC4NCj4gTW92aW5nIGZvcndhcmQsIEkgc3Ryb25nbHkgcmVjb21tZW5kIHlv dSBpbnB1dCB5b3VyIGlkZWFzIGRpcmVjdGx5IGludG8gdGhlDQo+IHdvcmsgb2YgdGhlICJDRE5J IEZvb3RwcmludCBhbmQgQ2FwYWJpbGl0aWVzIEFkdmVydGlzZW1lbnQiIERlc2lnbiBUZWFtIHRo YXQgaXMNCj4gY2hhcnRlcmVkIHdpdGggZGVmaW5pbmcgdGhlIHNlbWFudGljcyBvZiB0aGUgaW5m b3JtYXRpb24gdGhhdCBpcyB0byBiZSBhZHZlcnRpc2VkLg0KPg0KPiBUaGFua3MNCj4NCj4gRnJh bmNvaXMNCj4NCj4gT24gMTYgSnVsIDIwMTIsIGF0IDEyOjM2LCBTb25naGFpYmluIHdyb3RlOg0K Pg0KPiA+IEhpLA0KPiA+DQo+ID4gV2UganVzdCBzdWJtaXR0ZWQgYSBkcmFmdCBhYm91dCBzZXJ2 aWNlIGxldmVsIHJlcXVpcmVtZW50cyBiYXNlZCBmb290cHJpbnQuDQo+IFRoaXMgZHJhZnQgaXMg bWFpbmx5IHVzZWQgdG8gZ2VuZXJhdGUgdGhlIGRpc2N1c3Npb24gb24gdGhpcyBhc3BlY3QgYW5k IGl0IGlzIHN0aWxsIG9uDQo+IGEgaGlnaCBsZXZlbCBpZGVhIHN0YWdlLiBXZSBoYXZlIG5vdCBn aXZlbiBkZWVwIHRob3VnaHQgb24gdGhlIGRldGFpbHMgaW4gdGhpcw0KPiBkb2N1bWVudC4gU28g YW55IGRpc2N1c3Npb24gYW5kIGNvbW1lbnRzIGFyZSB3ZWxjb21lIQ0KPiA+DQo+ID4gaHR0cDov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc29uZy1jZG5pLXNsci1iYXNlZC1m b290cHJpbnQtMDEudHh0DQo+ID4NCj4gPiBCUiwNCj4gPiAtSGFpYmluDQo+ID4NCj4gPj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiA+PiBTZW50OiBNb25kYXks IEp1bHkgMTYsIDIwMTIgNjozMSBQTQ0KPiA+PiBUbzogU29uZ2hhaWJpbg0KPiA+PiBDYzogemhh bmd5dW5mZWlAY2hpbmFtb2JpbGUuY29tDQo+ID4+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3INCj4gZHJhZnQtc29uZy1jZG5pLXNsci1iYXNlZC1mb290cHJpbnQtMDEudHh0 DQo+ID4+DQo+ID4+DQo+ID4+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zb25nLWNkbmkt c2xyLWJhc2VkLWZvb3RwcmludC0wMS50eHQNCj4gPj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBIYWliaW4gU29uZyBhbmQgcG9zdGVkIHRvIHRoZQ0KPiA+PiBJRVRGIHJlcG9z aXRvcnkuDQo+ID4+DQo+ID4+IEZpbGVuYW1lOiAgIGRyYWZ0LXNvbmctY2RuaS1zbHItYmFzZWQt Zm9vdHByaW50DQo+ID4+IFJldmlzaW9uOiAgIDAxDQo+ID4+IFRpdGxlOiAgICAgICAgICAgICAg QSBTTFIgKFNlcnZpY2UgTGV2ZWwgUmVxdWlyZW1lbnRzKSBiYXNlZCBmb290cHJpbnQgZm9yIENE TkkNCj4gPj4gQ3JlYXRpb24gZGF0ZTogICAgICAyMDEyLTA3LTE2DQo+ID4+IFdHIElEOiAgICAg ICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ID4+IE51bWJlciBvZiBwYWdlczogNw0K PiA+PiBVUkw6DQo+ID4+DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LXNvbmctY2RuaS1zbHItYmFzZWQtZm9vdHByaW50LTAxLnR4dA0KPiA+PiBTdGF0dXM6DQo+ ID4+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc29uZy1jZG5pLXNsci1i YXNlZC1mb290cHJpbnQNCj4gPj4gSHRtbGl6ZWQ6DQo+ID4+IGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXNvbmctY2RuaS1zbHItYmFzZWQtZm9vdHByaW50LTAxDQo+ID4+IERpZmY6 DQo+ID4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtc29uZy1jZG5p LXNsci1iYXNlZC1mb290cHJpbnQtMDENCj4gPj4NCj4gPj4gQWJzdHJhY3Q6DQo+ID4+ICAgRm9v dHByaW50IGFkdmVydGlzZW1lbnQgaXMgYSB2ZXJ5IGltcG9ydGFudCBzdGVwIGZvciBDRE4NCj4g Pj4gICBpbnRlcmNvbm5lY3Rpb24gYW5kIGdlbmVyYXRlcyBhIGxvdCBvZiBkaXNjdXNzaW9uLiAg QWN0dWFsbHksIGVhY2gNCj4gPj4gICBDRE4gY2FuIHNlcnZlIHRoZSB3aG9sZSB3b3JsZCBpZiBp dHMgc3Vycm9nYXRlcyBhcmUgcHVibGljbHkNCj4gPj4gICByZWFjaGFibGUgYnkgSVAgYWRkcmVz c2VzLiAgQnV0IGlmIGEgQ0ROIGRvZXMgdGhhdCwgaXQgY2FuIG5vdA0KPiA+PiAgIHNhdGlzZnkg dGhlIHJlcXVpcmVtZW50cyBmcm9tIHRoZSBhcHBsaWNhdGlvbnMuICBTbyBDRE5zIGRlbGl2ZXIN Cj4gPj4gICBjb250ZW50cyBmb3IgYXBwbGljYXRpb25zLCBhbmQgdGhlIGJhc2ljIHJlcXVpcmVt ZW50cyBzaG91bGQgYmUgZnJvbQ0KPiA+PiAgIHRoZSBhcHBsaWNhdGlvbnMsIGJ1dCB0aGVyZSBp cyByYXJlIGRpc2N1c3Npb24gb24gc2VydmljZSBsZXZlbA0KPiA+PiAgIHJlcXVpcmVtZW50cyBi YXNlZCBmb290cHJpbnQuICBUaGlzIGRvY3VtZW50IGlzIHVzZWQgdG8gZ2VuZXJhdGUgdGhlDQo+ ID4+ICAgZGlzY3Vzc2lvbiBvbiB0aGlzIGFzcGVjdC4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4N Cj4gPj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+IENETmkgbWFpbGluZyBsaXN0DQo+ID4gQ0ROaUBp ZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaQ0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0ROaSBt YWlsaW5nIGxpc3QNCkNETmlAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY2RuaQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkNETmkgbWFpbGluZyBsaXN0DQpDRE5pQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nkbmk= ------=_001_NextPart656444263201_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
    Does this involves request redirection interface interactions? I mean= ,=20 maybe the request redirected by uCDN can fetch the SLA information (after=20 translation to parameters). In this sense, it should be transferred i= n the=20 request routing interface.
     
    BR
    Yunfei
     
    zhangyunfei
     
    From: Songhaibin
    Date: 2012-08-01 08:19
    CC: cdni@ietf.org
    Subject: Re: [CDNi] New Version Notification for=20 draft-song-cdni-slr-based-footprint-01.txt
    I just lost my chance to present t= his draft with my bad English. It reser= ved my energy:) Someone asked me, why d= o not you call it SLA based footprint?&= nbsp;The answer is, the upstream CDN needs&n= bsp;to sign SLA with each application for&nb= sp;the content distribution, but I do not&nb= sp;know if the upstream CDN needs to si= gn SLA with the downstream CDN for each=  application, probably not. In that case,&nb= sp;the upstream CDN has to translate the&nbs= p;performance and other requirements to the = technical parameters and tells the downstream&nbs= p;CDN. And the downstream CDN just tells&nbs= p;the upstream CDN its footprint which can&n= bsp;satisfy these requirements. Besides that, &nb= sp; SLA is out of scope for IETF.
     
    We do not talk in the document abo= ut the issue when some downstream CDNs = can cover the same area (while satisfies&nbs= p;the application requirements). It is reasonable=  to choose one with even better perform= ance (needs a lot of work), or just&nbs= p;choose the cheaper one(saves energe for th= is WG).
     
    BR,
    -Haibin
    ________________________________________
    From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] on=  behalf of Songhaibin [haibin.song@huawei.com]
    Sent: Thursday, July 26, 2012 12:55 PM<= /DIV>
    To: Francois Le Faucheur (flefauch)
    Cc: cdni@ietf.org
    Subject: Re: [CDNi] New Version Notification=     for     draft-song-cdni-s= lr-based-footprint-01.txt
     
    OK. Thanks for the good suggestion. I&n= bsp;notice there will be side meeting on&nbs= p;footprint and cap advertisement. I will tr= y to join the discussion.
     
    -Haibin
     
    > -----Original Message-----
    > From: Francois Le Faucheur (flefauch)&n= bsp;[mailto:flefauch@cisco.com]
    > Sent: Wednesday, July 25, 2012 3:5= 3 PM
    > To: Songhaibin
    > Cc: cdni@ietf.org; Jan Seedorf; Jon&nbs= p;Peterson (jon.peterson@neustar.biz);
    > Stefano Previdi (sprevidi)
    > Subject: Re: [CDNi] New Version No= tification for
    > draft-song-cdni-slr-based-footprint-01.txt
    >
    > Hello Haibin,
    >
    > As per your request, you'll have&n= bsp;a 5 min slot in Vancouver to introd= uce this notion
    > of service level requirements based&nbs= p;footprint.
    > Moving forward, I strongly recommend&nb= sp;you input your ideas directly into the
    > work of the "CDNI Footprint and&nb= sp;Capabilities Advertisement" Design Team that i= s
    > chartered with defining the semantics&n= bsp;of the information that is to be ad= vertised.
    >
    > Thanks
    >
    > Francois
    >
    > On 16 Jul 2012, at 12:36, Son= ghaibin wrote:
    >
    > > Hi,
    > >
    > > We just submitted a draft&nbs= p;about service level requirements based footprin= t.
    > This draft is mainly used to = generate the discussion on this aspect and&n= bsp;it is still on
    > a high level idea stage. We h= ave not given deep thought on the detai= ls in this
    > document. So any discussion and co= mments are welcome!
    > >
    > > http://www.ietf.org/internet-drafts/draft-song-cd= ni-slr-based-footprint-01.txt
    > >
    > > BR,
    > > -Haibin
    > >
    > >> -----Original Message-----
    > >> From: internet-drafts@ietf.org [mai= lto:internet-drafts@ietf.org]
    > >> Sent: Monday, July 16, 20= 12 6:31 PM
    > >> To: Songhaibin
    > >> Cc: zhangyunfei@chinamobile.com
    > >> Subject: New Version Notificat= ion for
    > draft-song-cdni-slr-based-footprint-01.txt
    > >>
    > >>
    > >> A new version of I-D,&nbs= p;draft-song-cdni-slr-based-footprint-01.txt
    > >> has been successfully submitte= d by Haibin Song and posted to the
    > >> IETF repository.
    > >>
    > >> Filename:   draft-song-cdni-sl= r-based-footprint
    > >> Revision:   01
    > >> Title:      &nb= sp;       A SLR (Service = ;Level Requirements) based footprint for CDNI
    > >> Creation date:    &n= bsp; 2012-07-16
    > >> WG ID:     &nbs= p;        Individual Submissi= on
    > >> Number of pages: 7
    > >> URL:
    > >>
    > http://www.ietf.org/internet-drafts/draft-song-cdni-slr-bas= ed-footprint-01.txt
    > >> Status:
    > >> http://datatracker.ietf.org/doc/draft-song-cd= ni-slr-based-footprint
    > >> Htmlized:
    > >> http://tools.ietf.org/html/draft-song-cdni-sl= r-based-footprint-01
    > >> Diff:
    > >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-so= ng-cdni-slr-based-footprint-01
    > >>
    > >> Abstract:
    > >>   Footprint advertisement = ;is a very important step for CDN
    > >>   interconnection and gen= erates a lot of discussion.  Actually, = each
    > >>   CDN can serve the&= nbsp;whole world if its surrogates are publi= cly
    > >>   reachable by IP ad= dresses.  But if a CDN does that, = it can not
    > >>   satisfy the requirement= s from the applications.  So CDNs deliv= er
    > >>   contents for applicatio= ns, and the basic requirements should be&nbs= p;from
    > >>   the applications, but&n= bsp;there is rare discussion on service leve= l
    > >>   requirements based foot= print.  This document is used to genera= te the
    > >>   discussion on this = ;aspect.
    > >>
    > >>
    > >>
    > >>
    > >> 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
    ------=_001_NextPart656444263201_=------ From Martin.Stiemerling@neclab.eu Tue Jul 31 17:51:45 2012 Return-Path: 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 AE36B21F889D for ; Tue, 31 Jul 2012 17:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 BpIMT2UrLIXs for ; Tue, 31 Jul 2012 17:51:44 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5832B21F8864 for ; Tue, 31 Jul 2012 17:51:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 0B4331019CD for ; Wed, 1 Aug 2012 02:57:06 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uns4DOtQpHR for ; Wed, 1 Aug 2012 02:57:05 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id E0BD41019CC for ; Wed, 1 Aug 2012 02:57:00 +0200 (CEST) Received: from [10.7.0.105] (10.7.0.105) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 1 Aug 2012 02:51:57 +0200 Message-ID: <50187D7E.7000205@neclab.eu> Date: Wed, 1 Aug 2012 02:51:10 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: References: <20120709192420.30118.13648.idtracker@ietfa.amsl.com> In-Reply-To: <20120709192420.30118.13648.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120709192420.30118.13648.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.7.0.105] Subject: [CDNi] Fwd: I-D Action: draft-tarapore-mboned-multicast-cdni-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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 00:51:45 -0000 FYI. This draft has been presented in the mboned WG this week. At least it is listed on the materials site. Martin -------- Original Message -------- Subject: I-D Action: draft-tarapore-mboned-multicast-cdni-00.txt Date: Mon, 9 Jul 2012 12:24:20 -0700 From: Reply-To: To: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multicast Considerations in Support of CDN-I Author(s) : Percy S. Tarapore Robert Sayko Ram Krishnan Filename : draft-tarapore-mboned-multicast-cdni-00.txt Pages : 12 Date : 2012-07-09 Abstract: This document examines the current capabilities of multicast to support content distribution in an environment involving multiple Service Providers joining together to form a Content Distribution Network Interconnection (CDN-I) Federation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-tarapore-mboned-multicast-cdni There's also a htmlized version available at: http://tools.ietf.org/html/draft-tarapore-mboned-multicast-cdni-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From Jan.Seedorf@neclab.eu Tue Jul 31 18:05:27 2012 Return-Path: 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 EA44221F8577; Tue, 31 Jul 2012 18:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 cU8y2hdHk9Dz; Tue, 31 Jul 2012 18:05:23 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 20F4521F8533; Tue, 31 Jul 2012 18:05:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id D19741019CD; Wed, 1 Aug 2012 03:10:44 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mbcaSJGuOuc; Wed, 1 Aug 2012 03:10:44 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id B4B591019CC; Wed, 1 Aug 2012 03:10:09 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.252]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 1 Aug 2012 03:04:47 +0200 From: Jan Seedorf To: Jan Seedorf , "cdni-footprint@ietf.org" , "cdni@ietf.org" Thread-Topic: Date/time for 2nd CDNI Footprint/Capabilities Design Team Side Meeting at IETF-84 Thread-Index: Ac1vgWY6JRydI902SBS25hdYzZvsBA== Date: Wed, 1 Aug 2012 01:05:28 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE32CE33F7@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.7.0.210] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Date/time for 2nd CDNI Footprint/Capabilities Design Team Side Meeting at IETF-84 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 01:05:27 -0000 Several people have indicated that they will come to this meeting, so: "it'= s on" :) Let's meet tomorrow (WED) at 15:00 at the IETF registration desk t= o continue our discussions, trying to make some progress ... - Jan > -----Original Message----- > From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- > bounces@ietf.org] On Behalf Of Jan Seedorf > Sent: Wednesday, August 01, 2012 1:18 AM > To: cdni-footprint@ietf.org > Cc: Brandenburg, R. (Ray) van (ray.vanbrandenburg@tno.nl); Enrico > Marocco; gilles.bertrand@orange.com; emile.stephan@orange.com; Kevin J > Ma (kevin.ma@azukisystems.com) > Subject: Re: [cdni-footprint] Doodle for 2nd CDNI Footprint/Capabilities > Design Team Side Meeting at IETF-84 >=20 > Guys, >=20 > Looking at the latest doodle it seems that actually *** WED 15:00-17:00 *= ** > would be a good slot where a reasonable amount of people can make it. So = I > suggest having another CDNI Footprint/Capabilities Design Team Side > Meeting at this time. >=20 > Please confirm via email if you can actually make this slot, so that we s= ee if it > really makes sense to have the meeting (i.e. all people that indicated so= in > the doodle really coming). >=20 > - Jan >=20 From haibin.song@huawei.com Tue Jul 31 18:23:58 2012 Return-Path: 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 BE80711E816E for ; Tue, 31 Jul 2012 18:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.089 X-Spam-Level: X-Spam-Status: No, score=-6.089 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=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 KWA+iiZcqGXm for ; Tue, 31 Jul 2012 18:23:57 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 44FE711E80E7 for ; Tue, 31 Jul 2012 18:23:57 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIN09906; Tue, 31 Jul 2012 21:23:57 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 31 Jul 2012 18:21:53 -0700 Received: from SZXEML425-HUB.china.huawei.com (10.72.61.33) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 31 Jul 2012 18:21:56 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.243]) by szxeml425-hub.china.huawei.com ([10.72.61.33]) with mapi id 14.01.0323.003; Wed, 1 Aug 2012 09:21:53 +0800 From: Songhaibin To: zhangyunfei , "Francois Le Faucheur (flefauch)" Thread-Topic: Re: [CDNi] New Version Notification for draft-song-cdni-slr-based-footprint-01.txt Thread-Index: AQHNb384G40GNQLq6U6t6ggRO8OZEJdEJ9k7 Date: Wed, 1 Aug 2012 01:21:52 +0000 Message-ID: References: , , , <2012080108471006917955@chinamobile.com> In-Reply-To: <2012080108471006917955@chinamobile.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.45] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F23AF7DC7szxeml534mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "cdni@ietf.org" Subject: Re: [CDNi] New Version Notification for draft-song-cdni-slr-based-footprint-01.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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 01:23:58 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F23AF7DC7szxeml534mbxchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It's okay to do it, but footprint may have its own interface, although all = these CDNI interfaces migh share a same underlying protocol (e.g. http). -Haibin ________________________________ From: zhangyunfei [zhangyunfei@chinamobile.com] Sent: Wednesday, August 01, 2012 8:47 AM To: Songhaibin; Francois Le Faucheur (flefauch) Cc: cdni@ietf.org Subject: Re: Re: [CDNi] New Version Notification for draft-song-cdni-slr-ba= sed-footprint-01.txt Does this involves request redirection interface interactions? I mean, mayb= e the request redirected by uCDN can fetch the SLA information (after trans= lation to parameters). In this sense, it should be transferred in the reque= st routing interface. BR Yunfei ________________________________ zhangyunfei From: Songhaibin Date: 2012-08-01 08:19 To: Francois Le Faucheur (flefauch) CC: cdni@ietf.org Subject: Re: [CDNi] New Version Notification for draft-song-cdni-slr-based-= footprint-01.txt I just lost my chance to present this draft with my bad English. It reserve= d my energy:) Someone asked me, why do not you call it SLA based footprint?= The answer is, the upstream CDN needs to sign SLA with each application fo= r the content distribution, but I do not know if the upstream CDN needs to = sign SLA with the downstream CDN for each application, probably not. In tha= t case, the upstream CDN has to translate the performance and other require= ments to the technical parameters and tells the downstream CDN. And the dow= nstream CDN just tells the upstream CDN its footprint which can satisfy the= se requirements. Besides that, SLA is out of scope for IETF. We do not talk in the document about the issue when some downstream CDNs ca= n cover the same area (while satisfies the application requirements). It is= reasonable to choose one with even better performance (needs a lot of work= ), or just choose the cheaper one(saves energe for this WG). BR, -Haibin ________________________________________ From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] on behalf of Songhaibin= [haibin.song@huawei.com] Sent: Thursday, July 26, 2012 12:55 PM To: Francois Le Faucheur (flefauch) Cc: cdni@ietf.org Subject: Re: [CDNi] New Version Notification for draft-song-cdni-slr= -based-footprint-01.txt OK. Thanks for the good suggestion. I notice there will be side meeting on = footprint and cap advertisement. I will try to join the discussion. -Haibin > -----Original Message----- > From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > Sent: Wednesday, July 25, 2012 3:53 PM > To: Songhaibin > Cc: cdni@ietf.org; Jan Seedorf; Jon Peterson (jon.peterson@neustar.biz); > Stefano Previdi (sprevidi) > Subject: Re: [CDNi] New Version Notification for > draft-song-cdni-slr-based-footprint-01.txt > > Hello Haibin, > > As per your request, you'll have a 5 min slot in Vancouver to introduce t= his notion > of service level requirements based footprint. > Moving forward, I strongly recommend you input your ideas directly into t= he > work of the "CDNI Footprint and Capabilities Advertisement" Design Team t= hat is > chartered with defining the semantics of the information that is to be ad= vertised. > > Thanks > > Francois > > On 16 Jul 2012, at 12:36, Songhaibin wrote: > > > Hi, > > > > We just submitted a draft about service level requirements based footpr= int. > This draft is mainly used to generate the discussion on this aspect and i= t is still on > a high level idea stage. We have not given deep thought on the details in= this > document. So any discussion and comments are welcome! > > > > http://www.ietf.org/internet-drafts/draft-song-cdni-slr-based-footprint= -01.txt > > > > BR, > > -Haibin > > > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Monday, July 16, 2012 6:31 PM > >> To: Songhaibin > >> Cc: zhangyunfei@chinamobile.com > >> Subject: New Version Notification for > draft-song-cdni-slr-based-footprint-01.txt > >> > >> > >> A new version of I-D, draft-song-cdni-slr-based-footprint-01.txt > >> has been successfully submitted by Haibin Song and posted to the > >> IETF repository. > >> > >> Filename: draft-song-cdni-slr-based-footprint > >> Revision: 01 > >> Title: A SLR (Service Level Requirements) based footprint= for CDNI > >> Creation date: 2012-07-16 > >> WG ID: Individual Submission > >> Number of pages: 7 > >> URL: > >> > http://www.ietf.org/internet-drafts/draft-song-cdni-slr-based-footprint-0= 1.txt > >> Status: > >> http://datatracker.ietf.org/doc/draft-song-cdni-slr-based-footprint > >> Htmlized: > >> http://tools.ietf.org/html/draft-song-cdni-slr-based-footprint-01 > >> Diff: > >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-song-cdni-slr-based-footpri= nt-01 > >> > >> Abstract: > >> Footprint advertisement is a very important step for CDN > >> interconnection and generates a lot of discussion. Actually, each > >> CDN can serve the whole world if its surrogates are publicly > >> reachable by IP addresses. But if a CDN does that, it can not > >> satisfy the requirements from the applications. So CDNs deliver > >> contents for applications, and the basic requirements should be from > >> the applications, but there is rare discussion on service level > >> requirements based footprint. This document is used to generate the > >> discussion on this aspect. > >> > >> > >> > >> > >> 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 --_000_E33E01DFD5BEA24B9F3F18671078951F23AF7DC7szxeml534mbxchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    It's okay to do it, but footprint may have its own interface, altho= ugh all these CDNI interfaces migh share a same underlying protoc= ol (e.g. http).

     

    -Haibin

    From: zhangyunfei [zhangyunfei@chinamobile= .com]
    Sent: Wednesday, August 01, 2012 8:47 AM
    To: Songhaibin; Francois Le Faucheur (flefauch)
    Cc: cdni@ietf.org
    Subject: Re: Re: [CDNi] New Version Notification for draft-song-cdni= -slr-based-footprint-01.txt

    Does this involves request redirection interface interactions? I mean,= maybe the request redirected by uCDN can fetch the SLA information (after = translation to parameters). In this sense, it should be transferred in= the request routing interface.
     
    BR
    Yunfei
     
    zhangyunfei
     
    From: Songhaibin
    Date: 2012-08-01 08:19
    Subject: Re: [CDNi] New Version Notification for draft-son= g-cdni-slr-based-footprint-01.txt
    I just lost my chance to present th= is draft with my bad English. It reserve= d my energy:) Someone asked me, why do&n= bsp;not you call it SLA based footprint? = ;The answer is, the upstream CDN needs t= o sign SLA with each application for the=  content distribution, but I do not know=  if the upstream CDN needs to sign = SLA with the downstream CDN for each app= lication, probably not. In that case, the&nbs= p;upstream CDN has to translate the performan= ce and other requirements to the technical&nb= sp;parameters and tells the downstream CDN. A= nd the downstream CDN just tells the ups= tream CDN its footprint which can satisfy&nbs= p;these requirements. Besides that,   SLA&nbs= p;is out of scope for IETF.
     
    We do not talk in the document abou= t the issue when some downstream CDNs ca= n cover the same area (while satisfies t= he application requirements). It is reasonable&nbs= p;to choose one with even better performance&= nbsp;(needs a lot of work), or just choo= se the cheaper one(saves energe for this = ;WG).
     
    BR,
    -Haibin
    ________________________________________
    From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] on&= nbsp;behalf of Songhaibin [haibin.song@huawei.com]
    Sent: Thursday, July 26, 2012 12:55 PM
    To: Francois Le Faucheur (flefauch)
    Cc: cdni@ietf.org
    Subject: Re: [CDNi] New Version Notification&= nbsp;   for     draft-song-cdni-slr= -based-footprint-01.txt
     
    OK. Thanks for the good suggestion. I&nb= sp;notice there will be side meeting on = footprint and cap advertisement. I will try&n= bsp;to join the discussion.
     
    -Haibin
     
    > -----Original Message-----
    > From: Francois Le Faucheur (flefauch)&nb= sp;[mailto:flefauch@cisco.com]
    > Sent: Wednesday, July 25, 2012 3:53=  PM
    > To: Songhaibin
    > Cc: cdni@ietf.org; Jan Seedorf; Jon = ;Peterson (jon.peterson@neustar.biz);
    > Stefano Previdi (sprevidi)
    > Subject: Re: [CDNi] New Version Not= ification for
    > draft-song-cdni-slr-based-footprint-01.txt
    >
    > Hello Haibin,
    >
    > As per your request, you'll have&nb= sp;a 5 min slot in Vancouver to introduc= e this notion
    > of service level requirements based = ;footprint.
    > Moving forward, I strongly recommend&nbs= p;you input your ideas directly into the
    > work of the "CDNI Footprint an= d Capabilities Advertisement" Design Team tha= t is
    > chartered with defining the semantics&nb= sp;of the information that is to be adve= rtised.
    >
    > Thanks
    >
    > Francois
    >
    > On 16 Jul 2012, at 12:36, Song= haibin wrote:
    >
    > > Hi,
    > >
    > > We just submitted a draft = ;about service level requirements based footprint.=
    > This draft is mainly used to g= enerate the discussion on this aspect and&nbs= p;it is still on
    > a high level idea stage. We ha= ve not given deep thought on the details=  in this
    > document. So any discussion and com= ments are welcome!
    > >
    > > http://www.ietf.org/internet-drafts/draft-song-cdn= i-slr-based-footprint-01.txt
    > >
    > > BR,
    > > -Haibin
    > >
    > >> -----Original Message-----
    > >> From: internet-drafts@ietf.org [mail= to:internet-drafts@ietf.org]
    > >> Sent: Monday, July 16, 201= 2 6:31 PM
    > >> To: Songhaibin
    > >> Cc: zhangyunfei@chinamobile.com
    > >> Subject: New Version Notificati= on for
    > draft-song-cdni-slr-based-footprint-01.txt
    > >>
    > >>
    > >> A new version of I-D, = ;draft-song-cdni-slr-based-footprint-01.txt
    > >> has been successfully submitted=  by Haibin Song and posted to the
    > >> IETF repository.
    > >>
    > >> Filename:   draft-song-cdni-slr= -based-footprint
    > >> Revision:   01
    > >> Title:      &nbs= p;       A SLR (Service L= evel Requirements) based footprint for CDNI
    > >> Creation date:    &nb= sp; 2012-07-16
    > >> WG ID:      = ;        Individual Submission=
    > >> Number of pages: 7
    > >> URL:
    > >>
    > http://www.ietf.org/internet-drafts/draft-song-cdni-slr-base= d-footprint-01.txt
    > >> Status:
    > >> http://datatracker.ietf.org/doc/draft-song-cdn= i-slr-based-footprint
    > >> Htmlized:
    > >> http://tools.ietf.org/html/draft-song-cdni-slr= -based-footprint-01
    > >> Diff:
    > >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-son= g-cdni-slr-based-footprint-01
    > >>
    > >> Abstract:
    > >>   Footprint advertisement = is a very important step for CDN
    > >>   interconnection and gene= rates a lot of discussion.  Actually, ea= ch
    > >>   CDN can serve the&n= bsp;whole world if its surrogates are publicl= y
    > >>   reachable by IP add= resses.  But if a CDN does that, it=  can not
    > >>   satisfy the requirements=  from the applications.  So CDNs deliver=
    > >>   contents for application= s, and the basic requirements should be = from
    > >>   the applications, but&nb= sp;there is rare discussion on service level<= /div>
    > >>   requirements based footp= rint.  This document is used to generate=  the
    > >>   discussion on this = aspect.
    > >>
    > >>
    > >>
    > >>
    > >> 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
    --_000_E33E01DFD5BEA24B9F3F18671078951F23AF7DC7szxeml534mbxchi_-- From zhangyunfei@chinamobile.com Tue Jul 31 18:27:37 2012 Return-Path: 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 C989E11E8186 for ; Tue, 31 Jul 2012 18:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.93 X-Spam-Level: X-Spam-Status: No, score=-97.93 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, 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 kBnLXIqdmjq6 for ; Tue, 31 Jul 2012 18:27:36 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 25CB111E8184 for ; Tue, 31 Jul 2012 18:27:36 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id A2EFDE632; Wed, 1 Aug 2012 09:27:36 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 90704E62B; Wed, 1 Aug 2012 09:27:36 +0800 (CST) Received: from zyf-PC ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012080109273207-2212 ; Wed, 1 Aug 2012 09:27:32 +0800 Date: Wed, 1 Aug 2012 09:27:24 +0800 From: zhangyunfei To: Songhaibin , "Francois Le Faucheur (flefauch)" References: , , , <2012080108471006917955@chinamobile.com>, X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012080109272481253360@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-08-01 09:27:33, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-08-01 09:27:35 Content-Type: multipart/related; boundary="----=_001_NextPart771257566584_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19076.003 X-TM-AS-Result: No--40.150-7.0-31-10 X-imss-scan-details: No--40.150-7.0-31-10;No--40.150-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: "cdni@ietf.org" Subject: Re: [CDNi] New Version Notification for draft-song-cdni-slr-based-footprint-01.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 01:27:37 -0000 ------=_001_NextPart771257566584_=---- Content-Type: multipart/alternative; boundary="----=_002_NextPart820738870603_=----" ------=_002_NextPart820738870603_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="iso-8859-1" SSBhbSBub3Qgc3VyZSBpZiBJIHVuZGVyc3RhbmQgcmlnaHQNClRoZSBTTFIgcGFyYW1ldGVycyBh cmUgZnJvbSB0aGUgdXNlciBhZ2VudCBpbnN0ZWFkIG9mIGZyb20gdGhlIENETiBpdHNlbGYuIElz IGl0IGluIHRoZSBzYW1lIGNhdGVnb3J5IGFzIGZvb3RwcmludCBpbnRlcmZhY2U/DQoNCg0KDQoN Cg0KDQp6aGFuZ3l1bmZlaQ0KDQpGcm9tOiBTb25naGFpYmluDQpEYXRlOiAyMDEyLTA4LTAxIDA5 OjIxDQpUbzogemhhbmd5dW5mZWk7IEZyYW5jb2lzIExlIEZhdWNoZXVyIChmbGVmYXVjaCkNCkND OiBjZG5pQGlldGYub3JnDQpTdWJqZWN0OiBSRTogUmU6IFtDRE5pXSBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LXNvbmctY2RuaS1zbHItYmFzZWQtZm9vdHByaW50LTAxLnR4dA0K SXQncyBva2F5IHRvIGRvIGl0LCBidXQgZm9vdHByaW50IG1heSBoYXZlIGl0cyBvd24gaW50ZXJm YWNlLCBhbHRob3VnaCBhbGwgdGhlc2UgQ0ROSSBpbnRlcmZhY2VzIG1pZ2ggc2hhcmUgYSBzYW1l IHVuZGVybHlpbmcgcHJvdG9jb2wgKGUuZy4gaHR0cCkuDQoNCi1IYWliaW4NCg0KDQoNCkZyb206 IHpoYW5neXVuZmVpIFt6aGFuZ3l1bmZlaUBjaGluYW1vYmlsZS5jb21dDQpTZW50OiBXZWRuZXNk YXksIEF1Z3VzdCAwMSwgMjAxMiA4OjQ3IEFNDQpUbzogU29uZ2hhaWJpbjsgRnJhbmNvaXMgTGUg RmF1Y2hldXIgKGZsZWZhdWNoKQ0KQ2M6IGNkbmlAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBSZTog W0NETmldIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc29uZy1jZG5pLXNsci1i YXNlZC1mb290cHJpbnQtMDEudHh0DQoNCg0KRG9lcyB0aGlzIGludm9sdmVzIHJlcXVlc3QgcmVk aXJlY3Rpb24gaW50ZXJmYWNlIGludGVyYWN0aW9ucz8gSSBtZWFuLCBtYXliZSB0aGUgcmVxdWVz dCByZWRpcmVjdGVkIGJ5IHVDRE4gY2FuIGZldGNoIHRoZSBTTEEgaW5mb3JtYXRpb24gKGFmdGVy IHRyYW5zbGF0aW9uIHRvIHBhcmFtZXRlcnMpLiBJbiB0aGlzIHNlbnNlLCBpdCBzaG91bGQgYmUg dHJhbnNmZXJyZWQgaW4gdGhlIHJlcXVlc3Qgcm91dGluZyBpbnRlcmZhY2UuDQoNCkJSDQpZdW5m ZWkNCg0KDQoNCg0Kemhhbmd5dW5mZWkNCg0KRnJvbTogU29uZ2hhaWJpbg0KRGF0ZTogMjAxMi0w OC0wMSAwODoxOQ0KVG86IEZyYW5jb2lzIExlIEZhdWNoZXVyIChmbGVmYXVjaCkNCkNDOiBjZG5p QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0NETmldIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtc29uZy1jZG5pLXNsci1iYXNlZC1mb290cHJpbnQtMDEudHh0DQpJIGp1c3QgbG9z dCBteSBjaGFuY2UgdG8gcHJlc2VudCB0aGlzIGRyYWZ0IHdpdGggbXkgYmFkIEVuZ2xpc2guIEl0 IHJlc2VydmVkIG15IGVuZXJneTopIFNvbWVvbmUgYXNrZWQgbWUsIHdoeSBkbyBub3QgeW91IGNh bGwgaXQgU0xBIGJhc2VkIGZvb3RwcmludD8gVGhlIGFuc3dlciBpcywgdGhlIHVwc3RyZWFtIENE TiBuZWVkcyB0byBzaWduIFNMQSB3aXRoIGVhY2ggYXBwbGljYXRpb24gZm9yIHRoZSBjb250ZW50 IGRpc3RyaWJ1dGlvbiwgYnV0IEkgZG8gbm90IGtub3cgaWYgdGhlIHVwc3RyZWFtIENETiBuZWVk cyB0byBzaWduIFNMQSB3aXRoIHRoZSBkb3duc3RyZWFtIENETiBmb3IgZWFjaCBhcHBsaWNhdGlv biwgcHJvYmFibHkgbm90LiBJbiB0aGF0IGNhc2UsIHRoZSB1cHN0cmVhbSBDRE4gaGFzIHRvIHRy YW5zbGF0ZSB0aGUgcGVyZm9ybWFuY2UgYW5kIG90aGVyIHJlcXVpcmVtZW50cyB0byB0aGUgdGVj aG5pY2FsIHBhcmFtZXRlcnMgYW5kIHRlbGxzIHRoZSBkb3duc3RyZWFtIENETi4gQW5kIHRoZSBk b3duc3RyZWFtIENETiBqdXN0IHRlbGxzIHRoZSB1cHN0cmVhbSBDRE4gaXRzIGZvb3RwcmludCB3 aGljaCBjYW4gc2F0aXNmeSB0aGVzZSByZXF1aXJlbWVudHMuIEJlc2lkZXMgdGhhdCwgICBTTEEg aXMgb3V0IG9mIHNjb3BlIGZvciBJRVRGLg0KDQpXZSBkbyBub3QgdGFsayBpbiB0aGUgZG9jdW1l bnQgYWJvdXQgdGhlIGlzc3VlIHdoZW4gc29tZSBkb3duc3RyZWFtIENETnMgY2FuIGNvdmVyIHRo ZSBzYW1lIGFyZWEgKHdoaWxlIHNhdGlzZmllcyB0aGUgYXBwbGljYXRpb24gcmVxdWlyZW1lbnRz KS4gSXQgaXMgcmVhc29uYWJsZSB0byBjaG9vc2Ugb25lIHdpdGggZXZlbiBiZXR0ZXIgcGVyZm9y bWFuY2UgKG5lZWRzIGEgbG90IG9mIHdvcmspLCBvciBqdXN0IGNob29zZSB0aGUgY2hlYXBlciBv bmUoc2F2ZXMgZW5lcmdlIGZvciB0aGlzIFdHKS4NCg0KQlIsDQotSGFpYmluDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBjZG5pLWJvdW5jZXNAaWV0Zi5v cmcgW2NkbmktYm91bmNlc0BpZXRmLm9yZ10gb24gYmVoYWxmIG9mIFNvbmdoYWliaW4gW2hhaWJp bi5zb25nQGh1YXdlaS5jb21dDQpTZW50OiBUaHVyc2RheSwgSnVseSAyNiwgMjAxMiAxMjo1NSBQ TQ0KVG86IEZyYW5jb2lzIExlIEZhdWNoZXVyIChmbGVmYXVjaCkNCkNjOiBjZG5pQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW0NETmldIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiAgICBmb3IgICAg IGRyYWZ0LXNvbmctY2RuaS1zbHItYmFzZWQtZm9vdHByaW50LTAxLnR4dA0KDQpPSy4gVGhhbmtz IGZvciB0aGUgZ29vZCBzdWdnZXN0aW9uLiBJIG5vdGljZSB0aGVyZSB3aWxsIGJlIHNpZGUgbWVl dGluZyBvbiBmb290cHJpbnQgYW5kIGNhcCBhZHZlcnRpc2VtZW50LiBJIHdpbGwgdHJ5IHRvIGpv aW4gdGhlIGRpc2N1c3Npb24uDQoNCi1IYWliaW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBGcmFuY29pcyBMZSBGYXVjaGV1ciAoZmxlZmF1Y2gpIFttYWlsdG86Zmxl ZmF1Y2hAY2lzY28uY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMjUsIDIwMTIgMzo1MyBQ TQ0KPiBUbzogU29uZ2hhaWJpbg0KPiBDYzogY2RuaUBpZXRmLm9yZzsgSmFuIFNlZWRvcmY7IEpv biBQZXRlcnNvbiAoam9uLnBldGVyc29uQG5ldXN0YXIuYml6KTsNCj4gU3RlZmFubyBQcmV2aWRp IChzcHJldmlkaSkNCj4gU3ViamVjdDogUmU6IFtDRE5pXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yDQo+IGRyYWZ0LXNvbmctY2RuaS1zbHItYmFzZWQtZm9vdHByaW50LTAxLnR4dA0KPg0K PiBIZWxsbyBIYWliaW4sDQo+DQo+IEFzIHBlciB5b3VyIHJlcXVlc3QsIHlvdSdsbCBoYXZlIGEg NSBtaW4gc2xvdCBpbiBWYW5jb3V2ZXIgdG8gaW50cm9kdWNlIHRoaXMgbm90aW9uDQo+IG9mIHNl cnZpY2UgbGV2ZWwgcmVxdWlyZW1lbnRzIGJhc2VkIGZvb3RwcmludC4NCj4gTW92aW5nIGZvcndh cmQsIEkgc3Ryb25nbHkgcmVjb21tZW5kIHlvdSBpbnB1dCB5b3VyIGlkZWFzIGRpcmVjdGx5IGlu dG8gdGhlDQo+IHdvcmsgb2YgdGhlICJDRE5JIEZvb3RwcmludCBhbmQgQ2FwYWJpbGl0aWVzIEFk dmVydGlzZW1lbnQiIERlc2lnbiBUZWFtIHRoYXQgaXMNCj4gY2hhcnRlcmVkIHdpdGggZGVmaW5p bmcgdGhlIHNlbWFudGljcyBvZiB0aGUgaW5mb3JtYXRpb24gdGhhdCBpcyB0byBiZSBhZHZlcnRp c2VkLg0KPg0KPiBUaGFua3MNCj4NCj4gRnJhbmNvaXMNCj4NCj4gT24gMTYgSnVsIDIwMTIsIGF0 IDEyOjM2LCBTb25naGFpYmluIHdyb3RlOg0KPg0KPiA+IEhpLA0KPiA+DQo+ID4gV2UganVzdCBz dWJtaXR0ZWQgYSBkcmFmdCBhYm91dCBzZXJ2aWNlIGxldmVsIHJlcXVpcmVtZW50cyBiYXNlZCBm b290cHJpbnQuDQo+IFRoaXMgZHJhZnQgaXMgbWFpbmx5IHVzZWQgdG8gZ2VuZXJhdGUgdGhlIGRp c2N1c3Npb24gb24gdGhpcyBhc3BlY3QgYW5kIGl0IGlzIHN0aWxsIG9uDQo+IGEgaGlnaCBsZXZl bCBpZGVhIHN0YWdlLiBXZSBoYXZlIG5vdCBnaXZlbiBkZWVwIHRob3VnaHQgb24gdGhlIGRldGFp bHMgaW4gdGhpcw0KPiBkb2N1bWVudC4gU28gYW55IGRpc2N1c3Npb24gYW5kIGNvbW1lbnRzIGFy ZSB3ZWxjb21lIQ0KPiA+DQo+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtc29uZy1jZG5pLXNsci1iYXNlZC1mb290cHJpbnQtMDEudHh0DQo+ID4NCj4gPiBCUiwN Cj4gPiAtSGFpYmluDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4g RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXQ0KPiA+PiBTZW50OiBNb25kYXksIEp1bHkgMTYsIDIwMTIgNjozMSBQTQ0KPiA+PiBU bzogU29uZ2hhaWJpbg0KPiA+PiBDYzogemhhbmd5dW5mZWlAY2hpbmFtb2JpbGUuY29tDQo+ID4+ IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJhZnQtc29uZy1jZG5p LXNsci1iYXNlZC1mb290cHJpbnQtMDEudHh0DQo+ID4+DQo+ID4+DQo+ID4+IEEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC1zb25nLWNkbmktc2xyLWJhc2VkLWZvb3RwcmludC0wMS50eHQNCj4g Pj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBIYWliaW4gU29uZyBhbmQgcG9z dGVkIHRvIHRoZQ0KPiA+PiBJRVRGIHJlcG9zaXRvcnkuDQo+ID4+DQo+ID4+IEZpbGVuYW1lOiAg IGRyYWZ0LXNvbmctY2RuaS1zbHItYmFzZWQtZm9vdHByaW50DQo+ID4+IFJldmlzaW9uOiAgIDAx DQo+ID4+IFRpdGxlOiAgICAgICAgICAgICAgQSBTTFIgKFNlcnZpY2UgTGV2ZWwgUmVxdWlyZW1l bnRzKSBiYXNlZCBmb290cHJpbnQgZm9yIENETkkNCj4gPj4gQ3JlYXRpb24gZGF0ZTogICAgICAy MDEyLTA3LTE2DQo+ID4+IFdHIElEOiAgICAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQo+ID4+IE51bWJlciBvZiBwYWdlczogNw0KPiA+PiBVUkw6DQo+ID4+DQo+IGh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNvbmctY2RuaS1zbHItYmFzZWQtZm9vdHBy aW50LTAxLnR4dA0KPiA+PiBTdGF0dXM6DQo+ID4+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtc29uZy1jZG5pLXNsci1iYXNlZC1mb290cHJpbnQNCj4gPj4gSHRtbGl6ZWQ6 DQo+ID4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNvbmctY2RuaS1zbHItYmFz ZWQtZm9vdHByaW50LTAxDQo+ID4+IERpZmY6DQo+ID4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtc29uZy1jZG5pLXNsci1iYXNlZC1mb290cHJpbnQtMDENCj4gPj4N Cj4gPj4gQWJzdHJhY3Q6DQo+ID4+ICAgRm9vdHByaW50IGFkdmVydGlzZW1lbnQgaXMgYSB2ZXJ5 IGltcG9ydGFudCBzdGVwIGZvciBDRE4NCj4gPj4gICBpbnRlcmNvbm5lY3Rpb24gYW5kIGdlbmVy YXRlcyBhIGxvdCBvZiBkaXNjdXNzaW9uLiAgQWN0dWFsbHksIGVhY2gNCj4gPj4gICBDRE4gY2Fu IHNlcnZlIHRoZSB3aG9sZSB3b3JsZCBpZiBpdHMgc3Vycm9nYXRlcyBhcmUgcHVibGljbHkNCj4g Pj4gICByZWFjaGFibGUgYnkgSVAgYWRkcmVzc2VzLiAgQnV0IGlmIGEgQ0ROIGRvZXMgdGhhdCwg aXQgY2FuIG5vdA0KPiA+PiAgIHNhdGlzZnkgdGhlIHJlcXVpcmVtZW50cyBmcm9tIHRoZSBhcHBs aWNhdGlvbnMuICBTbyBDRE5zIGRlbGl2ZXINCj4gPj4gICBjb250ZW50cyBmb3IgYXBwbGljYXRp b25zLCBhbmQgdGhlIGJhc2ljIHJlcXVpcmVtZW50cyBzaG91bGQgYmUgZnJvbQ0KPiA+PiAgIHRo ZSBhcHBsaWNhdGlvbnMsIGJ1dCB0aGVyZSBpcyByYXJlIGRpc2N1c3Npb24gb24gc2VydmljZSBs ZXZlbA0KPiA+PiAgIHJlcXVpcmVtZW50cyBiYXNlZCBmb290cHJpbnQuICBUaGlzIGRvY3VtZW50 IGlzIHVzZWQgdG8gZ2VuZXJhdGUgdGhlDQo+ID4+ICAgZGlzY3Vzc2lvbiBvbiB0aGlzIGFzcGVj dC4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IENE TmkgbWFpbGluZyBsaXN0DQo+ID4gQ0ROaUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY2RuaQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KQ0ROaSBtYWlsaW5nIGxpc3QNCkNETmlAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaQ0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNETmkgbWFpbGluZyBsaXN0DQpDRE5p QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nkbmk= ------=_002_NextPart820738870603_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"
    I am not sure if I understand right
    The SLR parameters are from the user agent instead of from the CDN it= self.=20 Is it in the same category as footprint interface?
     
     
     
    zhangyunfei
     
    From: Songhaibin
    Date: 2012-08-01 09:21
    To: zhangyunfei; Francois Le Faucheur (flefauch)
    CC: cdni@ietf.org
    Subject: RE: Re: [CDNi] New Version Notification for=20 draft-song-cdni-slr-based-footprint-01.txt

    It's okay to do it, but footprint may have its own interface, alth= ough=20 all these CDNI interfaces migh share a same underlying protocol = (e.g.=20 http).

     

    -Haibin

    From: zhangyunfei=20 [zhangyunfei@chinamobile.com]
    Sent: Wednesday, August 01, 2012 8= :47=20 AM
    To: Songhaibin; Francois Le Faucheur (flefauch)
    Cc:= =20 cdni@ietf.org
    Subject: Re: Re: [CDNi] New Version Notification f= or=20 draft-song-cdni-slr-based-footprint-01.txt

    Does this involves request redirection interface interactions? I mean= ,=20 maybe the request redirected by uCDN can fetch the SLA information (after=20 translation to parameters). In this sense, it should be transferred i= n the=20 request routing interface.
     
    BR
    Yunfei
     
    zhangyunfei
     
    From: Songhaibin
    Date: 2012-08-01 08:19
    Subject: Re: [CDNi] New Version Notification for=20 draft-song-cdni-slr-based-footprint-01.txt
    I just lost my chance to present t= his draft with my bad English. It reser= ved my energy:) Someone asked me, why d= o not you call it SLA based footprint?&= nbsp;The answer is, the upstream CDN needs&n= bsp;to sign SLA with each application for&nb= sp;the content distribution, but I do not&nb= sp;know if the upstream CDN needs to si= gn SLA with the downstream CDN for each=  application, probably not. In that case,&nb= sp;the upstream CDN has to translate the&nbs= p;performance and other requirements to the = technical parameters and tells the downstream&nbs= p;CDN. And the downstream CDN just tells&nbs= p;the upstream CDN its footprint which can&n= bsp;satisfy these requirements. Besides that, &nb= sp; SLA is out of scope for IETF.
     
    We do not talk in the document abo= ut the issue when some downstream CDNs = can cover the same area (while satisfies&nbs= p;the application requirements). It is reasonable=  to choose one with even better perform= ance (needs a lot of work), or just&nbs= p;choose the cheaper one(saves energe for th= is WG).
     
    BR,
    -Haibin
    ________________________________________
    From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] on=  behalf of Songhaibin [haibin.song@huawei.com]
    Sent: Thursday, July 26, 2012 12:55 PM<= /DIV>
    To: Francois Le Faucheur (flefauch)
    Cc: cdni@ietf.org
    Subject: Re: [CDNi] New Version Notification=     for     draft-song-cdni-s= lr-based-footprint-01.txt
     
    OK. Thanks for the good suggestion. I&n= bsp;notice there will be side meeting on&nbs= p;footprint and cap advertisement. I will tr= y to join the discussion.
     
    -Haibin
     
    > -----Original Message-----
    > From: Francois Le Faucheur (flefauch)&n= bsp;[mailto:flefauch@cisco.com]
    > Sent: Wednesday, July 25, 2012 3:5= 3 PM
    > To: Songhaibin
    > Cc: cdni@ietf.org; Jan Seedorf; Jon&nbs= p;Peterson (jon.peterson@neustar.biz);
    > Stefano Previdi (sprevidi)
    > Subject: Re: [CDNi] New Version No= tification for
    > draft-song-cdni-slr-based-footprint-01.txt
    >
    > Hello Haibin,
    >
    > As per your request, you'll have&n= bsp;a 5 min slot in Vancouver to introd= uce this notion
    > of service level requirements based&nbs= p;footprint.
    > Moving forward, I strongly recommend&nb= sp;you input your ideas directly into the
    > work of the "CDNI Footprint and&nb= sp;Capabilities Advertisement" Design Team that i= s
    > chartered with defining the semantics&n= bsp;of the information that is to be ad= vertised.
    >
    > Thanks
    >
    > Francois
    >
    > On 16 Jul 2012, at 12:36, Son= ghaibin wrote:
    >
    > > Hi,
    > >
    > > We just submitted a draft&nbs= p;about service level requirements based footprin= t.
    > This draft is mainly used to = generate the discussion on this aspect and&n= bsp;it is still on
    > a high level idea stage. We h= ave not given deep thought on the detai= ls in this
    > document. So any discussion and co= mments are welcome!
    > >
    > > http://www.ietf.org/internet-drafts/draft-song-cd= ni-slr-based-footprint-01.txt
    > >
    > > BR,
    > > -Haibin
    > >
    > >> -----Original Message-----
    > >> From: internet-drafts@ietf.org [mai= lto:internet-drafts@ietf.org]
    > >> Sent: Monday, July 16, 20= 12 6:31 PM
    > >> To: Songhaibin
    > >> Cc: zhangyunfei@chinamobile.com
    > >> Subject: New Version Notificat= ion for
    > draft-song-cdni-slr-based-footprint-01.txt
    > >>
    > >>
    > >> A new version of I-D,&nbs= p;draft-song-cdni-slr-based-footprint-01.txt
    > >> has been successfully submitte= d by Haibin Song and posted to the
    > >> IETF repository.
    > >>
    > >> Filename:   draft-song-cdni-sl= r-based-footprint
    > >> Revision:   01
    > >> Title:      &nb= sp;       A SLR (Service = ;Level Requirements) based footprint for CDNI
    > >> Creation date:    &n= bsp; 2012-07-16
    > >> WG ID:     &nbs= p;        Individual Submissi= on
    > >> Number of pages: 7
    > >> URL:
    > >>
    > http://www.ietf.org/internet-drafts/draft-song-cdni-slr-bas= ed-footprint-01.txt
    > >> Status:
    > >> http://datatracker.ietf.org/doc/draft-song-cd= ni-slr-based-footprint
    > >> Htmlized:
    > >> http://tools.ietf.org/html/draft-song-cdni-sl= r-based-footprint-01
    > >> Diff:
    > >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-so= ng-cdni-slr-based-footprint-01
    > >>
    > >> Abstract:
    > >>   Footprint advertisement = ;is a very important step for CDN
    > >>   interconnection and gen= erates a lot of discussion.  Actually, = each
    > >>   CDN can serve the&= nbsp;whole world if its surrogates are publi= cly
    > >>   reachable by IP ad= dresses.  But if a CDN does that, = it can not
    > >>   satisfy the requirement= s from the applications.  So CDNs deliv= er
    > >>   contents for applicatio= ns, and the basic requirements should be&nbs= p;from
    > >>   the applications, but&n= bsp;there is rare discussion on service leve= l
    > >>   requirements based foot= print.  This document is used to genera= te the
    > >>   discussion on this = ;aspect.
    > >>
    > >>
    > >>
    > >>
    > >> 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
    ------=_002_NextPart820738870603_=------ ------=_001_NextPart771257566584_=---- Content-Type: image/gif; name="14.gif" Content-ID: <_Foxmail.0@6883172B-ABD2-4924-8255-648D5113A3A4> Content-Transfer-Encoding: base64 R0lGODlhFAAUAPfkAOrq6rCQZeq6KMi7qPfv1vDw8OWgCsCGIPnaX9jW1ZRKEJ1bGPfdiO/PTv77 TLqlgkIpCEIhCMyZM/PdQP7HQf3NFdeoKf75T+feQv/wUv/hRcatKf/oH8yzTf/tJf//5//GP//n IP/7PsaUGL2EEOfGGJlmM//bR9alEP7mUqVjEP/RQuLQpv/9SP/7Sf/xLP/VRP/65f/7Of79Qf/8 Rv/9Qr2tQqWUe5yESv/lM3tjGM6lGPzMFf3rUu/GMf/9TPzLG//PPszMzPz4P/++CK1rGP35Sf3j bfz5Q//cP//HJ/roMf79Rey/J//vLv/hSu/OKfz2RoRjGOfGId7OrfzzTP/tT/PVNvrvSf/kSf/f QYx7GP/qTP/MM//+Rf/zKs6lIfntRK1rEP/rMf/pKPvvNP/GQf/uJfXdN0opCMa1IWNCEK2UIfbk Rf/8PefeOd61Id6tIebMMLWcIfjfLf/jTv/ERP/eRf3rJf/IQ//xTf/0Uv+7Cf6/C//4MP7ACf/l O/nvPv/XO/73Nf7zUv3wLPzsLZxaEMzMmcyZZv/jIvf39/778//XRPjrO/30MuiwM/7xKvzzOP/j Tf+/B/z2PP/INP/NQNbOKf/yLP76T++zE//rUf/TRP/3Tf/2T//7R//0UP/GRP73MfzwTv/dScaM If/5Tc69KfPPMv/rJvfnOPnRJP/kKv/cRvfVLfnwQv/1M96tKf/VQ5R7MffvMa2ca4RrQrWlOf31 Mf37Rf/0Qf/0Sv33Nv/mSP/0NP/qRf/5Sv37Qv36Pv/3N//uSq2UQqWMOf/6RP/wSP76Pf/2Rf/4 P//xRv/xRLWlUv/1R86tQoxrKf75OdbGrf/zPv/oRpyMWqWMWs69QtbGpf//MbWcUv/3Mf//OaWM a72thL2tSv/vQP/7Q////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/C05FVFNDQVBFMi4wAwEA AAAh+QQFyADkACwAAAAAFAAUAAAI/wDJCRzIgMERBAiOMBjIkKHBDHtChcrAKcWThQ0FHiFE6sIF TRc+hbJSp1GDjAx+aNLkwMEPB6c86eHypFMHhz2wGDmGg1YLFy7CSTM2qdSKmwLrtImCwdYHbdlo YMD2AVw0VyskCGTQJgwSG1Q+EHhWA6xYbncuQTpGjoEmLENsXLtx45YIXN9uUMOhAQYIthsDVXqz JkIEHTIwpDEsRcMsOybIIcjgSNK2ORAgoBrkbUsECBu0PC7SlsuqMo+6qcHkZ1SsWmw2AEqyQlRk Bly4LDFU6EWkL5leOBmTw4cgtbQEouFCpwgYPB7OeFBFphUUBbJEmQogsIGGV1MU7GQIwYFDCEVw FJiyREEFQyha7rg6pGJEiREqFMRR0uXAN4Y++EDHLDygQIIYJKBQQQVKHBBZQ3HEAcQrffxBCRF8 VGDAAcllRI4EEhhgAB98QCLiAiR4yNAB2HBYBDbYqCjjjAEBACH5BAUKAOQALAIAAQARABAAAAiV AMkJzLBHEzk9VsjVWSGwYcNPn/Y4nOjwE8WGGk405CIQVIsWDYPxKpbFoUFdTJh48UKOBihoyXxV JCdshs0a5MYhW9bMmsM9SIYpE+HGDTkRzHY5AybQDjlCDafJcFhNnMBGechlINdrIjGKomglJJdr 4q+JTi+qpaC2rduJIN42tBRXbkMSarsECWLJkpJNRXA0DAgAIfkEBcgA5AAsAgACABEADwAACI0A yQkkdeGCwIMIEWpKiPAJwh4X9hzDQetgOGnGyDWygxCDrQ/aspHDgO0DuGiNuiC0QeUDgWfkWLrk JiihjWs3btwih+vbDWo4BIJIGCECwqICZ3EUuC2hN4Z2ihzslrBWQlECuTDcCkmgr61gyX0NS85H QlYlwCoBO4uhJYEVGfb5Q4kInwoGDpg4GBAAIfkEBQoA5AAsAQACABAAEAAACIMAyQkk9+lTKEJ6 rFjh4mugw4cONUAE1aLFwGC8ipErtULgnj1MmHjxQo4GKGjJfLnqKFDYjJc1yI1DtqyZtTsOhykT 4cYNORHMdjkDBpHcNBkOq4mD2OshMYgarZDL9fCXwzxFs2otamerQ0sO77jS2gUij6wHTEAMApEE La8DDwgMCAA7 ------=_001_NextPart771257566584_=------ From haibin.song@huawei.com Tue Jul 31 22:22:11 2012 Return-Path: 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 BA5F521F85E7 for ; Tue, 31 Jul 2012 22:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.587 X-Spam-Level: X-Spam-Status: No, score=-5.587 tagged_above=-999 required=5 tests=[AWL=-0.589, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_35=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 6CnpZnqyFlop for ; Tue, 31 Jul 2012 22:22:10 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBD421F85DB for ; Tue, 31 Jul 2012 22:22:10 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIN23228; Wed, 01 Aug 2012 01:22:09 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 31 Jul 2012 22:19:53 -0700 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 31 Jul 2012 22:19:52 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.243]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Wed, 1 Aug 2012 13:19:46 +0800 From: Songhaibin To: zhangyunfei , "Francois Le Faucheur (flefauch)" Thread-Topic: RE: [CDNi] New Version Notification for draft-song-cdni-slr-based-footprint-01.txt Thread-Index: AQHNb4TWB8V61XfUlkiCREZ0xT3+TZdEasbh Date: Wed, 1 Aug 2012 05:19:46 +0000 Message-ID: References: , , , <2012080108471006917955@chinamobile.com>, , <2012080109272481253360@chinamobile.com> In-Reply-To: <2012080109272481253360@chinamobile.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.68] Content-Type: multipart/related; boundary="_004_E33E01DFD5BEA24B9F3F18671078951F23AF7E2Bszxeml534mbxchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "cdni@ietf.org" Subject: Re: [CDNi] New Version Notification for draft-song-cdni-slr-based-footprint-01.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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 05:22:11 -0000 --_004_E33E01DFD5BEA24B9F3F18671078951F23AF7E2Bszxeml534mbxchi_ Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F23AF7E2Bszxeml534mbxchi_" --_000_E33E01DFD5BEA24B9F3F18671078951F23AF7E2Bszxeml534mbxchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No. The SLR parameters are translated from the SLA by upstream CDN. This SL= A is signed by upstream CDN and content distribution applications. BR, -Haibin ________________________________ From: zhangyunfei [zhangyunfei@chinamobile.com] Sent: Wednesday, August 01, 2012 9:27 AM To: Songhaibin; Francois Le Faucheur (flefauch) Cc: cdni@ietf.org Subject: Re: RE: [CDNi] New Version Notification for draft-song-cdni-slr-ba= sed-footprint-01.txt I am not sure if I understand right[cid:_Foxmail.0@6883172B-ABD2-4924-8255-= 648D5113A3A4] The SLR parameters are from the user agent instead of from the CDN itself. = Is it in the same category as footprint interface? ________________________________ zhangyunfei From: Songhaibin Date: 2012-08-01 09:21 To: zhangyunfei; Francois Le Faucheur (= flefauch) CC: cdni@ietf.org Subject: RE: Re: [CDNi] New Version Notification for draft-song-cdni-slr-ba= sed-footprint-01.txt It's okay to do it, but footprint may have its own interface, although all = these CDNI interfaces migh share a same underlying protocol (e.g. http). -Haibin ________________________________ From: zhangyunfei [zhangyunfei@chinamobile.com] Sent: Wednesday, August 01, 2012 8:47 AM To: Songhaibin; Francois Le Faucheur (flefauch) Cc: cdni@ietf.org Subject: Re: Re: [CDNi] New Version Notification for draft-song-cdni-slr-ba= sed-footprint-01.txt Does this involves request redirection interface interactions? I mean, mayb= e the request redirected by uCDN can fetch the SLA information (after trans= lation to parameters). In this sense, it should be transferred in the reque= st routing interface. BR Yunfei ________________________________ zhangyunfei From: Songhaibin Date: 2012-08-01 08:19 To: Francois Le Faucheur (flefauch) CC: cdni@ietf.org Subject: Re: [CDNi] New Version Notification for draft-song-cdni-slr-based-= footprint-01.txt I just lost my chance to present this draft with my bad English. It reserve= d my energy:) Someone asked me, why do not you call it SLA based footprint?= The answer is, the upstream CDN needs to sign SLA with each application fo= r the content distribution, but I do not know if the upstream CDN needs to = sign SLA with the downstream CDN for each application, probably not. In tha= t case, the upstream CDN has to translate the performance and other require= ments to the technical parameters and tells the downstream CDN. And the dow= nstream CDN just tells the upstream CDN its footprint which can satisfy the= se requirements. Besides that, SLA is out of scope for IETF. We do not talk in the document about the issue when some downstream CDNs ca= n cover the same area (while satisfies the application requirements). It is= reasonable to choose one with even better performance (needs a lot of work= ), or just choose the cheaper one(saves energe for this WG). BR, -Haibin ________________________________________ From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] on behalf of Songhaibin= [haibin.song@huawei.com] Sent: Thursday, July 26, 2012 12:55 PM To: Francois Le Faucheur (flefauch) Cc: cdni@ietf.org Subject: Re: [CDNi] New Version Notification for draft-song-cdni-slr= -based-footprint-01.txt OK. Thanks for the good suggestion. I notice there will be side meeting on = footprint and cap advertisement. I will try to join the discussion. -Haibin > -----Original Message----- > From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > Sent: Wednesday, July 25, 2012 3:53 PM > To: Songhaibin > Cc: cdni@ietf.org; Jan Seedorf; Jon Peterson (jon.peterson@neustar.biz); > Stefano Previdi (sprevidi) > Subject: Re: [CDNi] New Version Notification for > draft-song-cdni-slr-based-footprint-01.txt > > Hello Haibin, > > As per your request, you'll have a 5 min slot in Vancouver to introduce t= his notion > of service level requirements based footprint. > Moving forward, I strongly recommend you input your ideas directly into t= he > work of the "CDNI Footprint and Capabilities Advertisement" Design Team t= hat is > chartered with defining the semantics of the information that is to be ad= vertised. > > Thanks > > Francois > > On 16 Jul 2012, at 12:36, Songhaibin wrote: > > > Hi, > > > > We just submitted a draft about service level requirements based footpr= int. > This draft is mainly used to generate the discussion on this aspect and i= t is still on > a high level idea stage. We have not given deep thought on the details in= this > document. So any discussion and comments are welcome! > > > > http://www.ietf.org/internet-drafts/draft-song-cdni-slr-based-footprint= -01.txt > > > > BR, > > -Haibin > > > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Monday, July 16, 2012 6:31 PM > >> To: Songhaibin > >> Cc: zhangyunfei@chinamobile.com > >> Subject: New Version Notification for > draft-song-cdni-slr-based-footprint-01.txt > >> > >> > >> A new version of I-D, draft-song-cdni-slr-based-footprint-01.txt > >> has been successfully submitted by Haibin Song and posted to the > >> IETF repository. > >> > >> Filename: draft-song-cdni-slr-based-footprint > >> Revision: 01 > >> Title: A SLR (Service Level Requirements) based footprint= for CDNI > >> Creation date: 2012-07-16 > >> WG ID: Individual Submission > >> Number of pages: 7 > >> URL: > >> > http://www.ietf.org/internet-drafts/draft-song-cdni-slr-based-footprint-0= 1.txt > >> Status: > >> http://datatracker.ietf.org/doc/draft-song-cdni-slr-based-footprint > >> Htmlized: > >> http://tools.ietf.org/html/draft-song-cdni-slr-based-footprint-01 > >> Diff: > >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-song-cdni-slr-based-footpri= nt-01 > >> > >> Abstract: > >> Footprint advertisement is a very important step for CDN > >> interconnection and generates a lot of discussion. Actually, each > >> CDN can serve the whole world if its surrogates are publicly > >> reachable by IP addresses. But if a CDN does that, it can not > >> satisfy the requirements from the applications. So CDNs deliver > >> contents for applications, and the basic requirements should be from > >> the applications, but there is rare discussion on service level > >> requirements based footprint. This document is used to generate the > >> discussion on this aspect. > >> > >> > >> > >> > >> 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 --_000_E33E01DFD5BEA24B9F3F18671078951F23AF7E2Bszxeml534mbxchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    No. The SLR parameters are translated from the SLA by upstream CDN.= This SLA is signed by upstream CDN and content distribution applicati= ons.

     

    BR,

    -Haibin 

     

     

    From: zhangyunfei [zhangyunfei@chinamobile= .com]
    Sent: Wednesday, August 01, 2012 9:27 AM
    To: Songhaibin; Francois Le Faucheur (flefauch)
    Cc: cdni@ietf.org
    Subject: Re: RE: [CDNi] New Version Notification for draft-song-cdni= -slr-based-footprint-01.txt

    I am not sure if I understand right
    The SLR parameters are from the user agent instead of from the CDN its= elf. Is it in the same category as footprint interface?
     
     
     
    zhangyunfei
     
    From: Songhaibin
    Date: 2012-08-01 09:21
    Subject: RE: Re: [CDNi] New Version Notification for draft= -song-cdni-slr-based-footprint-01.txt

    It's okay to do it, but footprint may have its own interface, altho= ugh all these CDNI interfaces migh share a same underlying protoc= ol (e.g. http).

     

    -Haibin

    From: zhangyunfei [zhangyunfei@chinamobile= .com]
    Sent: Wednesday, August 01, 2012 8:47 AM
    To: Songhaibin; Francois Le Faucheur (flefauch)
    Cc: cdni@ietf.org
    Subject: Re: Re: [CDNi] New Version Notification for draft-song-cdni= -slr-based-footprint-01.txt

    Does this involves request redirection interface interactions? I mean,= maybe the request redirected by uCDN can fetch the SLA information (after = translation to parameters). In this sense, it should be transferred in= the request routing interface.
     
    BR
    Yunfei
     
    zhangyunfei
     
    From: Songhaibin
    Date: 2012-08-01 08:19
    Subject: Re: [CDNi] New Version Notification for draft-son= g-cdni-slr-based-footprint-01.txt
    I just lost my chance to present th= is draft with my bad English. It reserve= d my energy:) Someone asked me, why do&n= bsp;not you call it SLA based footprint? = ;The answer is, the upstream CDN needs t= o sign SLA with each application for the=  content distribution, but I do not know=  if the upstream CDN needs to sign = SLA with the downstream CDN for each app= lication, probably not. In that case, the&nbs= p;upstream CDN has to translate the performan= ce and other requirements to the technical&nb= sp;parameters and tells the downstream CDN. A= nd the downstream CDN just tells the ups= tream CDN its footprint which can satisfy&nbs= p;these requirements. Besides that,   SLA&nbs= p;is out of scope for IETF.
     
    We do not talk in the document abou= t the issue when some downstream CDNs ca= n cover the same area (while satisfies t= he application requirements). It is reasonable&nbs= p;to choose one with even better performance&= nbsp;(needs a lot of work), or just choo= se the cheaper one(saves energe for this = ;WG).
     
    BR,
    -Haibin
    ________________________________________
    From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] on&= nbsp;behalf of Songhaibin [haibin.song@huawei.com]
    Sent: Thursday, July 26, 2012 12:55 PM
    To: Francois Le Faucheur (flefauch)
    Cc: cdni@ietf.org
    Subject: Re: [CDNi] New Version Notification&= nbsp;   for     draft-song-cdni-slr= -based-footprint-01.txt
     
    OK. Thanks for the good suggestion. I&nb= sp;notice there will be side meeting on = footprint and cap advertisement. I will try&n= bsp;to join the discussion.
     
    -Haibin
     
    > -----Original Message-----
    > From: Francois Le Faucheur (flefauch)&nb= sp;[mailto:flefauch@cisco.com]
    > Sent: Wednesday, July 25, 2012 3:53=  PM
    > To: Songhaibin
    > Cc: cdni@ietf.org; Jan Seedorf; Jon = ;Peterson (jon.peterson@neustar.biz);
    > Stefano Previdi (sprevidi)
    > Subject: Re: [CDNi] New Version Not= ification for
    > draft-song-cdni-slr-based-footprint-01.txt
    >
    > Hello Haibin,
    >
    > As per your request, you'll have&nb= sp;a 5 min slot in Vancouver to introduc= e this notion
    > of service level requirements based = ;footprint.
    > Moving forward, I strongly recommend&nbs= p;you input your ideas directly into the
    > work of the "CDNI Footprint an= d Capabilities Advertisement" Design Team tha= t is
    > chartered with defining the semantics&nb= sp;of the information that is to be adve= rtised.
    >
    > Thanks
    >
    > Francois
    >
    > On 16 Jul 2012, at 12:36, Song= haibin wrote:
    >
    > > Hi,
    > >
    > > We just submitted a draft = ;about service level requirements based footprint.=
    > This draft is mainly used to g= enerate the discussion on this aspect and&nbs= p;it is still on
    > a high level idea stage. We ha= ve not given deep thought on the details=  in this
    > document. So any discussion and com= ments are welcome!
    > >
    > > http://www.ietf.org/internet-drafts/draft-song-cdn= i-slr-based-footprint-01.txt
    > >
    > > BR,
    > > -Haibin
    > >
    > >> -----Original Message-----
    > >> From: internet-drafts@ietf.org [mail= to:internet-drafts@ietf.org]
    > >> Sent: Monday, July 16, 201= 2 6:31 PM
    > >> To: Songhaibin
    > >> Cc: zhangyunfei@chinamobile.com
    > >> Subject: New Version Notificati= on for
    > draft-song-cdni-slr-based-footprint-01.txt
    > >>
    > >>
    > >> A new version of I-D, = ;draft-song-cdni-slr-based-footprint-01.txt
    > >> has been successfully submitted=  by Haibin Song and posted to the
    > >> IETF repository.
    > >>
    > >> Filename:   draft-song-cdni-slr= -based-footprint
    > >> Revision:   01
    > >> Title:      &nbs= p;       A SLR (Service L= evel Requirements) based footprint for CDNI
    > >> Creation date:    &nb= sp; 2012-07-16
    > >> WG ID:      = ;        Individual Submission=
    > >> Number of pages: 7
    > >> URL:
    > >>
    > http://www.ietf.org/internet-drafts/draft-song-cdni-slr-base= d-footprint-01.txt
    > >> Status:
    > >> http://datatracker.ietf.org/doc/draft-song-cdn= i-slr-based-footprint
    > >> Htmlized:
    > >> http://tools.ietf.org/html/draft-song-cdni-slr= -based-footprint-01
    > >> Diff:
    > >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-son= g-cdni-slr-based-footprint-01
    > >>
    > >> Abstract:
    > >>   Footprint advertisement = is a very important step for CDN
    > >>   interconnection and gene= rates a lot of discussion.  Actually, ea= ch
    > >>   CDN can serve the&n= bsp;whole world if its surrogates are publicl= y
    > >>   reachable by IP add= resses.  But if a CDN does that, it=  can not
    > >>   satisfy the requirements=  from the applications.  So CDNs deliver=
    > >>   contents for application= s, and the basic requirements should be = from
    > >>   the applications, but&nb= sp;there is rare discussion on service level<= /div>
    > >>   requirements based footp= rint.  This document is used to generate=  the
    > >>   discussion on this = aspect.
    > >>
    > >>
    > >>
    > >>
    > >> 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
    --_000_E33E01DFD5BEA24B9F3F18671078951F23AF7E2Bszxeml534mbxchi_-- --_004_E33E01DFD5BEA24B9F3F18671078951F23AF7E2Bszxeml534mbxchi_ Content-Type: image/gif; name="14.gif" Content-Description: 14.gif Content-Disposition: inline; filename="14.gif"; size=1662; creation-date="Wed, 01 Aug 2012 01:27:39 GMT"; modification-date="Wed, 01 Aug 2012 01:27:39 GMT" Content-ID: <_Foxmail.0@6883172B-ABD2-4924-8255-648D5113A3A4> Content-Transfer-Encoding: base64 R0lGODlhFAAUAPfkAOrq6rCQZeq6KMi7qPfv1vDw8OWgCsCGIPnaX9jW1ZRKEJ1bGPfdiO/PTv77 TLqlgkIpCEIhCMyZM/PdQP7HQf3NFdeoKf75T+feQv/wUv/hRcatKf/oH8yzTf/tJf//5//GP//n IP/7PsaUGL2EEOfGGJlmM//bR9alEP7mUqVjEP/RQuLQpv/9SP/7Sf/xLP/VRP/65f/7Of79Qf/8 Rv/9Qr2tQqWUe5yESv/lM3tjGM6lGPzMFf3rUu/GMf/9TPzLG//PPszMzPz4P/++CK1rGP35Sf3j bfz5Q//cP//HJ/roMf79Rey/J//vLv/hSu/OKfz2RoRjGOfGId7OrfzzTP/tT/PVNvrvSf/kSf/f QYx7GP/qTP/MM//+Rf/zKs6lIfntRK1rEP/rMf/pKPvvNP/GQf/uJfXdN0opCMa1IWNCEK2UIfbk Rf/8PefeOd61Id6tIebMMLWcIfjfLf/jTv/ERP/eRf3rJf/IQ//xTf/0Uv+7Cf6/C//4MP7ACf/l O/nvPv/XO/73Nf7zUv3wLPzsLZxaEMzMmcyZZv/jIvf39/778//XRPjrO/30MuiwM/7xKvzzOP/j Tf+/B/z2PP/INP/NQNbOKf/yLP76T++zE//rUf/TRP/3Tf/2T//7R//0UP/GRP73MfzwTv/dScaM If/5Tc69KfPPMv/rJvfnOPnRJP/kKv/cRvfVLfnwQv/1M96tKf/VQ5R7MffvMa2ca4RrQrWlOf31 Mf37Rf/0Qf/0Sv33Nv/mSP/0NP/qRf/5Sv37Qv36Pv/3N//uSq2UQqWMOf/6RP/wSP76Pf/2Rf/4 P//xRv/xRLWlUv/1R86tQoxrKf75OdbGrf/zPv/oRpyMWqWMWs69QtbGpf//MbWcUv/3Mf//OaWM a72thL2tSv/vQP/7Q////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/C05FVFNDQVBFMi4wAwEA AAAh+QQFyADkACwAAAAAFAAUAAAI/wDJCRzIgMERBAiOMBjIkKHBDHtChcrAKcWThQ0FHiFE6sIF TRc+hbJSp1GDjAx+aNLkwMEPB6c86eHypFMHhz2wGDmGg1YLFy7CSTM2qdSKmwLrtImCwdYHbdlo YMD2AVw0VyskCGTQJgwSG1Q+EHhWA6xYbncuQTpGjoEmLENsXLtx45YIXN9uUMOhAQYIthsDVXqz JkIEHTIwpDEsRcMsOybIIcjgSNK2ORAgoBrkbUsECBu0PC7SlsuqMo+6qcHkZ1SsWmw2AEqyQlRk Bly4LDFU6EWkL5leOBmTw4cgtbQEouFCpwgYPB7OeFBFphUUBbJEmQogsIGGV1MU7GQIwYFDCEVw FJiyREEFQyha7rg6pGJEiREqFMRR0uXAN4Y++EDHLDygQIIYJKBQQQVKHBBZQ3HEAcQrffxBCRF8 VGDAAcllRI4EEhhgAB98QCLiAiR4yNAB2HBYBDbYqCjjjAEBACH5BAUKAOQALAIAAQARABAAAAiV AMkJzLBHEzk9VsjVWSGwYcNPn/Y4nOjwE8WGGk405CIQVIsWDYPxKpbFoUFdTJh48UKOBihoyXxV JCdshs0a5MYhW9bMmsM9SIYpE+HGDTkRzHY5AybQDjlCDafJcFhNnMBGechlINdrIjGKomglJJdr 4q+JTi+qpaC2rduJIN42tBRXbkMSarsECWLJkpJNRXA0DAgAIfkEBcgA5AAsAgACABEADwAACI0A yQkkdeGCwIMIEWpKiPAJwh4X9hzDQetgOGnGyDWygxCDrQ/aspHDgO0DuGiNuiC0QeUDgWfkWLrk JiihjWs3btwih+vbDWo4BIJIGCECwqICZ3EUuC2hN4Z2ihzslrBWQlECuTDcCkmgr61gyX0NS85H QlYlwCoBO4uhJYEVGfb5Q4kInwoGDpg4GBAAIfkEBQoA5AAsAQACABAAEAAACIMAyQkk9+lTKEJ6 rFjh4mugw4cONUAE1aLFwGC8ipErtULgnj1MmHjxQo4GKGjJfLnqKFDYjJc1yI1DtqyZtTsOhykT 4cYNORHMdjkDBpHcNBkOq4mD2OshMYgarZDL9fCXwzxFs2otamerQ0sO77jS2gUij6wHTEAMApEE La8DDwgMCAA7 --_004_E33E01DFD5BEA24B9F3F18671078951F23AF7E2Bszxeml534mbxchi_-- From yry@cs.yale.edu Tue Jul 31 22:33:16 2012 Return-Path: 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 D60A221F8645 for ; Tue, 31 Jul 2012 22:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, 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 bBJ5aMT4HMiH for ; Tue, 31 Jul 2012 22:33:16 -0700 (PDT) Received: from vm-emlprdomr-06.its.yale.edu (vm-emlprdomr-06.its.yale.edu [130.132.50.147]) by ietfa.amsl.com (Postfix) with ESMTP id 32FCE21F8608 for ; Tue, 31 Jul 2012 22:33:15 -0700 (PDT) Received: from Faculty-Supports-MacBook-Pro-2.local ([67.21.202.20]) (authenticated bits=0) by vm-emlprdomr-06.its.yale.edu (8.14.4/8.14.4) with ESMTP id q715X53T006958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Aug 2012 01:33:14 -0400 Message-ID: <5018BF8D.4040506@cs.yale.edu> Date: Wed, 01 Aug 2012 13:33:01 +0800 From: "Y. Richard Yang" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: cdni@ietf.org Content-Type: multipart/alternative; boundary="------------070407080901030005050002" X-Scanned-By: MIMEDefang 2.71 on 130.132.50.147 Subject: [CDNi] comments on draft-lefaucheur-cdni-logging-delivery-01.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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 05:33:17 -0000 This is a multi-part message in MIME format. --------------070407080901030005050002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, As suggested by Francois during the meeting today, here are some comments on draft-lefaucheur-cdni-logging-delivery-01, on the Regular HTTP Log Fields (Sec. 2.2): - We may Client Port in addition to Client IP; - About request parameters encoded in message body. In particular, some request parameters (URI, for example, for the purpose of hiding) may be encoded in the message body of a POST message; - Total bytes and total duration may not be sufficient. For example, for the 95-percentile based charging is used, we may need to log transferred bytes in each charging interval, say 5 min; - There are use cases to log client QoE, for example, freezing ratio and # of freezing times. Such metrics may be only observable by the End User Agent only. A dCDN may collect such data (from End User Agent) and report to uCDN/CSP. Thanks. Richard --------------070407080901030005050002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

    As suggested by Francois during the meeting today, here are some comments on draft-lefaucheur-cdni-logging-delivery-01, on the Regular HTTP Log Fields (Sec. 2.2):

    - We may Client Port in addition to Client IP;

    - About request parameters encoded in message body. In particular, some request parameters (URI, for example, for the purpose of hiding) may be encoded in the message body of a POST message;

    - Total bytes and total duration may not be sufficient. For example, for the 95-percentile based charging is used, we may need to log transferred bytes in each charging interval, say 5 min;

    - There are use cases to log client QoE, for example, freezing ratio and # of freezing times. Such metrics may be only observable by the End User Agent only. A dCDN may collect such data (from End User Agent) and report to uCDN/CSP.

    Thanks.

    Richard

    --------------070407080901030005050002-- From li.mian@zte.com.cn Tue Jul 31 23:52:39 2012 Return-Path: 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 D3E5311E8087; Tue, 31 Jul 2012 23:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.891 X-Spam-Level: X-Spam-Status: No, score=-95.891 tagged_above=-999 required=5 tests=[AWL=3.102, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 3UI42dcYbwzg; Tue, 31 Jul 2012 23:52:37 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id BEF9721F856D; Tue, 31 Jul 2012 23:52:36 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 107232556518306; Wed, 1 Aug 2012 14:40:39 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 47492.5802358122; Wed, 1 Aug 2012 14:52:25 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q716qPlu039733; Wed, 1 Aug 2012 14:52:25 +0800 (GMT-8) (envelope-from li.mian@zte.com.cn) In-Reply-To: <005f01cd6f46$5ce667d0$16b33770$@com> To: zahariad@synelixis.com, cdni@ietf.org, cdni-bounces@ietf.org, "'Bhumip Khasnabish'" , jin.weiyi@zte.com.cn MIME-Version: 1.0 X-KeepSent: 0FE52EBB:B98B9CBB-48257A4D:0025B551; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: li.mian@zte.com.cn Date: Wed, 1 Aug 2012 14:52:19 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-01 14:52:20, Serialize complete at 2012-08-01 14:52:20 Content-Type: multipart/alternative; boundary="=_alternative 0025C11448257A4D_=" X-MAIL: mse01.zte.com.cn q716qPlu039733 Subject: [CDNi] =?gb2312?b?tPC4tDogUmU6ICBGd2Q6CWRyYWZ0LWppbi1jZG5pLWNv?= =?gb2312?b?bnRlbnQtZGVkdXBsaWNhdGlvbi1vcHRpbWl6YXRpb24tMDIudHh0?= 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 06:52:40 -0000 This is a multipart message in MIME format. --=_alternative 0025C11448257A4D_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RGVhciBUaGVvZG9yZSwNCg0KVGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzIGFuZCBzaGFyaW5n IHdpdGggdXMgeW91ciBwcm9wb3NhbHMuIENvdWxkIHlvdSANCnBsZWFzZSBzaGFyZSB0aGUgZG9j dW1lbnRzIHlvdSBtZW50aW9uZWQgYmVsb3cgd2l0aCBtZT8gQmFzZWQgb24gd2hhdCB5b3UgDQpl eHBsYWluZWQgaW4gcHJldmlvdXMgZW1haWwsIEkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBmb3IgY2xh cmlmaWNhdGlvbjoNCjEuIFdlIGJvdGggY29uc2lkZXIgaXQgbmVjZXNzYXJ5IHRvIGhhdmUgYSB1 bmlxdWUgY29udGVudCBpZGVudGlmaWVyIGZvciBhIA0KY29udGVudCBvYmplY3QuIE91ciBvcGlu aW9uIGluIHRoaXMgZHJhZnQgaXMgdGhhdCB0aGlzIGNvbnRlbnQgSUQgaXMgDQpDU1AtdW5pcXVl LiBDb3VsZCB5b3UgcGxlYXNlIGV4cGxhaW4gbW9yZSBhYm91dCB0aGUgdW5pcXVlbmVzcyBvZiB0 aGUgVUlEIA0KaW4geW91ciBwcm9wb3NhbD8NCjIuIEJ5IGFwcGx5aW5nIHRoZSBtZWNoYW5pc20g eW91IHByb3Bvc2VkIGJlbG93LCB3ZSBjYW4gZ3VhcmFudGVlIHRoZSANCmNvbnRlbnQgaXMgdW5p cXVlbHkgc3RvcmVkIGluIG9uZSBDRE4uIEFuZCBhY2NvcmRpbmcgdG8gbXkgYW5hbHlzaXMgb24g dGhlIA0KYmFzaXMgb2YgeW91ciBleHBsYW5hdGlvbiwgdGhlIGNvbnRlbnQgcmVwbGljYXRpb24g aXMgY2hlY2tlZCBieSBjb21wYXJpbmcgDQp0aGUgQ1VSTCB3aGljaCBpcyBzaW1pbGFyIHRvIHRo ZSBjdXJyZW50IG1lY2hhbmlzbSBpbiBDRE5pIHdvcmssIGNvcnJlY3QgDQptZSBpZiBteSB1bmRl cnN0YW5kaW5nIGlzIHdyb25nLiBJZiBzbywgd2hlbiByZWRpcmVjdGlvbiBvY2N1cnMgYmV0d2Vl biANCnVDRE5zIGFuZCBkQ0ROLCB0aGUgVVJMIHdvdWxkIGJlIGNoYW5nZWQgYW5kIHRodXMgYmUg ZGlmZmVyZW50IHdpdGggdGhlIA0Kb3JpZ2luYWwgb25lIC0gQ1VSTC4gQW5kIGlmIGEgZENETiBp cyBjb25uZWN0ZWQgd2l0aCB0d28gZGlmZmVyZW50IHVDRE5zIA0KYW5kIHR3byBlbmQgdXNlcnMg cmVxdWVzdCB0aGUgc2FtZSBjb250ZW50IGZyb20gdGhlc2UgdHdvIHVDRE5zIA0KcmVzcGVjdGl2 ZWx5LCB0aGUgdHdvIHVDRE5zIG1heSBnZW5lcmF0ZSBkaWZmZXJlbnQgcmVkaXJlY3Rpb24gVVJM cyB0byB0aGUgDQpkQ0ROLiBJbiB0aGlzIGNhc2Ugd2UgdGhpbmsgdGhlIGNvbnRlbnQgZHVwbGlj YXRpb24gaXNzdWUgc3RpbGwgZXhpc3RzLiANCkhvdyBkbyB5b3UgdGhpbms/IElmIG15IHVuZGVy c3RhbmRpbmcgaXMgd3JvbmcsIGNvdWxkIHlvdSBwbGVhc2UgZXhwbGFpbiANCm1vcmUgb24gaG93 IHRvIGNvbnNpZGVyIHRoaXMgaXNzdWUgYnkgdXNpbmcgeW91ciBwcm9wb3NhbD8NCg0KVGhhbmsg eW91IGFnYWlufg0KDQpjZG5pLWJvdW5jZXNAaWV0Zi5vcmcg5YaZ5LqOIDIwMTItMDgtMDEgMDI6 MDA6MjM6DQoNCj4gRGVhciBCaHVtaXAsIA0KPiANCj4gU29tZSBpZGVhcyBhbmQgY29uc2lkZXJh dGlvbnMgb24gdGhlIGRyYWZ0Lg0KPiANCj4gV2UgaGF2ZSBkb25lIHNvbWUgd29yayBpbiB0aGUg YXJlYSBvZiBkZS1kdXBsaWNhdGlvbiBvZiBjb250ZW50IA0KPiAoUGxlYXNlIHNlZSBUaC4gWmFo YXJpYWRpcywgRS4gUXVhY2NoaW8sIOKAnEZhc3QgY29udGVudC1hd2FyZSANCj4gZGVsaXZlcnkg aW4gb3ZlcmxheSBuZXR3b3JrcyzigJ0gSUVFRSBDT01TT0MgTU1UQyBFLUxldHRlciwgVm9sLjYs IE5vLg0KPiA3LCBKdWx5IDIwMTEsIHBwLiA0NC00NykpDQo+IA0KPiBBY3R1YWxseSwgd2UgYmVs aWV2ZSB0aGF0IGl0IGlzIG5lZWRlZCB0byBkZWZpbmUgVW5pcXVlIElEcyAoVUlEKSANCj4gcGVy IGNvbnRlbnQgb2JqZWN0L2NodW5rIGluIG9yZGVyIHRvOiANCj4gYSkgQXZvaWQgZXh0ZW5kZWQg ZGF0YSByZXBsaWNhdGlvbnMgYXQgdGhlIENETiBsZXZlbCBhbmQgbWluaW1pemUgDQo+IHRoZSBs b2FkIHRvIGZpbmQgdGhlIGNvcnJlY3Qgb2JqZWN0Lg0KPiBiKSBEZXRlY3QgYW5kIHJldHJpZXZl IHZlcnkgZmFzdCB0aGUgY29udGVudC4gVGhpcyBzaG91bGQgYmUgZmFzdCANCj4gZW5vdWdoIHRv IGFsbG93IGV2ZW4gc2VhbWxlc3MgcmVhbC10aW1lIHZpZGVvIHN0cmVhbWluZyBieSANCj4gcmV0 cmlldmluZyB2aWRlbyBjaHVua3MgDQo+IGMpIEJlIGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGgg dG9kYXlz4oCZIFVSTHMgKGluIGNhc2UgdGhlIA0KPiBjb250ZW50L2NodW5rIGlzIG5vdCBmb3Vu ZCwgeW91IHNob3VsZCBiZSBhYmxlIHRvIGdvIHRvIHRoZSBvcmlnaW5hbCANCnNpdGUpLg0KPiAN Cj4gSW4gb3JkZXIgdG8gbWVldCB0aGUgKGEpLCBVSUQgc2hvdWxkIGJlIGFsd2F5cyBhc3NvY2lh dGVkIHdpdGggdGhlIA0KPiBjb250ZW50IG9iamVjdCBpdHNlbGYgKGUuZy4gZW5jYXBzdWxhdGVk IGluIHRoZSBvYmplY3QpIG9yIGJlIGJhc2VkIA0KPiBvbiB1bmlxdWUgY2hhcmFjdGVyaXN0aWNz IG9mIHRoZSBjb250ZW50IG9iamVjdCAoZS5nLiBhIHNldCBvZiBsb3cgDQo+IGxldmVsIGRlc2Ny aXB0b3JzKS4gSG93ZXZlciwgKGIpLCBwb3NlcyB0aGF0IHRoaXMgY291bGQgYmUgDQo+IGNhbGN1 bGF0ZWQgb25jZSAob3Igc29tZXRpbWVzKSwgYnV0IHNob3VsZCBub3QgYmUgY2FsY3VsYXRlZCBv ciANCj4gZ2VuZXJhdGVkIGVhY2ggdGltZSB0aGUgb2JqZWN0IGlzIHJlcXVlc3RlZDsgaW5zdGVh ZCBpdCBzaG91bGQgYmUgDQo+IOKAnGNhcnJpZWTigJ0gYW5kIOKAnGV4dHJhY3RlZOKAnSBpbiBt b3N0IGNhc2VzLiAgT24gdGhlIG90aGVyIGhhbmQsIGR1ZSB0byANCj4gYmFja3dhcmRzIGNvbXBh dGliaWxpdHkgbmVlZHMgKGMpLCB3ZSBzaG91bGQgbm90IGNoYW5nZSB0aGUgc3RhbmRhcmQNCj4g ZmlsZSBmb3JtYXQgKGUuZy4gd2UgY291bGQgbm90IGVuY2Fwc3VsYXRlIFVJRCBvciBsb3cgbGV2 ZWwgDQo+IGRlc2NyaXB0b3IgaW4gdGhlIGNvbnRlbnQgb2JqZWN0KS4gDQo+IA0KPiBPbmUgc29s dXRpb24gY291bGQgYmUgdG8gY3JlYXRlIGEgd3JhcHBlciB0aGF0IHdvdWxkIGVuY2Fwc3VsYXRl IHRoZQ0KPiBVSUQgd2hlbmV2ZXIgdGhlIGNvbnRlbnQgb2JqZWN0IGVudGVycyB0aGUgQ0ROIGFu ZCBleHRyYWN0cyB0aGF0IGF0IA0KPiB0aGUgdGltZSB0aGF0IHRoZSBjb250ZW50IG9iamVjdCBs ZWF2ZXMgdGhlIENETiwgYnV0IHRoaXMgd291bGQgDQo+IGluY3JlYXNlIHRoZSBjb21wbGV4aXR5 IGFuZCBwcm9jZXNzaW5nIHRpbWUuDQo+IA0KPiBJbnN0ZWFkLCB3ZSBwcm9wb3NlIHRvIHVzZSBh cyBVSUQgYSBmb3JtYWwgZmlsZSBuYW1lIGZvcm1hdC4gVUlEIA0KPiB3aWxsIGJlIGEgc3RyaW5n IGNvbmNhdGVuYXRpb24gaW4gdGhlIGZvcm1hdDogDQo+IA0KPiBDTS1DSUQtZmlsZW5hbWUuZXh0 IA0KPiANCj4gd2hlcmU6DQo+IOKAoiBDTSBpcyBhIOKAnENvbnRlbnQgTWFya2Vy4oCdIA0KPiDi gKIgQ0lEIGlzIGEgY29udGVudCBzaWduYXR1cmUsIHdoaWNoIGNvdWxkIGJlIGEgc2VsZi1jZXJ0 aWZ5aW5nIA0KPiBpZGVudGlmaWVyIGUuZy4gTUQ1IG9yIFNIQS0xIGJhc2VkLWhhc2ggZnVuY3Rp b24gb24gdGhlIGZpbGUncyANCj4gY29udGVudCBvciBldmVuIGEgY29tYmluYXRpb24gb2Ygc2Vh cmNoYWJsZSBsb3cgbGV2ZWwgZGVzY3JpcHRvcnMuICwNCj4gd2hpY2ggZ3VhcmFudGVlcyBhbiBl YXN5IGFuZCBmYXN0IGRldGVjdGlvbiB0aGF0IHRoaXMgbmFtZSBpcyBhIFVJRA0KPiDigKIgdGhl IG9yaWdpbmFsIGZpbGVuYW1lLCB3aGljaCBpcyB1c2VkIGZvciBtYWtpbmcgVUlEIGVhc2lseSAN Cj4gcmVjb2duaXplZCBieSBodW1hbnMgYW5kIGF2b2lkIGNvbXBsZXggc2VsZi1jZXJ0aWZ5aW5n IG5hbWVzLg0KPiANCj4gV2hlbmV2ZXIgbmV3IGNvbnRlbnQgaXMgcHVibGlzaGVkIG9yIHN0b3Jl ZCBhdCB0aGUgQ0ROLCB0aGUgb2JqZWN0IA0KPiBmaWxlbmFtZSBjb3VsZCBiZSByZW5hbWVkIHRv IGEgVUlEIGFuZCB0aGUgVVJMIHRvIGEgQ29udGVudCBVUkwgDQo+IChDVVJMKSB3aXRoIHRoZSAN Cj4gZm9sbG93aW5nIGZvcm1hdDogDQo+IA0KPiBodHRwOi8vd3d3LiB3ZWJzaXRlLmNvbS/igKYv Q00tQ0lELWZpbGVuYW1lLmV4dA0KPiANCj4gVGhlIENVUkwgaXMgYSBVUkksIHdoaWNoIGlzIGRl c2lnbmVkIHRvIGVuYWJsZSBjYWNoaW5nIG1lY2hhbmlzbXMgDQo+IGFuZCB0cmlnZ2VyIENETi1y ZWxhdGVkIGZ1bmN0aW9uYWxpdHkgKGUuZy4gYWNjZXNzaW5nIHRoZSBDRE4gDQo+IG92ZXJsYXkg bmV0d29yayBhbmQgcXVlcnlpbmcgZm9yIGxvY2FsbHkgb3Ig4oCcbmVhcmJ54oCdIGNhY2hlZCAN Cj4gY29udGVudCkuIEl0IHNob3VsZCBhbHNvIGJlIGVtcGhhc2l6ZWQgdGhhdCBmcm9tIHRoZSBD VVJMLCB0aGUgDQo+IG9yaWdpbmFsIFVSTCBhbmQgdGhlIFVJRCBtYXkgYmUgZWFzaWx5IGV4dHJh Y3RlZCwgd2hpbGUgb24gdGhlIG90aGVyDQo+IGhhbmQgaXQgaXMgZnVsbHkgYmFja3dhcmRzIGNv bXBhdGlibGUgd2l0aCBleGlzdGluZyBicm93c2VycyBhbmQgbm8gDQo+IG1vZGlmaWNhdGlvbnMg YXJlIG5lZWRlZC4gSW4gdGhpcyB3YXksIHdlIG1heSBzZWFtbGVzc2x5IHN1cHBvcnQgYW55DQo+ IGtpbmQgb2YgZGF0YSBhdmFpbGFibGUgaW4gdGhlIEludGVybmV0ICh0ZXh0LCBpbWFnZXMsIHZh cmlvdXMgdHlwZXMgDQo+IG9mIGF1ZGlvIG9yIHZpZGVvKSwgd2hpbGUgaW4gY2FzZSB0aGUgY29u dGVudCBvYmplY3QgaXMgbm90IGNhY2hlZCANCj4gaW4gdGhlIENETiwgd2UgY2FuIGFsd2F5cyBn byBiYWNrIHRvIHRoZSBvcmlnaW5hbCBzb3VyY2UgVVJMLg0KPiANCj4gQmVzdCByZWdhcmRzLA0K PiBUaGVvZG9yZQ0KPiANCj4gRnJvbTogY2RuaS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2Ru aS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgDQo+IEJodW1pcCBLaGFzbmFiaXNoDQo+ IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMzEsIDIwMTIgODo0NCBQTQ0KPiBUbzogY2RuaUBpZXRmLm9y Zw0KPiBTdWJqZWN0OiBbQ0ROaV0gRndkOiANCmRyYWZ0LWppbi1jZG5pLWNvbnRlbnQtZGVkdXBs aWNhdGlvbi1vcHRpbWl6YXRpb24tMDIudHh0DQo+IA0KPiANCj4gVG86IGktZC1hbm5vdW5jZSBh dCBpZXRmLm9yZyANCj4gU3ViamVjdDogSS1EIEFjdGlvbjogDQpkcmFmdC1qaW4tY2RuaS1jb250 ZW50LWRlZHVwbGljYXRpb24tb3B0aW1pemF0aW9uLTAyLnR4dCANCj4gRnJvbTogaW50ZXJuZXQt ZHJhZnRzIGF0IGlldGYub3JnIA0KPiBEYXRlOiBTdW4sIDI5IEp1bCAyMDEyIDE5OjI5OjE0IC0w NzAwIA0KPiBEZWxpdmVyZWQtdG86IGktZC1hbm5vdW5jZSBhdCBpZXRmYS5hbXNsLmNvbSANCj4g TGlzdC1hcmNoaXZlOiA8aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2ktZC1h bm5vdW5jZT4gDQo+IExpc3QtaGVscDogPG1haWx0bzppLWQtYW5ub3VuY2UtcmVxdWVzdEBpZXRm Lm9yZz9zdWJqZWN0PWhlbHA+IA0KPiBMaXN0LWlkOiBJbnRlcm5ldCBEcmFmdCBBbm5vdW5jZW1l bnRzIG9ubHkgPGktZC1hbm5vdW5jZS5pZXRmLm9yZz4gDQo+IExpc3QtcG9zdDogPG1haWx0bzpp LWQtYW5ub3VuY2VAaWV0Zi5vcmc+IA0KPiBMaXN0LXN1YnNjcmliZTogPGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlPiwgPA0KPiBtYWlsdG86aS1kLWFu bm91bmNlLXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD1zdWJzY3JpYmU+IA0KPiBMaXN0LXVuc3Vi c2NyaWJlOiA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9vcHRpb25zL2ktZC1hbm5vdW5j ZT4sIDwNCj4gbWFpbHRvOmktZC1hbm5vdW5jZS1yZXF1ZXN0QGlldGYub3JnP3N1YmplY3Q9dW5z dWJzY3JpYmU+IA0KPiBSZXBseS10bzogaW50ZXJuZXQtZHJhZnRzIGF0IGlldGYub3JnIA0KPiAN Cj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50 ZXJuZXQtRHJhZnRzIA0KPiBkaXJlY3Rvcmllcy4NCj4gDQo+IA0KPiAgICAgICAgIFRpdGxlICAg ICAgICAgICA6IENvbnRlbnQgRGUtZHVwbGljYXRpb24gZm9yIENETmkgT3B0aW1pemF0aW9uDQo+ ICAgICAgICAgQXV0aG9yKHMpICAgICAgIDogV2VpWWkgSmluDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgTWlhbiBMaQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEJodW1pcCBLaGFz bmFiaXNoDQo+ICAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtamluLWNkbmktY29udGVu dC1kZWR1cGxpY2F0aW9uLQ0KPiBvcHRpbWl6YXRpb24tMDIudHh0DQo+ICAgICAgICAgUGFnZXMg ICAgICAgICAgIDogMTcNCj4gICAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDEyLTA3LTI5DQo+ IA0KPiBBYnN0cmFjdDoNCj4gICAgUmVjZW50IGV4cGxvc2l2ZSBncm93dGggb2YgY29udGVudCBk ZWxpdmVyeS9kaXN0cmlidXRpb24gbmV0d29ya3MNCj4gICAgKENETnMpIGFuZCB0aGVpciBpbnRl cmNvbm5lY3Rpb24gYXJlIGNhdXNpbmcgdW5pbnRlbmRlZCByZXBldGl0aW9uIG9mDQo+ICAgIGNv bnRlbnQgc3RvcmFnZSBpbiB0aGUgc2FtZSBkQ0ROLiAgVGhpcyBjYW4gYmUgYXZvaWRlZCBieSB1 c2luZyBhDQo+ICAgIHN1aXRhYmxlIGRlLWR1cGxpY2F0aW9uIG1lY2hhbmlzbS4gIFRoaXMgZG9j dW1lbnQgZXhwbG9yZXMgdGhlDQo+ICAgIHNjZW5hcmlvcyB3aGljaCBjcmVhdGUgdGhlIHByb2Js ZW1zLCBhbmQgdGhlbiBkaXNjdXNzZXMgdGhlDQo+ICAgIGFwcHJvYWNoZXMgdG8gZWxpbWluYXRl IHRoZSBkdXBsaWNhdGVkIHRyYW5zbWlzc2lvbiBvZiB0aGUgc2FtZQ0KPiAgICBjb250ZW50IGZy b20gdUNETihzKSB0byBkQ0ROIGluIENETmkgbmV0d29ya3MuICBUbyBpbXBsZW1lbnQgdGhlDQo+ ICAgIG9wdGltaXphdGlvbiwgc29tZSBlbmhhbmNlbWVudHMgdG8gdGhlIENETmkgbWV0YWRhdGEg bW9kZWwgYW5kDQo+ICAgIGludGVyZmFjZSBhcmUgcmVxdWlyZWQuDQo+IA0KPiANCj4gVGhlIElF VEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWppbi1jZG5pLWNvbnRlbnQtDQo+IGRlZHVw bGljYXRpb24tb3B0aW1pemF0aW9uDQo+IA0KPiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJz aW9uIGF2YWlsYWJsZSBhdDoNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamlu LWNkbmktY29udGVudC1kZWR1cGxpY2F0aW9uLQ0KPiBvcHRpbWl6YXRpb24tMDINCj4gDQo+IEEg ZGlmZiBmcm9tIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWppbi1jZG5pLWNvbnRlbnQtDQo+IGRlZHVw bGljYXRpb24tb3B0aW1pemF0aW9uLTAyDQo+IA0KPiANCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBh bHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzLw0KPiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gQ0ROaSBtYWlsaW5nIGxpc3QNCj4gQ0ROaUBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkNCg0K --=_alternative 0025C11448257A4D_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0ic2Fucy1zZXJpZiI+RGVhciBU aGVvZG9yZSw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFj ZT0ic2Fucy1zZXJpZiI+VGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzDQphbmQgc2hhcmluZyB3 aXRoIHVzIHlvdXIgcHJvcG9zYWxzLiBDb3VsZCB5b3UgcGxlYXNlIHNoYXJlIHRoZSBkb2N1bWVu dHMNCnlvdSBtZW50aW9uZWQgYmVsb3cgd2l0aCBtZT8gQmFzZWQgb24gd2hhdCB5b3UgZXhwbGFp bmVkIGluIHByZXZpb3VzIGVtYWlsLA0KSSBoYXZlIHNvbWUgcXVlc3Rpb25zIGZvciBjbGFyaWZp Y2F0aW9uOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJzYW5z LXNlcmlmIj4xLiBXZSBib3RoIGNvbnNpZGVyIGl0DQpuZWNlc3NhcnkgdG8gaGF2ZSBhIHVuaXF1 ZSBjb250ZW50IGlkZW50aWZpZXIgZm9yIGEgY29udGVudCBvYmplY3QuIE91cg0Kb3BpbmlvbiBp biB0aGlzIGRyYWZ0IGlzIHRoYXQgdGhpcyBjb250ZW50IElEIGlzIENTUC11bmlxdWUuIENvdWxk IHlvdQ0KcGxlYXNlIGV4cGxhaW4gbW9yZSBhYm91dCB0aGUgdW5pcXVlbmVzcyBvZiB0aGUgVUlE IGluIHlvdXIgcHJvcG9zYWw/PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgw IGZhY2U9InNhbnMtc2VyaWYiPjIuIEJ5IGFwcGx5aW5nIHRoZSBtZWNoYW5pc20NCnlvdSBwcm9w b3NlZCBiZWxvdywgd2UgY2FuIGd1YXJhbnRlZSB0aGUgY29udGVudCBpcyB1bmlxdWVseSBzdG9y ZWQgaW4NCm9uZSBDRE4uIEFuZCBhY2NvcmRpbmcgdG8gbXkgYW5hbHlzaXMgb24gdGhlIGJhc2lz IG9mIHlvdXIgZXhwbGFuYXRpb24sDQp0aGUgY29udGVudCByZXBsaWNhdGlvbiBpcyBjaGVja2Vk IGJ5IGNvbXBhcmluZyB0aGUgQ1VSTCB3aGljaCBpcyBzaW1pbGFyDQp0byB0aGUgY3VycmVudCBt ZWNoYW5pc20gaW4gQ0ROaSB3b3JrLCBjb3JyZWN0IG1lIGlmIG15IHVuZGVyc3RhbmRpbmcgaXMN Cndyb25nLiBJZiBzbywgd2hlbiByZWRpcmVjdGlvbiBvY2N1cnMgYmV0d2VlbiB1Q0ROcyBhbmQg ZENETiwgdGhlIFVSTCB3b3VsZA0KYmUgY2hhbmdlZCBhbmQgdGh1cyBiZSBkaWZmZXJlbnQgd2l0 aCB0aGUgb3JpZ2luYWwgb25lIC0gQ1VSTC4gQW5kIGlmIGENCmRDRE4gaXMgY29ubmVjdGVkIHdp dGggdHdvIGRpZmZlcmVudCB1Q0ROcyBhbmQgdHdvIGVuZCB1c2VycyByZXF1ZXN0IHRoZQ0Kc2Ft ZSBjb250ZW50IGZyb20gdGhlc2UgdHdvIHVDRE5zIHJlc3BlY3RpdmVseSwgdGhlIHR3byB1Q0RO cyBtYXkgZ2VuZXJhdGUNCmRpZmZlcmVudCByZWRpcmVjdGlvbiBVUkxzIHRvIHRoZSBkQ0ROLiBJ biB0aGlzIGNhc2Ugd2UgdGhpbmsgdGhlIGNvbnRlbnQNCmR1cGxpY2F0aW9uIGlzc3VlIHN0aWxs IGV4aXN0cy4gSG93IGRvIHlvdSB0aGluaz8gSWYgbXkgdW5kZXJzdGFuZGluZyBpcw0Kd3Jvbmcs IGNvdWxkIHlvdSBwbGVhc2UgZXhwbGFpbiBtb3JlIG9uIGhvdyB0byBjb25zaWRlciB0aGlzIGlz c3VlIGJ5IHVzaW5nDQp5b3VyIHByb3Bvc2FsPzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgY29sb3I9IzAwMDA4MCBmYWNlPSJzYW5zLXNlcmlmIj5UaGFuayB5b3UgYWdhaW5+PC9mb250 Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Y2RuaS1ib3VuY2VzQGlldGYub3JnIOWGmeS6 jiAyMDEyLTA4LTAxIDAyOjAwOjIzOjxicj4NCjxicj4NCiZndDsgRGVhciBCaHVtaXAsIDwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgU29tZSBpZGVhcyBhbmQgY29uc2lkZXJhdGlvbnMgb24g dGhlIGRyYWZ0LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgV2UgaGF2ZSBkb25lIHNvbWUg d29yayBpbiB0aGUgYXJlYSBvZiBkZS1kdXBsaWNhdGlvbg0Kb2YgY29udGVudCA8YnI+DQomZ3Q7 IChQbGVhc2Ugc2VlIFRoLiBaYWhhcmlhZGlzLCBFLiBRdWFjY2hpbywg4oCcRmFzdCBjb250ZW50 LWF3YXJlIDxicj4NCiZndDsgZGVsaXZlcnkgaW4gb3ZlcmxheSBuZXR3b3JrcyzigJ0gSUVFRSBD T01TT0MgTU1UQyBFLUxldHRlciwgVm9sLjYsDQpOby48YnI+DQomZ3Q7IDcsIEp1bHkgMjAxMSwg cHAuIDQ0LTQ3KSk8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7 PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEFjdHVhbGx5LCB3ZSBiZWxp ZXZlIHRoYXQgaXQgaXMgbmVlZGVkIHRvIGRlZmluZQ0KVW5pcXVlIElEcyAoVUlEKSA8YnI+DQom Z3Q7IHBlciBjb250ZW50IG9iamVjdC9jaHVuayBpbiBvcmRlciB0bzogPC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IGEpIEF2b2lkIGV4dGVuZGVkIGRhdGEgcmVwbGljYXRp b25zIGF0IHRoZSBDRE4NCmxldmVsIGFuZCBtaW5pbWl6ZSA8YnI+DQomZ3Q7IHRoZSBsb2FkIHRv IGZpbmQgdGhlIGNvcnJlY3Qgb2JqZWN0LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyBiKSBEZXRlY3QgYW5kIHJldHJpZXZlIHZlcnkgZmFzdCB0aGUgY29udGVudC4NClRo aXMgc2hvdWxkIGJlIGZhc3QgPGJyPg0KJmd0OyBlbm91Z2ggdG8gYWxsb3cgZXZlbiBzZWFtbGVz cyByZWFsLXRpbWUgdmlkZW8gc3RyZWFtaW5nIGJ5IDxicj4NCiZndDsgcmV0cmlldmluZyB2aWRl byBjaHVua3MgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IGMpIEJlIGJh Y2t3YXJkcyBjb21wYXRpYmxlIHdpdGggdG9kYXlz4oCZIFVSTHMNCihpbiBjYXNlIHRoZSA8YnI+ DQomZ3Q7IGNvbnRlbnQvY2h1bmsgaXMgbm90IGZvdW5kLCB5b3Ugc2hvdWxkIGJlIGFibGUgdG8g Z28gdG8gdGhlIG9yaWdpbmFsDQpzaXRlKS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IElu IG9yZGVyIHRvIG1lZXQgdGhlIChhKSwgVUlEIHNob3VsZCBiZSBhbHdheXMNCmFzc29jaWF0ZWQg d2l0aCB0aGUgPGJyPg0KJmd0OyBjb250ZW50IG9iamVjdCBpdHNlbGYgKGUuZy4gZW5jYXBzdWxh dGVkIGluIHRoZSBvYmplY3QpIG9yIGJlIGJhc2VkDQo8YnI+DQomZ3Q7IG9uIHVuaXF1ZSBjaGFy YWN0ZXJpc3RpY3Mgb2YgdGhlIGNvbnRlbnQgb2JqZWN0IChlLmcuIGEgc2V0IG9mIGxvdw0KPGJy Pg0KJmd0OyBsZXZlbCBkZXNjcmlwdG9ycykuIEhvd2V2ZXIsIChiKSwgcG9zZXMgdGhhdCB0aGlz IGNvdWxkIGJlIDxicj4NCiZndDsgY2FsY3VsYXRlZCBvbmNlIChvciBzb21ldGltZXMpLCBidXQg c2hvdWxkIG5vdCBiZSBjYWxjdWxhdGVkIG9yIDxicj4NCiZndDsgZ2VuZXJhdGVkIGVhY2ggdGlt ZSB0aGUgb2JqZWN0IGlzIHJlcXVlc3RlZDsgaW5zdGVhZCBpdCBzaG91bGQgYmUNCjxicj4NCiZn dDsg4oCcY2FycmllZOKAnSBhbmQg4oCcZXh0cmFjdGVk4oCdIGluIG1vc3QgY2FzZXMuICZuYnNw O09uIHRoZSBvdGhlcg0KaGFuZCwgZHVlIHRvIDxicj4NCiZndDsgYmFja3dhcmRzIGNvbXBhdGli aWxpdHkgbmVlZHMgKGMpLCB3ZSBzaG91bGQgbm90IGNoYW5nZSB0aGUgc3RhbmRhcmQ8YnI+DQom Z3Q7IGZpbGUgZm9ybWF0IChlLmcuIHdlIGNvdWxkIG5vdCBlbmNhcHN1bGF0ZSBVSUQgb3IgbG93 IGxldmVsIDxicj4NCiZndDsgZGVzY3JpcHRvciBpbiB0aGUgY29udGVudCBvYmplY3QpLiA8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IE9uZSBzb2x1dGlvbiBjb3VsZCBiZSB0byBjcmVhdGUg YSB3cmFwcGVyIHRoYXQNCndvdWxkIGVuY2Fwc3VsYXRlIHRoZTxicj4NCiZndDsgVUlEIHdoZW5l dmVyIHRoZSBjb250ZW50IG9iamVjdCBlbnRlcnMgdGhlIENETiBhbmQgZXh0cmFjdHMgdGhhdCBh dA0KPGJyPg0KJmd0OyB0aGUgdGltZSB0aGF0IHRoZSBjb250ZW50IG9iamVjdCBsZWF2ZXMgdGhl IENETiwgYnV0IHRoaXMgd291bGQgPGJyPg0KJmd0OyBpbmNyZWFzZSB0aGUgY29tcGxleGl0eSBh bmQgcHJvY2Vzc2luZyB0aW1lLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSW5zdGVhZCwg d2UgcHJvcG9zZSB0byB1c2UgYXMgVUlEIGEgZm9ybWFsIGZpbGUNCm5hbWUgZm9ybWF0LiBVSUQg PGJyPg0KJmd0OyB3aWxsIGJlIGEgc3RyaW5nIGNvbmNhdGVuYXRpb24gaW4gdGhlIGZvcm1hdDog PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBDTS1DSUQtZmlsZW5hbWUuZXh0IDwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgd2hlcmU6PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7IOKAoiBDTSBpcyBhIOKAnENvbnRlbnQgTWFya2Vy4oCdIDwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyDigKIgQ0lEIGlzIGEgY29udGVudCBzaWduYXR1cmUs IHdoaWNoIGNvdWxkIGJlDQphIHNlbGYtY2VydGlmeWluZyA8YnI+DQomZ3Q7IGlkZW50aWZpZXIg ZS5nLiBNRDUgb3IgU0hBLTEgYmFzZWQtaGFzaCBmdW5jdGlvbiBvbiB0aGUgZmlsZSdzIDxicj4N CiZndDsgY29udGVudCBvciBldmVuIGEgY29tYmluYXRpb24gb2Ygc2VhcmNoYWJsZSBsb3cgbGV2 ZWwgZGVzY3JpcHRvcnMuDQosPGJyPg0KJmd0OyB3aGljaCBndWFyYW50ZWVzIGFuIGVhc3kgYW5k IGZhc3QgZGV0ZWN0aW9uIHRoYXQgdGhpcyBuYW1lIGlzIGEgVUlEPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IOKAoiB0aGUgb3JpZ2luYWwgZmlsZW5hbWUsIHdoaWNoIGlz IHVzZWQgZm9yIG1ha2luZw0KVUlEIGVhc2lseSA8YnI+DQomZ3Q7IHJlY29nbml6ZWQgYnkgaHVt YW5zIGFuZCBhdm9pZCBjb21wbGV4IHNlbGYtY2VydGlmeWluZyBuYW1lcy48L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7IFdoZW5ldmVyIG5ldyBjb250ZW50IGlzIHB1Ymxpc2hlZCBvciBzdG9y ZWQgYXQNCnRoZSBDRE4sIHRoZSBvYmplY3QgPGJyPg0KJmd0OyBmaWxlbmFtZSBjb3VsZCBiZSBy ZW5hbWVkIHRvIGEgVUlEIGFuZCB0aGUgVVJMIHRvIGEgQ29udGVudCBVUkwgPGJyPg0KJmd0OyAo Q1VSTCkgd2l0aCB0aGUgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IGZv bGxvd2luZyBmb3JtYXQ6IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAm bmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgaHR0cDovL3d3dy4g d2Vic2l0ZS5jb20v4oCmL0NNLUNJRC1maWxlbmFtZS5leHQ8L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IFRoZSBDVVJMIGlzIGEgVVJJLCB3aGljaCBpcyBkZXNpZ25lZCB0byBlbmFibGUNCmNh Y2hpbmcgbWVjaGFuaXNtcyA8YnI+DQomZ3Q7IGFuZCB0cmlnZ2VyIENETi1yZWxhdGVkIGZ1bmN0 aW9uYWxpdHkgKGUuZy4gYWNjZXNzaW5nIHRoZSBDRE4gPGJyPg0KJmd0OyBvdmVybGF5IG5ldHdv cmsgYW5kIHF1ZXJ5aW5nIGZvciBsb2NhbGx5IG9yIOKAnG5lYXJieeKAnSBjYWNoZWQgPGJyPg0K Jmd0OyBjb250ZW50KS4gSXQgc2hvdWxkIGFsc28gYmUgZW1waGFzaXplZCB0aGF0IGZyb20gdGhl IENVUkwsIHRoZSA8YnI+DQomZ3Q7IG9yaWdpbmFsIFVSTCBhbmQgdGhlIFVJRCBtYXkgYmUgZWFz aWx5IGV4dHJhY3RlZCwgd2hpbGUgb24gdGhlIG90aGVyPGJyPg0KJmd0OyBoYW5kIGl0IGlzIGZ1 bGx5IGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGggZXhpc3RpbmcgYnJvd3NlcnMgYW5kIG5vDQo8 YnI+DQomZ3Q7IG1vZGlmaWNhdGlvbnMgYXJlIG5lZWRlZC4gSW4gdGhpcyB3YXksIHdlIG1heSBz ZWFtbGVzc2x5IHN1cHBvcnQgYW55PGJyPg0KJmd0OyBraW5kIG9mIGRhdGEgYXZhaWxhYmxlIGlu IHRoZSBJbnRlcm5ldCAodGV4dCwgaW1hZ2VzLCB2YXJpb3VzIHR5cGVzDQo8YnI+DQomZ3Q7IG9m IGF1ZGlvIG9yIHZpZGVvKSwgd2hpbGUgaW4gY2FzZSB0aGUgY29udGVudCBvYmplY3QgaXMgbm90 IGNhY2hlZA0KPGJyPg0KJmd0OyBpbiB0aGUgQ0ROLCB3ZSBjYW4gYWx3YXlzIGdvIGJhY2sgdG8g dGhlIG9yaWdpbmFsIHNvdXJjZSBVUkwuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBCZXN0 IHJlZ2FyZHMsPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFRoZW9kb3Jl PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBGcm9tOiBjZG5pLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmddDQpPbiBCZWhhbGYgT2YgPGJyPg0KJmd0OyBC aHVtaXAgS2hhc25hYmlzaDxicj4NCiZndDsgU2VudDogVHVlc2RheSwgSnVseSAzMSwgMjAxMiA4 OjQ0IFBNPGJyPg0KJmd0OyBUbzogY2RuaUBpZXRmLm9yZzxicj4NCiZndDsgU3ViamVjdDogW0NE TmldIEZ3ZDogZHJhZnQtamluLWNkbmktY29udGVudC1kZWR1cGxpY2F0aW9uLW9wdGltaXphdGlv bi0wMi50eHQ8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgVG86IGktZC1h bm5vdW5jZSBhdCBpZXRmLm9yZyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgU3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtamluLWNkbmktY29udGVudC1kZWR1cGxpY2F0 aW9uLW9wdGltaXphdGlvbi0wMi50eHQNCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyBGcm9tOiBpbnRlcm5ldC1kcmFmdHMgYXQgaWV0Zi5vcmcgPC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IERhdGU6IFN1biwgMjkgSnVsIDIwMTIgMTk6Mjk6MTQg LTA3MDAgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IERlbGl2ZXJlZC10 bzogaS1kLWFubm91bmNlIGF0IGlldGZhLmFtc2wuY29tDQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDsgTGlzdC1hcmNoaXZlOiAmbHQ7aHR0cDovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL2ktZC1hbm5vdW5jZSZndDsNCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyBMaXN0LWhlbHA6ICZsdDttYWlsdG86aS1kLWFubm91bmNlLXJlcXVl c3RAaWV0Zi5vcmc/c3ViamVjdD1oZWxwJmd0Ow0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7IExpc3QtaWQ6IEludGVybmV0IERyYWZ0IEFubm91bmNlbWVudHMgb25seSAm bHQ7aS1kLWFubm91bmNlLmlldGYub3JnJmd0Ow0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7IExpc3QtcG9zdDogJmx0O21haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmcm Z3Q7DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgTGlzdC1zdWJzY3Jp YmU6ICZsdDtodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5j ZSZndDssDQombHQ7PGJyPg0KJmd0OyBtYWlsdG86aS1kLWFubm91bmNlLXJlcXVlc3RAaWV0Zi5v cmc/c3ViamVjdD1zdWJzY3JpYmUmZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyBMaXN0LXVuc3Vic2NyaWJlOiAmbHQ7aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9vcHRpb25zL2ktZC1hbm5vdW5jZSZndDssDQombHQ7PGJyPg0KJmd0OyBtYWlsdG86aS1kLWFu bm91bmNlLXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD11bnN1YnNjcmliZSZndDsgPC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFJlcGx5LXRvOiBpbnRlcm5ldC1kcmFmdHMg YXQgaWV0Zi5vcmcgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4N CiZndDsgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUg SW50ZXJuZXQtRHJhZnRzDQo8YnI+DQomZ3Q7IGRpcmVjdG9yaWVzLjwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaXRsZSAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7ICZuYnNwOyA6IENvbnRlbnQgRGUtZHVwbGljYXRpb24gZm9yIENETmkgT3B0aW1pemF0 aW9uPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBBdXRob3IocykgJm5ic3A7DQombmJzcDsgJm5ic3A7IDogV2VpWWkgSmlu PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgTWlhbiBMaTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEJodW1pcCBLaGFzbmFi aXNoPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBGaWxlbmFtZSAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7OiBkcmFm dC1qaW4tY2RuaS1jb250ZW50LWRlZHVwbGljYXRpb24tPGJyPg0KJmd0OyBvcHRpbWl6YXRpb24t MDIudHh0PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBQYWdlcyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw OyA6IDE3PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBEYXRlICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOzogMjAxMi0wNy0yOTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgQWJzdHJhY3Q6 PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDtSZWNl bnQgZXhwbG9zaXZlIGdyb3d0aCBvZiBjb250ZW50DQpkZWxpdmVyeS9kaXN0cmlidXRpb24gbmV0 d29ya3M8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNw OyhDRE5zKSBhbmQgdGhlaXIgaW50ZXJjb25uZWN0aW9uDQphcmUgY2F1c2luZyB1bmludGVuZGVk IHJlcGV0aXRpb24gb2Y8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5i c3A7ICZuYnNwO2NvbnRlbnQgc3RvcmFnZSBpbiB0aGUgc2FtZSBkQ0ROLg0KJm5ic3A7VGhpcyBj YW4gYmUgYXZvaWRlZCBieSB1c2luZyBhPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7ICZuYnNwOyAmbmJzcDtzdWl0YWJsZSBkZS1kdXBsaWNhdGlvbiBtZWNoYW5pc20uDQom bmJzcDtUaGlzIGRvY3VtZW50IGV4cGxvcmVzIHRoZTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7c2NlbmFyaW9zIHdoaWNoIGNyZWF0ZSB0aGUgcHJv YmxlbXMsDQphbmQgdGhlbiBkaXNjdXNzZXMgdGhlPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDthcHByb2FjaGVzIHRvIGVsaW1pbmF0ZSB0aGUgZHVw bGljYXRlZA0KdHJhbnNtaXNzaW9uIG9mIHRoZSBzYW1lPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDtjb250ZW50IGZyb20gdUNETihzKSB0byBkQ0RO IGluDQpDRE5pIG5ldHdvcmtzLiAmbmJzcDtUbyBpbXBsZW1lbnQgdGhlPC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDtvcHRpbWl6YXRpb24sIHNvbWUg ZW5oYW5jZW1lbnRzDQp0byB0aGUgQ0ROaSBtZXRhZGF0YSBtb2RlbCBhbmQ8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO2ludGVyZmFjZSBhcmUgcmVx dWlyZWQuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2Ug Zm9yIHRoaXMgZHJhZnQNCmlzOjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qaW4tY2RuaS1jb250ZW50 LTxicj4NCiZndDsgZGVkdXBsaWNhdGlvbi1vcHRpbWl6YXRpb248L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Ojwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1qaW4tY2RuaS1jb250ZW50LWRlZHVwbGljYXRpb24tPGJyPg0KJmd0OyBv cHRpbWl6YXRpb24tMDI8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5i c3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEEgZGlmZiBmcm9tIHBy ZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0OjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWpp bi1jZG5pLWNvbnRlbnQtPGJyPg0KJmd0OyBkZWR1cGxpY2F0aW9uLW9wdGltaXphdGlvbi0wMjwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5v bnltb3VzDQpGVFAgYXQ6PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IGZ0 cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7ICZuYnNwO19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KJmd0OyBDRE5pIG1haWxpbmcgbGlzdDxicj4NCiZndDsgQ0ROaUBp ZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9j ZG5pPGJyPg0KPC9mb250PjwvdHQ+DQo= --=_alternative 0025C11448257A4D_=--