From RMurray@velocix.com Thu Mar 1 08:46: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 2A21A21E82AD for ; Thu, 1 Mar 2012 08:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] 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 D-9Vl8n+ZMLa for ; Thu, 1 Mar 2012 08:46:33 -0800 (PST) Received: from owa.velocix.com (host1.cachelogic.com [212.44.43.80]) by ietfa.amsl.com (Postfix) with ESMTP id A163721E8264 for ; Thu, 1 Mar 2012 08:46:17 -0800 (PST) Received: from EXB03CAM.corp.velocix.com ([169.254.4.238]) by exc02cam.corp.velocix.com ([172.16.16.133]) with mapi id 14.02.0247.003; Wed, 29 Feb 2012 21:24:52 +0000 From: Rob Murray To: "cdni@ietf.org" Thread-Topic: CDNI Triggers interface Thread-Index: AQHM9yiS9f5MjNMAgUyVfS/GL0lNnQ== Date: Wed, 29 Feb 2012 21:24:52 +0000 Message-ID: In-Reply-To: <20120229193726.22156.55872.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.16.16.169] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] CDNI Triggers interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 16:46:34 -0000 Hi all, I've just uploaded a new draft that proposes a CDNI Triggers interface ... http://datatracker.ietf.org/doc/draft-murray-cdni-triggers/ There was some discussion at the last WG meeting about whether triggers fit best as part of the control or metadata interface - the suggestion was that concrete proposals for the interface might help us spot commonality with one or the other, so let's see! Please take a look, your comments are welcome. Best regards, Rob. On 29/02/2012 19:37, "internet-drafts@ietf.org" wrote: >A new version of I-D, draft-murray-cdni-triggers-00.txt has been >successfully submitted by Rob Murray and posted to the IETF repository. > >Filename: draft-murray-cdni-triggers >Revision: 00 >Title: CDN Interconnect Triggers >Creation date: 2012-02-29 >WG ID: Individual Submission >Number of pages: 33 > >Abstract: > This document proposes a mechanism for a CDN to trigger activity in > an interconnected CDN that is configured to deliver content on its > behalf. The upstream CDN can use this mechanism to request that the > downstream CDN pre-positions metadata or content, or that it re- > validate or purge metadata or content. The upstream CDN can monitor > the status of activity that it has triggered in the downstream CDN. > > > =20 > =20 > > >The IETF Secretariat From ben@niven-jenkins.co.uk Sun Mar 4 08:38: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 37AB621F8648 for ; Sun, 4 Mar 2012 08:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.271 X-Spam-Level: X-Spam-Status: No, score=-103.271 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bO+Fl7mt8IHz for ; Sun, 4 Mar 2012 08:38:35 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id B1E6021F8647 for ; Sun, 4 Mar 2012 08:38:34 -0800 (PST) Received: from cpc10-cmbg15-2-0-cust121.5-4.cable.virginmedia.com ([86.30.246.122] helo=[192.168.0.3]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1S4ES9-0008M2-7s; Sun, 04 Mar 2012 16:38:33 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Ben Niven-Jenkins In-Reply-To: <562ECB2F-4F36-4AF1-AD30-EEEC9146DCFC@cisco.com> Date: Sun, 4 Mar 2012 16:38:31 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <933EA207-0ABB-450E-92F3-B607D9DBE741@niven-jenkins.co.uk> References: <8E09C72DBC577D489F13A71228C0B7BF031722A3@ftrdmel0.rd.francetelecom.fr> <4715AB6C-6566-4E09-BCE1-1B7F5C604C80@cisco.com> <562ECB2F-4F36-4AF1-AD30-EEEC9146DCFC@cisco.com> To: Francois Le Faucheur X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org Subject: Re: [CDNi] Working Group Last Call on draft-ietf-cdni-use-cases-03.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 16:38:36 -0000 On 22 Feb 2012, at 16:31, Francois Le Faucheur wrote: > Folks, >=20 > The Last Call period for draft-ietf-cdni-use-cases has now closed, but = we haven't received any comments, so we'll extend it until 2 March. Apologies that this is a little past the deadline. I have read draft-ietf-cdni-use-cases-03 and apart from one thing I = think it is ready to be sent to the IESG. Sections 2, 3 and 4 seem to fulfil the purpose of the document, i.e. to = outline the different *use cases for interconnecting CDNs*, however = section 5 seems out of place in this document because it describes CSP = requirements that are placed on CDNs today and does not introduce any = CDN Interconnect specific *use cases*. I propose that we remove section 5 from the use cases draft and then = take the text of that section and distill it into the specific = requirements it describes and we add the resulting requirements to the = requirements draft. Ben > =20 > As per the show of hand at the last IETF meeting, quite a few of you = are familiar with this document. So can you please have a look at the = latest version and pass on your comments, or a brief statement like "I = think it's ready" or "I think it needs rework before going further", so = we can get explicit confirmation that the document is ready (or not) = from the WG perspective. >=20 > Thanks >=20 > Francois & Rich >=20 >=20 > On 30 Jan 2012, at 14:37, Francois Le Faucheur wrote: >=20 >> All, >>=20 >> This is the start of a two-week working group last call on = draft-ietf-cdni-use-cases-03.txt: >> https://datatracker.ietf.org/doc/draft-ietf-cdni-use-cases/ >>=20 >> This working group last call will end 13 Feb 2012. Please send your = comments to the CDNI mailing list. >>=20 >> Francois & Rich >>=20 >>=20 >> Begin forwarded message: >>=20 >>> From: >>> Date: 30 January 2012 12:12:50 CET >>> To: >>> Subject: [CDNi] TR: I-D Action: draft-ietf-cdni-use-cases-03.txt >>>=20 >>> Hi, >>>=20 >>> We have submitted a revision addressing Kent's comments. >>>=20 >>> = http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-ietf-= cdni-use-cases-02.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-cdni-use-= cases-03.txt=20 >>>=20 >>> Best regards, >>>=20 >>> Gilles >>>=20 >>>=20 >>>=20 >>>=20 >>> -----Message d'origine----- >>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part = de internet-drafts@ietf.org >>> Envoy=E9 : lundi 30 janvier 2012 12:07 >>> =C0 : i-d-announce@ietf.org >>> Cc : cdni@ietf.org >>> Objet : [CDNi] I-D Action: draft-ietf-cdni-use-cases-03.txt >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Content Delivery Networks = Interconnection Working Group of the IETF. >>>=20 >>> Title : Use Cases for Content Delivery Network = Interconnection >>> Author(s) : Gilles Bertrand >>> Stephan Emile >>> Grant Watson >>> Trevor Burbridge >>> Philip Eardley >>> Kevin Ma >>> Filename : draft-ietf-cdni-use-cases-03.txt >>> Pages : 18 >>> Date : 2012-01-30 >>>=20 >>> Content Delivery Networks (CDNs) are commonly used for improving = the >>> End User experience of a content delivery service, at a reasonable >>> cost. This document outlines real world use cases (not technical >>> solutions) for interconnecting CDNs. It focuses on use cases that >>> correspond to identified industry needs and that are expected to = be >>> realized once a CDN Interconnection (CDNI) solution is available. >>> This document can be used to provide guidance to the CDNI WG about >>> the interconnection arrangements to be supported and to validate = the >>> requirements of the various CDNI interfaces. >>>=20 >>>=20 >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-03.txt >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-03.txt >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From ben@niven-jenkins.co.uk Sun Mar 4 10:17: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 221CD21F8686 for ; Sun, 4 Mar 2012 10:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.341 X-Spam-Level: X-Spam-Status: No, score=-103.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ITqlc6oi7tO for ; Sun, 4 Mar 2012 10:17:04 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id C54B721F8684 for ; Sun, 4 Mar 2012 10:17:03 -0800 (PST) Received: from cpc10-cmbg15-2-0-cust121.5-4.cable.virginmedia.com ([86.30.246.122] helo=[192.168.0.3]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1S4FzS-0007ym-9I; Sun, 04 Mar 2012 18:17:02 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Ben Niven-Jenkins In-Reply-To: <005f01ccec9a$77e2c210$67a84630$@com> Date: Sun, 4 Mar 2012 18:17:01 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <62EB0429-81BC-4A57-A483-8638E7EE94DB@niven-jenkins.co.uk> References: <005f01ccec9a$77e2c210$67a84630$@com> To: HeXiaoyan X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org Subject: Re: [CDNi] FW: New Version Notification for draft-he-cdni-routing-request-redirection-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 18:17:05 -0000 On 16 Feb 2012, at 11:02, HeXiaoyan wrote: > Hi all, > We have submitted a draft on the routing request = redirection=EF=BC=88Recursive mode=EF=BC=89 of RRI, = http://datatracker.ietf.org/doc/draft-he-cdni-routing-request-redirection/= I notice this is the third internet-draft that has now being published = on this topic each with a different filename (the others being = draft-xiaoyan-cdni-request-routing-protocol and = draft-xiaoyan-cdni-requestrouting) and that many of the authors are = common across all three drafts. What is the relationship between the three drafts because from a glance = they all look pretty similar? Normal convention would be to just update the draft number between = revisions not to publish under a new filename as that makes keeping = track of which is the most up to date version significantly easier (as = well helping track the history of things like IPR declarations as drafts = move through the publication process). Thanks Ben >=20 > Your comments are welcome. >=20 > Best Regards > Xiaoyan(Susan) He >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Thursday, February 16, 2012 5:04 PM > To: hexiaoyan@huawei.com > Cc: cheng@gsta.com; hexiaoyan@huawei.com; = spencer.dawkins@wondermaster.com; niwei@chinamobile.com > Subject: New Version Notification for = draft-he-cdni-routing-request-redirection-00.txt >=20 > A new version of I-D, draft-he-cdni-routing-request-redirection-00.txt = has been successfully submitted by Xiaoyan He and posted to the IETF = repository. >=20 > Filename: draft-he-cdni-routing-request-redirection > Revision: 00 > Title: Routing Request Redirection for CDN = Interconnection > Creation date: 2012-02-16 > WG ID: Individual Submission > Number of pages: 13 >=20 > Abstract: > The Request Routing Interface comprises the asynchronous = advertisement > of footprint and capabilities by a dCDN that allows a uCDN to decide = whether > to redirect particular user requests to that dCDN; and the = synchronous operation > of actually redirecting a user request. This document describes = protocol for the > part of user requests redirection. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From ben@niven-jenkins.co.uk Sun Mar 4 12:28: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 D30A521F855A for ; Sun, 4 Mar 2012 12:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.359 X-Spam-Level: X-Spam-Status: No, score=-103.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7u+dT9eEpW+j for ; Sun, 4 Mar 2012 12:28:56 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7A421F853B for ; Sun, 4 Mar 2012 12:28:56 -0800 (PST) Received: from cpc10-cmbg15-2-0-cust121.5-4.cable.virginmedia.com ([86.30.246.122] helo=[192.168.0.3]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1S4I34-0007rl-PN for cdni@ietf.org; Sun, 04 Mar 2012 20:28:55 +0000 From: Ben Niven-Jenkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 4 Mar 2012 20:28:54 +0000 Message-Id: To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Subject: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-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: Sun, 04 Mar 2012 20:28:56 -0000 Authors, Some comments on draft-lefaucheur-cdni-logging-delivery-00. 1) In section 3.2.1.2 (Segment-Based Log fields) and section 3.2.2.1 = (Event Based Log Triggers) you mandate support for a number of log = fields such as abr-protocol, representation, manifest-id and content-id = that a downstream CDN may have no ability to generate, for example = because the downstream CDN is acting in a pure HTTP reverse proxy mode = and may not be aware of that level of information and/or because the = control of how to identify those fields is owned by the CSP and none of = CDNs may have visibility of that mapping information. Such a requirement to force CDNs and CDNI in general to require such = mappings seems overkill to me. 2) In section 6 you propose an additional requirement to allow an = upstream CDN to indicate through CDNI metadata the log format the = downstream CDN should use. Rather than define a set of specific formats, = we could allow the upstream CDN to specify CDNI metadata indicating the = specific log fields it is interested in receiving. The upstream CDN = could then tailor what it asks for according to what it requires and = avoid the transfer of log fields that it does not need. 3) Although you do not yet specify a particular log digest format it = would seem reasonable to me to reuse the W3C model = (http://www.w3.org/TR/WD-logfile.html) and also to use the W3C = convention for log field prefixes such as c-, cs-, etc. 4) If the motivation for summary/aggregated log lines is a concern over = the volume of data that needs to be transferred then in Velocix we have = done some experiments on using an alternative lookup table based = structure for log lines that retains all the verbosity of the original = delivery log lines but by itself appears to give equivalent compression = to gzip and combined with gzip reduces the size significantly when = compared to what gzip alone achieves (in some cases averaging as little = as 13 bits per complete log line). If the volume of logs to be transferred is a concern and there is = interest in investigating this approach further I can write-up more = details either in a separate draft or as a section in = draft-lefaucheur-cdni-logging-delivery. Ben= From philip.eardley@bt.com Sun Mar 4 13:47: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 9A0B921F862B for ; Sun, 4 Mar 2012 13:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.402 X-Spam-Level: X-Spam-Status: No, score=-103.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjXv9depu8e8 for ; Sun, 4 Mar 2012 13:47:45 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7CA21F8628 for ; Sun, 4 Mar 2012 13:47:45 -0800 (PST) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 4 Mar 2012 21:47:43 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.164]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Sun, 4 Mar 2012 21:47:43 +0000 From: To: , Date: Sun, 4 Mar 2012 21:47:42 +0000 Thread-Topic: [CDNi] Working Group Last Call on draft-ietf-cdni-use-cases-03.txt Thread-Index: Acz6JUFl6OTrei7BTBK15gOme+ZyogAKSxoY Message-ID: <9510D26531EF184D9017DF24659BB87F331CE2EA71@EMV65-UKRD.domain1.systemhost.net> References: <8E09C72DBC577D489F13A71228C0B7BF031722A3@ftrdmel0.rd.francetelecom.fr> <4715AB6C-6566-4E09-BCE1-1B7F5C604C80@cisco.com> <562ECB2F-4F36-4AF1-AD30-EEEC9146DCFC@cisco.com>, <933EA207-0ABB-450E-92F3-B607D9DBE741@niven-jenkins.co.uk> In-Reply-To: <933EA207-0ABB-450E-92F3-B607D9DBE741@niven-jenkins.co.uk> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: cdni@ietf.org Subject: Re: [CDNi] Working Group Last Call on draft-ietf-cdni-use-cases-03.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 21:47:46 -0000 your point is logical, although personally I think it's better if Section 5= is included - this is probably the first document someone would read about= cdni, so a bit of hinting about where the tricky points might be is quite = nice.=20 I agree the requirements should go into the requirements draft. at a very q= uick glance it seems that someof them are not in there. Should they be adde= d, or is it correct that they're missing? - 5.1: resolution-constraint=20 - 5.1 geolocation-constraint (geo-location from where content delivered) - 5.2 security (CSP restricting uCDN which restricts dCDN about which secur= ity protocol to use) - 5.2 security (CSP enforcing per-request authentication/authorisation)=20 - 5.3 branding =20 Anyway, if S5 stays in the use cases, should be consistent with the require= ments doc best wishes phil ________________________________________ From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf Of Ben Niven-= Jenkins [ben@niven-jenkins.co.uk] Sent: 04 March 2012 16:38 To: Francois Le Faucheur Cc: cdni@ietf.org Subject: Re: [CDNi] Working Group Last Call on draft-ietf-cdni-use-cases-0= 3.txt On 22 Feb 2012, at 16:31, Francois Le Faucheur wrote: > Folks, > > The Last Call period for draft-ietf-cdni-use-cases has now closed, but we= haven't received any comments, so we'll extend it until 2 March. Apologies that this is a little past the deadline. I have read draft-ietf-cdni-use-cases-03 and apart from one thing I think i= t is ready to be sent to the IESG. Sections 2, 3 and 4 seem to fulfil the purpose of the document, i.e. to out= line the different *use cases for interconnecting CDNs*, however section 5 = seems out of place in this document because it describes CSP requirements t= hat are placed on CDNs today and does not introduce any CDN Interconnect sp= ecific *use cases*. I propose that we remove section 5 from the use cases draft and then take t= he text of that section and distill it into the specific requirements it de= scribes and we add the resulting requirements to the requirements draft. Ben > > As per the show of hand at the last IETF meeting, quite a few of you are = familiar with this document. So can you please have a look at the latest ve= rsion and pass on your comments, or a brief statement like "I think it's re= ady" or "I think it needs rework before going further", so we can get expli= cit confirmation that the document is ready (or not) from the WG perspectiv= e. > > Thanks > > Francois & Rich > > > On 30 Jan 2012, at 14:37, Francois Le Faucheur wrote: > >> All, >> >> This is the start of a two-week working group last call on draft-ietf-cd= ni-use-cases-03.txt: >> https://datatracker.ietf.org/doc/draft-ietf-cdni-use-cases/ >> >> This working group last call will end 13 Feb 2012. Please send your comm= ents to the CDNI mailing list. >> >> Francois & Rich >> >> >> Begin forwarded message: >> >>> From: >>> Date: 30 January 2012 12:12:50 CET >>> To: >>> Subject: [CDNi] TR: I-D Action: draft-ietf-cdni-use-cases-03.txt >>> >>> Hi, >>> >>> We have submitted a revision addressing Kent's comments. >>> >>> http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-ie= tf-cdni-use-cases-02.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-cdni-us= e-cases-03.txt >>> >>> Best regards, >>> >>> Gilles >>> >>> >>> >>> >>> -----Message d'origine----- >>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de= internet-drafts@ietf.org >>> Envoy=E9 : lundi 30 janvier 2012 12:07 >>> =C0 : i-d-announce@ietf.org >>> Cc : cdni@ietf.org >>> Objet : [CDNi] I-D Action: draft-ietf-cdni-use-cases-03.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the Content Delivery Networks Interco= nnection Working Group of the IETF. >>> >>> Title : Use Cases for Content Delivery Network Interconne= ction >>> Author(s) : Gilles Bertrand >>> Stephan Emile >>> Grant Watson >>> Trevor Burbridge >>> Philip Eardley >>> Kevin Ma >>> Filename : draft-ietf-cdni-use-cases-03.txt >>> Pages : 18 >>> Date : 2012-01-30 >>> >>> Content Delivery Networks (CDNs) are commonly used for improving the >>> End User experience of a content delivery service, at a reasonable >>> cost. This document outlines real world use cases (not technical >>> solutions) for interconnecting CDNs. It focuses on use cases that >>> correspond to identified industry needs and that are expected to be >>> realized once a CDN Interconnection (CDNI) solution is available. >>> This document can be used to provide guidance to the CDNI WG about >>> the interconnection arrangements to be supported and to validate the >>> requirements of the various CDNI interfaces. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-03.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-03.txt >>> >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >> >> >> _______________________________________________ >> 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 hexiaoyan@huawei.com Sun Mar 4 19:25: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 3A22F21F8698 for ; Sun, 4 Mar 2012 19:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.346 X-Spam-Level: X-Spam-Status: No, score=-6.346 tagged_above=-999 required=5 tests=[AWL=0.253, 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 zRf76gYi6Lh0 for ; Sun, 4 Mar 2012 19:25:09 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 719BC21F8682 for ; Sun, 4 Mar 2012 19:25:09 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0E005FX6TOWM@szxga04-in.huawei.com> for cdni@ietf.org; Mon, 05 Mar 2012 11:25:01 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0E00A476TC6I@szxga04-in.huawei.com> for cdni@ietf.org; Mon, 05 Mar 2012 11:25:00 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHF55193; Mon, 05 Mar 2012 11:25:00 +0800 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 05 Mar 2012 11:24:21 +0800 Received: from w36710x (10.144.4.163) by smtpscn.huawei.com (10.82.67.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 05 Mar 2012 11:24:36 +0800 Date: Mon, 05 Mar 2012 11:23:50 +0800 From: HeXiaoyan In-reply-to: <62EB0429-81BC-4A57-A483-8638E7EE94DB@niven-jenkins.co.uk> X-Originating-IP: [10.144.4.163] To: 'Ben Niven-Jenkins' Message-id: <006a01ccfa7f$62ebe880$28c3b980$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: Acz6MwH0wJF5+zv8T2yyHGz/7YuvDgAR3ITQ X-CFilter-Loop: Reflected References: <005f01ccec9a$77e2c210$67a84630$@com> <62EB0429-81BC-4A57-A483-8638E7EE94DB@niven-jenkins.co.uk> Cc: cdni@ietf.org Subject: Re: [CDNi] FW: New Version Notification for draft-he-cdni-routing-request-redirection-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 03:25:10 -0000 Ben, You are right. Main content (redirection part) of the three drafts are = quite similar. Minor difference is the first version is an informational draft for = discussion which only includes redirection part, second version's intended status is standard track including redirection = and capability advertisement part. Third one is according the meeting's conclusion to divide redirection = and capability advertisement to two separate draft which therefore only = includes redirection part. Thanks for telling the convention, I'll pay attention to that. Best Regards Xiaoyan(Susan) He > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Monday, March 05, 2012 2:17 AM > To: HeXiaoyan > Cc: cdni@ietf.org > Subject: Re: [CDNi] FW: New Version Notification for > draft-he-cdni-routing-request-redirection-00.txt >=20 > On 16 Feb 2012, at 11:02, HeXiaoyan wrote: >=20 > > Hi all, > > We have submitted a draft on the routing request = redirection=EF=BC=88Recursive > mode=EF=BC=89 of RRI, > = http://datatracker.ietf.org/doc/draft-he-cdni-routing-request-redirection= / >=20 > I notice this is the third internet-draft that has now being published = on this > topic each with a different filename (the others being > draft-xiaoyan-cdni-request-routing-protocol and > draft-xiaoyan-cdni-requestrouting) and that many of the authors are = common > across all three drafts. >=20 > What is the relationship between the three drafts because from a = glance they > all look pretty similar? >=20 > Normal convention would be to just update the draft number between = revisions > not to publish under a new filename as that makes keeping track of = which is the > most up to date version significantly easier (as well helping track = the history of > things like IPR declarations as drafts move through the publication = process). >=20 > Thanks > Ben >=20 > > > > Your comments are welcome. > > > > Best Regards > > Xiaoyan(Susan) He > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Thursday, February 16, 2012 5:04 PM > > To: hexiaoyan@huawei.com > > Cc: cheng@gsta.com; hexiaoyan@huawei.com; > spencer.dawkins@wondermaster.com; niwei@chinamobile.com > > Subject: New Version Notification for > draft-he-cdni-routing-request-redirection-00.txt > > > > A new version of I-D, = draft-he-cdni-routing-request-redirection-00.txt has > been successfully submitted by Xiaoyan He and posted to the IETF = repository. > > > > Filename: draft-he-cdni-routing-request-redirection > > Revision: 00 > > Title: Routing Request Redirection for CDN Interconnection > > Creation date: 2012-02-16 > > WG ID: Individual Submission > > Number of pages: 13 > > > > Abstract: > > The Request Routing Interface comprises the asynchronous = advertisement > > of footprint and capabilities by a dCDN that allows a uCDN to = decide > whether > > to redirect particular user requests to that dCDN; and the = synchronous > operation > > of actually redirecting a user request. This document describes = protocol > for the > > part of user requests redirection. > > > > > > > > > > The IETF Secretariat > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From gilles.bertrand@orange.com Tue Mar 6 01:50:55 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 10B1621F86FF for ; Tue, 6 Mar 2012 01:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abUaUdgLjAfX for ; Tue, 6 Mar 2012 01:50:52 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAAF21F86B4 for ; Tue, 6 Mar 2012 01:50:52 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 43F885D91EB for ; Tue, 6 Mar 2012 10:50:51 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 3BB475D88DD for ; Tue, 6 Mar 2012 10:50:51 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 10:50:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Mar 2012 10:50:43 +0100 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF0330B60B@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-bertrand-cdni-footprint-discovery-00.txt Thread-Index: Acz6+QRxnvblsFg8TDG1aa4AYVgUlAAAAfzQAB+sVrA= From: To: X-OriginalArrivalTime: 06 Mar 2012 09:50:51.0039 (UTC) FILETIME=[9D4C82F0:01CCFB7E] Subject: [CDNi] TR: I-D Action: draft-bertrand-cdni-footprint-discovery-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, 06 Mar 2012 09:50:55 -0000 Hi everyone, I have submitted a new draft on CDN Footprint Discovery in CDNI. Its = main purpose is to present use cases for CDN Footprint Discovery in = CDNI. It provides a survey of existing work on the subject and a set = of additional requirements for controlling the exchange of Footprint = information. http://www.ietf.org/internet-drafts/draft-bertrand-cdni-footprint-discove= ry-00.txt=20 Any feedback is welcome. Cheers, Gilles=20 -----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 5 mars 2012 18:54 =C0=A0: = i-d-announce@ietf.org Objet=A0: I-D Action: = draft-bertrand-cdni-footprint-discovery-00.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : CDN Footprint Discovery Author(s) : Gilles Bertrand Filename : draft-bertrand-cdni-footprint-discovery-00.txt Pages : 13 Date : 2012-03-05 Interconnected CDNs need to exchange information on the set of end- users to which they can deliver content. This information is commonly referred to as "CDN Footprint". This memo presents use cases for CDN Footprint Discovery in CDNI. It provides a survey of existing work on the subject and a set of additional requirements for controlling the exchange of Footprint information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bertrand-cdni-footprint-discove= ry-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-bertrand-cdni-footprint-discover= y-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt From Jan.Seedorf@neclab.eu Tue Mar 6 08:10: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 57DC121F850F for ; Tue, 6 Mar 2012 08:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 OB8M-ywte+WQ for ; Tue, 6 Mar 2012 08:10:03 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 81AEC21F86CE for ; Tue, 6 Mar 2012 08:10:03 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id D55ED28000086 for ; Tue, 6 Mar 2012 17:10:02 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zu2ChUVVlfoI for ; Tue, 6 Mar 2012 17:10:02 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id BB0E928000084 for ; Tue, 6 Mar 2012 17:09:57 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.41]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 6 Mar 2012 17:09:53 +0100 From: Jan Seedorf To: "cdni@ietf.org" Thread-Topic: New draft on Semantics for CDNI Request Routing - Footprint and Capabilities Advertisement Thread-Index: Acz7s1q92FnFNKytTgaKbNcl4d1JmQ== Date: Tue, 6 Mar 2012 16:09:57 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24F15792@DAPHNIS.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] New draft on Semantics for CDNI Request Routing - Footprint and Capabilities 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: Tue, 06 Mar 2012 16:10:04 -0000 CDNI Folks, As discussed in Taipei, we have submitted a draft that tries to define the = semantics for the "Footprint and Capabilities Advertisement" part of CDNI R= equest Routing, see http://tools.ietf.org/html/draft-spp-cdni-rr-foot-cap-s= emantics-00. In Taipei, Martin had agreed to put effort into this (and inde= ed he started the draft, thanks!), but since he is currently busy with othe= r tasks, I have contributed some text together with Jon and Stefano. Curren= tly, the draft has a lot of open issues and questions, which is probably a = good thing to get discussions going. Abstract: This document tries to capture the semantics of the "Footprint and Capabili= ties Advertisment" part of the CDNI Request Routing interface, i.e. the des= ired meaning and what "Footprint and Capabilities Advertisment" is expected= to offer within CDNI. The discussion in this document has the goal to fac= ilitate the choosing of one or more suitable protocols for "Footprint and C= apabilities Advertisment" within CDNI Request Routing. If you can think of any other key questions/issues you think need to be dis= cussed (which are not contained in the draft yet), please let us know; we c= an add them in a future version and will try to remember them for the discu= ssion in Paris. Looking forward to comments and discussions, - Jan From richard_woundy@cable.comcast.com Tue Mar 6 15:52: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 80A4521E8015 for ; Tue, 6 Mar 2012 15:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.23 X-Spam-Level: X-Spam-Status: No, score=-101.23 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 sdTXrSGAW-Kz for ; Tue, 6 Mar 2012 15:52:09 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id C24C721E800F for ; Tue, 6 Mar 2012 15:52:07 -0800 (PST) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.8264455; Tue, 06 Mar 2012 16:40:55 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Tue, 6 Mar 2012 18:52:03 -0500 From: "Woundy, Richard" To: "cdni@ietf.org" Thread-Topic: Agenda requests for CDNI at IETF 83/Paris Thread-Index: Acz786Q7t9JGi63ARBCiAY/xMIthUg== Date: Tue, 6 Mar 2012 23:51:43 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD128972A84@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.96.69.110] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD128972A84PACDCEXMB05cabl_" MIME-Version: 1.0 Subject: [CDNi] Agenda requests for CDNI at IETF 83/Paris 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, 06 Mar 2012 23:52:11 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD128972A84PACDCEXMB05cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Please send us your agenda requests for the upcoming CDNI WG meeting at IET= F 83. Priority will be given to items on the charter, or to topics already = discussed on the list. If you have requests for agenda slots at the Paris meeting, please send the= m to Francois and me by March 12, identifying the draft, the length of the = scheduled slot and the name of the speaker. Note: please respond even if yo= u had replied to our earlier call for presentations (http://www.ietf.org/ma= il-archive/web/cdni/current/msg00788.html). Below are our upcoming deadlines: 2012-03-12 (Monday): Internet Draft final submission cut-off by 17:00 PT (U= TC -7) 2012-03-14 (Wednesday): Draft Working Group agendas due by 17:00 PT (UTC -7= ) Two timeslots have been scheduled for CDNI: Thursday, Afternoon Session I 1300-1500, Room Name: 252B Friday, Morning Session I 0900-1100, Room Name: 242AB -- Rich and Francois --_000_1CA25301D2219F40B3AA37201F0EACD128972A84PACDCEXMB05cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Please send us your agenda requests for the upcoming= CDNI WG meeting at IETF 83. Priority will be given to items on the charter= , or to topics already discussed on the list.

 

If you have requests for agenda slots at the Pari= s meeting, please send them to Francois and me by March 12, identifying the= draft, the length of the scheduled slot and the name of the speaker. Note:= please respond even if you had replied to our earlier call for presentations (http://www.ietf.org/mail-archive/w= eb/cdni/current/msg00788.html).

 

Below are our upcoming deadlines:

2012-03-12 (Monday): Internet Draft final submiss= ion cut-off by 17:00 PT (UTC -7)

2012-03-14 (Wednesday): Draft Working Group agend= as due by 17:00 PT (UTC -7)

 

Two timeslots have been scheduled for CDNI:<= /o:p>

    Thursday, Afternoon Session I = 1300-1500, Room Name: 252B

    Friday, Morning Session I 0900= -1100, Room Name: 242AB

 

-- Rich and Francois

--_000_1CA25301D2219F40B3AA37201F0EACD128972A84PACDCEXMB05cabl_-- From hexiaoyan@huawei.com Tue Mar 6 17:35: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 4C12521F8528 for ; Tue, 6 Mar 2012 17:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.159 X-Spam-Level: X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=0.440, 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 IYoTZHaHb14W for ; Tue, 6 Mar 2012 17:35:42 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id AB4FE21F848C for ; Tue, 6 Mar 2012 17:35:42 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0H008KWR3AV2@szxga04-in.huawei.com> for cdni@ietf.org; Wed, 07 Mar 2012 09:35:34 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0H00LU2R3AMD@szxga04-in.huawei.com> for cdni@ietf.org; Wed, 07 Mar 2012 09:35:34 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHH09365; Wed, 07 Mar 2012 09:35:34 +0800 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 07 Mar 2012 09:35:03 +0800 Received: from w36710x (10.144.4.163) by smtpscn.huawei.com (10.82.67.161) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 07 Mar 2012 09:35:29 +0800 Date: Wed, 07 Mar 2012 09:35:26 +0800 From: HeXiaoyan X-Originating-IP: [10.144.4.163] To: cdni@ietf.org Message-id: <00ab01ccfc02$93558010$ba008030$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Acz8AdEWM6XGpMaPQBSKprHUaf+MnQAABWPg X-CFilter-Loop: Reflected Subject: [CDNi] FW: New Version Notification for draft-he-cdni-cap-info-advertising-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, 07 Mar 2012 01:35:43 -0000 Hi all, Based on our discussion on the mailing list, I have upload a revision of our draft on capability advertising. https://datatracker.ietf.org/doc/draft-he-cdni-cap-info-advertising/ Your comments are welcome. Best Regards Xiaoyan(Susan) He -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Wednesday, March 07, 2012 9:30 AM To: hexiaoyan@huawei.com Cc: cheng@gsta.com; niwei@chinamobile.com; spencer@wonderhamster.org; zhangyunfei@chinamobile.com Subject: New Version Notification for draft-he-cdni-cap-info-advertising-01.txt A new version of I-D, draft-he-cdni-cap-info-advertising-01.txt has been successfully submitted by Xiaoyan He and posted to the IETF repository. Filename: draft-he-cdni-cap-info-advertising Revision: 01 Title: Capability Information Advertising for CDN Interconnection Creation date: 2012-03-06 WG ID: Individual Submission Number of pages: 20 Abstract: This document describes protocol for capability information advertising which is used to communicate capability and status information among interconnected Content Delivery Networks (CDNs). The IETF Secretariat From kleung@cisco.com Wed Mar 7 13:42: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 E773411E80AE for ; Wed, 7 Mar 2012 13:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.12 X-Spam-Level: X-Spam-Status: No, score=-9.12 tagged_above=-999 required=5 tests=[AWL=1.479, 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 ej6MW9Ug4aKT for ; Wed, 7 Mar 2012 13:42:47 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 900F311E8097 for ; Wed, 7 Mar 2012 13:42:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=3752; q=dns/txt; s=iport; t=1331156556; x=1332366156; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Aup48zJUOip8nJR3zWzx9tabLYezjWXEjv5s7vXw5B4=; b=RIq12fV9BIcfQH7FJCUOCRCaEu5Mrbj7LYocrAnGxqaqdeQEvCujCoXY nw2J7bCfx9/DB8g6vUIzBus4jYn7KqVRh3fM5t1cisjntOMnh0Jn61JJn pgX8iuDWJZHtQKXPLvbkMj50+FRNXpyJWtLcFry/H2g8CeDyYABh1a8HV 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD/VV0+rRDoI/2dsb2JhbAA6CrUmgQeCCgEBAQQBAQEPAR0KNBcEAgEIEQQBAQsGFwEGASYfCQgBAQQBCQkIGodlAQuaRAGfCooghWxjBIhSnQaDBA X-IronPort-AV: E=Sophos;i="4.73,548,1325462400"; d="scan'208";a="34913693" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 07 Mar 2012 21:42:36 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q27LgaAI009559; Wed, 7 Mar 2012 21:42:36 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Mar 2012 13:42:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Mar 2012 13:42:35 -0800 Message-ID: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 Thread-Index: Acz6RW+eUVGpJW97Q0aRcSdnKlM8ZwCVyDkw References: From: "Kent Leung (kleung)" To: "Ben Niven-Jenkins" , X-OriginalArrivalTime: 07 Mar 2012 21:42:36.0171 (UTC) FILETIME=[35F445B0:01CCFCAB] Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-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, 07 Mar 2012 21:42:48 -0000 Hi Ben. Thanks for your feedback. My comments below. -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: Sunday, March 04, 2012 12:29 PM To: cdni@ietf.org Subject: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 Authors, Some comments on draft-lefaucheur-cdni-logging-delivery-00. 1) In section 3.2.1.2 (Segment-Based Log fields) and section 3.2.2.1 (Event Based Log Triggers) you mandate support for a number of log fields such as abr-protocol, representation, manifest-id and content-id that a downstream CDN may have no ability to generate, for example because the downstream CDN is acting in a pure HTTP reverse proxy mode and may not be aware of that level of information and/or because the control of how to identify those fields is owned by the CSP and none of CDNs may have visibility of that mapping information. Such a requirement to force CDNs and CDNI in general to require such mappings seems overkill to me. KL> As stated, "... such aggregation requires a degree of application awareness in dCDN to recognize that the many HTTP requests correspond to a single video." So the premise is that the dCDN knows that it's delivering ABR content. In some cases, it's possible that the representation may not be known. But in general, the log fields contain information that are pertinent to an ABR content. 2) In section 6 you propose an additional requirement to allow an upstream CDN to indicate through CDNI metadata the log format the downstream CDN should use. Rather than define a set of specific formats, we could allow the upstream CDN to specify CDNI metadata indicating the specific log fields it is interested in receiving. The upstream CDN could then tailor what it asks for according to what it requires and avoid the transfer of log fields that it does not need. KL> Agree that it's useful for uCDN to request only the information that's needed without extraneous fields. This can be accomplished with a customized log format provided by uCDN. In a sense, this is a superset of selective fields. 3) Although you do not yet specify a particular log digest format it would seem reasonable to me to reuse the W3C model (http://www.w3.org/TR/WD-logfile.html) and also to use the W3C convention for log field prefixes such as c-, cs-, etc. KL> Right, the specific format is not specified. This reference seems reasonable to me. 4) If the motivation for summary/aggregated log lines is a concern over the volume of data that needs to be transferred then in Velocix we have done some experiments on using an alternative lookup table based structure for log lines that retains all the verbosity of the original delivery log lines but by itself appears to give equivalent compression to gzip and combined with gzip reduces the size significantly when compared to what gzip alone achieves (in some cases averaging as little as 13 bits per complete log line). If the volume of logs to be transferred is a concern and there is interest in investigating this approach further I can write-up more details either in a separate draft or as a section in draft-lefaucheur-cdni-logging-delivery. KL> I think the intent is to summarize succinctly the ABR session in the logging. I haven't discussed this in finer details with Francois yet. It seems to me that the compression technique can be considered as optimization in delivery of either session-based or event-based logging. We can discuss this further if our goals are aligned. Kent Ben _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From ben@niven-jenkins.co.uk Wed Mar 7 14:27: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 F3A8611E809D for ; Wed, 7 Mar 2012 14:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.374 X-Spam-Level: X-Spam-Status: No, score=-103.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiN3x13LTjKC for ; Wed, 7 Mar 2012 14:27:03 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id B9EBF11E8074 for ; Wed, 7 Mar 2012 14:27:02 -0800 (PST) Received: from cpc10-cmbg15-2-0-cust121.5-4.cable.virginmedia.com ([86.30.246.122] helo=[192.168.0.4]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1S5PK0-0007oS-T3; Wed, 07 Mar 2012 22:27:01 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com> Date: Wed, 7 Mar 2012 22:27:00 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com> To: "Kent Leung (kleung)" X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-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, 07 Mar 2012 22:27:04 -0000 Kent, On 7 Mar 2012, at 21:42, Kent Leung (kleung) wrote: > Hi Ben. Thanks for your feedback. My comments below. >=20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of >=20 > Some comments on draft-lefaucheur-cdni-logging-delivery-00. >=20 > 1) In section 3.2.1.2 (Segment-Based Log fields) and section 3.2.2.1 > (Event Based Log Triggers) you mandate support for a number of log > fields such as abr-protocol, representation, manifest-id and = content-id > that a downstream CDN may have no ability to generate, for example > because the downstream CDN is acting in a pure HTTP reverse proxy mode > and may not be aware of that level of information and/or because the > control of how to identify those fields is owned by the CSP and none = of > CDNs may have visibility of that mapping information. >=20 > Such a requirement to force CDNs and CDNI in general to require such > mappings seems overkill to me. >=20 > KL> As stated, "... such aggregation requires a degree of application > awareness in dCDN to recognize that the many HTTP requests correspond = to > a single video." So the premise is that the dCDN knows that it's > delivering ABR content. In some cases, it's possible that the > representation may not be known. And my point is that I don't think that premise holds true and reality = is the opposite, i.e. in general the dCDN will not know what it's = delivering and only some dCDNs will have the application awareness to = produce the log fields you suggest. > But in general, the log fields contain > information that are pertinent to an ABR content. I am not exactly sure what you mean by this. I agree the fields you = suggest would be useful but I don't think having the application = awareness to generate them should be a mandatory requirement for = interoperability as suggested by section 3.2 An implementation of the CDNI Logging interface MUST support logging for delivery of content using HTTP adaptive streaming in the Segment- Based Logging format and the Event-Based Logging format, and MAY support logging in the Summary-Based Logging format. > 2) In section 6 you propose an additional requirement to allow an > upstream CDN to indicate through CDNI metadata the log format the > downstream CDN should use. Rather than define a set of specific = formats, > we could allow the upstream CDN to specify CDNI metadata indicating = the > specific log fields it is interested in receiving. The upstream CDN > could then tailor what it asks for according to what it requires and > avoid the transfer of log fields that it does not need. >=20 > KL> Agree that it's useful for uCDN to request only the information > that's needed without extraneous fields. This can be accomplished with = a > customized log format provided by uCDN. In a sense, this is a superset > of selective fields. That is another approach which would probably make life easier for the = dCDN. > 4) If the motivation for summary/aggregated log lines is a concern = over > the volume of data that needs to be transferred then in Velocix we = have > done some experiments on using an alternative lookup table based > structure for log lines that retains all the verbosity of the original > delivery log lines but by itself appears to give equivalent = compression > to gzip and combined with gzip reduces the size significantly when > compared to what gzip alone achieves (in some cases averaging as = little > as 13 bits per complete log line). >=20 > If the volume of logs to be transferred is a concern and there is > interest in investigating this approach further I can write-up more > details either in a separate draft or as a section in > draft-lefaucheur-cdni-logging-delivery. >=20 > KL> I think the intent is to summarize succinctly the ABR session in = the > logging. I think they're two separate things. If we're worried about the volume = of data our experiments show that can be significantly reduced using = structured log files with lookup tables. That technique is applicable = regardless of the actual fields in a log file. Whether we require ABR session summary information to be logged is a = separate discussion to how we might optimise the structure of any log = files we require. Ben > I haven't discussed this in finer details with Francois yet. It > seems to me that the compression technique can be considered as > optimization in delivery of either session-based or event-based = logging. > We can discuss this further if our goals are aligned. >=20 > Kent >=20 > Ben > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From Jan.Seedorf@neclab.eu Thu Mar 8 08:16: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 85E5121F8650 for ; Thu, 8 Mar 2012 08:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 VIXyi45AlSDj for ; Thu, 8 Mar 2012 08:16:43 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 81F1221F852E for ; Thu, 8 Mar 2012 08:16:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 2A30B1007C2; Thu, 8 Mar 2012 17:16:38 +0100 (CET) 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 zwYepQvQMw29; Thu, 8 Mar 2012 17:16:38 +0100 (CET) Received: from ENCELADUS.office.hd (unknown [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 10761100792; Thu, 8 Mar 2012 17:16:28 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.41]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Thu, 8 Mar 2012 17:16:32 +0100 From: Jan Seedorf To: "gilles.bertrand@orange.com" , "cdni@ietf.org" Thread-Topic: [CDNi] TR: I-D Action: draft-bertrand-cdni-footprint-discovery-00.txt Thread-Index: Acz6+QRxnvblsFg8TDG1aa4AYVgUlAAAAfzQAB+sVrAAc7slcA== Date: Thu, 8 Mar 2012 16:16:32 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24F168FA@DAPHNIS.office.hd> References: <8E09C72DBC577D489F13A71228C0B7BF0330B60B@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF0330B60B@ftrdmel0.rd.francetelecom.fr> 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] TR: I-D Action: draft-bertrand-cdni-footprint-discovery-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, 08 Mar 2012 16:16:44 -0000 Gilles, Just a short question: Is "CDN Footprint Discovery" the opposite direction = of "CDN Footprint advertisement", or how are the terms related? - Jan > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > gilles.bertrand@orange.com > Sent: Tuesday, March 06, 2012 10:51 AM > To: cdni@ietf.org > Subject: [CDNi] TR: I-D Action: draft-bertrand-cdni-footprint-discovery-0= 0.txt >=20 > Hi everyone, >=20 > I have submitted a new draft on CDN Footprint Discovery in CDNI. Its main > purpose is to present use cases for CDN Footprint Discovery in CDNI. It > provides a survey of existing work on the subject and a set of addition= al > requirements for controlling the exchange of Footprint information. >=20 > http://www.ietf.org/internet-drafts/draft-bertrand-cdni-footprint- > discovery-00.txt >=20 > Any feedback is welcome. >=20 > Cheers, >=20 > Gilles >=20 >=20 > -----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: lun= di 5 > mars 2012 18:54 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft= -bertrand- > cdni-footprint-discovery-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 > Title : CDN Footprint Discovery > Author(s) : Gilles Bertrand > Filename : draft-bertrand-cdni-footprint-discovery-00.txt > Pages : 13 > Date : 2012-03-05 >=20 > Interconnected CDNs need to exchange information on the set of end- > users to which they can deliver content. This information is > commonly referred to as "CDN Footprint". This memo presents use > cases for CDN Footprint Discovery in CDNI. It provides a survey of > existing work on the subject and a set of additional requirements for > controlling the exchange of Footprint information. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bertrand-cdni-footprint- > discovery-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-bertrand-cdni-footprint-discover= y- > 00.txt >=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 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From Jan.Seedorf@neclab.eu Thu Mar 8 08:38: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 EF17721F86CB for ; Thu, 8 Mar 2012 08:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 13LE0zBAQel9 for ; Thu, 8 Mar 2012 08:38:27 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id BDCEE21F86D0 for ; Thu, 8 Mar 2012 08:38:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 87E06100792; Thu, 8 Mar 2012 17:38:13 +0100 (CET) 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 3no7jDyfoMW8; Thu, 8 Mar 2012 17:38:13 +0100 (CET) Received: from METHONE.office.hd (unknown [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 6AF241007C2; Thu, 8 Mar 2012 17:37:48 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.41]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 8 Mar 2012 17:37:27 +0100 From: Jan Seedorf To: stefano previdi Thread-Topic: Questions on draft-previdi-cdni-footprint-advertisement-00 Thread-Index: Acz2Lv2ue6S3SGEmQby1HP94jyog0QACrzaAAAAnyQABw1j8gA== Date: Thu, 8 Mar 2012 16:37:31 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24F1695D@DAPHNIS.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE24F11D2A@DAPHNIS.office.hd> <075049AD-E2B9-40DA-8900-F54E7B6AF64E@cisco.com> In-Reply-To: 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: "Jan Medved \(jmedved\)" , "cdni@ietf.org" Subject: Re: [CDNi] Questions on draft-previdi-cdni-footprint-advertisement-00 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 16:38:28 -0000 Hi Stefano, Thanks for your answers. It clarified a lot, and I am waiting for your upda= ted draft which hopefully will make things even more clear for me. One thing that is not clear for me yet (excuse me, I am not a BGP expert): = The semantics of a community value field, i.e. is it like a PID (a grouping= ), or like a cost value (a quantifying parameter for some type/metric)? - Jan > -----Original Message----- > From: stefano previdi [mailto:sprevidi@cisco.com] > Sent: Tuesday, February 28, 2012 7:00 PM > To: Jan Seedorf > Cc: Francois Le Faucheur (flefauch); Allan GUILLOU; Jan Medved (jmedved); > cdni@ietf.org > Subject: Re: Questions on draft-previdi-cdni-footprint-advertisement-00 >=20 > >=20 >=20 > On Feb 28, 2012, at 6:55 PM, stefano previdi wrote: >=20 > Hi Jan, >=20 > I'm in the process of submitting version 01 which has some changes in > terminology and encoding options. I'll try to address your questions > below. >=20 > On Feb 28, 2012, at 5:14 PM, Jan Seedorf wrote: > > Dear authors of the BGP CDNI Footprint Advertisement draft, > > > > I have some questions, maybe you can clarify: > > -- BGP communities are currently used per AS, e.g. 100:500 means AS 100= is > attaching a value of 100 to a given route. >=20 >=20 > to be more precise, in your example AS100 is attaching a value of 500. >=20 >=20 > > In your scheme, do you intend to use communities per footprint identifi= er, > e.g. 100:200:300 means AS 100 is attaching a value of 300 for footprint > identifier 100:200? >=20 >=20 > not really. We propose the use of BGP Extended community (RFC4360) for > FPE Identifiers. >=20 >=20 > > -- section 4.2.3 says " The CDNI Connectivity Advertisement contains a = new > (TBD) attribute called Origin_AS_PATH that contains the AS_PATH value > describing the distance (expressed in AS Hop Count) between the CDN and > the advertised connected footprint."; in the examples in section 7, howev= er, > Origin_AS_PATH is not the AS hop count but the ID of the source AS; I > assume it is a mistake in the example, correct? >=20 >=20 > nope, the example is correct. AS_PATH Attribute in BGP contains the list > of AS# the update traversed. AS hop-count is computed when you process > the update. >=20 > Origin_AS_PATH has the same format. >=20 >=20 > > -- in your scheme, how can you explicitly express costs (e.g. latency, > bandwidth, monetary costs, ...) to a certain footprint identifier? I unde= rstand > a ranking, but it is not clear to me how you express explicit costs. Via = an > extended community value per footprint identifier? >=20 >=20 > BGP distane is based on AS hop-count. THere's no topology involved (as yo= u > rarely exchange topology between ASs). >=20 > However, nothing prevents to use BGP attributes (MED, Communities) in > order > to represent preferences that could also be based on costs. >=20 >=20 > > -- what is confusing to me is that original BGP connectivity refers to = AS-level > routing, while CDN connectivity to me is (in principle) quite independent > from AS-level routing. >=20 >=20 > We use a tool called BGP but we use it in the CDNI context. >=20 > So, the messaging and the signaling will reflect the shape of the CDNI Me= sh > and not the Internet mesh. >=20 >=20 > > For instance, I can very well imagine 2 CDNs which have a direct bilate= ral > CDN-interconnection agreement, but which have many AS-hops between > their footprints. So the connectivity via AS-level BGP footprints is very > confusing to me. Maybe you can explain it. >=20 >=20 > AS number (in the CDNI context) refers to the CDN using such AS number. > The different CDN BGP sessions you will have will tell you about all CDN > interconnectivity. This is not related to the underneath inter-AS > connectivity. >=20 > In the new draft I also include a topology example that, hopefully, will > help... >=20 > s. >=20 >=20 > > > > > > Thanks for answering, > > > > - Jan > > >=20 >=20 From sprevidi@cisco.com Thu Mar 8 08:44: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 F0A5321F86B6 for ; Thu, 8 Mar 2012 08:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 qnPUmxUsvE+T for ; Thu, 8 Mar 2012 08:44:42 -0800 (PST) Received: from av-tac-sj.cisco.com (firebird.cisco.com [171.68.227.73]) by ietfa.amsl.com (Postfix) with ESMTP id EE61921F8693 for ; Thu, 8 Mar 2012 08:44:41 -0800 (PST) X-TACSUNS: Virus Scanned Received: from bonfire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q28GieQT026411 for ; Thu, 8 Mar 2012 08:44:41 -0800 (PST) Received: from dhcp-10-155-68-224.cisco.com (dhcp-10-155-68-224.cisco.com [10.155.68.224]) by bonfire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q28GidI8022271; Thu, 8 Mar 2012 08:44:39 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: stefano previdi In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE24F1695D@DAPHNIS.office.hd> Date: Thu, 8 Mar 2012 17:44:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2779C9F0771F974CAD742BAE6D9904FE24F11D2A@DAPHNIS.office.hd> <075049AD-E2B9-40DA-8900-F54E7B6AF64E@cisco.com> <2779C9F0771F974CAD742BAE6D9904FE24F1695D@DAPHNIS.office.hd> To: Jan Seedorf X-Mailer: Apple Mail (2.1257) Cc: "Jan Medved \(jmedved\)" , "cdni@ietf.org" Subject: Re: [CDNi] Questions on draft-previdi-cdni-footprint-advertisement-00 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 16:44:43 -0000 On Mar 8, 2012, at 5:37 PM, Jan Seedorf wrote: > Hi Stefano, >=20 > Thanks for your answers. It clarified a lot, and I am waiting for your = updated draft which hopefully will make things even more clear for me. >=20 > One thing that is not clear for me yet (excuse me, I am not a BGP = expert): The semantics of a community value field, i.e. is it like a PID = (a grouping), or like a cost value (a quantifying parameter for some = type/metric)? in BGP, a community is a tag you assign to a given prefix. There's=20 no semantic in the attribute (unless specified for reserved community=20 numbers). If you take the analogy with ALTO, a community can be easily used as=20 a PID in order to group prefixes. I know a deployed ALTO implementation that does it... ;-) s. > - Jan >=20 >> -----Original Message----- >> From: stefano previdi [mailto:sprevidi@cisco.com] >> Sent: Tuesday, February 28, 2012 7:00 PM >> To: Jan Seedorf >> Cc: Francois Le Faucheur (flefauch); Allan GUILLOU; Jan Medved = (jmedved); >> cdni@ietf.org >> Subject: Re: Questions on = draft-previdi-cdni-footprint-advertisement-00 >>=20 >> >>=20 >>=20 >> On Feb 28, 2012, at 6:55 PM, stefano previdi wrote: >>=20 >> Hi Jan, >>=20 >> I'm in the process of submitting version 01 which has some changes in >> terminology and encoding options. I'll try to address your questions >> below. >>=20 >> On Feb 28, 2012, at 5:14 PM, Jan Seedorf wrote: >>> Dear authors of the BGP CDNI Footprint Advertisement draft, >>>=20 >>> I have some questions, maybe you can clarify: >>> -- BGP communities are currently used per AS, e.g. 100:500 means AS = 100 is >> attaching a value of 100 to a given route. >>=20 >>=20 >> to be more precise, in your example AS100 is attaching a value of = 500. >>=20 >>=20 >>> In your scheme, do you intend to use communities per footprint = identifier, >> e.g. 100:200:300 means AS 100 is attaching a value of 300 for = footprint >> identifier 100:200? >>=20 >>=20 >> not really. We propose the use of BGP Extended community (RFC4360) = for >> FPE Identifiers. >>=20 >>=20 >>> -- section 4.2.3 says " The CDNI Connectivity Advertisement contains = a new >> (TBD) attribute called Origin_AS_PATH that contains the AS_PATH value >> describing the distance (expressed in AS Hop Count) between the CDN = and >> the advertised connected footprint."; in the examples in section 7, = however, >> Origin_AS_PATH is not the AS hop count but the ID of the source AS; I >> assume it is a mistake in the example, correct? >>=20 >>=20 >> nope, the example is correct. AS_PATH Attribute in BGP contains the = list >> of AS# the update traversed. AS hop-count is computed when you = process >> the update. >>=20 >> Origin_AS_PATH has the same format. >>=20 >>=20 >>> -- in your scheme, how can you explicitly express costs (e.g. = latency, >> bandwidth, monetary costs, ...) to a certain footprint identifier? I = understand >> a ranking, but it is not clear to me how you express explicit costs. = Via an >> extended community value per footprint identifier? >>=20 >>=20 >> BGP distane is based on AS hop-count. THere's no topology involved = (as you >> rarely exchange topology between ASs). >>=20 >> However, nothing prevents to use BGP attributes (MED, Communities) in >> order >> to represent preferences that could also be based on costs. >>=20 >>=20 >>> -- what is confusing to me is that original BGP connectivity refers = to AS-level >> routing, while CDN connectivity to me is (in principle) quite = independent >> from AS-level routing. >>=20 >>=20 >> We use a tool called BGP but we use it in the CDNI context. >>=20 >> So, the messaging and the signaling will reflect the shape of the = CDNI Mesh >> and not the Internet mesh. >>=20 >>=20 >>> For instance, I can very well imagine 2 CDNs which have a direct = bilateral >> CDN-interconnection agreement, but which have many AS-hops between >> their footprints. So the connectivity via AS-level BGP footprints is = very >> confusing to me. Maybe you can explain it. >>=20 >>=20 >> AS number (in the CDNI context) refers to the CDN using such AS = number. >> The different CDN BGP sessions you will have will tell you about all = CDN >> interconnectivity. This is not related to the underneath inter-AS >> connectivity. >>=20 >> In the new draft I also include a topology example that, hopefully, = will >> help... >>=20 >> s. >>=20 >>=20 >>>=20 >>>=20 >>> Thanks for answering, >>>=20 >>> - Jan >>>=20 >>=20 >>=20 >=20 >=20 From sprevidi@cisco.com Thu Mar 8 13:23: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 0485C21E8046 for ; Thu, 8 Mar 2012 13:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 32vYsYnDDoVJ for ; Thu, 8 Mar 2012 13:23:27 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E059A21E8067 for ; Thu, 8 Mar 2012 13:23:26 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q28LNPmH023243 for ; Thu, 8 Mar 2012 22:23:25 +0100 (CET) Received: from dhcp-10-55-81-86.cisco.com (dhcp-10-55-81-86.cisco.com [10.55.81.86]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q28LNMNZ007402 for ; Thu, 8 Mar 2012 22:23:23 +0100 (CET) From: stefano previdi Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Mar 2012 22:23:21 +0100 References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com> To: cdni@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [CDNi] Fwd: New Version Notification for draft-previdi-cdni-footprint-advertisement-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, 08 Mar 2012 21:23:28 -0000 Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt > Date: March 8, 2012 8:45:53 PM GMT+01:00 > To: sprevidi@cisco.com > Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com >=20 > A new version of I-D, = draft-previdi-cdni-footprint-advertisement-01.txt has been successfully = submitted by Stefano Previdi and posted to the IETF repository. >=20 > Filename: draft-previdi-cdni-footprint-advertisement > Revision: 01 > Title: CDNI Footprint Advertisement > Creation date: 2012-03-08 > WG ID: Individual Submission > Number of pages: 27 >=20 > Abstract: > This document describes the use of BGP for Content Delivery Networks > (CDNs) in order to advertise information about footprint and > connectivity to footprint in the context of CDNI. >=20 >=20 >=20 > This draft is for the CDNI Working Group. >=20 > Thanks. > s. >=20 > The IETF Secretariat >=20 From grant.watson@bt.com Thu Mar 8 14:17: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 DB7BE21F85A8 for ; Thu, 8 Mar 2012 14:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.683 X-Spam-Level: X-Spam-Status: No, score=-2.683 tagged_above=-999 required=5 tests=[AWL=0.916, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxUlCF+26eLb for ; Thu, 8 Mar 2012 14:17:59 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABC121F85A7 for ; Thu, 8 Mar 2012 14:17:58 -0800 (PST) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 8 Mar 2012 22:17:58 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.101]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Thu, 8 Mar 2012 22:17:57 +0000 From: To: , Date: Thu, 8 Mar 2012 22:17:56 +0000 Thread-Topic: [CDNi] Fwd: New Version Notification for draft-previdi-cdni-footprint-advertisement-01.txt Thread-Index: Acz9cbeCVVxQ/9YWTza3TU9+u/NkcgABe5VJ Message-ID: <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net> References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Fwd: New Version Notification for draft-previdi-cdni-footprint-advertisement-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, 08 Mar 2012 22:18:00 -0000 Hi, The document talks about "Capability Advertisements" and the proposal to us= e MP-BGP messages to advertise/exchange CDN capabilities. However, the docu= ment does not explicitly define what is ment by "CDN Capability". I understand "CDN Capability" to mean things like delivery technology (for = example RTMP or HTTP etc.) or perhaps a specific form of content authorisat= ion etc. Can you confirm I am correct in assuming this or if not clarify wh= at the correct meaning is. Cheers, g- ________________________________________ From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf Of stefano pr= evidi [sprevidi@cisco.com] Sent: 08 March 2012 21:23 To: cdni@ietf.org Subject: [CDNi] Fwd: New Version Notification for draft-previdi-cdni-= footprint-advertisement-01.txt Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-previdi-cdni-footprint-advert= isement-01.txt > Date: March 8, 2012 8:45:53 PM GMT+01:00 > To: sprevidi@cisco.com > Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com > > A new version of I-D, draft-previdi-cdni-footprint-advertisement-01.txt h= as been successfully submitted by Stefano Previdi and posted to the IETF re= pository. > > Filename: draft-previdi-cdni-footprint-advertisement > Revision: 01 > Title: CDNI Footprint Advertisement > Creation date: 2012-03-08 > WG ID: Individual Submission > Number of pages: 27 > > Abstract: > This document describes the use of BGP for Content Delivery Networks > (CDNs) in order to advertise information about footprint and > connectivity to footprint in the context of CDNI. > > > > This draft is for the CDNI Working Group. > > Thanks. > s. > > The IETF Secretariat > _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni= From ina@juniper.net Thu Mar 8 14:43: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 B808D21E8051 for ; Thu, 8 Mar 2012 14:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.242 X-Spam-Level: X-Spam-Status: No, score=-6.242 tagged_above=-999 required=5 tests=[AWL=0.357, 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 up3IAQermCqv for ; Thu, 8 Mar 2012 14:43:06 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id E432321E8050 for ; Thu, 8 Mar 2012 14:43:05 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKT1k1+Kgdfvaww2RBnZKYkwcZxDVp0I8k@postini.com; Thu, 08 Mar 2012 14:43:06 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 8 Mar 2012 14:42:47 -0800 From: Ina Minei To: stefano previdi , "cdni@ietf.org" Date: Thu, 8 Mar 2012 14:42:46 -0800 Thread-Topic: Questions on draft-previdi-cdni-footprint-advertisement-01.txt Thread-Index: Acz9cbc4U3WHwOuqQpObCUsIg5+/JQACg/CA Message-ID: <189716C74BBB9C4095FE8CA503B1FC3A5784C3188C@EMBX02-HQ.jnpr.net> References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Questions on draft-previdi-cdni-footprint-advertisement-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, 08 Mar 2012 22:43:06 -0000 Stefano,=20 A few questions regarding the new section on capabilities advertisements: 1. Can you list some example capabilities that you are thinking about? 2. Who/how is the mapping made between the capabilities and the communities= that represent them and how is this maintained consistent across the mesh?= (which is under different admin domains) 3. Can capabilities really be expressed as a community or is a more flexibl= e encoding needed? (I guess I am wondering what you mean by capabilities) 3. The advertisement is for a prefix in the CDN footprint - this implies th= at when reachability changes for that footprint, capabilities are readverti= sed, though nothing changes for the CDN itself. This is probably not ideal.= Was wondering if you can explain a bit that choice, and if instead the cdn= id can be used.=20 Thank you,=20 Ina=20 -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of ste= fano previdi Sent: Thursday, March 08, 2012 1:23 PM To: cdni@ietf.org Subject: [CDNi] Fwd: New Version Notification for draft-previdi-cdni-footpr= int-advertisement-01.txt Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-previdi-cdni-footprint-advert= isement-01.txt > Date: March 8, 2012 8:45:53 PM GMT+01:00 > To: sprevidi@cisco.com > Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com >=20 > A new version of I-D, draft-previdi-cdni-footprint-advertisement-01.txt h= as been successfully submitted by Stefano Previdi and posted to the IETF re= pository. >=20 > Filename: draft-previdi-cdni-footprint-advertisement > Revision: 01 > Title: CDNI Footprint Advertisement > Creation date: 2012-03-08 > WG ID: Individual Submission > Number of pages: 27 >=20 > Abstract: > This document describes the use of BGP for Content Delivery Networks > (CDNs) in order to advertise information about footprint and > connectivity to footprint in the context of CDNI. >=20 >=20 >=20 > This draft is for the CDNI Working Group. >=20 > Thanks. > s. >=20 > The IETF Secretariat >=20 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From kleung@cisco.com Thu Mar 8 15:48: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 DEB1721F8504 for ; Thu, 8 Mar 2012 15:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.416 X-Spam-Level: X-Spam-Status: No, score=-9.416 tagged_above=-999 required=5 tests=[AWL=1.183, 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 Jl+IZasDismM for ; Thu, 8 Mar 2012 15:48:52 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id F124B21F84FF for ; Thu, 8 Mar 2012 15:48:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=5174; q=dns/txt; s=iport; t=1331250532; x=1332460132; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=1r3HT/5QdER84LncQq6tbHMgJcgafg17CfAWQ3+Pt+M=; b=jvFLhJuIsx4VDnEa1i/juqP7Hyr6jMICopP8Js2hASyomGzaNdyvySsE AN2ykEFT/6qW5RodPLVYHqH9p1cq+we/JotOxyvJhWxBd2gXSWnUr4Zex JPUQqfSS4qDvizX+W80aXoO1e8mW9QiboceU/Mzn687J7324d+dqfa6d4 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD1FWU+rRDoG/2dsb2JhbAA4CrU2gQeCCgEBAQMBAQEBDwEdCjQLBQcEAgEIFQ0GFwEGASYfEQEBBAoJCBEJh2MEAQugCwGXAgSKH4VUYwSIUp0LgwQ X-IronPort-AV: E=Sophos;i="4.73,554,1325462400"; d="scan'208";a="35105576" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 08 Mar 2012 23:48:38 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q28Nmc99017888; Thu, 8 Mar 2012 23:48:38 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 15:48:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Mar 2012 15:48:37 -0800 Message-ID: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 Thread-Index: Acz8sWvMMLqudGQ2RZyCnhMZ9OyjLgA0PeZA References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com> From: "Kent Leung (kleung)" To: "Ben Niven-Jenkins" X-OriginalArrivalTime: 08 Mar 2012 23:48:38.0673 (UTC) FILETIME=[FBF84010:01CCFD85] Cc: cdni@ietf.org Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-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, 08 Mar 2012 23:48:53 -0000 Comments below. >=20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of >=20 > Some comments on draft-lefaucheur-cdni-logging-delivery-00. >=20 > 1) In section 3.2.1.2 (Segment-Based Log fields) and section 3.2.2.1 > (Event Based Log Triggers) you mandate support for a number of log > fields such as abr-protocol, representation, manifest-id and content-id > that a downstream CDN may have no ability to generate, for example > because the downstream CDN is acting in a pure HTTP reverse proxy mode > and may not be aware of that level of information and/or because the > control of how to identify those fields is owned by the CSP and none of > CDNs may have visibility of that mapping information. >=20 > Such a requirement to force CDNs and CDNI in general to require such > mappings seems overkill to me. >=20 > KL> As stated, "... such aggregation requires a degree of application > awareness in dCDN to recognize that the many HTTP requests correspond to > a single video." So the premise is that the dCDN knows that it's > delivering ABR content. In some cases, it's possible that the > representation may not be known. And my point is that I don't think that premise holds true and reality is the opposite, i.e. in general the dCDN will not know what it's delivering and only some dCDNs will have the application awareness to produce the log fields you suggest. KL> Hmm, if the dCDN is not aware about the ABR session, then Section 3.2 would not apply since the dCDN considers itself to be delivering non-ABR content. Non-ABR content delivery does not require the log fields specified in this section. > But in general, the log fields contain > information that are pertinent to an ABR content. I am not exactly sure what you mean by this. I agree the fields you suggest would be useful but I don't think having the application awareness to generate them should be a mandatory requirement for interoperability as suggested by section 3.2 An implementation of the CDNI Logging interface MUST support logging for delivery of content using HTTP adaptive streaming in the Segment- Based Logging format and the Event-Based Logging format, and MAY support logging in the Summary-Based Logging format. KL> Are these fields in Sect 3.2 useful or applicable for non-ABR content delivery? No. I sense that I'm still missing your point. > 2) In section 6 you propose an additional requirement to allow an > upstream CDN to indicate through CDNI metadata the log format the > downstream CDN should use. Rather than define a set of specific formats, > we could allow the upstream CDN to specify CDNI metadata indicating the > specific log fields it is interested in receiving. The upstream CDN > could then tailor what it asks for according to what it requires and > avoid the transfer of log fields that it does not need. >=20 > KL> Agree that it's useful for uCDN to request only the information > that's needed without extraneous fields. This can be accomplished with a > customized log format provided by uCDN. In a sense, this is a superset > of selective fields. That is another approach which would probably make life easier for the dCDN. > 4) If the motivation for summary/aggregated log lines is a concern over > the volume of data that needs to be transferred then in Velocix we have > done some experiments on using an alternative lookup table based > structure for log lines that retains all the verbosity of the original > delivery log lines but by itself appears to give equivalent compression > to gzip and combined with gzip reduces the size significantly when > compared to what gzip alone achieves (in some cases averaging as little > as 13 bits per complete log line). >=20 > If the volume of logs to be transferred is a concern and there is > interest in investigating this approach further I can write-up more > details either in a separate draft or as a section in > draft-lefaucheur-cdni-logging-delivery. >=20 > KL> I think the intent is to summarize succinctly the ABR session in the > logging. I think they're two separate things. If we're worried about the volume of data our experiments show that can be significantly reduced using structured log files with lookup tables. That technique is applicable regardless of the actual fields in a log file. Whether we require ABR session summary information to be logged is a separate discussion to how we might optimise the structure of any log files we require. Ben KL> Sure, I think we can discuss more on this when Francois is available as I'm not clear on his thoughts. Kent > I haven't discussed this in finer details with Francois yet. It > seems to me that the compression technique can be considered as > optimization in delivery of either session-based or event-based logging. > We can discuss this further if our goals are aligned. >=20 > Kent >=20 > Ben > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From Jan.Seedorf@neclab.eu Fri Mar 9 00:32: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 4382521F8576 for ; Fri, 9 Mar 2012 00:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 4bhhMl0UiJfd for ; Fri, 9 Mar 2012 00:32:41 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 64CA021F8569 for ; Fri, 9 Mar 2012 00:32:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id E38E01007DB; Fri, 9 Mar 2012 09:32:32 +0100 (CET) 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 VZkFd7S0zpbu; Fri, 9 Mar 2012 09:32:32 +0100 (CET) Received: from ENCELADUS.office.hd (unknown [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id C60461006E9; Fri, 9 Mar 2012 09:32:17 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.41]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Fri, 9 Mar 2012 09:32:25 +0100 From: Jan Seedorf To: "grant.watson@bt.com" , "sprevidi@cisco.com" , "cdni@ietf.org" Thread-Topic: [CDNi] Fwd: New Version Notification for draft-previdi-cdni-footprint-advertisement-01.txt Thread-Index: AQHM/XlmOIApnnu8iU+hAIIf6U65LpZhos1A Date: Fri, 9 Mar 2012 08:32:24 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24F18202@DAPHNIS.office.hd> References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net> In-Reply-To: <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Fwd: New Version Notification for draft-previdi-cdni-footprint-advertisement-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: Fri, 09 Mar 2012 08:32:42 -0000 Grant, I am not speaking for draft-previdi-cdni-footprint-advertisement (since I a= m not a co-author of that draft), but in general, we are having a broader d= iscussion on what we (the CDNI WG) mean by capabilities, see http://tools.ietf.org/html/draft-spp-cdni-rr-foot-cap-semantics-00 - Jan > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > grant.watson@bt.com > Sent: Thursday, March 08, 2012 11:18 PM > To: sprevidi@cisco.com; cdni@ietf.org > Subject: Re: [CDNi] Fwd: New Version Notification for draft-previdi-cdni- > footprint-advertisement-01.txt >=20 >=20 > Hi, >=20 > The document talks about "Capability Advertisements" and the proposal to > use MP-BGP messages to advertise/exchange CDN capabilities. However, > the document does not explicitly define what is ment by "CDN Capability". >=20 > I understand "CDN Capability" to mean things like delivery technology (fo= r > example RTMP or HTTP etc.) or perhaps a specific form of content > authorisation etc. Can you confirm I am correct in assuming this or if no= t > clarify what the correct meaning is. >=20 > Cheers, >=20 > g- >=20 >=20 >=20 > ________________________________________ > From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf Of stefano > previdi [sprevidi@cisco.com] > Sent: 08 March 2012 21:23 > To: cdni@ietf.org > Subject: [CDNi] Fwd: New Version Notification for draft-previdi-cdn= i- > footprint-advertisement-01.txt >=20 > Begin forwarded message: >=20 > > From: internet-drafts@ietf.org > > Subject: New Version Notification for draft-previdi-cdni-footprint- > advertisement-01.txt > > Date: March 8, 2012 8:45:53 PM GMT+01:00 > > To: sprevidi@cisco.com > > Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com > > > > A new version of I-D, draft-previdi-cdni-footprint-advertisement-01.txt= has > been successfully submitted by Stefano Previdi and posted to the IETF > repository. > > > > Filename: draft-previdi-cdni-footprint-advertisement > > Revision: 01 > > Title: CDNI Footprint Advertisement > > Creation date: 2012-03-08 > > WG ID: Individual Submission > > Number of pages: 27 > > > > Abstract: > > This document describes the use of BGP for Content Delivery Networks > > (CDNs) in order to advertise information about footprint and > > connectivity to footprint in the context of CDNI. > > > > > > > > This draft is for the CDNI Working Group. > > > > Thanks. > > s. > > > > The IETF Secretariat > > >=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 gilles.bertrand@orange.com Fri Mar 9 01:10: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 DD74121F85F0 for ; Fri, 9 Mar 2012 01:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.644 X-Spam-Level: X-Spam-Status: No, score=-5.644 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joGNxKJawwfl for ; Fri, 9 Mar 2012 01:10:28 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 1004D21F85DD for ; Fri, 9 Mar 2012 01:10:27 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8C732E30371; Fri, 9 Mar 2012 10:11:36 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 860CBE30305; Fri, 9 Mar 2012 10:11:36 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 10:10:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Mar 2012 10:10:16 +0100 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF0330C1F0@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE24F168FA@DAPHNIS.office.hd> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] TR: I-D Action:draft-bertrand-cdni-footprint-discovery-00.txt Thread-Index: Acz6+QRxnvblsFg8TDG1aa4AYVgUlAAAAfzQAB+sVrAAc7slcAAjNyMg References: <8E09C72DBC577D489F13A71228C0B7BF0330B60B@ftrdmel0.rd.francetelecom.fr> <2779C9F0771F974CAD742BAE6D9904FE24F168FA@DAPHNIS.office.hd> From: To: X-OriginalArrivalTime: 09 Mar 2012 09:10:25.0513 (UTC) FILETIME=[76CFDD90:01CCFDD4] Cc: cdni@ietf.org Subject: Re: [CDNi] TR: I-D Action:draft-bertrand-cdni-footprint-discovery-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, 09 Mar 2012 09:10:29 -0000 Hi Jan, The term "Footprint advertisement" implies that the dCDN sends = advertisements about its footprint through a protocol.=20 draft-bertrand-cdni-footprint-discovery shows that such advertisements = through a protocol are not always required depending on what information = the CDNs need to share (e.g., high level vs. detailed footprint = information). That's why we use a more general term in the draft: = "Footprint Discovery". Best regards, Gilles -----Message d'origine----- De=A0: Jan Seedorf [mailto:Jan.Seedorf@neclab.eu]=20 Envoy=E9=A0: jeudi 8 mars 2012 17:17 =C0=A0: BERTRAND Gilles RD-CORE-ISS; cdni@ietf.org Objet=A0: RE: [CDNi] TR: I-D = Action:draft-bertrand-cdni-footprint-discovery-00.txt Gilles, Just a short question: Is "CDN Footprint Discovery" the opposite = direction of "CDN Footprint advertisement", or how are the terms = related? - Jan > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf=20 > Of gilles.bertrand@orange.com > Sent: Tuesday, March 06, 2012 10:51 AM > To: cdni@ietf.org > Subject: [CDNi] TR: I-D Action:=20 > draft-bertrand-cdni-footprint-discovery-00.txt >=20 > Hi everyone, >=20 > I have submitted a new draft on CDN Footprint Discovery in CDNI. Its=20 > main purpose is to present use cases for CDN Footprint Discovery in = CDNI. It > provides a survey of existing work on the subject and a set of = additional > requirements for controlling the exchange of Footprint information. >=20 > http://www.ietf.org/internet-drafts/draft-bertrand-cdni-footprint- > discovery-00.txt >=20 > Any feedback is welcome. >=20 > Cheers, >=20 > Gilles >=20 >=20 > -----Message d'origine----- > De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-=20 > bounces@ietf.org] De la part de internet-drafts@ietf.org Envoy=E9=A0:=20 > lundi 5 mars 2012 18:54 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D = Action:=20 > draft-bertrand- cdni-footprint-discovery-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : CDN Footprint Discovery > Author(s) : Gilles Bertrand > Filename : draft-bertrand-cdni-footprint-discovery-00.txt > Pages : 13 > Date : 2012-03-05 >=20 > Interconnected CDNs need to exchange information on the set of end- > users to which they can deliver content. This information is > commonly referred to as "CDN Footprint". This memo presents use > cases for CDN Footprint Discovery in CDNI. It provides a survey of > existing work on the subject and a set of additional requirements = for > controlling the exchange of Footprint information. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bertrand-cdni-footprint- > discovery-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-bertrand-cdni-footprint-disco > very- > 00.txt >=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 From Jan.Seedorf@neclab.eu Fri Mar 9 01:30: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 DF7A921F85A7 for ; Fri, 9 Mar 2012 01:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 s8HYy6TCCCcP for ; Fri, 9 Mar 2012 01:30:58 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id DD00121F85AA for ; Fri, 9 Mar 2012 01:30:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id B1A9A1007DE; Fri, 9 Mar 2012 10:30:49 +0100 (CET) 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 Hqd3b5HYjbvP; Fri, 9 Mar 2012 10:30:49 +0100 (CET) Received: from ENCELADUS.office.hd (unknown [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 90D941007DC; Fri, 9 Mar 2012 10:30:39 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.41]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Fri, 9 Mar 2012 10:30:26 +0100 From: Jan Seedorf To: "gilles.bertrand@orange.com" Thread-Topic: [CDNi] TR: I-D Action:draft-bertrand-cdni-footprint-discovery-00.txt Thread-Index: AQHM/dR6/epYBsx7x0mvx8/Aa1uoE5ZhseDw Date: Fri, 9 Mar 2012 09:30:25 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24F182E0@DAPHNIS.office.hd> References: <8E09C72DBC577D489F13A71228C0B7BF0330B60B@ftrdmel0.rd.francetelecom.fr> <2779C9F0771F974CAD742BAE6D9904FE24F168FA@DAPHNIS.office.hd> <8E09C72DBC577D489F13A71228C0B7BF0330C1F0@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF0330C1F0@ftrdmel0.rd.francetelecom.fr> 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 Cc: "cdni@ietf.org" Subject: Re: [CDNi] TR: I-D Action:draft-bertrand-cdni-footprint-discovery-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, 09 Mar 2012 09:30:59 -0000 Hi Gilles, Thanks for the explanation, although I do not see why the term is more gene= ral. What I find confusing about the term "Footprint Discovery" is that - at a f= irst glance - it is not clear if it means a) discovery from the perspective= of the uCDN, i.e. a uCDN asking itself: "what footprint does a given dCDN = have?", or b) discovery from the perspective of a dCDN *ITSELF*, i.e. a dCD= N asking itself: "what footprint do I currently have?", in order to be able= to advertise that discovered footprint then to a uCDN. - Jan > -----Original Message----- > From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com] > Sent: Friday, March 09, 2012 10:10 AM > To: Jan Seedorf > Cc: cdni@ietf.org > Subject: RE: [CDNi] TR: I-D Action:draft-bertrand-cdni-footprint-discover= y- > 00.txt >=20 > Hi Jan, >=20 > The term "Footprint advertisement" implies that the dCDN sends > advertisements about its footprint through a protocol. >=20 > draft-bertrand-cdni-footprint-discovery shows that such advertisements > through a protocol are not always required depending on what information > the CDNs need to share (e.g., high level vs. detailed footprint informati= on). > That's why we use a more general term in the draft: "Footprint Discovery"= . >=20 > Best regards, >=20 > Gilles >=20 > -----Message d'origine----- > De=A0: Jan Seedorf [mailto:Jan.Seedorf@neclab.eu] > Envoy=E9=A0: jeudi 8 mars 2012 17:17 > =C0=A0: BERTRAND Gilles RD-CORE-ISS; cdni@ietf.org > Objet=A0: RE: [CDNi] TR: I-D Action:draft-bertrand-cdni-footprint-discove= ry- > 00.txt >=20 > Gilles, >=20 > Just a short question: Is "CDN Footprint Discovery" the opposite directio= n of > "CDN Footprint advertisement", or how are the terms related? >=20 > - Jan >=20 > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > > Of gilles.bertrand@orange.com > > Sent: Tuesday, March 06, 2012 10:51 AM > > To: cdni@ietf.org > > Subject: [CDNi] TR: I-D Action: > > draft-bertrand-cdni-footprint-discovery-00.txt > > > > Hi everyone, > > > > I have submitted a new draft on CDN Footprint Discovery in CDNI. Its > > main purpose is to present use cases for CDN Footprint Discovery in CDN= I. > It > > provides a survey of existing work on the subject and a set of additi= onal > > requirements for controlling the exchange of Footprint information. > > > > http://www.ietf.org/internet-drafts/draft-bertrand-cdni-footprint- > > discovery-00.txt > > > > Any feedback is welcome. > > > > Cheers, > > > > 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 5 mars 2012 18:54 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Act= ion: > > draft-bertrand- cdni-footprint-discovery-00.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > Title : CDN Footprint Discovery > > Author(s) : Gilles Bertrand > > Filename : draft-bertrand-cdni-footprint-discovery-00.txt > > Pages : 13 > > Date : 2012-03-05 > > > > Interconnected CDNs need to exchange information on the set of end- > > users to which they can deliver content. This information is > > commonly referred to as "CDN Footprint". This memo presents use > > cases for CDN Footprint Discovery in CDNI. It provides a survey of > > existing work on the subject and a set of additional requirements fo= r > > controlling the exchange of Footprint information. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-bertrand-cdni-footprint- > > discovery-00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-bertrand-cdni-footprint-disco > > very- > > 00.txt > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From sprevidi@cisco.com Fri Mar 9 02:29: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 0A31E21F85F8 for ; Fri, 9 Mar 2012 02:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 GZHWl2OY7tl4 for ; Fri, 9 Mar 2012 02:29:58 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2898221F85F9 for ; Fri, 9 Mar 2012 02:29:58 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q29ATvqc014719 for ; Fri, 9 Mar 2012 11:29:57 +0100 (CET) Received: from dhcp-10-61-97-44.cisco.com (dhcp-10-61-97-44.cisco.com [10.61.97.44]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q29ATuip022650; Fri, 9 Mar 2012 11:29:56 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: stefano previdi In-Reply-To: <57D43604-001C-4A15-A854-675040440527@jet-stream.nl> Date: Fri, 9 Mar 2012 11:29:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8FB9D5DC-897C-463B-8BC4-82F997CF26DB@cisco.com> References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com> <189716C74BBB9C4095FE8CA503B1FC3A5784C3188C@EMBX02-HQ.jnpr.net> <57D43604-001C-4A15-A854-675040440527@jet-stream.nl> To: Stef van der Ziel X-Mailer: Apple Mail (2.1257) Cc: "cdni@ietf.org" Subject: Re: [CDNi] Questions on draft-previdi-cdni-footprint-advertisement-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: Fri, 09 Mar 2012 10:29:59 -0000 On Mar 9, 2012, at 7:02 AM, Stef van der Ziel wrote: > Hi, >=20 > I would not recommend to use BGP to share CDN information, that would = effectively lock a CDN into the network layer not really.=20 The fact that you use BGP as a tool for propagating footprint=20 information doesn't make your CDN a layer3 model. As described in the proposal, we have a new AF for the purpose=20 of CDNI. s. > while CDNs need to run on top of multiple networks, abstracted from = the network. CDN interconnectivity should be API based. You can't assume = that a CDN would use BGP anyway. >=20 > Best, Stef >=20 >=20 >=20 > On 8 mrt. 2012, at 23:42, Ina Minei wrote: >=20 >> Stefano,=20 >>=20 >> A few questions regarding the new section on capabilities = advertisements: >> 1. Can you list some example capabilities that you are thinking = about? >> 2. Who/how is the mapping made between the capabilities and the = communities that represent them and how is this maintained consistent = across the mesh? (which is under different admin domains) >> 3. Can capabilities really be expressed as a community or is a more = flexible encoding needed? (I guess I am wondering what you mean by = capabilities) >> 3. The advertisement is for a prefix in the CDN footprint - this = implies that when reachability changes for that footprint, capabilities = are readvertised, though nothing changes for the CDN itself. This is = probably not ideal. Was wondering if you can explain a bit that choice, = and if instead the cdn id can be used.=20 >>=20 >> Thank you,=20 >>=20 >> Ina=20 >>=20 >>=20 >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of stefano previdi >> Sent: Thursday, March 08, 2012 1:23 PM >> To: cdni@ietf.org >> Subject: [CDNi] Fwd: New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>=20 >>=20 >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>> Date: March 8, 2012 8:45:53 PM GMT+01:00 >>> To: sprevidi@cisco.com >>> Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com >>>=20 >>> A new version of I-D, = draft-previdi-cdni-footprint-advertisement-01.txt has been successfully = submitted by Stefano Previdi and posted to the IETF repository. >>>=20 >>> Filename: draft-previdi-cdni-footprint-advertisement >>> Revision: 01 >>> Title: CDNI Footprint Advertisement >>> Creation date: 2012-03-08 >>> WG ID: Individual Submission >>> Number of pages: 27 >>>=20 >>> Abstract: >>> This document describes the use of BGP for Content Delivery Networks >>> (CDNs) in order to advertise information about footprint and >>> connectivity to footprint in the context of CDNI. >>>=20 >>>=20 >>>=20 >>> This draft is for the CDNI Working Group. >>>=20 >>> Thanks. >>> s. >>>=20 >>> The IETF Secretariat >>>=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 From sprevidi@cisco.com Fri Mar 9 02:39: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 F205C21F85D7 for ; Fri, 9 Mar 2012 02:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 ywrwJUbvLcCn for ; Fri, 9 Mar 2012 02:39:31 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D233B21F85D4 for ; Fri, 9 Mar 2012 02:39:30 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q29AdTgl015996 for ; Fri, 9 Mar 2012 11:39:29 +0100 (CET) Received: from dhcp-10-61-97-44.cisco.com (dhcp-10-61-97-44.cisco.com [10.61.97.44]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q29AdTUW029883; Fri, 9 Mar 2012 11:39:29 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: stefano previdi In-Reply-To: <189716C74BBB9C4095FE8CA503B1FC3A5784C3188C@EMBX02-HQ.jnpr.net> Date: Fri, 9 Mar 2012 11:39:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com> <189716C74BBB9C4095FE8CA503B1FC3A5784C3188C@EMBX02-HQ.jnpr.net> To: Ina Minei X-Mailer: Apple Mail (2.1257) Cc: "cdni@ietf.org" Subject: Re: [CDNi] Questions on draft-previdi-cdni-footprint-advertisement-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: Fri, 09 Mar 2012 10:39:32 -0000 Hi Ina, thanks for your comments... some answers below. On Mar 8, 2012, at 11:42 PM, Ina Minei wrote: > Stefano,=20 >=20 > A few questions regarding the new section on capabilities = advertisements: > 1. Can you list some example capabilities that you are thinking about? > 2. Who/how is the mapping made between the capabilities and the = communities that represent them and how is this maintained consistent = across the mesh? (which is under different admin domains) well, at this stage of the proposal, I think about communities as=20 an encoding/mapping mechanism for capabilities. When the WG will=20 have figured out what capabilities needs to be advertised, we have=20 good method for advertising them (std vs ext vs wide). > 3. Can capabilities really be expressed as a community or is a more = flexible encoding needed? (I guess I am wondering what you mean by = capabilities) nothing prevents us from defining a more ad-hoc attribute if=20 necessary. We may probably go that path if more structured encoding=20 is required. > 3. The advertisement is for a prefix in the CDN footprint - this = implies that when reachability changes for that footprint, capabilities = are readvertised, To my (probably perfectible) knowledge, the capability is associated=20 to a CDN, not a prefix. However, nothing prevents the use of=20 capability communities to FP element. When the capability is related to the CDN, you only have to=20 advertise the set of capability communities into _one_ prefix=20 that is owned by the CDN. Any change on capabilities will not=20 trigger any FP element re-advertisement. s. > though nothing changes for the CDN itself. This is probably not ideal. = Was wondering if you can explain a bit that choice, and if instead the = cdn id can be used.=20 >=20 > Thank you,=20 >=20 > Ina=20 >=20 >=20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of stefano previdi > Sent: Thursday, March 08, 2012 1:23 PM > To: cdni@ietf.org > Subject: [CDNi] Fwd: New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >=20 >=20 >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >> Date: March 8, 2012 8:45:53 PM GMT+01:00 >> To: sprevidi@cisco.com >> Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com >>=20 >> A new version of I-D, = draft-previdi-cdni-footprint-advertisement-01.txt has been successfully = submitted by Stefano Previdi and posted to the IETF repository. >>=20 >> Filename: draft-previdi-cdni-footprint-advertisement >> Revision: 01 >> Title: CDNI Footprint Advertisement >> Creation date: 2012-03-08 >> WG ID: Individual Submission >> Number of pages: 27 >>=20 >> Abstract: >> This document describes the use of BGP for Content Delivery Networks >> (CDNs) in order to advertise information about footprint and >> connectivity to footprint in the context of CDNI. >>=20 >>=20 >>=20 >> This draft is for the CDNI Working Group. >>=20 >> Thanks. >> s. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 From sprevidi@cisco.com Fri Mar 9 02:43: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 8ED8321F8613 for ; Fri, 9 Mar 2012 02:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 JGoHuCFxr0a1 for ; Fri, 9 Mar 2012 02:43:51 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 137BF21F84C8 for ; Fri, 9 Mar 2012 02:43:47 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q29Ahl9N016521 for ; Fri, 9 Mar 2012 11:43:47 +0100 (CET) Received: from dhcp-10-61-97-44.cisco.com (dhcp-10-61-97-44.cisco.com [10.61.97.44]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q29AhjEi003550; Fri, 9 Mar 2012 11:43:45 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: stefano previdi In-Reply-To: <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net> Date: Fri, 9 Mar 2012 11:43:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net> To: "" X-Mailer: Apple Mail (2.1257) Cc: cdni@ietf.org Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-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: Fri, 09 Mar 2012 10:43:52 -0000 Hi Grant, On Mar 8, 2012, at 11:17 PM, = wrote: >=20 > Hi, >=20 > The document talks about "Capability Advertisements" and the proposal = to use MP-BGP messages to advertise/exchange CDN capabilities. However, = the document does not explicitly define what is ment by "CDN = Capability". indeed... and it is somehow intended... As JanS pointed out, there's another draft that should explicit=20 the semantics of FP/Capabilities. In this proposal we define the=20 mechanism through which the capability information can be=20 exchanged. Obviously, at some point, we'll have to synchronize. > I understand "CDN Capability" to mean things like delivery technology = (for example RTMP or HTTP etc.) or perhaps a specific form of content = authorisation etc. Can you confirm I am correct in assuming this or if = not clarify what the correct meaning is. My understanding goes in the same direction, so far. s. >=20 > Cheers, >=20 > g- >=20 >=20 >=20 > ________________________________________ > From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf Of = stefano previdi [sprevidi@cisco.com] > Sent: 08 March 2012 21:23 > To: cdni@ietf.org > Subject: [CDNi] Fwd: New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >> Date: March 8, 2012 8:45:53 PM GMT+01:00 >> To: sprevidi@cisco.com >> Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com >>=20 >> A new version of I-D, = draft-previdi-cdni-footprint-advertisement-01.txt has been successfully = submitted by Stefano Previdi and posted to the IETF repository. >>=20 >> Filename: draft-previdi-cdni-footprint-advertisement >> Revision: 01 >> Title: CDNI Footprint Advertisement >> Creation date: 2012-03-08 >> WG ID: Individual Submission >> Number of pages: 27 >>=20 >> Abstract: >> This document describes the use of BGP for Content Delivery Networks >> (CDNs) in order to advertise information about footprint and >> connectivity to footprint in the context of CDNI. >>=20 >>=20 >>=20 >> This draft is for the CDNI Working Group. >>=20 >> Thanks. >> s. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 From grant.watson@bt.com Fri Mar 9 03:51: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 7D55F21F8639 for ; Fri, 9 Mar 2012 03:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, J_CHICKENPOX_61=0.6, 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 9q-C3cbYymaY for ; Fri, 9 Mar 2012 03:51:01 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 8A19621F863B for ; Fri, 9 Mar 2012 03:51:01 -0800 (PST) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 9 Mar 2012 11:51:00 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.101]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Fri, 9 Mar 2012 11:51:00 +0000 From: To: , Date: Fri, 9 Mar 2012 11:50:59 +0000 Thread-Topic: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-01.txt Thread-Index: Acz94YPgfP1SF0c2Tx68H0R9AVZP8gABMeNw Message-ID: <1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net> References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-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: Fri, 09 Mar 2012 11:51:02 -0000 Thanks, understood. Then my general feedback would be - I think working out what capability inf= ormation needs to be shared between the CDNs would ideally be worked though= prior to deciding the right way to do it. BGP doesn't feel like an obvious= choice for exchanging the kind of CDN Capability information I'd envisage = being passed between CDN. Has a discussion taken place as to why BGP over o= ther methods? (e.g. API/metadata) There are drafts discussing metadata righ= t now that propose ways of describing the capability requirements between C= DN (e.g. "deliver this content using RMTP" etc.), why would we not also exc= hange capabilities over the same interface for example? It's easier to understand why it may be considered that BGP should/could be= used for the exchange of network footprint information but less so for CDN= Capabilities, IMHO. In some cases CDN may not want or need to implement fo= otprint advertisement entirely (for example in a simple bi-lateral relation= ship the CDN operators could easily elect to exchange footprint information= out-of-band), in this case they presumably wouldn't want to be dependent o= n BGP to exchange capability information. g- -----Original Message----- From: stefano previdi [mailto:sprevidi@cisco.com]=20 Sent: 09 March 2012 10:44 To: Watson,G,Grant,DMK5 R Cc: cdni@ietf.org Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footpri= nt-advertisement-01.txt Hi Grant, On Mar 8, 2012, at 11:17 PM, wr= ote: >=20 > Hi, >=20 > The document talks about "Capability Advertisements" and the proposal to = use MP-BGP messages to advertise/exchange CDN capabilities. However, the do= cument does not explicitly define what is ment by "CDN Capability". indeed... and it is somehow intended... As JanS pointed out, there's another draft that should explicit the semanti= cs of FP/Capabilities. In this proposal we define the mechanism through whi= ch the capability information can be exchanged. Obviously, at some point, we'll have to synchronize. > I understand "CDN Capability" to mean things like delivery technology (fo= r example RTMP or HTTP etc.) or perhaps a specific form of content authoris= ation etc. Can you confirm I am correct in assuming this or if not clarify = what the correct meaning is. My understanding goes in the same direction, so far. s. >=20 > Cheers, >=20 > g- >=20 >=20 >=20 > ________________________________________ > From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf Of=20 > stefano previdi [sprevidi@cisco.com] > Sent: 08 March 2012 21:23 > To: cdni@ietf.org > Subject: [CDNi] Fwd: New Version Notification for draft-previdi-cdn= i-footprint-advertisement-01.txt >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for=20 >> draft-previdi-cdni-footprint-advertisement-01.txt >> Date: March 8, 2012 8:45:53 PM GMT+01:00 >> To: sprevidi@cisco.com >> Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com >>=20 >> A new version of I-D, draft-previdi-cdni-footprint-advertisement-01.txt = has been successfully submitted by Stefano Previdi and posted to the IETF r= epository. >>=20 >> Filename: draft-previdi-cdni-footprint-advertisement >> Revision: 01 >> Title: CDNI Footprint Advertisement >> Creation date: 2012-03-08 >> WG ID: Individual Submission >> Number of pages: 27 >>=20 >> Abstract: >> This document describes the use of BGP for Content Delivery Networks >> (CDNs) in order to advertise information about footprint and =20 >> connectivity to footprint in the context of CDNI. >>=20 >>=20 >>=20 >> This draft is for the CDNI Working Group. >>=20 >> Thanks. >> s. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 From Jan.Seedorf@neclab.eu Fri Mar 9 04:57: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 BA6A821F8609 for ; Fri, 9 Mar 2012 04:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.253 X-Spam-Level: X-Spam-Status: No, score=-102.253 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, J_CHICKENPOX_61=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 G9OKaR-4yFNb for ; Fri, 9 Mar 2012 04:57:41 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 609DB21F85F4 for ; Fri, 9 Mar 2012 04:57:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 953EF1007E2; Fri, 9 Mar 2012 13:57:05 +0100 (CET) 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 OlhYgEEniWSL; Fri, 9 Mar 2012 13:57:05 +0100 (CET) Received: from ENCELADUS.office.hd (unknown [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 75F221007E0; Fri, 9 Mar 2012 13:56:50 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.41]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Fri, 9 Mar 2012 13:56:58 +0100 From: Jan Seedorf To: "grant.watson@bt.com" , "sprevidi@cisco.com" , "cdni@ietf.org" Thread-Topic: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-01.txt Thread-Index: AQHM/esIlU4ASuvXAESb3A6A0QSzYJZh66PQ Date: Fri, 9 Mar 2012 12:56:58 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24F18568@DAPHNIS.office.hd> References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net> <1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net> In-Reply-To: <1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-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: Fri, 09 Mar 2012 12:57:41 -0000 > Then my general feedback would be - I think working out what capability > information needs to be shared between the CDNs would ideally be worked > though prior to deciding the right way to do it. This is exactly what the CDNI WG decided at IEF-82 and the rationale for th= e semantics draft (draft-spp-cdni-rr-foot-cap-semantics). First, let's unde= rstand what we want/need, then let's decide on a protocol. We assume some i= nteresting discussions on "working out what capability information needs to= be shared between the CDNs" in Paris, we tried to provide input to this di= scussion in the semantics draft. - Jan > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > grant.watson@bt.com > Sent: Friday, March 09, 2012 12:51 PM > To: sprevidi@cisco.com; cdni@ietf.org > Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footp= rint- > advertisement-01.txt >=20 > Thanks, understood. >=20 > Then my general feedback would be - I think working out what capability > information needs to be shared between the CDNs would ideally be worked > though prior to deciding the right way to do it. BGP doesn't feel like an > obvious choice for exchanging the kind of CDN Capability information I'd > envisage being passed between CDN. Has a discussion taken place as to why > BGP over other methods? (e.g. API/metadata) There are drafts discussing > metadata right now that propose ways of describing the capability > requirements between CDN (e.g. "deliver this content using RMTP" etc.), > why would we not also exchange capabilities over the same interface for > example? >=20 > It's easier to understand why it may be considered that BGP should/could = be > used for the exchange of network footprint information but less so for CD= N > Capabilities, IMHO. In some cases CDN may not want or need to implement > footprint advertisement entirely (for example in a simple bi-lateral > relationship the CDN operators could easily elect to exchange footprint > information out-of-band), in this case they presumably wouldn't want to b= e > dependent on BGP to exchange capability information. >=20 > g- >=20 >=20 > -----Original Message----- > From: stefano previdi [mailto:sprevidi@cisco.com] > Sent: 09 March 2012 10:44 > To: Watson,G,Grant,DMK5 R > Cc: cdni@ietf.org > Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footp= rint- > advertisement-01.txt >=20 > Hi Grant, >=20 > On Mar 8, 2012, at 11:17 PM, > wrote: > > > > Hi, > > > > The document talks about "Capability Advertisements" and the proposal t= o > use MP-BGP messages to advertise/exchange CDN capabilities. However, > the document does not explicitly define what is ment by "CDN Capability". >=20 >=20 > indeed... and it is somehow intended... >=20 > As JanS pointed out, there's another draft that should explicit the seman= tics > of FP/Capabilities. In this proposal we define the mechanism through whic= h > the capability information can be exchanged. >=20 > Obviously, at some point, we'll have to synchronize. >=20 >=20 > > I understand "CDN Capability" to mean things like delivery technology (= for > example RTMP or HTTP etc.) or perhaps a specific form of content > authorisation etc. Can you confirm I am correct in assuming this or if no= t > clarify what the correct meaning is. >=20 >=20 > My understanding goes in the same direction, so far. >=20 > s. >=20 >=20 > > > > Cheers, > > > > g- > > > > > > > > ________________________________________ > > From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf Of > > stefano previdi [sprevidi@cisco.com] > > Sent: 08 March 2012 21:23 > > To: cdni@ietf.org > > Subject: [CDNi] Fwd: New Version Notification for draft-previdi-c= dni- > footprint-advertisement-01.txt > > > > Begin forwarded message: > > > >> From: internet-drafts@ietf.org > >> Subject: New Version Notification for > >> draft-previdi-cdni-footprint-advertisement-01.txt > >> Date: March 8, 2012 8:45:53 PM GMT+01:00 > >> To: sprevidi@cisco.com > >> Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com > >> > >> A new version of I-D, draft-previdi-cdni-footprint-advertisement-01.tx= t > has been successfully submitted by Stefano Previdi and posted to the IETF > repository. > >> > >> Filename: draft-previdi-cdni-footprint-advertisement > >> Revision: 01 > >> Title: CDNI Footprint Advertisement > >> Creation date: 2012-03-08 > >> WG ID: Individual Submission > >> Number of pages: 27 > >> > >> Abstract: > >> This document describes the use of BGP for Content Delivery Networks > >> (CDNs) in order to advertise information about footprint and > >> connectivity to footprint in the context of CDNI. > >> > >> > >> > >> This draft is for the CDNI Working Group. > >> > >> Thanks. > >> s. > >> > >> The IETF Secretariat > >> > > > > _______________________________________________ > > 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 gilles.bertrand@orange.com Fri Mar 9 06: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 B8FDE21F865D for ; Fri, 9 Mar 2012 06:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.846 X-Spam-Level: X-Spam-Status: No, score=-5.846 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55cZ52FVKLxu for ; Fri, 9 Mar 2012 06:07:38 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id B8E9F21F8658 for ; Fri, 9 Mar 2012 06:07:37 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 72C157E4003; Fri, 9 Mar 2012 15:07:36 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 692607E4002; Fri, 9 Mar 2012 15:07:36 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 15:07:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Mar 2012 15:07:15 +0100 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF03351A5E@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE24F182E0@DAPHNIS.office.hd> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] TR: I-D Action:draft-bertrand-cdni-footprint-discovery-00.txt Thread-Index: AQHM/dR6/epYBsx7x0mvx8/Aa1uoE5ZhseDwgABMmMA= References: <8E09C72DBC577D489F13A71228C0B7BF0330B60B@ftrdmel0.rd.francetelecom.fr> <2779C9F0771F974CAD742BAE6D9904FE24F168FA@DAPHNIS.office.hd> <8E09C72DBC577D489F13A71228C0B7BF0330C1F0@ftrdmel0.rd.francetelecom.fr> <2779C9F0771F974CAD742BAE6D9904FE24F182E0@DAPHNIS.office.hd> From: To: X-OriginalArrivalTime: 09 Mar 2012 14:07:36.0288 (UTC) FILETIME=[FAC83600:01CCFDFD] Cc: cdni@ietf.org Subject: Re: [CDNi] TR: I-D Action:draft-bertrand-cdni-footprint-discovery-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, 09 Mar 2012 14:07:38 -0000 Hi Jan, > What I find confusing about the term "Footprint Discovery" is that - = at a first glance - it is not clear if it means a) discovery from the = perspective of the uCDN, i.e. a uCDN asking itself: "what footprint does = a given dCDN have?",=20 > or b) discovery from the perspective of a dCDN *ITSELF*, i.e. a dCDN = asking itself: "what footprint do I currently have?", in order to be = able to advertise that discovered footprint then to a uCDN. The dCDN knows its CDN Footprint ("b" what footprint do I currently = have) because it discovers the CDN Footprint of its own dCDNs ("a" what = footprint does a given dCDN have). In your statement "a" and "b" are = different recursions of the Footprint Discovery problem. Cheers, Gilles=20 > -----Original Message----- > From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com] > Sent: Friday, March 09, 2012 10:10 AM > To: Jan Seedorf > Cc: cdni@ietf.org > Subject: RE: [CDNi] TR: I-D=20 > Action:draft-bertrand-cdni-footprint-discovery- > 00.txt >=20 > Hi Jan, >=20 > The term "Footprint advertisement" implies that the dCDN sends=20 > advertisements about its footprint through a protocol. >=20 > draft-bertrand-cdni-footprint-discovery shows that such advertisements = > through a protocol are not always required depending on what=20 > information the CDNs need to share (e.g., high level vs. detailed = footprint information). > That's why we use a more general term in the draft: "Footprint = Discovery". >=20 > Best regards, >=20 > Gilles >=20 > -----Message d'origine----- > De=A0: Jan Seedorf [mailto:Jan.Seedorf@neclab.eu] Envoy=E9=A0: jeudi 8 = mars=20 > 2012 17:17 =C0=A0: BERTRAND Gilles RD-CORE-ISS; cdni@ietf.org = Objet=A0: RE:=20 > [CDNi] TR: I-D Action:draft-bertrand-cdni-footprint-discovery- > 00.txt >=20 > Gilles, >=20 > Just a short question: Is "CDN Footprint Discovery" the opposite=20 > direction of "CDN Footprint advertisement", or how are the terms = related? >=20 > - Jan >=20 > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = > > Of gilles.bertrand@orange.com > > Sent: Tuesday, March 06, 2012 10:51 AM > > To: cdni@ietf.org > > Subject: [CDNi] TR: I-D Action: > > draft-bertrand-cdni-footprint-discovery-00.txt > > > > Hi everyone, > > > > I have submitted a new draft on CDN Footprint Discovery in CDNI. Its = > > main purpose is to present use cases for CDN Footprint Discovery in = CDNI. > It > > provides a survey of existing work on the subject and a set of = additional > > requirements for controlling the exchange of Footprint information. > > > > http://www.ietf.org/internet-drafts/draft-bertrand-cdni-footprint- > > discovery-00.txt > > > > Any feedback is welcome. > > > > Cheers, > > > > Gilles > > > > > > -----Message d'origine----- > > De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-=20 > > bounces@ietf.org] De la part de internet-drafts@ietf.org = Envoy=E9=A0: > > lundi 5 mars 2012 18:54 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D = Action: > > draft-bertrand- cdni-footprint-discovery-00.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > Title : CDN Footprint Discovery > > Author(s) : Gilles Bertrand > > Filename : draft-bertrand-cdni-footprint-discovery-00.txt > > Pages : 13 > > Date : 2012-03-05 > > > > Interconnected CDNs need to exchange information on the set of = end- > > users to which they can deliver content. This information is > > commonly referred to as "CDN Footprint". This memo presents use > > cases for CDN Footprint Discovery in CDNI. It provides a survey = of > > existing work on the subject and a set of additional requirements = for > > controlling the exchange of Footprint information. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-bertrand-cdni-footprint- > > discovery-00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-bertrand-cdni-footprint-dis > > co > > very- > > 00.txt > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From Jan.Seedorf@neclab.eu Fri Mar 9 06:19: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 52C3621F865C for ; Fri, 9 Mar 2012 06:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 NA1Q28FPg-no for ; Fri, 9 Mar 2012 06:19:26 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 458A121F8623 for ; Fri, 9 Mar 2012 06:19:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 4BA7B1007EC; Fri, 9 Mar 2012 15:19:17 +0100 (CET) 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 pTWC4VXaTWdG; Fri, 9 Mar 2012 15:19:17 +0100 (CET) Received: from ENCELADUS.office.hd (unknown [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 2FAB91007EB; Fri, 9 Mar 2012 15:19:07 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.41]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Fri, 9 Mar 2012 15:19:15 +0100 From: Jan Seedorf To: "gilles.bertrand@orange.com" Thread-Topic: [CDNi] TR: I-D Action:draft-bertrand-cdni-footprint-discovery-00.txt Thread-Index: AQHM/dR6/epYBsx7x0mvx8/Aa1uoE5ZhseDwgABMmMCAAATvsA== Date: Fri, 9 Mar 2012 14:19:15 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24F18626@DAPHNIS.office.hd> References: <8E09C72DBC577D489F13A71228C0B7BF0330B60B@ftrdmel0.rd.francetelecom.fr> <2779C9F0771F974CAD742BAE6D9904FE24F168FA@DAPHNIS.office.hd> <8E09C72DBC577D489F13A71228C0B7BF0330C1F0@ftrdmel0.rd.francetelecom.fr> <2779C9F0771F974CAD742BAE6D9904FE24F182E0@DAPHNIS.office.hd> <8E09C72DBC577D489F13A71228C0B7BF03351A5E@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF03351A5E@ftrdmel0.rd.francetelecom.fr> 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 Cc: "cdni@ietf.org" Subject: Re: [CDNi] TR: I-D Action:draft-bertrand-cdni-footprint-discovery-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, 09 Mar 2012 14:19:27 -0000 > does a given dCDN have). In your statement "a" and "b" are different > recursions of the Footprint Discovery problem. Ok, and what out of these recursion is your draft about? :) - Jan > -----Original Message----- > From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com] > Sent: Friday, March 09, 2012 3:07 PM > To: Jan Seedorf > Cc: cdni@ietf.org > Subject: RE: [CDNi] TR: I-D Action:draft-bertrand-cdni-footprint-discover= y- > 00.txt >=20 > Hi Jan, >=20 > > What I find confusing about the term "Footprint Discovery" is that - at= a first > glance - it is not clear if it means a) discovery from the perspective of= the > uCDN, i.e. a uCDN asking itself: "what footprint does a given dCDN have?"= , > > or b) discovery from the perspective of a dCDN *ITSELF*, i.e. a dCDN as= king > itself: "what footprint do I currently have?", in order to be able to adv= ertise > that discovered footprint then to a uCDN. >=20 > The dCDN knows its CDN Footprint ("b" what footprint do I currently have) > because it discovers the CDN Footprint of its own dCDNs ("a" what footpri= nt > does a given dCDN have). In your statement "a" and "b" are different > recursions of the Footprint Discovery problem. >=20 > Cheers, >=20 > Gilles >=20 >=20 > > -----Original Message----- > > From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com] > > Sent: Friday, March 09, 2012 10:10 AM > > To: Jan Seedorf > > Cc: cdni@ietf.org > > Subject: RE: [CDNi] TR: I-D > > Action:draft-bertrand-cdni-footprint-discovery- > > 00.txt > > > > Hi Jan, > > > > The term "Footprint advertisement" implies that the dCDN sends > > advertisements about its footprint through a protocol. > > > > draft-bertrand-cdni-footprint-discovery shows that such advertisements > > through a protocol are not always required depending on what > > information the CDNs need to share (e.g., high level vs. detailed footp= rint > information). > > That's why we use a more general term in the draft: "Footprint Discover= y". > > > > Best regards, > > > > Gilles > > > > -----Message d'origine----- > > De=A0: Jan Seedorf [mailto:Jan.Seedorf@neclab.eu] Envoy=E9=A0: jeudi 8 = mars > > 2012 17:17 =C0=A0: BERTRAND Gilles RD-CORE-ISS; cdni@ietf.org Objet=A0:= RE: > > [CDNi] TR: I-D Action:draft-bertrand-cdni-footprint-discovery- > > 00.txt > > > > Gilles, > > > > Just a short question: Is "CDN Footprint Discovery" the opposite > > direction of "CDN Footprint advertisement", or how are the terms relate= d? > > > > - Jan > > > > > -----Original Message----- > > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > > > Of gilles.bertrand@orange.com > > > Sent: Tuesday, March 06, 2012 10:51 AM > > > To: cdni@ietf.org > > > Subject: [CDNi] TR: I-D Action: > > > draft-bertrand-cdni-footprint-discovery-00.txt > > > > > > Hi everyone, > > > > > > I have submitted a new draft on CDN Footprint Discovery in CDNI. Its > > > main purpose is to present use cases for CDN Footprint Discovery in > CDNI. > > It > > > provides a survey of existing work on the subject and a set of addi= tional > > > requirements for controlling the exchange of Footprint information. > > > > > > http://www.ietf.org/internet-drafts/draft-bertrand-cdni-footprint- > > > discovery-00.txt > > > > > > Any feedback is welcome. > > > > > > Cheers, > > > > > > 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 5 mars 2012 18:54 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D A= ction: > > > draft-bertrand- cdni-footprint-discovery-00.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : CDN Footprint Discovery > > > Author(s) : Gilles Bertrand > > > Filename : draft-bertrand-cdni-footprint-discovery-00.txt > > > Pages : 13 > > > Date : 2012-03-05 > > > > > > Interconnected CDNs need to exchange information on the set of end= - > > > users to which they can deliver content. This information is > > > commonly referred to as "CDN Footprint". This memo presents use > > > cases for CDN Footprint Discovery in CDNI. It provides a survey o= f > > > existing work on the subject and a set of additional requirements = for > > > controlling the exchange of Footprint information. > > > > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-bertrand-cdni-footprint- > > > discovery-00.txt > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > This Internet-Draft can be retrieved at: > > > ftp://ftp.ietf.org/internet-drafts/draft-bertrand-cdni-footprint-dis > > > co > > > very- > > > 00.txt > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > > > CDNi mailing list > > > CDNi@ietf.org > > > https://www.ietf.org/mailman/listinfo/cdni From Jan.Seedorf@neclab.eu Fri Mar 9 08:52:23 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 0918C21E8013 for ; Fri, 9 Mar 2012 08:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 oIKwD720NaN5 for ; Fri, 9 Mar 2012 08:52:21 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0014021F866B for ; Fri, 9 Mar 2012 08:52:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 8E3541007EC; Fri, 9 Mar 2012 17:52:11 +0100 (CET) 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 1Nbi+1THrAUE; Fri, 9 Mar 2012 17:52:11 +0100 (CET) Received: from ENCELADUS.office.hd (unknown [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 709461007DF; Fri, 9 Mar 2012 17:51:46 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.41]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Fri, 9 Mar 2012 17:51:34 +0100 From: Jan Seedorf To: stefano previdi Thread-Topic: Questions on draft-previdi-cdni-footprint-advertisement-00 Thread-Index: Acz2Lv2ue6S3SGEmQby1HP94jyog0QACrzaAAAAnyQABw1j8gP//9UEA//5bWVA= Date: Fri, 9 Mar 2012 16:51:34 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24F18782@DAPHNIS.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE24F11D2A@DAPHNIS.office.hd> <075049AD-E2B9-40DA-8900-F54E7B6AF64E@cisco.com> <2779C9F0771F974CAD742BAE6D9904FE24F1695D@DAPHNIS.office.hd> In-Reply-To: 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: "Jan Medved \(jmedved\)" , "cdni@ietf.org" Subject: Re: [CDNi] Questions on draft-previdi-cdni-footprint-advertisement-00 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 16:52:23 -0000 Thanks Stefano for the explanation. So ok, the community is like the PID in= ALTO, an identifier for a certain prefix, fine. How do you assign a cost (= whatever type or meaning of cost) to such a community then with BGP? Thanks, - Jan > -----Original Message----- > From: stefano previdi [mailto:sprevidi@cisco.com] > Sent: Thursday, March 08, 2012 5:45 PM > To: Jan Seedorf > Cc: Francois Le Faucheur (flefauch); Allan GUILLOU; Jan Medved (jmedved); > cdni@ietf.org > Subject: Re: Questions on draft-previdi-cdni-footprint-advertisement-00 >=20 >=20 > On Mar 8, 2012, at 5:37 PM, Jan Seedorf wrote: >=20 > > Hi Stefano, > > > > Thanks for your answers. It clarified a lot, and I am waiting for your = updated > draft which hopefully will make things even more clear for me. > > > > One thing that is not clear for me yet (excuse me, I am not a BGP exper= t): > The semantics of a community value field, i.e. is it like a PID (a groupi= ng), or > like a cost value (a quantifying parameter for some type/metric)? >=20 >=20 > in BGP, a community is a tag you assign to a given prefix. There's > no semantic in the attribute (unless specified for reserved community > numbers). >=20 > If you take the analogy with ALTO, a community can be easily used as > a PID in order to group prefixes. >=20 > I know a deployed ALTO implementation that does it... ;-) >=20 > s. >=20 >=20 > > - Jan > > > >> -----Original Message----- > >> From: stefano previdi [mailto:sprevidi@cisco.com] > >> Sent: Tuesday, February 28, 2012 7:00 PM > >> To: Jan Seedorf > >> Cc: Francois Le Faucheur (flefauch); Allan GUILLOU; Jan Medved > (jmedved); > >> cdni@ietf.org > >> Subject: Re: Questions on draft-previdi-cdni-footprint-advertisement-0= 0 > >> > >> > >> > >> > >> On Feb 28, 2012, at 6:55 PM, stefano previdi wrote: > >> > >> Hi Jan, > >> > >> I'm in the process of submitting version 01 which has some changes in > >> terminology and encoding options. I'll try to address your questions > >> below. > >> > >> On Feb 28, 2012, at 5:14 PM, Jan Seedorf wrote: > >>> Dear authors of the BGP CDNI Footprint Advertisement draft, > >>> > >>> I have some questions, maybe you can clarify: > >>> -- BGP communities are currently used per AS, e.g. 100:500 means AS > 100 is > >> attaching a value of 100 to a given route. > >> > >> > >> to be more precise, in your example AS100 is attaching a value of 500. > >> > >> > >>> In your scheme, do you intend to use communities per footprint > identifier, > >> e.g. 100:200:300 means AS 100 is attaching a value of 300 for footprin= t > >> identifier 100:200? > >> > >> > >> not really. We propose the use of BGP Extended community (RFC4360) > for > >> FPE Identifiers. > >> > >> > >>> -- section 4.2.3 says " The CDNI Connectivity Advertisement contains = a > new > >> (TBD) attribute called Origin_AS_PATH that contains the AS_PATH value > >> describing the distance (expressed in AS Hop Count) between the CDN > and > >> the advertised connected footprint."; in the examples in section 7, > however, > >> Origin_AS_PATH is not the AS hop count but the ID of the source AS; I > >> assume it is a mistake in the example, correct? > >> > >> > >> nope, the example is correct. AS_PATH Attribute in BGP contains the li= st > >> of AS# the update traversed. AS hop-count is computed when you > process > >> the update. > >> > >> Origin_AS_PATH has the same format. > >> > >> > >>> -- in your scheme, how can you explicitly express costs (e.g. latency= , > >> bandwidth, monetary costs, ...) to a certain footprint identifier? I > understand > >> a ranking, but it is not clear to me how you express explicit costs. V= ia an > >> extended community value per footprint identifier? > >> > >> > >> BGP distane is based on AS hop-count. THere's no topology involved (as > you > >> rarely exchange topology between ASs). > >> > >> However, nothing prevents to use BGP attributes (MED, Communities) in > >> order > >> to represent preferences that could also be based on costs. > >> > >> > >>> -- what is confusing to me is that original BGP connectivity refers t= o AS- > level > >> routing, while CDN connectivity to me is (in principle) quite independ= ent > >> from AS-level routing. > >> > >> > >> We use a tool called BGP but we use it in the CDNI context. > >> > >> So, the messaging and the signaling will reflect the shape of the CDNI > Mesh > >> and not the Internet mesh. > >> > >> > >>> For instance, I can very well imagine 2 CDNs which have a direct bila= teral > >> CDN-interconnection agreement, but which have many AS-hops between > >> their footprints. So the connectivity via AS-level BGP footprints is v= ery > >> confusing to me. Maybe you can explain it. > >> > >> > >> AS number (in the CDNI context) refers to the CDN using such AS number= . > >> The different CDN BGP sessions you will have will tell you about all C= DN > >> interconnectivity. This is not related to the underneath inter-AS > >> connectivity. > >> > >> In the new draft I also include a topology example that, hopefully, wi= ll > >> help... > >> > >> s. > >> > >> > >>> > >>> > >>> Thanks for answering, > >>> > >>> - Jan > >>> > >> > >> > > > > From sprevidi@cisco.com Fri Mar 9 09:14: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 EC9A121E804B for ; Fri, 9 Mar 2012 09:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 aqzRnKssYZso for ; Fri, 9 Mar 2012 09:14:38 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id EE9EB21E8045 for ; Fri, 9 Mar 2012 09:14:37 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q29HEawr003322 for ; Fri, 9 Mar 2012 18:14:36 +0100 (CET) Received: from dhcp-10-55-81-75.cisco.com (dhcp-10-55-81-75.cisco.com [10.55.81.75]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q29HEXPr011829; Fri, 9 Mar 2012 18:14:33 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: stefano previdi In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE24F18782@DAPHNIS.office.hd> Date: Fri, 9 Mar 2012 18:14:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7EAAACE0-7FF4-4504-8273-55EEFB53DCBB@cisco.com> References: <2779C9F0771F974CAD742BAE6D9904FE24F11D2A@DAPHNIS.office.hd> <075049AD-E2B9-40DA-8900-F54E7B6AF64E@cisco.com> <2779C9F0771F974CAD742BAE6D9904FE24F1695D@DAPHNIS.office.hd> <2779C9F0771F974CAD742BAE6D9904FE24F18782@DAPHNIS.office.hd> To: Jan Seedorf X-Mailer: Apple Mail (2.1257) Cc: "Jan Medved \(jmedved\)" , "cdni@ietf.org" Subject: Re: [CDNi] Questions on draft-previdi-cdni-footprint-advertisement-00 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 17:14:39 -0000 On Mar 9, 2012, at 5:51 PM, Jan Seedorf wrote: > Thanks Stefano for the explanation. So ok, the community is like the = PID in ALTO, an identifier for a certain prefix, fine. How do you assign = a cost (whatever type or meaning of cost) to such a community then with = BGP? BGP uses AS_PATH in order to derive the cost of the reachability.=20 In our draft we use Origin_AS_PATH in order for a CDN to advertise=20 how it reaches a given FP. The whole picture is easily extensible if we make use of=20 draft-gredler-idr-ls-distribution-00. s. > Thanks, > - Jan >=20 >> -----Original Message----- >> From: stefano previdi [mailto:sprevidi@cisco.com] >> Sent: Thursday, March 08, 2012 5:45 PM >> To: Jan Seedorf >> Cc: Francois Le Faucheur (flefauch); Allan GUILLOU; Jan Medved = (jmedved); >> cdni@ietf.org >> Subject: Re: Questions on = draft-previdi-cdni-footprint-advertisement-00 >>=20 >>=20 >> On Mar 8, 2012, at 5:37 PM, Jan Seedorf wrote: >>=20 >>> Hi Stefano, >>>=20 >>> Thanks for your answers. It clarified a lot, and I am waiting for = your updated >> draft which hopefully will make things even more clear for me. >>>=20 >>> One thing that is not clear for me yet (excuse me, I am not a BGP = expert): >> The semantics of a community value field, i.e. is it like a PID (a = grouping), or >> like a cost value (a quantifying parameter for some type/metric)? >>=20 >>=20 >> in BGP, a community is a tag you assign to a given prefix. There's >> no semantic in the attribute (unless specified for reserved community >> numbers). >>=20 >> If you take the analogy with ALTO, a community can be easily used as >> a PID in order to group prefixes. >>=20 >> I know a deployed ALTO implementation that does it... ;-) >>=20 >> s. >>=20 >>=20 >>> - Jan >>>=20 >>>> -----Original Message----- >>>> From: stefano previdi [mailto:sprevidi@cisco.com] >>>> Sent: Tuesday, February 28, 2012 7:00 PM >>>> To: Jan Seedorf >>>> Cc: Francois Le Faucheur (flefauch); Allan GUILLOU; Jan Medved >> (jmedved); >>>> cdni@ietf.org >>>> Subject: Re: Questions on = draft-previdi-cdni-footprint-advertisement-00 >>>>=20 >>>> >>>>=20 >>>>=20 >>>> On Feb 28, 2012, at 6:55 PM, stefano previdi wrote: >>>>=20 >>>> Hi Jan, >>>>=20 >>>> I'm in the process of submitting version 01 which has some changes = in >>>> terminology and encoding options. I'll try to address your = questions >>>> below. >>>>=20 >>>> On Feb 28, 2012, at 5:14 PM, Jan Seedorf wrote: >>>>> Dear authors of the BGP CDNI Footprint Advertisement draft, >>>>>=20 >>>>> I have some questions, maybe you can clarify: >>>>> -- BGP communities are currently used per AS, e.g. 100:500 means = AS >> 100 is >>>> attaching a value of 100 to a given route. >>>>=20 >>>>=20 >>>> to be more precise, in your example AS100 is attaching a value of = 500. >>>>=20 >>>>=20 >>>>> In your scheme, do you intend to use communities per footprint >> identifier, >>>> e.g. 100:200:300 means AS 100 is attaching a value of 300 for = footprint >>>> identifier 100:200? >>>>=20 >>>>=20 >>>> not really. We propose the use of BGP Extended community (RFC4360) >> for >>>> FPE Identifiers. >>>>=20 >>>>=20 >>>>> -- section 4.2.3 says " The CDNI Connectivity Advertisement = contains a >> new >>>> (TBD) attribute called Origin_AS_PATH that contains the AS_PATH = value >>>> describing the distance (expressed in AS Hop Count) between the CDN >> and >>>> the advertised connected footprint."; in the examples in section 7, >> however, >>>> Origin_AS_PATH is not the AS hop count but the ID of the source AS; = I >>>> assume it is a mistake in the example, correct? >>>>=20 >>>>=20 >>>> nope, the example is correct. AS_PATH Attribute in BGP contains the = list >>>> of AS# the update traversed. AS hop-count is computed when you >> process >>>> the update. >>>>=20 >>>> Origin_AS_PATH has the same format. >>>>=20 >>>>=20 >>>>> -- in your scheme, how can you explicitly express costs (e.g. = latency, >>>> bandwidth, monetary costs, ...) to a certain footprint identifier? = I >> understand >>>> a ranking, but it is not clear to me how you express explicit = costs. Via an >>>> extended community value per footprint identifier? >>>>=20 >>>>=20 >>>> BGP distane is based on AS hop-count. THere's no topology involved = (as >> you >>>> rarely exchange topology between ASs). >>>>=20 >>>> However, nothing prevents to use BGP attributes (MED, Communities) = in >>>> order >>>> to represent preferences that could also be based on costs. >>>>=20 >>>>=20 >>>>> -- what is confusing to me is that original BGP connectivity = refers to AS- >> level >>>> routing, while CDN connectivity to me is (in principle) quite = independent >>>> from AS-level routing. >>>>=20 >>>>=20 >>>> We use a tool called BGP but we use it in the CDNI context. >>>>=20 >>>> So, the messaging and the signaling will reflect the shape of the = CDNI >> Mesh >>>> and not the Internet mesh. >>>>=20 >>>>=20 >>>>> For instance, I can very well imagine 2 CDNs which have a direct = bilateral >>>> CDN-interconnection agreement, but which have many AS-hops between >>>> their footprints. So the connectivity via AS-level BGP footprints = is very >>>> confusing to me. Maybe you can explain it. >>>>=20 >>>>=20 >>>> AS number (in the CDNI context) refers to the CDN using such AS = number. >>>> The different CDN BGP sessions you will have will tell you about = all CDN >>>> interconnectivity. This is not related to the underneath inter-AS >>>> connectivity. >>>>=20 >>>> In the new draft I also include a topology example that, hopefully, = will >>>> help... >>>>=20 >>>> s. >>>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>> Thanks for answering, >>>>>=20 >>>>> - Jan >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >=20 >=20 From Jan.Seedorf@neclab.eu Fri Mar 9 09:43: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 7B1CD21F86F5 for ; Fri, 9 Mar 2012 09:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 C5BD9eJaUBfR for ; Fri, 9 Mar 2012 09:43:19 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id AB3BC21F86EF for ; Fri, 9 Mar 2012 09:43:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 2A9171007F0 for ; Fri, 9 Mar 2012 18:43:09 +0100 (CET) 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 rDWx7a0YdtR6 for ; Fri, 9 Mar 2012 18:43:09 +0100 (CET) Received: from METHONE.office.hd (unknown [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 124F41007EC for ; Fri, 9 Mar 2012 18:43:04 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.41]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 9 Mar 2012 18:42:50 +0100 From: Jan Seedorf To: "cdni@ietf.org" Thread-Topic: New Version Notification for draft-seedorf-cdni-request-routing-alto-01.txt Thread-Index: Acz+G8Im/HSC35/xQiO9JoAXRYKYjg== Date: Fri, 9 Mar 2012 17:42:51 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24F1886D@DAPHNIS.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.227] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [CDNi] FW: New Version Notification for draft-seedorf-cdni-request-routing-alto-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: Fri, 09 Mar 2012 17:43:19 -0000 SGkgYWxsLA0KDQpJIGhhdmUgdXBsb2FkZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgQ0ROSSBSZXF1 ZXN0IFJvdXRpbmcgd2l0aCBBTFRPIGRyYWZ0LiBJIGNoYW5nZWQgdGhlIG5hbWUgdG8gZHJhZnQt c2VlZG9yZi1jZG5pLXJlcXVlc3Qtcm91dGluZy1hbHRvIHNvIHRoYXQgaXQgaXMgbGlzdGVkIGlu IHRoZSBDRE5JIHN0YXR1cyBwYWdlczsgd2UgYWdyZWVkIGF0IGxhc3QgSUVURiB0aGF0IHRoZSBk aXNjdXNzaW9ucyBzaG91bGQgaGFwcGVuIG1vc3RseSBpbiB0aGUgQ0ROSSBXRy4gQXMgZGlzY3Vz c2VkIGluIFRhaXBlaSwgdGhlIGRyYWZ0IG5vdyBmb2N1c3NlcyBvbiBkQ0ROIHNlbGVjdGlvbiB3 aXRoIEFMVE8uIFRoZSBkcmFmdCBnaXZlcyBhbiBleGFtcGxlIGhvdyBpdCBjb3VsZCB3b3JrLCBh bmQgZGlzY3Vzc2VzIHNvbWUgYXNzdW1wdGlvbnMgLyBjb25zaWRlcmF0aW9ucyBmb3IgdXNpbmcg QUxUTy4NCg0KIC0gSmFuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10g DQpTZW50OiBGcmlkYXksIE1hcmNoIDA5LCAyMDEyIDY6NDAgUE0NClRvOiBKYW4gU2VlZG9yZg0K U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zZWVkb3JmLWNkbmkt cmVxdWVzdC1yb3V0aW5nLWFsdG8tMDEudHh0DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC1zZWVkb3JmLWNkbmktcmVxdWVzdC1yb3V0aW5nLWFsdG8tMDEudHh0IGhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgSmFuIFNlZWRvcmYgYW5kIHBvc3RlZCB0byB0aGUgSUVURiBy ZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LXNlZWRvcmYtY2RuaS1yZXF1ZXN0LXJvdXRp bmctYWx0bw0KUmV2aXNpb246CSAwMQ0KVGl0bGU6CQkgQ0ROSSBSZXF1ZXN0IFJvdXRpbmcgd2l0 aCBBTFRPDQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0wMy0wOQ0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBT dWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDE0DQoNCkFic3RyYWN0Og0KICAgTmV0d29yayBT ZXJ2aWNlIFByb3ZpZGVycyAoTlNQcykgYXJlIGN1cnJlbnRseSBjb25zaWRlcmluZyB0byBkZXBs b3kNCiAgIENvbnRlbnQgRGVsaXZlcnkgTmV0d29ya3MgKENETnMpIHdpdGhpbiB0aGVpciBuZXR3 b3Jrcy4gIEFzIGENCiAgIGNvbnNlcXVlbmNlIG9mIHRoaXMgZGV2ZWxvcG1lbnQsIHRoZXJlIGlz IGEgbmVlZCBmb3IgaW50ZXJjb25uZWN0aW5nDQogICB0aGVzZSBsb2NhbCBDRE5zLiAgVGhlIG5l Y2Vzc2FyeSBpbnRlcmZhY2VzIGZvciBpbnRlci1jb25uZWN0aW5nIENETnMNCiAgIGFyZSBjdXJy ZW50bHkgYmVpbmcgZGVmaW5lZCBpbiB0aGUgQ29udGVudCBEZWxpdmVyeSBOZXR3b3Jrcw0KICAg SW50ZXJjb25uZWN0aW9uIChDRE5JKSBXRy4gIFRoaXMgZG9jdW1lbnQgZm9jdXNzZXMgb24gdGhl IFJlcXVlc3QNCiAgIFJvdXRpbmcgSW50ZXJmYWNlIG9mIENETkksIGFuZCBtb3JlIHNwZWNpZmlj YWxseSBvbiBob3cgdGhlIHNvbHV0aW9ucw0KICAgY3VycmVudGx5IGJlaW5nIGRlZmluZWQgaW4g dGhlIEFwcGxpY2F0aW9uIExheWVyIFRyYWZmaWMgT3B0aW1pemF0aW9uDQogICAoQUxUTykgV0cg Y2FuIGltcHJvdmUgQ0ROSSByZXF1ZXN0IHJvdXRpbmcuICBUaGUgb3ZlcmFsbCBpbnRlbnRpb24N CiAgIGJlaGluZCB0aGlzIGRvY3VtZW50IGlzIHRvIGZvc3RlciBkaXNjdXNzaW9ucyAoaW4gdGhl IENETkkgYXMgd2VsbCBhcw0KICAgaW4gdGhlIEFMVE8gV0cpIHJlZ2FyZGluZyBpZiwgaG93LCBh bmQgdW5kZXIgd2hhdCBjb25kaXRpb25zIEFMVE8gY2FuDQogICBiZSB1c2VmdWwgdG8gb3B0aW1p emUgQ0ROSSByZXF1ZXN0IHJvdXRpbmcuICBBcyBiYXNpcyBmb3IgdGhpcw0KICAgZGlzY3Vzc2lv biwgdGhpcyBkb2N1bWVudCBwcm92aWRlcyBjb25jcmV0ZSBleGFtcGxlcyBvZiBob3cgQUxUTyBj YW4NCiAgIGJlIGludGVncmF0ZWQgd2l0aGluIENETkkgcmVxdWVzdCByb3V0aW5nIGFuZCBpbiBw YXJ0aWN1bGFyIGluIHRoZQ0KICAgcHJvY2VzcyBvZiBzZWxlY3RpbmcgYSBkb3duc3RyZWFtIENE Ti4gIFRoZSBleGFtcGxlcyBpbiB0aGlzIGRvY3VtZW50DQogICBhcmUgYmFzZWQgb24gdGhlIHVz ZSBjYXNlcyBhbmQgZXhhbXBsZXMgY3VycmVudGx5IGJlaW5nIGRpc2N1c3NlZCBpbg0KICAgdGhl IENETkkgV0cuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNy ZXRhcmlhdA0K From internet-drafts@ietf.org Sat Mar 10 11:38: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 318FB21F8486; Sat, 10 Mar 2012 11:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 MHNU6iScP3DQ; Sat, 10 Mar 2012 11:38:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A7F21F847B; Sat, 10 Mar 2012 11:38:47 -0800 (PST) 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.00 Message-ID: <20120310193847.22396.46359.idtracker@ietfa.amsl.com> Date: Sat, 10 Mar 2012 11:38:47 -0800 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-problem-statement-04.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: Sat, 10 Mar 2012 19:38:48 -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 Interconnec= tion Working Group of the IETF. Title : Content Distribution Network Interconnection (CDNI) Prob= lem Statement Author(s) : Ben Niven-Jenkins Francois Le Faucheur Nabil Bitar Filename : draft-ietf-cdni-problem-statement-04.txt Pages : 36 Date : 2012-03-10 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cdni-problem-statement-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cdni-problem-statement-04.txt From ben@niven-jenkins.co.uk Sat Mar 10 11:45: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 A3C0C21F8584 for ; Sat, 10 Mar 2012 11:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLcPAdFS4D3d for ; Sat, 10 Mar 2012 11:45:45 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3C921F856A for ; Sat, 10 Mar 2012 11:45:44 -0800 (PST) Received: from cpc10-cmbg15-2-0-cust121.5-4.cable.virginmedia.com ([86.30.246.122] helo=[192.168.0.4]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1S6SEQ-0005D4-9o for cdni@ietf.org; Sat, 10 Mar 2012 19:45:34 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Ben Niven-Jenkins In-Reply-To: <20120310193847.22396.46359.idtracker@ietfa.amsl.com> Date: Sat, 10 Mar 2012 19:45:33 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <37B70933-0F89-4995-98F7-21E6FE98B9C1@niven-jenkins.co.uk> References: <20120310193847.22396.46359.idtracker@ietfa.amsl.com> To: cdni@ietf.org X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-problem-statement-04.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: Sat, 10 Mar 2012 19:45:45 -0000 Colleagues, This update addresses comments made by the Document Shepherd when he was = reviewing the draft prior to requesting publication from the IESG. Ben On 10 Mar 2012, at 19:38, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Content Delivery Networks = Interconnection Working Group of the IETF. >=20 > Title : Content Distribution Network Interconnection = (CDNI) Problem Statement > Author(s) : Ben Niven-Jenkins > Francois Le Faucheur > Nabil Bitar > Filename : draft-ietf-cdni-problem-statement-04.txt > Pages : 36 > Date : 2012-03-10 >=20 > 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. >=20 > The goal of this document is to outline the problem area of CDN > interconnection for the IETF CDNI (CDN Interconnection) working > group. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-cdni-problem-statement-04.t= xt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-cdni-problem-statement-04.tx= t >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From hexiaoyan@huawei.com Sun Mar 11 19: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 2072421F859F for ; Sun, 11 Mar 2012 19:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.866 X-Spam-Level: X-Spam-Status: No, score=-5.866 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, J_CHICKENPOX_61=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 nShCb5-wixMM for ; Sun, 11 Mar 2012 19:33:14 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id CC14621F853A for ; Sun, 11 Mar 2012 19:33:13 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0R00BYJ337VA@szxga04-in.huawei.com> for cdni@ietf.org; Mon, 12 Mar 2012 10:33:07 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0R001TP337XF@szxga04-in.huawei.com> for cdni@ietf.org; Mon, 12 Mar 2012 10:33:07 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHT10476; Mon, 12 Mar 2012 10:33:07 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Mar 2012 10:33:06 +0800 Received: from w36710x (10.144.4.163) by smtpscn.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Mar 2012 10:32:50 +0800 Date: Mon, 12 Mar 2012 10:32:49 +0800 From: HeXiaoyan In-reply-to: <2779C9F0771F974CAD742BAE6D9904FE24F18568@DAPHNIS.office.hd> X-Originating-IP: [10.144.4.163] To: 'Jan Seedorf' , grant.watson@bt.com, sprevidi@cisco.com, cdni@ietf.org Message-id: <014801ccfff8$6b8d33d0$42a79b70$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AQHM/esIlU4ASuvXAESb3A6A0QSzYJZh66PQgAQHuzA= X-CFilter-Loop: Reflected References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com> <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net> <1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net> <2779C9F0771F974CAD742BAE6D9904FE24F18568@DAPHNIS.office.hd> Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-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, 12 Mar 2012 02:33:15 -0000 Hi all, There is a draft from us addressing the same topic, I encourage the working group to look at it and take it also as an input for our discussion in Paris. http://datatracker.ietf.org/doc/draft-he-cdni-cap-info-advertising/ Thanks. Best Regards Xiaoyan(Susan) He > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Jan > Seedorf > Sent: Friday, March 09, 2012 8:57 PM > To: grant.watson@bt.com; sprevidi@cisco.com; cdni@ietf.org > Subject: Re: [CDNi] New Version Notification for > draft-previdi-cdni-footprint-advertisement-01.txt > > > Then my general feedback would be - I think working out what capability > > information needs to be shared between the CDNs would ideally be worked > > though prior to deciding the right way to do it. > This is exactly what the CDNI WG decided at IEF-82 and the rationale for the > semantics draft (draft-spp-cdni-rr-foot-cap-semantics). First, let's understand > what we want/need, then let's decide on a protocol. We assume some > interesting discussions on "working out what capability information needs to be > shared between the CDNs" in Paris, we tried to provide input to this discussion > in the semantics draft. > > > - Jan > > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > > grant.watson@bt.com > > Sent: Friday, March 09, 2012 12:51 PM > > To: sprevidi@cisco.com; cdni@ietf.org > > Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint- > > advertisement-01.txt > > > > Thanks, understood. > > > > Then my general feedback would be - I think working out what capability > > information needs to be shared between the CDNs would ideally be worked > > though prior to deciding the right way to do it. BGP doesn't feel like an > > obvious choice for exchanging the kind of CDN Capability information I'd > > envisage being passed between CDN. Has a discussion taken place as to why > > BGP over other methods? (e.g. API/metadata) There are drafts discussing > > metadata right now that propose ways of describing the capability > > requirements between CDN (e.g. "deliver this content using RMTP" etc.), > > why would we not also exchange capabilities over the same interface for > > example? > > > > It's easier to understand why it may be considered that BGP should/could be > > used for the exchange of network footprint information but less so for CDN > > Capabilities, IMHO. In some cases CDN may not want or need to implement > > footprint advertisement entirely (for example in a simple bi-lateral > > relationship the CDN operators could easily elect to exchange footprint > > information out-of-band), in this case they presumably wouldn't want to be > > dependent on BGP to exchange capability information. > > > > g- > > > > > > -----Original Message----- > > From: stefano previdi [mailto:sprevidi@cisco.com] > > Sent: 09 March 2012 10:44 > > To: Watson,G,Grant,DMK5 R > > Cc: cdni@ietf.org > > Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint- > > advertisement-01.txt > > > > Hi Grant, > > > > On Mar 8, 2012, at 11:17 PM, > > wrote: > > > > > > Hi, > > > > > > The document talks about "Capability Advertisements" and the proposal to > > use MP-BGP messages to advertise/exchange CDN capabilities. However, > > the document does not explicitly define what is ment by "CDN Capability". > > > > > > indeed... and it is somehow intended... > > > > As JanS pointed out, there's another draft that should explicit the semantics > > of FP/Capabilities. In this proposal we define the mechanism through which > > the capability information can be exchanged. > > > > Obviously, at some point, we'll have to synchronize. > > > > > > > I understand "CDN Capability" to mean things like delivery technology (for > > example RTMP or HTTP etc.) or perhaps a specific form of content > > authorisation etc. Can you confirm I am correct in assuming this or if not > > clarify what the correct meaning is. > > > > > > My understanding goes in the same direction, so far. > > > > s. > > > > > > > > > > Cheers, > > > > > > g- > > > > > > > > > > > > ________________________________________ > > > From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf Of > > > stefano previdi [sprevidi@cisco.com] > > > Sent: 08 March 2012 21:23 > > > To: cdni@ietf.org > > > Subject: [CDNi] Fwd: New Version Notification for draft-previdi-cdni- > > footprint-advertisement-01.txt > > > > > > Begin forwarded message: > > > > > >> From: internet-drafts@ietf.org > > >> Subject: New Version Notification for > > >> draft-previdi-cdni-footprint-advertisement-01.txt > > >> Date: March 8, 2012 8:45:53 PM GMT+01:00 > > >> To: sprevidi@cisco.com > > >> Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com > > >> > > >> A new version of I-D, draft-previdi-cdni-footprint-advertisement-01.txt > > has been successfully submitted by Stefano Previdi and posted to the IETF > > repository. > > >> > > >> Filename: draft-previdi-cdni-footprint-advertisement > > >> Revision: 01 > > >> Title: CDNI Footprint Advertisement > > >> Creation date: 2012-03-08 > > >> WG ID: Individual Submission > > >> Number of pages: 27 > > >> > > >> Abstract: > > >> This document describes the use of BGP for Content Delivery Networks > > >> (CDNs) in order to advertise information about footprint and > > >> connectivity to footprint in the context of CDNI. > > >> > > >> > > >> > > >> This draft is for the CDNI Working Group. > > >> > > >> Thanks. > > >> s. > > >> > > >> The IETF Secretariat > > >> > > > > > > _______________________________________________ > > > CDNi mailing list > > > CDNi@ietf.org > > > https://www.ietf.org/mailman/listinfo/cdni > > > > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From hexiaoyan@huawei.com Sun Mar 11 19:47: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 D700221F8575 for ; Sun, 11 Mar 2012 19:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.878 X-Spam-Level: X-Spam-Status: No, score=-5.878 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, J_CHICKENPOX_61=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 FADEhxdF-IKo for ; Sun, 11 Mar 2012 19:47:43 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id CB70A21F854F for ; Sun, 11 Mar 2012 19:47:42 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0R00AB03RIZC@szxga04-in.huawei.com> for cdni@ietf.org; Mon, 12 Mar 2012 10:47:42 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0R00FN23RH6C@szxga04-in.huawei.com> for cdni@ietf.org; Mon, 12 Mar 2012 10:47:42 +0800 (CST) Received: from szxeml211-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHT12228; Mon, 12 Mar 2012 10:47:41 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Mar 2012 10:46:52 +0800 Received: from w36710x (10.144.4.163) by smtpscn.huawei.com (10.82.67.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Mar 2012 10:47:36 +0800 Date: Mon, 12 Mar 2012 10:47:36 +0800 From: HeXiaoyan In-reply-to: <1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net> X-Originating-IP: [10.144.4.163] To: grant.watson@bt.com, sprevidi@cisco.com, cdni@ietf.org Message-id: <014c01ccfffa$7bc02a80$73407f80$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Acz94YPgfP1SF0c2Tx68H0R9AVZP8gABMeNwAISJzdA= X-CFilter-Loop: Reflected References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com> <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net> <1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net> Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-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, 12 Mar 2012 02:47:44 -0000 > Then my general feedback would be - I think working out what capability > information needs to be shared between the CDNs would ideally be worked > though prior to deciding the right way to do it. Agree. And besides the semantics draft Jan mentioned. Section 1-5 of our draft http://datatracker.ietf.org/doc/draft-he-cdni-cap-info-advertising/ discussed the criteria on determining the capability information needs to be shared between CDNs and semantics of them. Please experts who are interested in this topic have a look on it. >Has a discussion taken place as to why BGP over other methods? (e.g. API/metadata). I have the same concern, and asked a similar question last time in Taipei meeting, but for the time limit, we have not find chance discussed that sufficiently eventually I think. Best Regards Xiaoyan(Susan) He > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > grant.watson@bt.com > Sent: Friday, March 09, 2012 7:51 PM > To: sprevidi@cisco.com; cdni@ietf.org > Subject: Re: [CDNi] New Version Notification for > draft-previdi-cdni-footprint-advertisement-01.txt > > Thanks, understood. > > Then my general feedback would be - I think working out what capability > information needs to be shared between the CDNs would ideally be worked > though prior to deciding the right way to do it. BGP doesn't feel like an obvious > choice for exchanging the kind of CDN Capability information I'd envisage being > passed between CDN. Has a discussion taken place as to why BGP over other > methods? (e.g. API/metadata) There are drafts discussing metadata right now > that propose ways of describing the capability requirements between CDN (e.g. > "deliver this content using RMTP" etc.), why would we not also exchange > capabilities over the same interface for example? > > It's easier to understand why it may be considered that BGP should/could be > used for the exchange of network footprint information but less so for CDN > Capabilities, IMHO. In some cases CDN may not want or need to implement > footprint advertisement entirely (for example in a simple bi-lateral relationship > the CDN operators could easily elect to exchange footprint information > out-of-band), in this case they presumably wouldn't want to be dependent on > BGP to exchange capability information. > > g- > > > -----Original Message----- > From: stefano previdi [mailto:sprevidi@cisco.com] > Sent: 09 March 2012 10:44 > To: Watson,G,Grant,DMK5 R > Cc: cdni@ietf.org > Subject: Re: [CDNi] New Version Notification for > draft-previdi-cdni-footprint-advertisement-01.txt > > Hi Grant, > > On Mar 8, 2012, at 11:17 PM, > wrote: > > > > Hi, > > > > The document talks about "Capability Advertisements" and the proposal to > use MP-BGP messages to advertise/exchange CDN capabilities. However, the > document does not explicitly define what is ment by "CDN Capability". > > > indeed... and it is somehow intended... > > As JanS pointed out, there's another draft that should explicit the semantics of > FP/Capabilities. In this proposal we define the mechanism through which the > capability information can be exchanged. > > Obviously, at some point, we'll have to synchronize. > > > > I understand "CDN Capability" to mean things like delivery technology (for > example RTMP or HTTP etc.) or perhaps a specific form of content > authorisation etc. Can you confirm I am correct in assuming this or if not clarify > what the correct meaning is. > > > My understanding goes in the same direction, so far. > > s. > > > > > > Cheers, > > > > g- > > > > > > > > ________________________________________ > > From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf Of > > stefano previdi [sprevidi@cisco.com] > > Sent: 08 March 2012 21:23 > > To: cdni@ietf.org > > Subject: [CDNi] Fwd: New Version Notification for > draft-previdi-cdni-footprint-advertisement-01.txt > > > > Begin forwarded message: > > > >> From: internet-drafts@ietf.org > >> Subject: New Version Notification for > >> draft-previdi-cdni-footprint-advertisement-01.txt > >> Date: March 8, 2012 8:45:53 PM GMT+01:00 > >> To: sprevidi@cisco.com > >> Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com > >> > >> A new version of I-D, draft-previdi-cdni-footprint-advertisement-01.txt has > been successfully submitted by Stefano Previdi and posted to the IETF > repository. > >> > >> Filename: draft-previdi-cdni-footprint-advertisement > >> Revision: 01 > >> Title: CDNI Footprint Advertisement > >> Creation date: 2012-03-08 > >> WG ID: Individual Submission > >> Number of pages: 27 > >> > >> Abstract: > >> This document describes the use of BGP for Content Delivery Networks > >> (CDNs) in order to advertise information about footprint and > >> connectivity to footprint in the context of CDNI. > >> > >> > >> > >> This draft is for the CDNI Working Group. > >> > >> Thanks. > >> s. > >> > >> 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 swainner@cisco.com Mon Mar 12 07:25: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 1A2AD21F875B for ; Mon, 12 Mar 2012 07:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.407 X-Spam-Level: X-Spam-Status: No, score=-9.407 tagged_above=-999 required=5 tests=[AWL=0.591, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_61=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 XbE72ve8fQpc for ; Mon, 12 Mar 2012 07:25:56 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id AF4ED21F87C3 for ; Mon, 12 Mar 2012 07:25:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=15329; q=dns/txt; s=iport; t=1331562355; x=1332771955; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=mQ/+Eh0a0CLnDOFqUAYxjQBBDfR5Y2NoanZ3SQ+tY4Y=; b=EoD+0qVL0wW2WsYC6+jriDDLExWxMGHqnpafrKwyw4FJaUr98P3DtJ45 6RyK4Y4EmiUPCHDdM87E4juKc3sol4kdkDBvp/9XNrpurJKQTPEjl4c3p xBHyIp4+frwsPZICBPfTfk5kBWfzD24QRTrddUqMqNVDE78JZPOrRFt1l Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAL8GXk+rRDoI/2dsb2JhbABDtUyBB4IJAQEBAwEBAQEPARpBBAUBBgcECxEDAQEBAQkWCAcJAwIBAgEVHwkIEwYCAQEeh2MEDJ0VAZ5aBJEBBJVMkCOCfw X-IronPort-AV: E=Sophos;i="4.73,571,1325462400"; d="scan'208,217";a="35736117" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 12 Mar 2012 14:25:55 +0000 Received: from stealth-10-32-245-53.cisco.com (stealth-10-32-245-53.cisco.com [10.32.245.53]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2CEPsKq000497 for ; Mon, 12 Mar 2012 14:25:54 GMT Message-ID: <4F5E07FA.5090402@cisco.com> Date: Mon, 12 Mar 2012 10:28:10 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: cdni@ietf.org References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net> <1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net> In-Reply-To: <1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net> Content-Type: multipart/alternative; boundary="------------050400010806060504070501" Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-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, 12 Mar 2012 14:25:57 -0000 This is a multi-part message in MIME format. --------------050400010806060504070501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I too am struggling with how 'capabilities' can be advertised effectively in BGP. I'm inclined to delineate the 'footprint' from the 'capabilities'. Perhaps one approach is to indicate in the 'capabilities' the various METHODS for assessing the 'footprint'. In the 'capabilities' exchange, the options for METHODS of determining 'footprint' might be BGP AFI or BGP Communities or IGP Distance. Accordingly, a dCDN might indicate it has the capability of advertising (or allowing discovery of) different methods of 'footprint' advertisements and those methods might be weighted. I think the dCDN capabilities (e.g. delivery methods, security methods, etc.) will become far more complex than can be aggregated into a representative set of BGP communities. Nevertheless, I do think BGP communities is a viable method of advertising a 'footprint' ... one that is well understood by the network operators. Scott Wainner On 3/9/12 6:50 AM, grant.watson@bt.com wrote: > > Thanks, understood. > > Then my general feedback would be - I think working out what > capability information needs to be shared between the CDNs would > ideally be worked though prior to deciding the right way to do it. BGP > doesn't feel like an obvious choice for exchanging the kind of CDN > Capability information I'd envisage being passed between CDN. Has a > discussion taken place as to why BGP over other methods? (e.g. > API/metadata) There are drafts discussing metadata right now that > propose ways of describing the capability requirements between CDN > (e.g. "deliver this content using RMTP" etc.), why would we not also > exchange capabilities over the same interface for example? > > It's easier to understand why it may be considered that BGP > should/could be used for the exchange of network footprint information > but less so for CDN Capabilities, IMHO. In some cases CDN may not want > or need to implement footprint advertisement entirely (for example in > a simple bi-lateral relationship the CDN operators could easily elect > to exchange footprint information out-of-band), in this case they > presumably wouldn't want to be dependent on BGP to exchange capability > information. > > g- > > > -----Original Message----- > From: stefano previdi [mailto:sprevidi@cisco.com] > Sent: 09 March 2012 10:44 > To: Watson,G,Grant,DMK5 R > Cc: cdni@ietf.org > Subject: Re: [CDNi] New Version Notification for > draft-previdi-cdni-footprint-advertisement-01.txt > > Hi Grant, > > On Mar 8, 2012, at 11:17 PM, > wrote: > > > > Hi, > > > > The document talks about "Capability Advertisements" and the > proposal to use MP-BGP messages to advertise/exchange CDN > capabilities. However, the document does not explicitly define what is > ment by "CDN Capability". > > > indeed... and it is somehow intended... > > As JanS pointed out, there's another draft that should explicit the > semantics of FP/Capabilities. In this proposal we define the mechanism > through which the capability information can be exchanged. > > Obviously, at some point, we'll have to synchronize. > > > > I understand "CDN Capability" to mean things like delivery > technology (for example RTMP or HTTP etc.) or perhaps a specific form > of content authorisation etc. Can you confirm I am correct in assuming > this or if not clarify what the correct meaning is. > > > My understanding goes in the same direction, so far. > > s. > > > > > > Cheers, > > > > g- > > > > > > > > ________________________________________ > > From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf Of > > stefano previdi [sprevidi@cisco.com] > > Sent: 08 March 2012 21:23 > > To: cdni@ietf.org > > Subject: [CDNi] Fwd: New Version Notification for > draft-previdi-cdni-footprint-advertisement-01.txt > > > > Begin forwarded message: > > > >> From: internet-drafts@ietf.org > >> Subject: New Version Notification for > >> draft-previdi-cdni-footprint-advertisement-01.txt > >> Date: March 8, 2012 8:45:53 PM GMT+01:00 > >> To: sprevidi@cisco.com > >> Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com > >> > >> A new version of I-D, > draft-previdi-cdni-footprint-advertisement-01.txt has been > successfully submitted by Stefano Previdi and posted to the IETF > repository. > >> > >> Filename: draft-previdi-cdni-footprint-advertisement > >> Revision: 01 > >> Title: CDNI Footprint Advertisement > >> Creation date: 2012-03-08 > >> WG ID: Individual Submission > >> Number of pages: 27 > >> > >> Abstract: > >> This document describes the use of BGP for Content Delivery Networks > >> (CDNs) in order to advertise information about footprint and > >> connectivity to footprint in the context of CDNI. > >> > >> > >> > >> This draft is for the CDNI Working Group. > >> > >> Thanks. > >> s. > >> > >> 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 > --------------050400010806060504070501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I too am struggling with how 'capabilities' can be advertised effectively in BGP.  I'm inclined to delineate the 'footprint' from the 'capabilities'.

Perhaps one approach is to indicate in the 'capabilities' the various METHODS for assessing the 'footprint'.  In the 'capabilities' exchange, the options for METHODS of determining 'footprint' might be BGP AFI or BGP Communities or IGP Distance.  Accordingly, a dCDN might indicate it has the capability of advertising (or allowing discovery of) different methods of 'footprint' advertisements and those methods might be weighted.

I think the dCDN capabilities (e.g. delivery methods, security methods, etc.) will become far more complex than can be aggregated into a representative set of BGP communities.  Nevertheless, I do think BGP communities is a viable method of advertising a 'footprint' ... one that is well understood by the network operators.

Scott Wainner

On 3/9/12 6:50 AM, grant.watson@bt.com wrote:
Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-01.txt

Thanks, understood.

Then my general feedback would be - I think working out what capability information needs to be shared between the CDNs would ideally be worked though prior to deciding the right way to do it. BGP doesn't feel like an obvious choice for exchanging the kind of CDN Capability information I'd envisage being passed between CDN. Has a discussion taken place as to why BGP over other methods? (e.g. API/metadata) There are drafts discussing metadata right now that propose ways of describing the capability requirements between CDN (e.g. "deliver this content using RMTP" etc.), why would we not also exchange capabilities over the same interface for example?

It's easier to understand why it may be considered that BGP should/could be used for the exchange of network footprint information but less so for CDN Capabilities, IMHO. In some cases CDN may not want or need to implement footprint advertisement entirely (for example in a simple bi-lateral relationship the CDN operators could easily elect to exchange footprint information out-of-band), in this case they presumably wouldn't want to be dependent on BGP to exchange capability information.

g-


-----Original Message-----
From: stefano previdi [mailto:sprevidi@cisco.com]
Sent: 09 March 2012 10:44
To: Watson,G,Grant,DMK5 R
Cc: cdni@ietf.org
Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-01.txt

Hi Grant,

On Mar 8, 2012, at 11:17 PM, <grant.watson@bt.com> <grant.watson@bt.com> wrote:
>
> Hi,
>
> The document talks about "Capability Advertisements" and the proposal to use MP-BGP messages to advertise/exchange CDN capabilities. However, the document does not explicitly define what is ment by "CDN Capability".


indeed... and it is somehow intended...

As JanS pointed out, there's another draft that should explicit the semantics of FP/Capabilities. In this proposal we define the mechanism through which the capability information can be exchanged.

Obviously, at some point, we'll have to synchronize.


> I understand "CDN Capability" to mean things like delivery technology (for example RTMP or HTTP etc.) or perhaps a specific form of content authorisation etc. Can you confirm I am correct in assuming this or if not clarify what the correct meaning is.


My understanding goes in the same direction, so far.

s.


>
> Cheers,
>
> g-
>
>
>
> ________________________________________
> From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf Of
> stefano previdi [sprevidi@cisco.com]
> Sent: 08 March 2012 21:23
> To: cdni@ietf.org
> Subject: [CDNi] Fwd: New Version Notification for       draft-previdi-cdni-footprint-advertisement-01.txt
>
> Begin forwarded message:
>
>> From: internet-drafts@ietf.org
>> Subject: New Version Notification for
>> draft-previdi-cdni-footprint-advertisement-01.txt
>> Date: March 8, 2012 8:45:53 PM GMT+01:00
>> To: sprevidi@cisco.com
>> Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com
>>
>> A new version of I-D, draft-previdi-cdni-footprint-advertisement-01.txt has been successfully submitted by Stefano Previdi and posted to the IETF repository.
>>
>> Filename:      draft-previdi-cdni-footprint-advertisement
>> Revision:      01
>> Title:                 CDNI Footprint Advertisement
>> Creation date:         2012-03-08
>> WG ID:                 Individual Submission
>> Number of pages: 27
>>
>> Abstract:
>>  This document describes the use of BGP for Content Delivery Networks
>>  (CDNs) in order to advertise information about footprint and 
>> connectivity to footprint in the context of CDNI.
>>
>>
>>
>> This draft is for the CDNI Working Group.
>>
>> Thanks.
>> s.
>>
>> 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


--------------050400010806060504070501-- From flefauch@cisco.com Tue Mar 13 11:39: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 E9EC421F86F5 for ; Tue, 13 Mar 2012 11:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.166 X-Spam-Level: X-Spam-Status: No, score=-10.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 Gw25wsCByFCO for ; Tue, 13 Mar 2012 11:39:16 -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 EAD5721F8663 for ; Tue, 13 Mar 2012 11:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=8416; q=dns/txt; s=iport; t=1331663956; x=1332873556; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=E0K2hSLvfkdvwalwfllIzwUFLQh434IfV+41vxpVUaU=; b=joqfayGtvzn/Y4JUBV9NrSmujp2YsSqQf9zVn5WMTXtqfNlLzAhfPg71 KVH5dK4nr/wPOGyzobnpw5ps28hxq5kLNsphRA2NtZ0giBckGOBHJ2YbS DApROmH+NKweqg7RQT8dqPVWxnnGhWgn0NbKW55qMV8ZxLh/9jSLP5c6g c=; X-IronPort-AV: E=Sophos;i="4.73,578,1325462400"; d="scan'208";a="132215948" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 13 Mar 2012 18:39:14 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2DIdDbF012115; Tue, 13 Mar 2012 18:39:14 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Francois Le Faucheur In-Reply-To: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> Date: Tue, 13 Mar 2012 19:39:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> To: "Kent Leung (kleung)" , Niven-Jenkins Ben X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org, Viveganandhan Mahesh Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-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, 13 Mar 2012 18:39:18 -0000 Ben, Kent, Trying to extract the key points from the thread: 1) level of requirement for support of HTTP Adaptive Streaming Logging = Session (ie ABR-aware logs): This is a valid question.=20 The I-D proposes that some form of ABR-aware logging be mandatory. The = rationale is that ABR is expected to be a very common delivery format = and requires some form of log compression over very voluminous = per-segment logging. (BTW the I-D currently proposes that both = Segment-Based Logging format and Event-Based Logging format be = mandatory. But come to think of it, having only Event-Based Logging = format mandatory would be sufficient from my viewpoint).=20 Ben argues that ABR-aware logging should not be mandatory as it requires = extra awareness. To get more input, I'd propose we move that requirement level discussion = to the cdni-requirements document, and have the logging I-D only talks = about what such logs would look like. 2) flexible set of log fields: I agree it is a good idea to allow the uCDN to customize the set of log = fields reported by a dCDN for delivery. I was thinking that we'd start = with defining a few "fixed" set of fields and then later add the = customization, but perhaps we can start directly with customizable sets = of fields. To do that, I'd propose to: * retain the notion of Format Types (e.g Delivery_HTTP, = Delivery_Adaptive_Event, ...) * define a set of candidate fields in each Format Type * have uCDN signal in Metadata interface the desired Format Type = + set of fields needed (ie a subset of the set of candidate fields) * have dCDN explicitly indicate inside each log file (eg in File = Header), the Format Type and the set of fields actually included * define handling of potential capability mismatch situations if = any (eg1 uCDN requests a field that is not supported by dCDN if we allow = that, eg2 dCDN requests a format type that is not supported by dCDN). 3) encoding format: I also agree the W3C extended log format is a good base candidate to = look at. 4) summarization of Logging info for Adaptive Streaming delivery I believe some form of summarization is required. The Event-Based = Logging seems like a nice sweet-spot because it achieves a high = summarization gain without losing any info (ie any change in = bandwidth/quality is logged). The I-D suggests we may be able to come up = with another interesting sweet-spot (Summary-Based Log) providing a huge = summarization gain at the cost of losing some details, but does not yet = specify this. Ben, it'd be interesting to provide a brief write-up on the = summarization approach you mention so we can evaluate it (an email to = the list woudl be just fine). Thanks for the discussion. Francois =20 On 9 Mar 2012, at 00:48, Kent Leung (kleung) wrote: > Comments below. >=20 >>=20 >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > Of >>=20 >> Some comments on draft-lefaucheur-cdni-logging-delivery-00. >>=20 >> 1) In section 3.2.1.2 (Segment-Based Log fields) and section 3.2.2.1 >> (Event Based Log Triggers) you mandate support for a number of log >> fields such as abr-protocol, representation, manifest-id and > content-id >> that a downstream CDN may have no ability to generate, for example >> because the downstream CDN is acting in a pure HTTP reverse proxy = mode >> and may not be aware of that level of information and/or because the >> control of how to identify those fields is owned by the CSP and none > of >> CDNs may have visibility of that mapping information. >>=20 >> Such a requirement to force CDNs and CDNI in general to require such >> mappings seems overkill to me. >>=20 >> KL> As stated, "... such aggregation requires a degree of application >> awareness in dCDN to recognize that the many HTTP requests correspond > to >> a single video." So the premise is that the dCDN knows that it's >> delivering ABR content. In some cases, it's possible that the >> representation may not be known. >=20 > And my point is that I don't think that premise holds true and reality > is the opposite, i.e. in general the dCDN will not know what it's > delivering and only some dCDNs will have the application awareness to > produce the log fields you suggest. >=20 > KL> Hmm, if the dCDN is not aware about the ABR session, then Section > 3.2 would not apply since the dCDN considers itself to be delivering > non-ABR content. Non-ABR content delivery does not require the log > fields specified in this section. >=20 >=20 >> But in general, the log fields contain >> information that are pertinent to an ABR content. >=20 > I am not exactly sure what you mean by this. I agree the fields you > suggest would be useful but I don't think having the application > awareness to generate them should be a mandatory requirement for > interoperability as suggested by section 3.2 >=20 > An implementation of the CDNI Logging interface MUST support logging > for delivery of content using HTTP adaptive streaming in the = Segment- > Based Logging format and the Event-Based Logging format, and MAY > support logging in the Summary-Based Logging format. >=20 > KL> Are these fields in Sect 3.2 useful or applicable for non-ABR > content delivery? No. I sense that I'm still missing your point. >=20 >=20 >> 2) In section 6 you propose an additional requirement to allow an >> upstream CDN to indicate through CDNI metadata the log format the >> downstream CDN should use. Rather than define a set of specific > formats, >> we could allow the upstream CDN to specify CDNI metadata indicating > the >> specific log fields it is interested in receiving. The upstream CDN >> could then tailor what it asks for according to what it requires and >> avoid the transfer of log fields that it does not need. >>=20 >> KL> Agree that it's useful for uCDN to request only the information >> that's needed without extraneous fields. This can be accomplished = with > a >> customized log format provided by uCDN. In a sense, this is a = superset >> of selective fields. >=20 > That is another approach which would probably make life easier for the > dCDN. >=20 >> 4) If the motivation for summary/aggregated log lines is a concern > over >> the volume of data that needs to be transferred then in Velocix we > have >> done some experiments on using an alternative lookup table based >> structure for log lines that retains all the verbosity of the = original >> delivery log lines but by itself appears to give equivalent > compression >> to gzip and combined with gzip reduces the size significantly when >> compared to what gzip alone achieves (in some cases averaging as > little >> as 13 bits per complete log line). >>=20 >> If the volume of logs to be transferred is a concern and there is >> interest in investigating this approach further I can write-up more >> details either in a separate draft or as a section in >> draft-lefaucheur-cdni-logging-delivery. >>=20 >> KL> I think the intent is to summarize succinctly the ABR session in > the >> logging. >=20 > I think they're two separate things. If we're worried about the volume > of data our experiments show that can be significantly reduced using > structured log files with lookup tables. That technique is applicable > regardless of the actual fields in a log file. >=20 > Whether we require ABR session summary information to be logged is a > separate discussion to how we might optimise the structure of any log > files we require. >=20 > Ben >=20 > KL> Sure, I think we can discuss more on this when Francois is = available > as I'm not clear on his thoughts. >=20 > Kent >=20 >> I haven't discussed this in finer details with Francois yet. It >> seems to me that the compression technique can be considered as >> optimization in delivery of either session-based or event-based > logging. >> We can discuss this further if our goals are aligned. >>=20 >> Kent >>=20 >> Ben >> _______________________________________________ >> 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 stef@jet-stream.com Wed Mar 14 03:07: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 B1C3A21F8742 for ; Wed, 14 Mar 2012 03:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_61=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 IgcnKvZ3NlBw for ; Wed, 14 Mar 2012 03:07:29 -0700 (PDT) Received: from monitor1.jet-stream.nl (smtp.jet-stream.nl [91.196.106.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1E80C21F871B for ; Wed, 14 Mar 2012 03:07:27 -0700 (PDT) Received: from stef-jts-imac27.jetstream.office ([193.138.250.6]) (authenticated bits=0) by monitor1.jet-stream.nl (8.13.7/8.13.7) with ESMTP id q2EA7Se5007985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 14 Mar 2012 11:07:29 +0100 From: Stef van der Ziel Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_C5826D32-3CE7-430E-84B3-3DD8287C08DC" Date: Wed, 14 Mar 2012 11:07:23 +0100 In-Reply-To: <4F5E07FA.5090402@cisco.com> To: cdni@ietf.org References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net> <1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net> <4F5E07FA.5090402@cisco.com> Message-Id: <5826DF56-7335-49C6-997A-AAB109ED0913@jet-stream.com> X-Mailer: Apple Mail (2.1257) Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-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, 14 Mar 2012 10:07:30 -0000 --Apple-Mail=_C5826D32-3CE7-430E-84B3-3DD8287C08DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, I would not recommend using BGP for CDN capabilities sharing. BGP is a networking layer protocol. CDNs can and should run = independently from the network, or span multiple networks. Or run within = a part of a network, where BGP is not the right protocol. CDNs should = not be locked into networks or become dependent on networking layered = protocols. CDN interconnection should be done via APIs. Kind regards,=20 Stef van der Ziel On 12 mrt. 2012, at 15:28, Scott Wainner wrote: > I too am struggling with how 'capabilities' can be advertised = effectively in BGP. I'm inclined to delineate the 'footprint' from the = 'capabilities'. >=20 > Perhaps one approach is to indicate in the 'capabilities' the various = METHODS for assessing the 'footprint'. In the 'capabilities' exchange, = the options for METHODS of determining 'footprint' might be BGP AFI or = BGP Communities or IGP Distance. Accordingly, a dCDN might indicate it = has the capability of advertising (or allowing discovery of) different = methods of 'footprint' advertisements and those methods might be = weighted. >=20 > I think the dCDN capabilities (e.g. delivery methods, security = methods, etc.) will become far more complex than can be aggregated into = a representative set of BGP communities. Nevertheless, I do think BGP = communities is a viable method of advertising a 'footprint' ... one that = is well understood by the network operators. >=20 > Scott Wainner >=20 > On 3/9/12 6:50 AM, grant.watson@bt.com wrote: >>=20 >> Thanks, understood. >>=20 >> Then my general feedback would be - I think working out what = capability information needs to be shared between the CDNs would ideally = be worked though prior to deciding the right way to do it. BGP doesn't = feel like an obvious choice for exchanging the kind of CDN Capability = information I'd envisage being passed between CDN. Has a discussion = taken place as to why BGP over other methods? (e.g. API/metadata) There = are drafts discussing metadata right now that propose ways of describing = the capability requirements between CDN (e.g. "deliver this content = using RMTP" etc.), why would we not also exchange capabilities over the = same interface for example? >>=20 >> It's easier to understand why it may be considered that BGP = should/could be used for the exchange of network footprint information = but less so for CDN Capabilities, IMHO. In some cases CDN may not want = or need to implement footprint advertisement entirely (for example in a = simple bi-lateral relationship the CDN operators could easily elect to = exchange footprint information out-of-band), in this case they = presumably wouldn't want to be dependent on BGP to exchange capability = information. >>=20 >> g- >>=20 >>=20 >> -----Original Message----- >> From: stefano previdi [mailto:sprevidi@cisco.com] >> Sent: 09 March 2012 10:44 >> To: Watson,G,Grant,DMK5 R >> Cc: cdni@ietf.org >> Subject: Re: [CDNi] New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>=20 >> Hi Grant, >>=20 >> On Mar 8, 2012, at 11:17 PM, = wrote: >> > >> > Hi, >> > >> > The document talks about "Capability Advertisements" and the = proposal to use MP-BGP messages to advertise/exchange CDN capabilities. = However, the document does not explicitly define what is ment by "CDN = Capability". >>=20 >>=20 >> indeed... and it is somehow intended... >>=20 >> As JanS pointed out, there's another draft that should explicit the = semantics of FP/Capabilities. In this proposal we define the mechanism = through which the capability information can be exchanged. >>=20 >> Obviously, at some point, we'll have to synchronize. >>=20 >>=20 >> > I understand "CDN Capability" to mean things like delivery = technology (for example RTMP or HTTP etc.) or perhaps a specific form of = content authorisation etc. Can you confirm I am correct in assuming this = or if not clarify what the correct meaning is. >>=20 >>=20 >> My understanding goes in the same direction, so far. >>=20 >> s. >>=20 >>=20 >> > >> > Cheers, >> > >> > g- >> > >> > >> > >> > ________________________________________ >> > From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf Of >> > stefano previdi [sprevidi@cisco.com] >> > Sent: 08 March 2012 21:23 >> > To: cdni@ietf.org >> > Subject: [CDNi] Fwd: New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >> > >> > Begin forwarded message: >> > >> >> From: internet-drafts@ietf.org >> >> Subject: New Version Notification for >> >> draft-previdi-cdni-footprint-advertisement-01.txt >> >> Date: March 8, 2012 8:45:53 PM GMT+01:00 >> >> To: sprevidi@cisco.com >> >> Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com >> >> >> >> A new version of I-D, = draft-previdi-cdni-footprint-advertisement-01.txt has been successfully = submitted by Stefano Previdi and posted to the IETF repository. >> >> >> >> Filename: draft-previdi-cdni-footprint-advertisement >> >> Revision: 01 >> >> Title: CDNI Footprint Advertisement >> >> Creation date: 2012-03-08 >> >> WG ID: Individual Submission >> >> Number of pages: 27 >> >> >> >> Abstract: >> >> This document describes the use of BGP for Content Delivery = Networks >> >> (CDNs) in order to advertise information about footprint and=20 >> >> connectivity to footprint in the context of CDNI. >> >> >> >> >> >> >> >> This draft is for the CDNI Working Group. >> >> >> >> Thanks. >> >> s. >> >> >> >> The IETF Secretariat >> >> >> > >> > _______________________________________________ >> > 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 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --Apple-Mail=_C5826D32-3CE7-430E-84B3-3DD8287C08DC Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
Hi,

I would not recommend using BGP for CDN capabilities sharing.
BGP is a networking layer protocol. CDNs can and should run independently from the network, or span multiple networks. Or run within a part of a network, where BGP is not the right protocol. CDNs should not be locked into networks or become dependent on networking layered protocols. CDN interconnection should be done via APIs.

Kind regards, 

Stef van der Ziel


On 12 mrt. 2012, at 15:28, Scott Wainner wrote:

I too am struggling with how 'capabilities' can be advertised effectively in BGP.  I'm inclined to delineate the 'footprint' from the 'capabilities'.

Perhaps one approach is to indicate in the 'capabilities' the various METHODS for assessing the 'footprint'.  In the 'capabilities' exchange, the options for METHODS of determining 'footprint' might be BGP AFI or BGP Communities or IGP Distance.  Accordingly, a dCDN might indicate it has the capability of advertising (or allowing discovery of) different methods of 'footprint' advertisements and those methods might be weighted.

I think the dCDN capabilities (e.g. delivery methods, security methods, etc.) will become far more complex than can be aggregated into a representative set of BGP communities.  Nevertheless, I do think BGP communities is a viable method of advertising a 'footprint' ... one that is well understood by the network operators.

Scott Wainner

On 3/9/12 6:50 AM, grant.watson@bt.com wrote:
Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-01.txt

Thanks, understood.

Then my general feedback would be - I think working out what capability information needs to be shared between the CDNs would ideally be worked though prior to deciding the right way to do it. BGP doesn't feel like an obvious choice for exchanging the kind of CDN Capability information I'd envisage being passed between CDN. Has a discussion taken place as to why BGP over other methods? (e.g. API/metadata) There are drafts discussing metadata right now that propose ways of describing the capability requirements between CDN (e.g. "deliver this content using RMTP" etc.), why would we not also exchange capabilities over the same interface for example?

It's easier to understand why it may be considered that BGP should/could be used for the exchange of network footprint information but less so for CDN Capabilities, IMHO. In some cases CDN may not want or need to implement footprint advertisement entirely (for example in a simple bi-lateral relationship the CDN operators could easily elect to exchange footprint information out-of-band), in this case they presumably wouldn't want to be dependent on BGP to exchange capability information.

g-


-----Original Message-----
From: stefano previdi [mailto:sprevidi@cisco.com]
Sent: 09 March 2012 10:44
To: Watson,G,Grant,DMK5 R
Cc: cdni@ietf.org
Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-01.txt

Hi Grant,

On Mar 8, 2012, at 11:17 PM, <grant.watson@bt.com> <grant.watson@bt.com> wrote:
>
> Hi,
>
> The document talks about "Capability Advertisements" and the proposal to use MP-BGP messages to advertise/exchange CDN capabilities. However, the document does not explicitly define what is ment by "CDN Capability".


indeed... and it is somehow intended...

As JanS pointed out, there's another draft that should explicit the semantics of FP/Capabilities. In this proposal we define the mechanism through which the capability information can be exchanged.

Obviously, at some point, we'll have to synchronize.


> I understand "CDN Capability" to mean things like delivery technology (for example RTMP or HTTP etc.) or perhaps a specific form of content authorisation etc. Can you confirm I am correct in assuming this or if not clarify what the correct meaning is.


My understanding goes in the same direction, so far.

s.


>
> Cheers,
>
> g-
>
>
>
> ________________________________________
> From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf Of
> stefano previdi [sprevidi@cisco.com]
> Sent: 08 March 2012 21:23
> To: cdni@ietf.org
> Subject: [CDNi] Fwd: New Version Notification for       draft-previdi-cdni-footprint-advertisement-01.txt
>
> Begin forwarded message:
>
>> From: internet-drafts@ietf.org
>> Subject: New Version Notification for
>> draft-previdi-cdni-footprint-advertisement-01.txt
>> Date: March 8, 2012 8:45:53 PM GMT+01:00
>> To: sprevidi@cisco.com
>> Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com
>>
>> A new version of I-D, draft-previdi-cdni-footprint-advertisement-01.txt has been successfully submitted by Stefano Previdi and posted to the IETF repository.
>>
>> Filename:      draft-previdi-cdni-footprint-advertisement
>> Revision:      01
>> Title:                 CDNI Footprint Advertisement
>> Creation date:         2012-03-08
>> WG ID:                 Individual Submission
>> Number of pages: 27
>>
>> Abstract:
>>  This document describes the use of BGP for Content Delivery Networks
>>  (CDNs) in order to advertise information about footprint and 
>> connectivity to footprint in the context of CDNI.
>>
>>
>>
>> This draft is for the CDNI Working Group.
>>
>> Thanks.
>> s.
>>
>> 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

--Apple-Mail=_C5826D32-3CE7-430E-84B3-3DD8287C08DC-- From sprevidi@cisco.com Wed Mar 14 03:33: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 A5CE721F867E for ; Wed, 14 Mar 2012 03:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_61=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 6AENTMusWEzg for ; Wed, 14 Mar 2012 03:33:27 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 880D321F867B for ; Wed, 14 Mar 2012 03:33:27 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q2EAXOBH002478 for ; Wed, 14 Mar 2012 11:33:24 +0100 (CET) Received: from dhcp-10-55-81-152.cisco.com (dhcp-10-55-81-152.cisco.com [10.55.81.152]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q2EAXNj0021540; Wed, 14 Mar 2012 11:33:24 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: stefano previdi In-Reply-To: <5826DF56-7335-49C6-997A-AAB109ED0913@jet-stream.com> Date: Wed, 14 Mar 2012 11:33:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net> <1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net> <4F5E07FA.5090402@cisco.com> <5826DF56-7335-49C6-997A-AAB109ED0913@jet-stream.com> To: Stef van der Ziel X-Mailer: Apple Mail (2.1257) Cc: cdni@ietf.org Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-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, 14 Mar 2012 10:33:28 -0000 On Mar 14, 2012, at 11:07 AM, Stef van der Ziel wrote: > Hi, >=20 > I would not recommend using BGP for CDN capabilities sharing. > BGP is a networking layer protocol. not in the way we propose to use it in the CDNI context. > CDNs can and should run independently from the network, or span = multiple networks. Or run within a part of a network, where BGP is not = the right protocol. well, BGP is to be intended as MP-BGP with a scope of advertising=20 footprint and capability information. In that respect the semantic=20 is pretty clear. The fact that BGP is also used in other contexts=20 such as network layer routing, MPLS-VPN, multicast, etc. doesn't=20 preclude the use of the same technology into another context. > CDNs should not be locked into networks or become dependent on = networking layered protocols. absolutely agree. As you can see from the proposal, we leverage=20 what's available in the BGP databases as for footprint information.=20 However, also described in the proposal, we allow complete freedom=20 to any CDNI MP-BGP player to define its own policy and elements to=20 advertise. s. > CDN interconnection should be done via APIs. >=20 > Kind regards,=20 >=20 > Stef van der Ziel >=20 >=20 > On 12 mrt. 2012, at 15:28, Scott Wainner wrote: >=20 >> I too am struggling with how 'capabilities' can be advertised = effectively in BGP. I'm inclined to delineate the 'footprint' from the = 'capabilities'. >>=20 >> Perhaps one approach is to indicate in the 'capabilities' the various = METHODS for assessing the 'footprint'. In the 'capabilities' exchange, = the options for METHODS of determining 'footprint' might be BGP AFI or = BGP Communities or IGP Distance. Accordingly, a dCDN might indicate it = has the capability of advertising (or allowing discovery of) different = methods of 'footprint' advertisements and those methods might be = weighted. >>=20 >> I think the dCDN capabilities (e.g. delivery methods, security = methods, etc.) will become far more complex than can be aggregated into = a representative set of BGP communities. Nevertheless, I do think BGP = communities is a viable method of advertising a 'footprint' ... one that = is well understood by the network operators. >>=20 >> Scott Wainner >>=20 >> On 3/9/12 6:50 AM, grant.watson@bt.com wrote: >>> Thanks, understood. >>>=20 >>> Then my general feedback would be - I think working out what = capability information needs to be shared between the CDNs would ideally = be worked though prior to deciding the right way to do it. BGP doesn't = feel like an obvious choice for exchanging the kind of CDN Capability = information I'd envisage being passed between CDN. Has a discussion = taken place as to why BGP over other methods? (e.g. API/metadata) There = are drafts discussing metadata right now that propose ways of describing = the capability requirements between CDN (e.g. "deliver this content = using RMTP" etc.), why would we not also exchange capabilities over the = same interface for example? >>>=20 >>> It's easier to understand why it may be considered that BGP = should/could be used for the exchange of network footprint information = but less so for CDN Capabilities, IMHO. In some cases CDN may not want = or need to implement footprint advertisement entirely (for example in a = simple bi-lateral relationship the CDN operators could easily elect to = exchange footprint information out-of-band), in this case they = presumably wouldn't want to be dependent on BGP to exchange capability = information. >>>=20 >>> g- >>>=20 >>>=20 >>> -----Original Message----- >>> From: stefano previdi [mailto:sprevidi@cisco.com] >>> Sent: 09 March 2012 10:44 >>> To: Watson,G,Grant,DMK5 R >>> Cc: cdni@ietf.org >>> Subject: Re: [CDNi] New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>>=20 >>> Hi Grant, >>>=20 >>> On Mar 8, 2012, at 11:17 PM, = wrote: >>> > >>> > Hi, >>> > >>> > The document talks about "Capability Advertisements" and the = proposal to use MP-BGP messages to advertise/exchange CDN capabilities. = However, the document does not explicitly define what is ment by "CDN = Capability". >>>=20 >>>=20 >>> indeed... and it is somehow intended... >>>=20 >>> As JanS pointed out, there's another draft that should explicit the = semantics of FP/Capabilities. In this proposal we define the = mechanism through which the capability information can be exchanged. >>>=20 >>> Obviously, at some point, we'll have to synchronize. >>>=20 >>>=20 >>> > I understand "CDN Capability" to mean things like delivery = technology (for example RTMP or HTTP etc.) or perhaps a specific form of = content authorisation etc. Can you confirm I am correct in assuming this = or if not clarify what the correct meaning is. >>>=20 >>>=20 >>> My understanding goes in the same direction, so far. >>>=20 >>> s. >>>=20 >>>=20 >>> > >>> > Cheers, >>> > >>> > g- >>> > >>> > >>> > >>> > ________________________________________ >>> > From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf Of >>> > stefano previdi [sprevidi@cisco.com] >>> > Sent: 08 March 2012 21:23 >>> > To: cdni@ietf.org >>> > Subject: [CDNi] Fwd: New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>> > >>> > Begin forwarded message: >>> > >>> >> From: internet-drafts@ietf.org >>> >> Subject: New Version Notification for >>> >> draft-previdi-cdni-footprint-advertisement-01.txt >>> >> Date: March 8, 2012 8:45:53 PM GMT+01:00 >>> >> To: sprevidi@cisco.com >>> >> Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com >>> >> >>> >> A new version of I-D, = draft-previdi-cdni-footprint-advertisement-01.txt has been successfully = submitted by Stefano Previdi and posted to the IETF repository. >>> >> >>> >> Filename: draft-previdi-cdni-footprint-advertisement >>> >> Revision: 01 >>> >> Title: CDNI Footprint Advertisement >>> >> Creation date: 2012-03-08 >>> >> WG ID: Individual Submission >>> >> Number of pages: 27 >>> >> >>> >> Abstract: >>> >> This document describes the use of BGP for Content Delivery = Networks >>> >> (CDNs) in order to advertise information about footprint and=20 >>> >> connectivity to footprint in the context of CDNI. >>> >> >>> >> >>> >> >>> >> This draft is for the CDNI Working Group. >>> >> >>> >> Thanks. >>> >> s. >>> >> >>> >> The IETF Secretariat >>> >> >>> > >>> > _______________________________________________ >>> > 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 >> _______________________________________________ >> 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 stef@jet-stream.com Wed Mar 14 03:38: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 D65D721F861A for ; Wed, 14 Mar 2012 03:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.096 X-Spam-Level: X-Spam-Status: No, score=0.096 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_61=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 IIW9dcnC3JuP for ; Wed, 14 Mar 2012 03:38:10 -0700 (PDT) Received: from monitor1.jet-stream.nl (smtp.jet-stream.nl [91.196.106.226]) by ietfa.amsl.com (Postfix) with ESMTP id B310F21F8617 for ; Wed, 14 Mar 2012 03:38:09 -0700 (PDT) Received: from stef-jts-imac27.jetstream.office ([193.138.250.6]) (authenticated bits=0) by monitor1.jet-stream.nl (8.13.7/8.13.7) with ESMTP id q2EAcClQ012597 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 14 Mar 2012 11:38:13 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1257) From: Stef van der Ziel In-Reply-To: Date: Wed, 14 Mar 2012 11:38:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2C86FE78-1178-447F-8CB4-5AEA63625679@jet-stream.com> References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net> <1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net> <4F5E07FA.5090402@cisco.com> <5826DF56-7335-49C6-997A-AAB109ED0913@jet-stream.com> To: cdni@ietf.org X-Mailer: Apple Mail (2.1257) Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-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, 14 Mar 2012 10:38:10 -0000 Hi, It still looks like you're trying to lock CDNs into networking layer = protocols and use protocols for which they were not intended.=20 In most CDNs we deployed, BGP doesn't play any role. Not even in = federated scenarios.=20 Better use proper APIs!=20 Best, Stef On 14 mrt. 2012, at 11:33, stefano previdi wrote: >=20 > On Mar 14, 2012, at 11:07 AM, Stef van der Ziel wrote: >=20 >> Hi, >>=20 >> I would not recommend using BGP for CDN capabilities sharing. >> BGP is a networking layer protocol. >=20 >=20 > not in the way we propose to use it in the CDNI context. >=20 >=20 >> CDNs can and should run independently from the network, or span = multiple networks. Or run within a part of a network, where BGP is not = the right protocol. >=20 >=20 > well, BGP is to be intended as MP-BGP with a scope of advertising=20 > footprint and capability information. In that respect the semantic=20 > is pretty clear. The fact that BGP is also used in other contexts=20 > such as network layer routing, MPLS-VPN, multicast, etc. doesn't=20 > preclude the use of the same technology into another context. >=20 >=20 >> CDNs should not be locked into networks or become dependent on = networking layered protocols. >=20 >=20 > absolutely agree. As you can see from the proposal, we leverage=20 > what's available in the BGP databases as for footprint information.=20 > However, also described in the proposal, we allow complete freedom=20 > to any CDNI MP-BGP player to define its own policy and elements to=20 > advertise. >=20 > s. >=20 >=20 >> CDN interconnection should be done via APIs. >>=20 >> Kind regards,=20 >>=20 >> Stef van der Ziel >>=20 >>=20 >> On 12 mrt. 2012, at 15:28, Scott Wainner wrote: >>=20 >>> I too am struggling with how 'capabilities' can be advertised = effectively in BGP. I'm inclined to delineate the 'footprint' from the = 'capabilities'. >>>=20 >>> Perhaps one approach is to indicate in the 'capabilities' the = various METHODS for assessing the 'footprint'. In the 'capabilities' = exchange, the options for METHODS of determining 'footprint' might be = BGP AFI or BGP Communities or IGP Distance. Accordingly, a dCDN might = indicate it has the capability of advertising (or allowing discovery of) = different methods of 'footprint' advertisements and those methods might = be weighted. >>>=20 >>> I think the dCDN capabilities (e.g. delivery methods, security = methods, etc.) will become far more complex than can be aggregated into = a representative set of BGP communities. Nevertheless, I do think BGP = communities is a viable method of advertising a 'footprint' ... one that = is well understood by the network operators. >>>=20 >>> Scott Wainner >>>=20 >>> On 3/9/12 6:50 AM, grant.watson@bt.com wrote: >>>> Thanks, understood. >>>>=20 >>>> Then my general feedback would be - I think working out what = capability information needs to be shared between the CDNs would ideally = be worked though prior to deciding the right way to do it. BGP doesn't = feel like an obvious choice for exchanging the kind of CDN Capability = information I'd envisage being passed between CDN. Has a discussion = taken place as to why BGP over other methods? (e.g. API/metadata) There = are drafts discussing metadata right now that propose ways of describing = the capability requirements between CDN (e.g. "deliver this content = using RMTP" etc.), why would we not also exchange capabilities over the = same interface for example? >>>>=20 >>>> It's easier to understand why it may be considered that BGP = should/could be used for the exchange of network footprint information = but less so for CDN Capabilities, IMHO. In some cases CDN may not want = or need to implement footprint advertisement entirely (for example in a = simple bi-lateral relationship the CDN operators could easily elect to = exchange footprint information out-of-band), in this case they = presumably wouldn't want to be dependent on BGP to exchange capability = information. >>>>=20 >>>> g- >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: stefano previdi [mailto:sprevidi@cisco.com] >>>> Sent: 09 March 2012 10:44 >>>> To: Watson,G,Grant,DMK5 R >>>> Cc: cdni@ietf.org >>>> Subject: Re: [CDNi] New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>>>=20 >>>> Hi Grant, >>>>=20 >>>> On Mar 8, 2012, at 11:17 PM, = wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> The document talks about "Capability Advertisements" and the = proposal to use MP-BGP messages to advertise/exchange CDN capabilities. = However, the document does not explicitly define what is ment by "CDN = Capability". >>>>=20 >>>>=20 >>>> indeed... and it is somehow intended... >>>>=20 >>>> As JanS pointed out, there's another draft that should explicit the = semantics of FP/Capabilities. In this proposal we define the = mechanism through which the capability information can be exchanged. >>>>=20 >>>> Obviously, at some point, we'll have to synchronize. >>>>=20 >>>>=20 >>>>> I understand "CDN Capability" to mean things like delivery = technology (for example RTMP or HTTP etc.) or perhaps a specific form of = content authorisation etc. Can you confirm I am correct in assuming this = or if not clarify what the correct meaning is. >>>>=20 >>>>=20 >>>> My understanding goes in the same direction, so far. >>>>=20 >>>> s. >>>>=20 >>>>=20 >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> g- >>>>>=20 >>>>>=20 >>>>>=20 >>>>> ________________________________________ >>>>> From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf Of >>>>> stefano previdi [sprevidi@cisco.com] >>>>> Sent: 08 March 2012 21:23 >>>>> To: cdni@ietf.org >>>>> Subject: [CDNi] Fwd: New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>>> From: internet-drafts@ietf.org >>>>>> Subject: New Version Notification for >>>>>> draft-previdi-cdni-footprint-advertisement-01.txt >>>>>> Date: March 8, 2012 8:45:53 PM GMT+01:00 >>>>>> To: sprevidi@cisco.com >>>>>> Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com >>>>>>=20 >>>>>> A new version of I-D, = draft-previdi-cdni-footprint-advertisement-01.txt has been successfully = submitted by Stefano Previdi and posted to the IETF repository. >>>>>>=20 >>>>>> Filename: draft-previdi-cdni-footprint-advertisement >>>>>> Revision: 01 >>>>>> Title: CDNI Footprint Advertisement >>>>>> Creation date: 2012-03-08 >>>>>> WG ID: Individual Submission >>>>>> Number of pages: 27 >>>>>>=20 >>>>>> Abstract: >>>>>> This document describes the use of BGP for Content Delivery = Networks >>>>>> (CDNs) in order to advertise information about footprint and=20 >>>>>> connectivity to footprint in the context of CDNI. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> This draft is for the CDNI Working Group. >>>>>>=20 >>>>>> Thanks. >>>>>> s. >>>>>>=20 >>>>>> The IETF Secretariat >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> CDNi mailing list >>>>> CDNi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >>>>=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 >=20 >=20 From sprevidi@cisco.com Wed Mar 14 04:25: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 8C8AD21F8797 for ; Wed, 14 Mar 2012 04:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.236 X-Spam-Level: X-Spam-Status: No, score=-102.236 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, J_CHICKENPOX_61=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 LNF9ljgzDKmQ for ; Wed, 14 Mar 2012 04:25:52 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5F221F854D for ; Wed, 14 Mar 2012 04:25:52 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q2EBPpZL008954 for ; Wed, 14 Mar 2012 12:25:51 +0100 (CET) Received: from ams3-vpn-dhcp4632.cisco.com (ams3-vpn-dhcp4632.cisco.com [10.61.82.23]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q2EBPoeC004070; Wed, 14 Mar 2012 12:25:51 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: stefano previdi In-Reply-To: <2C86FE78-1178-447F-8CB4-5AEA63625679@jet-stream.com> Date: Wed, 14 Mar 2012 12:25:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <86AF8FF6-4BF3-41D9-837F-21A392C87F83@cisco.com> References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net> <1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net> <4F5E07FA.5090402@cisco.com> <5826DF56-7335-49C6-997A-AAB109ED0913@jet-stream.com> <2C86FE78-1178-447F-8CB4-5AEA63625679@jet-stream.com> To: Stef van der Ziel X-Mailer: Apple Mail (2.1257) Cc: cdni@ietf.org Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-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, 14 Mar 2012 11:25:53 -0000 On Mar 14, 2012, at 11:38 AM, Stef van der Ziel wrote: > Hi, >=20 > It still looks like you're trying to lock CDNs into networking layer = protocols and use protocols for which they were not intended.=20 well, I don't think so. We use the same tool... but differently. > In most CDNs we deployed, BGP doesn't play any role. Not even in = federated scenarios.=20 yes, but at the end of the day, the CDN relies on internet routing so=20 at some point there's a relationship between the CDN and the network=20 layer. In our proposal we just leverage the reachability information you can=20 get from your local SP/ISP so to figure out footprint information. Capabilities, I agree with you, is a different story but since we=20 don't know yet what is a capability (and which format it should/must/may=20= have) it's difficult to come with a proper scheme. Having said that, BGP=20= (as a tool) has all feature you need so to propagate both FP and caps. s. > Better use proper APIs!=20 >=20 > Best, Stef >=20 >=20 > On 14 mrt. 2012, at 11:33, stefano previdi wrote: >=20 >>=20 >> On Mar 14, 2012, at 11:07 AM, Stef van der Ziel wrote: >>=20 >>> Hi, >>>=20 >>> I would not recommend using BGP for CDN capabilities sharing. >>> BGP is a networking layer protocol. >>=20 >>=20 >> not in the way we propose to use it in the CDNI context. >>=20 >>=20 >>> CDNs can and should run independently from the network, or span = multiple networks. Or run within a part of a network, where BGP is not = the right protocol. >>=20 >>=20 >> well, BGP is to be intended as MP-BGP with a scope of advertising=20 >> footprint and capability information. In that respect the semantic=20 >> is pretty clear. The fact that BGP is also used in other contexts=20 >> such as network layer routing, MPLS-VPN, multicast, etc. doesn't=20 >> preclude the use of the same technology into another context. >>=20 >>=20 >>> CDNs should not be locked into networks or become dependent on = networking layered protocols. >>=20 >>=20 >> absolutely agree. As you can see from the proposal, we leverage=20 >> what's available in the BGP databases as for footprint information.=20= >> However, also described in the proposal, we allow complete freedom=20 >> to any CDNI MP-BGP player to define its own policy and elements to=20 >> advertise. >>=20 >> s. >>=20 >>=20 >>> CDN interconnection should be done via APIs. >>>=20 >>> Kind regards,=20 >>>=20 >>> Stef van der Ziel >>>=20 >>>=20 >>> On 12 mrt. 2012, at 15:28, Scott Wainner wrote: >>>=20 >>>> I too am struggling with how 'capabilities' can be advertised = effectively in BGP. I'm inclined to delineate the 'footprint' from the = 'capabilities'. >>>>=20 >>>> Perhaps one approach is to indicate in the 'capabilities' the = various METHODS for assessing the 'footprint'. In the 'capabilities' = exchange, the options for METHODS of determining 'footprint' might be = BGP AFI or BGP Communities or IGP Distance. Accordingly, a dCDN might = indicate it has the capability of advertising (or allowing discovery of) = different methods of 'footprint' advertisements and those methods might = be weighted. >>>>=20 >>>> I think the dCDN capabilities (e.g. delivery methods, security = methods, etc.) will become far more complex than can be aggregated into = a representative set of BGP communities. Nevertheless, I do think BGP = communities is a viable method of advertising a 'footprint' ... one that = is well understood by the network operators. >>>>=20 >>>> Scott Wainner >>>>=20 >>>> On 3/9/12 6:50 AM, grant.watson@bt.com wrote: >>>>> Thanks, understood. >>>>>=20 >>>>> Then my general feedback would be - I think working out what = capability information needs to be shared between the CDNs would ideally = be worked though prior to deciding the right way to do it. BGP doesn't = feel like an obvious choice for exchanging the kind of CDN Capability = information I'd envisage being passed between CDN. Has a discussion = taken place as to why BGP over other methods? (e.g. API/metadata) There = are drafts discussing metadata right now that propose ways of describing = the capability requirements between CDN (e.g. "deliver this content = using RMTP" etc.), why would we not also exchange capabilities over the = same interface for example? >>>>>=20 >>>>> It's easier to understand why it may be considered that BGP = should/could be used for the exchange of network footprint information = but less so for CDN Capabilities, IMHO. In some cases CDN may not want = or need to implement footprint advertisement entirely (for example in a = simple bi-lateral relationship the CDN operators could easily elect to = exchange footprint information out-of-band), in this case they = presumably wouldn't want to be dependent on BGP to exchange capability = information. >>>>>=20 >>>>> g- >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: stefano previdi [mailto:sprevidi@cisco.com] >>>>> Sent: 09 March 2012 10:44 >>>>> To: Watson,G,Grant,DMK5 R >>>>> Cc: cdni@ietf.org >>>>> Subject: Re: [CDNi] New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>>>>=20 >>>>> Hi Grant, >>>>>=20 >>>>> On Mar 8, 2012, at 11:17 PM, = wrote: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> The document talks about "Capability Advertisements" and the = proposal to use MP-BGP messages to advertise/exchange CDN capabilities. = However, the document does not explicitly define what is ment by "CDN = Capability". >>>>>=20 >>>>>=20 >>>>> indeed... and it is somehow intended... >>>>>=20 >>>>> As JanS pointed out, there's another draft that should explicit = the semantics of FP/Capabilities. In this proposal we define = the mechanism through which the capability information can be exchanged. >>>>>=20 >>>>> Obviously, at some point, we'll have to synchronize. >>>>>=20 >>>>>=20 >>>>>> I understand "CDN Capability" to mean things like delivery = technology (for example RTMP or HTTP etc.) or perhaps a specific form of = content authorisation etc. Can you confirm I am correct in assuming this = or if not clarify what the correct meaning is. >>>>>=20 >>>>>=20 >>>>> My understanding goes in the same direction, so far. >>>>>=20 >>>>> s. >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> g- >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> ________________________________________ >>>>>> From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf Of >>>>>> stefano previdi [sprevidi@cisco.com] >>>>>> Sent: 08 March 2012 21:23 >>>>>> To: cdni@ietf.org >>>>>> Subject: [CDNi] Fwd: New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>>>>>=20 >>>>>> Begin forwarded message: >>>>>>=20 >>>>>>> From: internet-drafts@ietf.org >>>>>>> Subject: New Version Notification for >>>>>>> draft-previdi-cdni-footprint-advertisement-01.txt >>>>>>> Date: March 8, 2012 8:45:53 PM GMT+01:00 >>>>>>> To: sprevidi@cisco.com >>>>>>> Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com >>>>>>>=20 >>>>>>> A new version of I-D, = draft-previdi-cdni-footprint-advertisement-01.txt has been successfully = submitted by Stefano Previdi and posted to the IETF repository. >>>>>>>=20 >>>>>>> Filename: draft-previdi-cdni-footprint-advertisement >>>>>>> Revision: 01 >>>>>>> Title: CDNI Footprint Advertisement >>>>>>> Creation date: 2012-03-08 >>>>>>> WG ID: Individual Submission >>>>>>> Number of pages: 27 >>>>>>>=20 >>>>>>> Abstract: >>>>>>> This document describes the use of BGP for Content Delivery = Networks >>>>>>> (CDNs) in order to advertise information about footprint and=20 >>>>>>> connectivity to footprint in the context of CDNI. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> This draft is for the CDNI Working Group. >>>>>>>=20 >>>>>>> Thanks. >>>>>>> s. >>>>>>>=20 >>>>>>> The IETF Secretariat >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> CDNi mailing list >>>>>> CDNi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> CDNi mailing list >>>>> CDNi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>=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 >>=20 >>=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 From stef@jet-stream.com Wed Mar 14 05:29: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 2216F21F86C8 for ; Wed, 14 Mar 2012 05:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.096 X-Spam-Level: X-Spam-Status: No, score=0.096 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_61=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 bl4NxCvgJFl2 for ; Wed, 14 Mar 2012 05:29:32 -0700 (PDT) Received: from monitor1.jet-stream.nl (smtp.jet-stream.nl [91.196.106.226]) by ietfa.amsl.com (Postfix) with ESMTP id E905721F86BE for ; Wed, 14 Mar 2012 05:29:31 -0700 (PDT) Received: from stef-jts-imac27.jetstream.office ([193.138.250.6]) (authenticated bits=0) by monitor1.jet-stream.nl (8.13.7/8.13.7) with ESMTP id q2ECTZDV025922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 14 Mar 2012 13:29:35 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Stef van der Ziel In-Reply-To: <86AF8FF6-4BF3-41D9-837F-21A392C87F83@cisco.com> Date: Wed, 14 Mar 2012 13:29:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0CC6542D-0A0E-41FB-B960-6A3763469BC8@jet-stream.com> References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net> <1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net> <4F5E07FA.5090402@cisco.com> <5826DF56-7335-49C6-997A-AAB109ED0913@jet-stream.com> <2C86FE78-1178-447F-8CB4-5AEA63625679@jet-stream.com> <86AF8FF6-4BF3-41D9-837F-21A392C87F83@cisco.com> To: cdni@ietf.org X-Mailer: Apple Mail (2.1257) Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-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, 14 Mar 2012 12:29:33 -0000 There are too many scenarios where a CDN does not rely on Internet = routing.=20 Think of multiple CDNs within a private network, that have to = interoperate. A CDN may also have a different footprint than the network topology.=20 I think that it is too easy to assume that BGP could be the right = protocol. Proper APIs offer the same function, but with all the freedom that CDNs = will need. Best, Stef On 14 mrt. 2012, at 12:25, stefano previdi wrote: >=20 > On Mar 14, 2012, at 11:38 AM, Stef van der Ziel wrote: >=20 >> Hi, >>=20 >> It still looks like you're trying to lock CDNs into networking layer = protocols and use protocols for which they were not intended.=20 >=20 >=20 > well, I don't think so. We use the same tool... but differently. >=20 >=20 >> In most CDNs we deployed, BGP doesn't play any role. Not even in = federated scenarios.=20 >=20 >=20 > yes, but at the end of the day, the CDN relies on internet routing so=20= > at some point there's a relationship between the CDN and the network=20= > layer. >=20 > In our proposal we just leverage the reachability information you can=20= > get from your local SP/ISP so to figure out footprint information. >=20 > Capabilities, I agree with you, is a different story but since we=20 > don't know yet what is a capability (and which format it = should/must/may=20 > have) it's difficult to come with a proper scheme. Having said that, = BGP=20 > (as a tool) has all feature you need so to propagate both FP and caps. >=20 > s. >=20 >=20 >=20 >> Better use proper APIs!=20 >>=20 >> Best, Stef >>=20 >>=20 >> On 14 mrt. 2012, at 11:33, stefano previdi wrote: >>=20 >>>=20 >>> On Mar 14, 2012, at 11:07 AM, Stef van der Ziel wrote: >>>=20 >>>> Hi, >>>>=20 >>>> I would not recommend using BGP for CDN capabilities sharing. >>>> BGP is a networking layer protocol. >>>=20 >>>=20 >>> not in the way we propose to use it in the CDNI context. >>>=20 >>>=20 >>>> CDNs can and should run independently from the network, or span = multiple networks. Or run within a part of a network, where BGP is not = the right protocol. >>>=20 >>>=20 >>> well, BGP is to be intended as MP-BGP with a scope of advertising=20 >>> footprint and capability information. In that respect the semantic=20= >>> is pretty clear. The fact that BGP is also used in other contexts=20 >>> such as network layer routing, MPLS-VPN, multicast, etc. doesn't=20 >>> preclude the use of the same technology into another context. >>>=20 >>>=20 >>>> CDNs should not be locked into networks or become dependent on = networking layered protocols. >>>=20 >>>=20 >>> absolutely agree. As you can see from the proposal, we leverage=20 >>> what's available in the BGP databases as for footprint information.=20= >>> However, also described in the proposal, we allow complete freedom=20= >>> to any CDNI MP-BGP player to define its own policy and elements to=20= >>> advertise. >>>=20 >>> s. >>>=20 >>>=20 >>>> CDN interconnection should be done via APIs. >>>>=20 >>>> Kind regards,=20 >>>>=20 >>>> Stef van der Ziel >>>>=20 >>>>=20 >>>> On 12 mrt. 2012, at 15:28, Scott Wainner wrote: >>>>=20 >>>>> I too am struggling with how 'capabilities' can be advertised = effectively in BGP. I'm inclined to delineate the 'footprint' from the = 'capabilities'. >>>>>=20 >>>>> Perhaps one approach is to indicate in the 'capabilities' the = various METHODS for assessing the 'footprint'. In the 'capabilities' = exchange, the options for METHODS of determining 'footprint' might be = BGP AFI or BGP Communities or IGP Distance. Accordingly, a dCDN might = indicate it has the capability of advertising (or allowing discovery of) = different methods of 'footprint' advertisements and those methods might = be weighted. >>>>>=20 >>>>> I think the dCDN capabilities (e.g. delivery methods, security = methods, etc.) will become far more complex than can be aggregated into = a representative set of BGP communities. Nevertheless, I do think BGP = communities is a viable method of advertising a 'footprint' ... one that = is well understood by the network operators. >>>>>=20 >>>>> Scott Wainner >>>>>=20 >>>>> On 3/9/12 6:50 AM, grant.watson@bt.com wrote: >>>>>> Thanks, understood. >>>>>>=20 >>>>>> Then my general feedback would be - I think working out what = capability information needs to be shared between the CDNs would ideally = be worked though prior to deciding the right way to do it. BGP doesn't = feel like an obvious choice for exchanging the kind of CDN Capability = information I'd envisage being passed between CDN. Has a discussion = taken place as to why BGP over other methods? (e.g. API/metadata) There = are drafts discussing metadata right now that propose ways of describing = the capability requirements between CDN (e.g. "deliver this content = using RMTP" etc.), why would we not also exchange capabilities over the = same interface for example? >>>>>>=20 >>>>>> It's easier to understand why it may be considered that BGP = should/could be used for the exchange of network footprint information = but less so for CDN Capabilities, IMHO. In some cases CDN may not want = or need to implement footprint advertisement entirely (for example in a = simple bi-lateral relationship the CDN operators could easily elect to = exchange footprint information out-of-band), in this case they = presumably wouldn't want to be dependent on BGP to exchange capability = information. >>>>>>=20 >>>>>> g- >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: stefano previdi [mailto:sprevidi@cisco.com] >>>>>> Sent: 09 March 2012 10:44 >>>>>> To: Watson,G,Grant,DMK5 R >>>>>> Cc: cdni@ietf.org >>>>>> Subject: Re: [CDNi] New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>>>>>=20 >>>>>> Hi Grant, >>>>>>=20 >>>>>> On Mar 8, 2012, at 11:17 PM, = wrote: >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> The document talks about "Capability Advertisements" and the = proposal to use MP-BGP messages to advertise/exchange CDN capabilities. = However, the document does not explicitly define what is ment by "CDN = Capability". >>>>>>=20 >>>>>>=20 >>>>>> indeed... and it is somehow intended... >>>>>>=20 >>>>>> As JanS pointed out, there's another draft that should explicit = the semantics of FP/Capabilities. In this proposal we define = the mechanism through which the capability information can be exchanged. >>>>>>=20 >>>>>> Obviously, at some point, we'll have to synchronize. >>>>>>=20 >>>>>>=20 >>>>>>> I understand "CDN Capability" to mean things like delivery = technology (for example RTMP or HTTP etc.) or perhaps a specific form of = content authorisation etc. Can you confirm I am correct in assuming this = or if not clarify what the correct meaning is. >>>>>>=20 >>>>>>=20 >>>>>> My understanding goes in the same direction, so far. >>>>>>=20 >>>>>> s. >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Cheers, >>>>>>>=20 >>>>>>> g- >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> ________________________________________ >>>>>>> From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf Of >>>>>>> stefano previdi [sprevidi@cisco.com] >>>>>>> Sent: 08 March 2012 21:23 >>>>>>> To: cdni@ietf.org >>>>>>> Subject: [CDNi] Fwd: New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>>>>>>=20 >>>>>>> Begin forwarded message: >>>>>>>=20 >>>>>>>> From: internet-drafts@ietf.org >>>>>>>> Subject: New Version Notification for >>>>>>>> draft-previdi-cdni-footprint-advertisement-01.txt >>>>>>>> Date: March 8, 2012 8:45:53 PM GMT+01:00 >>>>>>>> To: sprevidi@cisco.com >>>>>>>> Cc: allan.guillou@sfr.com, flefauch@cisco.com, = jmedved@cisco.com >>>>>>>>=20 >>>>>>>> A new version of I-D, = draft-previdi-cdni-footprint-advertisement-01.txt has been successfully = submitted by Stefano Previdi and posted to the IETF repository. >>>>>>>>=20 >>>>>>>> Filename: draft-previdi-cdni-footprint-advertisement >>>>>>>> Revision: 01 >>>>>>>> Title: CDNI Footprint Advertisement >>>>>>>> Creation date: 2012-03-08 >>>>>>>> WG ID: Individual Submission >>>>>>>> Number of pages: 27 >>>>>>>>=20 >>>>>>>> Abstract: >>>>>>>> This document describes the use of BGP for Content Delivery = Networks >>>>>>>> (CDNs) in order to advertise information about footprint and=20 >>>>>>>> connectivity to footprint in the context of CDNI. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> This draft is for the CDNI Working Group. >>>>>>>>=20 >>>>>>>> Thanks. >>>>>>>> s. >>>>>>>>=20 >>>>>>>> The IETF Secretariat >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> CDNi mailing list >>>>>>> CDNi@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> CDNi mailing list >>>>>> CDNi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>=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 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >>=20 >=20 >=20 From sprevidi@cisco.com Wed Mar 14 05:56:12 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 6F80621F8703 for ; Wed, 14 Mar 2012 05:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.224 X-Spam-Level: X-Spam-Status: No, score=-102.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_61=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 EJzaMqkx-MfO for ; Wed, 14 Mar 2012 05:56:11 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id BC5AF21F8702 for ; Wed, 14 Mar 2012 05:56:10 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q2EClUmB019176 for ; Wed, 14 Mar 2012 13:47:30 +0100 (CET) Received: from ams3-vpn-dhcp4632.cisco.com (ams3-vpn-dhcp4632.cisco.com [10.61.82.23]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q2EClTmF014296; Wed, 14 Mar 2012 13:47:29 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: stefano previdi In-Reply-To: <0CC6542D-0A0E-41FB-B960-6A3763469BC8@jet-stream.com> Date: Wed, 14 Mar 2012 13:47:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1705BCFB-D668-4437-8DD1-2D41E89FC5D1@cisco.com> References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net> <1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net> <4F5E07FA.5090402@cisco.com> <5826DF56-7335-49C6-997A-AAB109ED0913@jet-stream.com> <2C86FE78-1178-447F-8CB4-5AEA63625679@jet-stream.com> <86AF8FF6-4BF3-41D9-837F-21A392C87F83@cisco.com> <0CC6542D-0A0E-41FB-B960-6A3763469BC8@jet-stream.com> To: Stef van der Ziel X-Mailer: Apple Mail (2.1257) Cc: cdni@ietf.org Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-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, 14 Mar 2012 12:56:12 -0000 On Mar 14, 2012, at 1:29 PM, Stef van der Ziel wrote: > There are too many scenarios where a CDN does not rely on Internet = routing.=20 > Think of multiple CDNs within a private network, that have to = interoperate. still you need to route your packets at the end of the day and=20 it is likely to be done through a BGP entry. > A CDN may also have a different footprint than the network topology.=20= absolutely. that's why we propose to use MP-BGP for explicit FP=20 advertisement. > I think that it is too easy to assume that BGP could be the right = protocol. > Proper APIs offer the same function, but with all the freedom that = CDNs will need. "Proper API" may also fit (CDNI)MP-BGP definition... s. >=20 > Best, Stef >=20 >=20 >=20 > On 14 mrt. 2012, at 12:25, stefano previdi wrote: >=20 >>=20 >> On Mar 14, 2012, at 11:38 AM, Stef van der Ziel wrote: >>=20 >>> Hi, >>>=20 >>> It still looks like you're trying to lock CDNs into networking layer = protocols and use protocols for which they were not intended.=20 >>=20 >>=20 >> well, I don't think so. We use the same tool... but differently. >>=20 >>=20 >>> In most CDNs we deployed, BGP doesn't play any role. Not even in = federated scenarios.=20 >>=20 >>=20 >> yes, but at the end of the day, the CDN relies on internet routing so=20= >> at some point there's a relationship between the CDN and the network=20= >> layer. >>=20 >> In our proposal we just leverage the reachability information you can=20= >> get from your local SP/ISP so to figure out footprint information. >>=20 >> Capabilities, I agree with you, is a different story but since we=20 >> don't know yet what is a capability (and which format it = should/must/may=20 >> have) it's difficult to come with a proper scheme. Having said that, = BGP=20 >> (as a tool) has all feature you need so to propagate both FP and = caps. >>=20 >> s. >>=20 >>=20 >>=20 >>> Better use proper APIs!=20 >>>=20 >>> Best, Stef >>>=20 >>>=20 >>> On 14 mrt. 2012, at 11:33, stefano previdi wrote: >>>=20 >>>>=20 >>>> On Mar 14, 2012, at 11:07 AM, Stef van der Ziel wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> I would not recommend using BGP for CDN capabilities sharing. >>>>> BGP is a networking layer protocol. >>>>=20 >>>>=20 >>>> not in the way we propose to use it in the CDNI context. >>>>=20 >>>>=20 >>>>> CDNs can and should run independently from the network, or span = multiple networks. Or run within a part of a network, where BGP is not = the right protocol. >>>>=20 >>>>=20 >>>> well, BGP is to be intended as MP-BGP with a scope of advertising=20= >>>> footprint and capability information. In that respect the semantic=20= >>>> is pretty clear. The fact that BGP is also used in other contexts=20= >>>> such as network layer routing, MPLS-VPN, multicast, etc. doesn't=20 >>>> preclude the use of the same technology into another context. >>>>=20 >>>>=20 >>>>> CDNs should not be locked into networks or become dependent on = networking layered protocols. >>>>=20 >>>>=20 >>>> absolutely agree. As you can see from the proposal, we leverage=20 >>>> what's available in the BGP databases as for footprint information.=20= >>>> However, also described in the proposal, we allow complete freedom=20= >>>> to any CDNI MP-BGP player to define its own policy and elements to=20= >>>> advertise. >>>>=20 >>>> s. >>>>=20 >>>>=20 >>>>> CDN interconnection should be done via APIs. >>>>>=20 >>>>> Kind regards,=20 >>>>>=20 >>>>> Stef van der Ziel >>>>>=20 >>>>>=20 >>>>> On 12 mrt. 2012, at 15:28, Scott Wainner wrote: >>>>>=20 >>>>>> I too am struggling with how 'capabilities' can be advertised = effectively in BGP. I'm inclined to delineate the 'footprint' from the = 'capabilities'. >>>>>>=20 >>>>>> Perhaps one approach is to indicate in the 'capabilities' the = various METHODS for assessing the 'footprint'. In the 'capabilities' = exchange, the options for METHODS of determining 'footprint' might be = BGP AFI or BGP Communities or IGP Distance. Accordingly, a dCDN might = indicate it has the capability of advertising (or allowing discovery of) = different methods of 'footprint' advertisements and those methods might = be weighted. >>>>>>=20 >>>>>> I think the dCDN capabilities (e.g. delivery methods, security = methods, etc.) will become far more complex than can be aggregated into = a representative set of BGP communities. Nevertheless, I do think BGP = communities is a viable method of advertising a 'footprint' ... one that = is well understood by the network operators. >>>>>>=20 >>>>>> Scott Wainner >>>>>>=20 >>>>>> On 3/9/12 6:50 AM, grant.watson@bt.com wrote: >>>>>>> Thanks, understood. >>>>>>>=20 >>>>>>> Then my general feedback would be - I think working out what = capability information needs to be shared between the CDNs would ideally = be worked though prior to deciding the right way to do it. BGP doesn't = feel like an obvious choice for exchanging the kind of CDN Capability = information I'd envisage being passed between CDN. Has a discussion = taken place as to why BGP over other methods? (e.g. API/metadata) There = are drafts discussing metadata right now that propose ways of describing = the capability requirements between CDN (e.g. "deliver this content = using RMTP" etc.), why would we not also exchange capabilities over the = same interface for example? >>>>>>>=20 >>>>>>> It's easier to understand why it may be considered that BGP = should/could be used for the exchange of network footprint information = but less so for CDN Capabilities, IMHO. In some cases CDN may not want = or need to implement footprint advertisement entirely (for example in a = simple bi-lateral relationship the CDN operators could easily elect to = exchange footprint information out-of-band), in this case they = presumably wouldn't want to be dependent on BGP to exchange capability = information. >>>>>>>=20 >>>>>>> g- >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: stefano previdi [mailto:sprevidi@cisco.com] >>>>>>> Sent: 09 March 2012 10:44 >>>>>>> To: Watson,G,Grant,DMK5 R >>>>>>> Cc: cdni@ietf.org >>>>>>> Subject: Re: [CDNi] New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>>>>>>=20 >>>>>>> Hi Grant, >>>>>>>=20 >>>>>>> On Mar 8, 2012, at 11:17 PM, = wrote: >>>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> The document talks about "Capability Advertisements" and the = proposal to use MP-BGP messages to advertise/exchange CDN capabilities. = However, the document does not explicitly define what is ment by "CDN = Capability". >>>>>>>=20 >>>>>>>=20 >>>>>>> indeed... and it is somehow intended... >>>>>>>=20 >>>>>>> As JanS pointed out, there's another draft that should explicit = the semantics of FP/Capabilities. In this proposal we define = the mechanism through which the capability information can be exchanged. >>>>>>>=20 >>>>>>> Obviously, at some point, we'll have to synchronize. >>>>>>>=20 >>>>>>>=20 >>>>>>>> I understand "CDN Capability" to mean things like delivery = technology (for example RTMP or HTTP etc.) or perhaps a specific form of = content authorisation etc. Can you confirm I am correct in assuming this = or if not clarify what the correct meaning is. >>>>>>>=20 >>>>>>>=20 >>>>>>> My understanding goes in the same direction, so far. >>>>>>>=20 >>>>>>> s. >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>>=20 >>>>>>>> g- >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> ________________________________________ >>>>>>>> From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf = Of >>>>>>>> stefano previdi [sprevidi@cisco.com] >>>>>>>> Sent: 08 March 2012 21:23 >>>>>>>> To: cdni@ietf.org >>>>>>>> Subject: [CDNi] Fwd: New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>>>>>>>=20 >>>>>>>> Begin forwarded message: >>>>>>>>=20 >>>>>>>>> From: internet-drafts@ietf.org >>>>>>>>> Subject: New Version Notification for >>>>>>>>> draft-previdi-cdni-footprint-advertisement-01.txt >>>>>>>>> Date: March 8, 2012 8:45:53 PM GMT+01:00 >>>>>>>>> To: sprevidi@cisco.com >>>>>>>>> Cc: allan.guillou@sfr.com, flefauch@cisco.com, = jmedved@cisco.com >>>>>>>>>=20 >>>>>>>>> A new version of I-D, = draft-previdi-cdni-footprint-advertisement-01.txt has been successfully = submitted by Stefano Previdi and posted to the IETF repository. >>>>>>>>>=20 >>>>>>>>> Filename: draft-previdi-cdni-footprint-advertisement >>>>>>>>> Revision: 01 >>>>>>>>> Title: CDNI Footprint Advertisement >>>>>>>>> Creation date: 2012-03-08 >>>>>>>>> WG ID: Individual Submission >>>>>>>>> Number of pages: 27 >>>>>>>>>=20 >>>>>>>>> Abstract: >>>>>>>>> This document describes the use of BGP for Content Delivery = Networks >>>>>>>>> (CDNs) in order to advertise information about footprint and=20= >>>>>>>>> connectivity to footprint in the context of CDNI. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> This draft is for the CDNI Working Group. >>>>>>>>>=20 >>>>>>>>> Thanks. >>>>>>>>> s. >>>>>>>>>=20 >>>>>>>>> The IETF Secretariat >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> CDNi mailing list >>>>>>>> CDNi@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> CDNi mailing list >>>>>>> CDNi@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>>=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 >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>>=20 >>=20 >>=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 From flefauch@cisco.com Wed Mar 14 06:39:08 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 2149521F857D for ; Wed, 14 Mar 2012 06:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.88 X-Spam-Level: X-Spam-Status: No, score=-9.88 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, J_CHICKENPOX_61=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 XHXbo6dt9uR7 for ; Wed, 14 Mar 2012 06:39:07 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7F021F8576 for ; Wed, 14 Mar 2012 06:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=9435; q=dns/txt; s=iport; t=1331732346; x=1332941946; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=OTMafV/iPZUFnVBhmC+FK4a3fjbXJLKW17XGKq7W4HI=; b=giLfi3OfR6iVLuQ6xoh0WTUYsvLB1+EqLwpeUKJXrxRiPJsKaIiYltD4 6kZJ5iHv+BBA8saIXHR1vDL9JuQrXgV0fe0zpx9U+5qNDNChtDzkf+aWI 5HCJIGfke/R6/tBs/zKcKaB3BusV+L4+x5ey3GM5cwY5El+XlBFOQj/WB Y=; X-IronPort-AV: E=Sophos;i="4.73,584,1325462400"; d="scan'208";a="68465334" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 14 Mar 2012 13:39:02 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2EDd1Ij004584; Wed, 14 Mar 2012 13:39:01 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Francois Le Faucheur In-Reply-To: <2C86FE78-1178-447F-8CB4-5AEA63625679@jet-stream.com> Date: Wed, 14 Mar 2012 14:39:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net> <1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net> <4F5E07FA.5090402@cisco.com> <5826DF56-7335-49C6-997A-AAB109ED0913@jet-stream.com> <2C86FE78-1178-447F-8CB4-5AEA63625679@jet-stream.com> To: Stef van der Ziel X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-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, 14 Mar 2012 13:39:08 -0000 Hello Stef, (as an individual) On 14 Mar 2012, at 11:38, Stef van der Ziel wrote: > Hi, >=20 > It still looks like you're trying to lock CDNs into networking layer = protocols and use protocols for which they were not intended.=20 I am not sure such sweeping statement are really helping the discussion = much. Probably no more than saying "considering ALTO for CDN footprint = advertisement is bad because it is trying to lock CDNs into Peer-to-peer = protocols". I believe the plan of record for the group is : * identify the functional requirements of a cdn footprint = advertisement (including notably some potentially challenging aspects of = scaling and dynamic updates) * document various solutions to support these requirements and = assess their applicability * select one (or potentially more than one) solution based on = applicability > In most CDNs we deployed, BGP doesn't play any role. So I think you are saying that regardless of its relative applicability = you favor a particular solution because that is what you are familiar = with. This is a useful datapoint but not necessarily a killer argument = for people who extensively use other base technologies. > Not even in federated scenarios.=20 > Better use proper APIs!=20 I think there is agreement on that. The question remains on what is a proper APIs. Documenting the "proper API" you have in mind (like is being done for = other approaches) would be helpful in this exercise. Thanks Francois >=20 > Best, Stef >=20 >=20 > On 14 mrt. 2012, at 11:33, stefano previdi wrote: >=20 >>=20 >> On Mar 14, 2012, at 11:07 AM, Stef van der Ziel wrote: >>=20 >>> Hi, >>>=20 >>> I would not recommend using BGP for CDN capabilities sharing. >>> BGP is a networking layer protocol. >>=20 >>=20 >> not in the way we propose to use it in the CDNI context. >>=20 >>=20 >>> CDNs can and should run independently from the network, or span = multiple networks. Or run within a part of a network, where BGP is not = the right protocol. >>=20 >>=20 >> well, BGP is to be intended as MP-BGP with a scope of advertising=20 >> footprint and capability information. In that respect the semantic=20 >> is pretty clear. The fact that BGP is also used in other contexts=20 >> such as network layer routing, MPLS-VPN, multicast, etc. doesn't=20 >> preclude the use of the same technology into another context. >>=20 >>=20 >>> CDNs should not be locked into networks or become dependent on = networking layered protocols. >>=20 >>=20 >> absolutely agree. As you can see from the proposal, we leverage=20 >> what's available in the BGP databases as for footprint information.=20= >> However, also described in the proposal, we allow complete freedom=20 >> to any CDNI MP-BGP player to define its own policy and elements to=20 >> advertise. >>=20 >> s. >>=20 >>=20 >>> CDN interconnection should be done via APIs. >>>=20 >>> Kind regards,=20 >>>=20 >>> Stef van der Ziel >>>=20 >>>=20 >>> On 12 mrt. 2012, at 15:28, Scott Wainner wrote: >>>=20 >>>> I too am struggling with how 'capabilities' can be advertised = effectively in BGP. I'm inclined to delineate the 'footprint' from the = 'capabilities'. >>>>=20 >>>> Perhaps one approach is to indicate in the 'capabilities' the = various METHODS for assessing the 'footprint'. In the 'capabilities' = exchange, the options for METHODS of determining 'footprint' might be = BGP AFI or BGP Communities or IGP Distance. Accordingly, a dCDN might = indicate it has the capability of advertising (or allowing discovery of) = different methods of 'footprint' advertisements and those methods might = be weighted. >>>>=20 >>>> I think the dCDN capabilities (e.g. delivery methods, security = methods, etc.) will become far more complex than can be aggregated into = a representative set of BGP communities. Nevertheless, I do think BGP = communities is a viable method of advertising a 'footprint' ... one that = is well understood by the network operators. >>>>=20 >>>> Scott Wainner >>>>=20 >>>> On 3/9/12 6:50 AM, grant.watson@bt.com wrote: >>>>> Thanks, understood. >>>>>=20 >>>>> Then my general feedback would be - I think working out what = capability information needs to be shared between the CDNs would ideally = be worked though prior to deciding the right way to do it. BGP doesn't = feel like an obvious choice for exchanging the kind of CDN Capability = information I'd envisage being passed between CDN. Has a discussion = taken place as to why BGP over other methods? (e.g. API/metadata) There = are drafts discussing metadata right now that propose ways of describing = the capability requirements between CDN (e.g. "deliver this content = using RMTP" etc.), why would we not also exchange capabilities over the = same interface for example? >>>>>=20 >>>>> It's easier to understand why it may be considered that BGP = should/could be used for the exchange of network footprint information = but less so for CDN Capabilities, IMHO. In some cases CDN may not want = or need to implement footprint advertisement entirely (for example in a = simple bi-lateral relationship the CDN operators could easily elect to = exchange footprint information out-of-band), in this case they = presumably wouldn't want to be dependent on BGP to exchange capability = information. >>>>>=20 >>>>> g- >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: stefano previdi [mailto:sprevidi@cisco.com] >>>>> Sent: 09 March 2012 10:44 >>>>> To: Watson,G,Grant,DMK5 R >>>>> Cc: cdni@ietf.org >>>>> Subject: Re: [CDNi] New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>>>>=20 >>>>> Hi Grant, >>>>>=20 >>>>> On Mar 8, 2012, at 11:17 PM, = wrote: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> The document talks about "Capability Advertisements" and the = proposal to use MP-BGP messages to advertise/exchange CDN capabilities. = However, the document does not explicitly define what is ment by "CDN = Capability". >>>>>=20 >>>>>=20 >>>>> indeed... and it is somehow intended... >>>>>=20 >>>>> As JanS pointed out, there's another draft that should explicit = the semantics of FP/Capabilities. In this proposal we define = the mechanism through which the capability information can be exchanged. >>>>>=20 >>>>> Obviously, at some point, we'll have to synchronize. >>>>>=20 >>>>>=20 >>>>>> I understand "CDN Capability" to mean things like delivery = technology (for example RTMP or HTTP etc.) or perhaps a specific form of = content authorisation etc. Can you confirm I am correct in assuming this = or if not clarify what the correct meaning is. >>>>>=20 >>>>>=20 >>>>> My understanding goes in the same direction, so far. >>>>>=20 >>>>> s. >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> g- >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> ________________________________________ >>>>>> From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf Of >>>>>> stefano previdi [sprevidi@cisco.com] >>>>>> Sent: 08 March 2012 21:23 >>>>>> To: cdni@ietf.org >>>>>> Subject: [CDNi] Fwd: New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>>>>>=20 >>>>>> Begin forwarded message: >>>>>>=20 >>>>>>> From: internet-drafts@ietf.org >>>>>>> Subject: New Version Notification for >>>>>>> draft-previdi-cdni-footprint-advertisement-01.txt >>>>>>> Date: March 8, 2012 8:45:53 PM GMT+01:00 >>>>>>> To: sprevidi@cisco.com >>>>>>> Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com >>>>>>>=20 >>>>>>> A new version of I-D, = draft-previdi-cdni-footprint-advertisement-01.txt has been successfully = submitted by Stefano Previdi and posted to the IETF repository. >>>>>>>=20 >>>>>>> Filename: draft-previdi-cdni-footprint-advertisement >>>>>>> Revision: 01 >>>>>>> Title: CDNI Footprint Advertisement >>>>>>> Creation date: 2012-03-08 >>>>>>> WG ID: Individual Submission >>>>>>> Number of pages: 27 >>>>>>>=20 >>>>>>> Abstract: >>>>>>> This document describes the use of BGP for Content Delivery = Networks >>>>>>> (CDNs) in order to advertise information about footprint and=20 >>>>>>> connectivity to footprint in the context of CDNI. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> This draft is for the CDNI Working Group. >>>>>>>=20 >>>>>>> Thanks. >>>>>>> s. >>>>>>>=20 >>>>>>> The IETF Secretariat >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> CDNi mailing list >>>>>> CDNi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> CDNi mailing list >>>>> CDNi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>=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 >>=20 >>=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From stef@jet-stream.com Wed Mar 14 06:45: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 275B621F87DD for ; Wed, 14 Mar 2012 06:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.096 X-Spam-Level: X-Spam-Status: No, score=0.096 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_61=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 xYltMJtxoUB0 for ; Wed, 14 Mar 2012 06:45:46 -0700 (PDT) Received: from monitor1.jet-stream.nl (smtp.jet-stream.nl [91.196.106.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF9F21F87C6 for ; Wed, 14 Mar 2012 06:45:44 -0700 (PDT) Received: from stef-jts-imac27.jetstream.office ([193.138.250.6]) (authenticated bits=0) by monitor1.jet-stream.nl (8.13.7/8.13.7) with ESMTP id q2EDjej6023969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 14 Mar 2012 14:45:40 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Stef van der Ziel In-Reply-To: Date: Wed, 14 Mar 2012 14:45:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9D4A8F77-1A17-409A-83D0-A9E0FB041C7D@jet-stream.com> References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net> <1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net> <4F5E07FA.5090402@cisco.com> <5826DF56-7335-49C6-997A-AAB109ED0913@jet-stream.com> <2C86FE78-1178-447F-8CB4-5AEA63625679@jet-stream.com> To: cdni@ietf.org X-Mailer: Apple Mail (2.1257) Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-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, 14 Mar 2012 13:45:48 -0000 Hi Francois, I can understand that from a networking / routing gear vendor = perspective, Cisco looks at BGP (etc) for CDN functions. However CDNs aren't necessarily tied into the networking architecture, = instead they are more and more abstracted from the network layer. I don't favor a particular solution, I want to prevent that a standard = locks in CDN operators into specific environments. That would be a = pitfall for CDN operators. Using APIs instead, there is no need for a debate and there is no risk = for the actual CDN operator. I would love to share our ideas around CDN capabilities exchange.=20 Best, Stef On 14 mrt. 2012, at 14:39, Francois Le Faucheur wrote: > Hello Stef, >=20 > (as an individual) >=20 > On 14 Mar 2012, at 11:38, Stef van der Ziel wrote: >> Hi, >>=20 >> It still looks like you're trying to lock CDNs into networking layer = protocols and use protocols for which they were not intended.=20 >=20 > I am not sure such sweeping statement are really helping the = discussion much. Probably no more than saying "considering ALTO for CDN = footprint advertisement is bad because it is trying to lock CDNs into = Peer-to-peer protocols". >=20 > I believe the plan of record for the group is : > * identify the functional requirements of a cdn footprint = advertisement (including notably some potentially challenging aspects of = scaling and dynamic updates) > * document various solutions to support these requirements and = assess their applicability > * select one (or potentially more than one) solution based on = applicability >=20 >> In most CDNs we deployed, BGP doesn't play any role. >=20 > So I think you are saying that regardless of its relative = applicability you favor a particular solution because that is what you = are familiar with. This is a useful datapoint but not necessarily a = killer argument for people who extensively use other base technologies. >=20 >> Not even in federated scenarios.=20 >> Better use proper APIs!=20 >=20 > I think there is agreement on that. > The question remains on what is a proper APIs. >=20 > Documenting the "proper API" you have in mind (like is being done for = other approaches) would be helpful in this exercise. >=20 > Thanks >=20 > Francois >=20 >=20 >>=20 >> Best, Stef >>=20 >>=20 >> On 14 mrt. 2012, at 11:33, stefano previdi wrote: >>=20 >>>=20 >>> On Mar 14, 2012, at 11:07 AM, Stef van der Ziel wrote: >>>=20 >>>> Hi, >>>>=20 >>>> I would not recommend using BGP for CDN capabilities sharing. >>>> BGP is a networking layer protocol. >>>=20 >>>=20 >>> not in the way we propose to use it in the CDNI context. >>>=20 >>>=20 >>>> CDNs can and should run independently from the network, or span = multiple networks. Or run within a part of a network, where BGP is not = the right protocol. >>>=20 >>>=20 >>> well, BGP is to be intended as MP-BGP with a scope of advertising=20 >>> footprint and capability information. In that respect the semantic=20= >>> is pretty clear. The fact that BGP is also used in other contexts=20 >>> such as network layer routing, MPLS-VPN, multicast, etc. doesn't=20 >>> preclude the use of the same technology into another context. >>>=20 >>>=20 >>>> CDNs should not be locked into networks or become dependent on = networking layered protocols. >>>=20 >>>=20 >>> absolutely agree. As you can see from the proposal, we leverage=20 >>> what's available in the BGP databases as for footprint information.=20= >>> However, also described in the proposal, we allow complete freedom=20= >>> to any CDNI MP-BGP player to define its own policy and elements to=20= >>> advertise. >>>=20 >>> s. >>>=20 >>>=20 >>>> CDN interconnection should be done via APIs. >>>>=20 >>>> Kind regards,=20 >>>>=20 >>>> Stef van der Ziel >>>>=20 >>>>=20 >>>> On 12 mrt. 2012, at 15:28, Scott Wainner wrote: >>>>=20 >>>>> I too am struggling with how 'capabilities' can be advertised = effectively in BGP. I'm inclined to delineate the 'footprint' from the = 'capabilities'. >>>>>=20 >>>>> Perhaps one approach is to indicate in the 'capabilities' the = various METHODS for assessing the 'footprint'. In the 'capabilities' = exchange, the options for METHODS of determining 'footprint' might be = BGP AFI or BGP Communities or IGP Distance. Accordingly, a dCDN might = indicate it has the capability of advertising (or allowing discovery of) = different methods of 'footprint' advertisements and those methods might = be weighted. >>>>>=20 >>>>> I think the dCDN capabilities (e.g. delivery methods, security = methods, etc.) will become far more complex than can be aggregated into = a representative set of BGP communities. Nevertheless, I do think BGP = communities is a viable method of advertising a 'footprint' ... one that = is well understood by the network operators. >>>>>=20 >>>>> Scott Wainner >>>>>=20 >>>>> On 3/9/12 6:50 AM, grant.watson@bt.com wrote: >>>>>> Thanks, understood. >>>>>>=20 >>>>>> Then my general feedback would be - I think working out what = capability information needs to be shared between the CDNs would ideally = be worked though prior to deciding the right way to do it. BGP doesn't = feel like an obvious choice for exchanging the kind of CDN Capability = information I'd envisage being passed between CDN. Has a discussion = taken place as to why BGP over other methods? (e.g. API/metadata) There = are drafts discussing metadata right now that propose ways of describing = the capability requirements between CDN (e.g. "deliver this content = using RMTP" etc.), why would we not also exchange capabilities over the = same interface for example? >>>>>>=20 >>>>>> It's easier to understand why it may be considered that BGP = should/could be used for the exchange of network footprint information = but less so for CDN Capabilities, IMHO. In some cases CDN may not want = or need to implement footprint advertisement entirely (for example in a = simple bi-lateral relationship the CDN operators could easily elect to = exchange footprint information out-of-band), in this case they = presumably wouldn't want to be dependent on BGP to exchange capability = information. >>>>>>=20 >>>>>> g- >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: stefano previdi [mailto:sprevidi@cisco.com] >>>>>> Sent: 09 March 2012 10:44 >>>>>> To: Watson,G,Grant,DMK5 R >>>>>> Cc: cdni@ietf.org >>>>>> Subject: Re: [CDNi] New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>>>>>=20 >>>>>> Hi Grant, >>>>>>=20 >>>>>> On Mar 8, 2012, at 11:17 PM, = wrote: >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> The document talks about "Capability Advertisements" and the = proposal to use MP-BGP messages to advertise/exchange CDN capabilities. = However, the document does not explicitly define what is ment by "CDN = Capability". >>>>>>=20 >>>>>>=20 >>>>>> indeed... and it is somehow intended... >>>>>>=20 >>>>>> As JanS pointed out, there's another draft that should explicit = the semantics of FP/Capabilities. In this proposal we define = the mechanism through which the capability information can be exchanged. >>>>>>=20 >>>>>> Obviously, at some point, we'll have to synchronize. >>>>>>=20 >>>>>>=20 >>>>>>> I understand "CDN Capability" to mean things like delivery = technology (for example RTMP or HTTP etc.) or perhaps a specific form of = content authorisation etc. Can you confirm I am correct in assuming this = or if not clarify what the correct meaning is. >>>>>>=20 >>>>>>=20 >>>>>> My understanding goes in the same direction, so far. >>>>>>=20 >>>>>> s. >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Cheers, >>>>>>>=20 >>>>>>> g- >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> ________________________________________ >>>>>>> From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf Of >>>>>>> stefano previdi [sprevidi@cisco.com] >>>>>>> Sent: 08 March 2012 21:23 >>>>>>> To: cdni@ietf.org >>>>>>> Subject: [CDNi] Fwd: New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>>>>>>=20 >>>>>>> Begin forwarded message: >>>>>>>=20 >>>>>>>> From: internet-drafts@ietf.org >>>>>>>> Subject: New Version Notification for >>>>>>>> draft-previdi-cdni-footprint-advertisement-01.txt >>>>>>>> Date: March 8, 2012 8:45:53 PM GMT+01:00 >>>>>>>> To: sprevidi@cisco.com >>>>>>>> Cc: allan.guillou@sfr.com, flefauch@cisco.com, = jmedved@cisco.com >>>>>>>>=20 >>>>>>>> A new version of I-D, = draft-previdi-cdni-footprint-advertisement-01.txt has been successfully = submitted by Stefano Previdi and posted to the IETF repository. >>>>>>>>=20 >>>>>>>> Filename: draft-previdi-cdni-footprint-advertisement >>>>>>>> Revision: 01 >>>>>>>> Title: CDNI Footprint Advertisement >>>>>>>> Creation date: 2012-03-08 >>>>>>>> WG ID: Individual Submission >>>>>>>> Number of pages: 27 >>>>>>>>=20 >>>>>>>> Abstract: >>>>>>>> This document describes the use of BGP for Content Delivery = Networks >>>>>>>> (CDNs) in order to advertise information about footprint and=20 >>>>>>>> connectivity to footprint in the context of CDNI. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> This draft is for the CDNI Working Group. >>>>>>>>=20 >>>>>>>> Thanks. >>>>>>>> s. >>>>>>>>=20 >>>>>>>> The IETF Secretariat >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> CDNi mailing list >>>>>>> CDNi@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> CDNi mailing list >>>>>> CDNi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>=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 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 >=20 From swainner@cisco.com Wed Mar 14 06:45: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 2792621F87DD for ; Wed, 14 Mar 2012 06:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.525 X-Spam-Level: X-Spam-Status: No, score=-9.525 tagged_above=-999 required=5 tests=[AWL=0.473, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_61=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 h9C0LqUYFKEG for ; Wed, 14 Mar 2012 06:45:46 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7CF21F87D7 for ; Wed, 14 Mar 2012 06:45:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=34456; q=dns/txt; s=iport; t=1331732746; x=1332942346; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=YtmQcDOusowaUDfIdjgy59dAGPriONhpKSqYwdTReXI=; b=On21MejtER2p6Fdqt8zypGr0bfF5MDzpQUnPOlpCTpickWLvCXKFx90g LIL+ypTJaRxOgWPfmjkIHO/I6o4Z1Fh9GutCw3Mq0nFevmBmiGRibKkoG sbnt701RnlULZQSoC6J/2kZhjv32CasGn4gr0vDFFtv/dJvYeGCp3rL+f g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIOgYE+rRDoH/2dsb2JhbAA7CLYrgQeCCQEBAQMBAQEBDwEHE0EEBQENBAsRAwEBAQEJFgEBBgcJAwIBAgEVHwkIEwYCAQEeh2MEDJ0LnykEijaGSASIS40LjkCBaIMC X-IronPort-AV: E=Sophos;i="4.73,584,1325462400"; d="scan'208,217";a="35984215" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 14 Mar 2012 13:45:45 +0000 Received: from stealth-10-32-245-53.cisco.com (stealth-10-32-245-53.cisco.com [10.32.245.53]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2EDjiFr004248 for ; Wed, 14 Mar 2012 13:45:44 GMT Message-ID: <4F60A188.7080205@cisco.com> Date: Wed, 14 Mar 2012 09:47:52 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: cdni@ietf.org References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net><1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net><4F5E07FA.5090402@cisco.com><5826DF56-7335-49C6-997A-AAB109ED0913@jet-stream.com><2C86FE78-1178-447F-8CB4-5AEA63625679@jet-stream.com><86AF8FF6-4BF3-41D9-837F-21A392C87F83@cisco.com> <0CC6542D-0A0E-41FB-B960-6A3763469BC8@jet-stream.com> In-Reply-To: <0CC6542D-0A0E-41FB-B960-6A3763469BC8@jet-stream.com> Content-Type: multipart/alternative; boundary="------------040503050409040501030507" Subject: Re: [CDNi] New Version Notification fordraft-previdi-cdni-footprint-advertisement-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, 14 Mar 2012 13:45:49 -0000 This is a multi-part message in MIME format. --------------040503050409040501030507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit A 'proper API' whether defined by CDN-I or not requires information to be conveyed. That is the fundamental question in my mind. What information needs to be conveyed THROUGH that API / interface? We've clearly identified that the 'footprint' of the CDN and the network are not congruent. However, CDN will need to send packets through the network to reach the client. The best proximity path between any given delivery node and the client is defined by the network topology. I can have two devices sitting side-by-side while they are topologically connected in vastly different manners. We will certainly need some NETWORK INFORMATION conveyed through the API to discern the proximity of the client to any given delivery node. See ALTO. I think the focus is on what INFORMATION is needed. Then we can focus on the right conduit to convey that information. I suspect the issue is delineating between different types of "capabilities". There are CDN capabilities (ability to deliver content using HSS or HLS) and there are network capabilities (ability to reach a given prefix and cost associated with that path). Presumably, the CDN will collect BOTH sets of capabilities via various API / CDN-I and make the 'best' choice of delivery node. What information do we need from the network to make the best content routing decision in the uCDN? draft-he-cdni-cap-info-advertising-01 draft-bertrand-cdni-footprint-discovery-00 Question: Do we delineate our work around NETWORK capabilities / footprint and CDN capabilities / footprint? I see these as a disjoint set of information that the uCDN will need to assimilate and make a congruent assessment. We don't want to assign a delivery node that is not capable of delivering the content even though it is closer. Conversely, we may want to assign a delivery node that is topologically further away because of access costs. Scott On 3/14/12 8:29 AM, Stef van der Ziel wrote: > > There are too many scenarios where a CDN does not rely on Internet > routing. > Think of multiple CDNs within a private network, that have to > interoperate. > A CDN may also have a different footprint than the network topology. > I think that it is too easy to assume that BGP could be the right > protocol. > Proper APIs offer the same function, but with all the freedom that > CDNs will need. > > Best, Stef > > > > On 14 mrt. 2012, at 12:25, stefano previdi wrote: > > > > > On Mar 14, 2012, at 11:38 AM, Stef van der Ziel wrote: > > > >> Hi, > >> > >> It still looks like you're trying to lock CDNs into networking > layer protocols and use protocols for which they were not intended. > > > > > > well, I don't think so. We use the same tool... but differently. > > > > > >> In most CDNs we deployed, BGP doesn't play any role. Not even in > federated scenarios. > > > > > > yes, but at the end of the day, the CDN relies on internet routing so > > at some point there's a relationship between the CDN and the network > > layer. > > > > In our proposal we just leverage the reachability information you can > > get from your local SP/ISP so to figure out footprint information. > > > > Capabilities, I agree with you, is a different story but since we > > don't know yet what is a capability (and which format it should/must/may > > have) it's difficult to come with a proper scheme. Having said that, BGP > > (as a tool) has all feature you need so to propagate both FP and caps. > > > > s. > > > > > > > >> Better use proper APIs! > >> > >> Best, Stef > >> > >> > >> On 14 mrt. 2012, at 11:33, stefano previdi wrote: > >> > >>> > >>> On Mar 14, 2012, at 11:07 AM, Stef van der Ziel wrote: > >>> > >>>> Hi, > >>>> > >>>> I would not recommend using BGP for CDN capabilities sharing. > >>>> BGP is a networking layer protocol. > >>> > >>> > >>> not in the way we propose to use it in the CDNI context. > >>> > >>> > >>>> CDNs can and should run independently from the network, or span > multiple networks. Or run within a part of a network, where BGP is not > the right protocol. > >>> > >>> > >>> well, BGP is to be intended as MP-BGP with a scope of advertising > >>> footprint and capability information. In that respect the semantic > >>> is pretty clear. The fact that BGP is also used in other contexts > >>> such as network layer routing, MPLS-VPN, multicast, etc. doesn't > >>> preclude the use of the same technology into another context. > >>> > >>> > >>>> CDNs should not be locked into networks or become dependent on > networking layered protocols. > >>> > >>> > >>> absolutely agree. As you can see from the proposal, we leverage > >>> what's available in the BGP databases as for footprint information. > >>> However, also described in the proposal, we allow complete freedom > >>> to any CDNI MP-BGP player to define its own policy and elements to > >>> advertise. > >>> > >>> s. > >>> > >>> > >>>> CDN interconnection should be done via APIs. > >>>> > >>>> Kind regards, > >>>> > >>>> Stef van der Ziel > >>>> > >>>> > >>>> On 12 mrt. 2012, at 15:28, Scott Wainner wrote: > >>>> > >>>>> I too am struggling with how 'capabilities' can be advertised > effectively in BGP. I'm inclined to delineate the 'footprint' from > the 'capabilities'. > >>>>> > >>>>> Perhaps one approach is to indicate in the 'capabilities' the > various METHODS for assessing the 'footprint'. In the 'capabilities' > exchange, the options for METHODS of determining 'footprint' might be > BGP AFI or BGP Communities or IGP Distance. Accordingly, a dCDN might > indicate it has the capability of advertising (or allowing discovery > of) different methods of 'footprint' advertisements and those methods > might be weighted. > >>>>> > >>>>> I think the dCDN capabilities (e.g. delivery methods, security > methods, etc.) will become far more complex than can be aggregated > into a representative set of BGP communities. Nevertheless, I do > think BGP communities is a viable method of advertising a 'footprint' > ... one that is well understood by the network operators. > >>>>> > >>>>> Scott Wainner > >>>>> > >>>>> On 3/9/12 6:50 AM, grant.watson@bt.com wrote: > >>>>>> Thanks, understood. > >>>>>> > >>>>>> Then my general feedback would be - I think working out what > capability information needs to be shared between the CDNs would > ideally be worked though prior to deciding the right way to do it. BGP > doesn't feel like an obvious choice for exchanging the kind of CDN > Capability information I'd envisage being passed between CDN. Has a > discussion taken place as to why BGP over other methods? (e.g. > API/metadata) There are drafts discussing metadata right now that > propose ways of describing the capability requirements between CDN > (e.g. "deliver this content using RMTP" etc.), why would we not also > exchange capabilities over the same interface for example? > >>>>>> > >>>>>> It's easier to understand why it may be considered that BGP > should/could be used for the exchange of network footprint information > but less so for CDN Capabilities, IMHO. In some cases CDN may not want > or need to implement footprint advertisement entirely (for example in > a simple bi-lateral relationship the CDN operators could easily elect > to exchange footprint information out-of-band), in this case they > presumably wouldn't want to be dependent on BGP to exchange capability > information. > >>>>>> > >>>>>> g- > >>>>>> > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: stefano previdi [mailto:sprevidi@cisco.com] > >>>>>> Sent: 09 March 2012 10:44 > >>>>>> To: Watson,G,Grant,DMK5 R > >>>>>> Cc: cdni@ietf.org > >>>>>> Subject: Re: [CDNi] New Version Notification for > draft-previdi-cdni-footprint-advertisement-01.txt > >>>>>> > >>>>>> Hi Grant, > >>>>>> > >>>>>> On Mar 8, 2012, at 11:17 PM, > wrote: > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> The document talks about "Capability Advertisements" and the > proposal to use MP-BGP messages to advertise/exchange CDN > capabilities. However, the document does not explicitly define what is > ment by "CDN Capability". > >>>>>> > >>>>>> > >>>>>> indeed... and it is somehow intended... > >>>>>> > >>>>>> As JanS pointed out, there's another draft that should explicit > the semantics of FP/Capabilities. In this proposal we define > the mechanism through which the capability information can be exchanged. > >>>>>> > >>>>>> Obviously, at some point, we'll have to synchronize. > >>>>>> > >>>>>> > >>>>>>> I understand "CDN Capability" to mean things like delivery > technology (for example RTMP or HTTP etc.) or perhaps a specific form > of content authorisation etc. Can you confirm I am correct in assuming > this or if not clarify what the correct meaning is. > >>>>>> > >>>>>> > >>>>>> My understanding goes in the same direction, so far. > >>>>>> > >>>>>> s. > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> Cheers, > >>>>>>> > >>>>>>> g- > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> ________________________________________ > >>>>>>> From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf Of > >>>>>>> stefano previdi [sprevidi@cisco.com] > >>>>>>> Sent: 08 March 2012 21:23 > >>>>>>> To: cdni@ietf.org > >>>>>>> Subject: [CDNi] Fwd: New Version Notification for > draft-previdi-cdni-footprint-advertisement-01.txt > >>>>>>> > >>>>>>> Begin forwarded message: > >>>>>>> > >>>>>>>> From: internet-drafts@ietf.org > >>>>>>>> Subject: New Version Notification for > >>>>>>>> draft-previdi-cdni-footprint-advertisement-01.txt > >>>>>>>> Date: March 8, 2012 8:45:53 PM GMT+01:00 > >>>>>>>> To: sprevidi@cisco.com > >>>>>>>> Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com > >>>>>>>> > >>>>>>>> A new version of I-D, > draft-previdi-cdni-footprint-advertisement-01.txt has been > successfully submitted by Stefano Previdi and posted to the IETF > repository. > >>>>>>>> > >>>>>>>> Filename: draft-previdi-cdni-footprint-advertisement > >>>>>>>> Revision: 01 > >>>>>>>> Title: CDNI Footprint Advertisement > >>>>>>>> Creation date: 2012-03-08 > >>>>>>>> WG ID: Individual Submission > >>>>>>>> Number of pages: 27 > >>>>>>>> > >>>>>>>> Abstract: > >>>>>>>> This document describes the use of BGP for Content Delivery > Networks > >>>>>>>> (CDNs) in order to advertise information about footprint and > >>>>>>>> connectivity to footprint in the context of CDNI. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> This draft is for the CDNI Working Group. > >>>>>>>> > >>>>>>>> Thanks. > >>>>>>>> s. > >>>>>>>> > >>>>>>>> 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 > >>>> > >>>> _______________________________________________ > >>>> 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 > --------------040503050409040501030507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    A 'proper API' whether defined by CDN-I or not requires information to be conveyed.  That is the fundamental question in my mind.  What information needs to be conveyed THROUGH that API / interface?

    We've clearly identified that the 'footprint' of the CDN and the network are not congruent.  However, CDN will need to send packets through the network to reach the client.  The best proximity path between any given delivery node and the client is defined by the network topology.  I can have two devices sitting side-by-side while they are topologically connected in vastly different manners.  We will certainly need some NETWORK INFORMATION conveyed through the API to discern the proximity of the client to any given delivery node. See ALTO.

    I think the focus is on what INFORMATION is needed.  Then we can focus on the right conduit to convey that information.  I suspect the issue is delineating between different types of "capabilities".  There are CDN capabilities (ability to deliver content using HSS or HLS) and there are network capabilities (ability to reach a given prefix and cost associated with that path).  Presumably, the CDN will collect BOTH sets of capabilities via various API / CDN-I and make the 'best' choice of delivery node.

    What information do we need from the network to make the best content routing decision in the uCDN?

    draft-he-cdni-cap-info-advertising-01
    draft-bertrand-cdni-footprint-discovery-00

Question: Do we delineate our work around NETWORK capabilities / footprint and CDN capabilities / footprint?

I see these as a disjoint set of information that the uCDN will need to assimilate and make a congruent assessment.  We don't want to assign a delivery node that is not capable of delivering the content even though it is closer.  Conversely, we may want to assign a delivery node that is topologically further away because of access costs.

Scott

On 3/14/12 8:29 AM, Stef van der Ziel wrote:
Re: [CDNi] New Version Notification fordraft-previdi-cdni-footprint-advertisement-01.txt

There are too many scenarios where a CDN does not rely on Internet routing.
Think of multiple CDNs within a private network, that have to interoperate.
A CDN may also have a different footprint than the network topology.
I think that it is too easy to assume that BGP could be the right protocol.
Proper APIs offer the same function, but with all the freedom that CDNs will need.

Best, Stef



On 14 mrt. 2012, at 12:25, stefano previdi wrote:

>
> On Mar 14, 2012, at 11:38 AM, Stef van der Ziel wrote:
>
>> Hi,
>>
>> It still looks like you're trying to lock CDNs into networking layer protocols and use protocols for which they were not intended.
>
>
> well, I don't think so. We use the same tool... but differently.
>
>
>> In most CDNs we deployed, BGP doesn't play any role. Not even in federated scenarios.
>
>
> yes, but at the end of the day, the CDN relies on internet routing so
> at some point there's a relationship between the CDN and the network
> layer.
>
> In our proposal we just leverage the reachability information you can
> get from your local SP/ISP so to figure out footprint information.
>
> Capabilities, I agree with you, is a different story but since we
> don't know yet what is a capability (and which format it should/must/may
> have) it's difficult to come with a proper scheme. Having said that, BGP
> (as a tool) has all feature you need so to propagate both FP and caps.
>
> s.
>
>
>
>> Better use proper APIs!
>>
>> Best, Stef
>>
>>
>> On 14 mrt. 2012, at 11:33, stefano previdi wrote:
>>
>>>
>>> On Mar 14, 2012, at 11:07 AM, Stef van der Ziel wrote:
>>>
>>>> Hi,
>>>>
>>>> I would not recommend using BGP for CDN capabilities sharing.
>>>> BGP is a networking layer protocol.
>>>
>>>
>>> not in the way we propose to use it in the CDNI context.
>>>
>>>
>>>> CDNs can and should run independently from the network, or span multiple networks. Or run within a part of a network, where BGP is not the right protocol.
>>>
>>>
>>> well, BGP is to be intended as MP-BGP with a scope of advertising
>>> footprint and capability information. In that respect the semantic
>>> is pretty clear. The fact that BGP is also used in other contexts
>>> such as network layer routing, MPLS-VPN, multicast, etc. doesn't
>>> preclude the use of the same technology into another context.
>>>
>>>
>>>> CDNs should not be locked into networks or become dependent on networking layered protocols.
>>>
>>>
>>> absolutely agree. As you can see from the proposal, we leverage
>>> what's available in the BGP databases as for footprint information.
>>> However, also described in the proposal, we allow complete freedom
>>> to any CDNI MP-BGP player to define its own policy and elements to
>>> advertise.
>>>
>>> s.
>>>
>>>
>>>> CDN interconnection should be done via APIs.
>>>>
>>>> Kind regards,
>>>>
>>>> Stef van der Ziel
>>>>
>>>>
>>>> On 12 mrt. 2012, at 15:28, Scott Wainner wrote:
>>>>
>>>>> I too am struggling with how 'capabilities' can be advertised effectively in BGP.  I'm inclined to delineate the 'footprint' from the 'capabilities'.
>>>>>
>>>>> Perhaps one approach is to indicate in the 'capabilities' the various METHODS for assessing the 'footprint'.  In the 'capabilities' exchange, the options for METHODS of determining 'footprint' might be BGP AFI or BGP Communities or IGP Distance.  Accordingly, a dCDN might indicate it has the capability of advertising (or allowing discovery of) different methods of 'footprint' advertisements and those methods might be weighted.
>>>>>
>>>>> I think the dCDN capabilities (e.g. delivery methods, security methods, etc.) will become far more complex than can be aggregated into a representative set of BGP communities.  Nevertheless, I do think BGP communities is a viable method of advertising a 'footprint' ... one that is well understood by the network operators.
>>>>>
>>>>> Scott Wainner
>>>>>
>>>>> On 3/9/12 6:50 AM, grant.watson@bt.com wrote:
>>>>>> Thanks, understood.
>>>>>>
>>>>>> Then my general feedback would be - I think working out what capability information needs to be shared between the CDNs would ideally be worked though prior to deciding the right way to do it. BGP doesn't feel like an obvious choice for exchanging the kind of CDN Capability information I'd envisage being passed between CDN. Has a discussion taken place as to why BGP over other methods? (e.g. API/metadata) There are drafts discussing metadata right now that propose ways of describing the capability requirements between CDN (e.g. "deliver this content using RMTP" etc.), why would we not also exchange capabilities over the same interface for example?
>>>>>>
>>>>>> It's easier to understand why it may be considered that BGP should/could be used for the exchange of network footprint information but less so for CDN Capabilities, IMHO. In some cases CDN may not want or need to implement footprint advertisement entirely (for example in a simple bi-lateral relationship the CDN operators could easily elect to exchange footprint information out-of-band), in this case they presumably wouldn't want to be dependent on BGP to exchange capability information.
>>>>>>
>>>>>> g-
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: stefano previdi [mailto:sprevidi@cisco.com]
>>>>>> Sent: 09 March 2012 10:44
>>>>>> To: Watson,G,Grant,DMK5 R
>>>>>> Cc: cdni@ietf.org
>>>>>> Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-01.txt
>>>>>>
>>>>>> Hi Grant,
>>>>>>
>>>>>> On Mar 8, 2012, at 11:17 PM, <grant.watson@bt.com> <grant.watson@bt.com> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> The document talks about "Capability Advertisements" and the proposal to use MP-BGP messages to advertise/exchange CDN capabilities. However, the document does not explicitly define what is ment by "CDN Capability".
>>>>>>
>>>>>>
>>>>>> indeed... and it is somehow intended...
>>>>>>
>>>>>> As JanS pointed out, there's another draft that should explicit the semantics of FP/Capabilities. In this proposal we           define the mechanism through which the capability information can be exchanged.
>>>>>>
>>>>>> Obviously, at some point, we'll have to synchronize.
>>>>>>
>>>>>>
>>>>>>> I understand "CDN Capability" to mean things like delivery technology (for example RTMP or HTTP etc.) or perhaps a specific form of content authorisation etc. Can you confirm I am correct in assuming this or if not clarify what the           correct meaning is.
>>>>>>
>>>>>>
>>>>>> My understanding goes in the same direction, so far.
>>>>>>
>>>>>> s.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> g-
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ________________________________________
>>>>>>> From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf Of
>>>>>>> stefano previdi [sprevidi@cisco.com]
>>>>>>> Sent: 08 March 2012 21:23
>>>>>>> To: cdni@ietf.org
>>>>>>> Subject: [CDNi] Fwd: New Version Notification for       draft-previdi-cdni-footprint-advertisement-01.txt
>>>>>>>
>>>>>>> Begin forwarded message:
>>>>>>>
>>>>>>>> From: internet-drafts@ietf.org
>>>>>>>> Subject: New Version Notification for
>>>>>>>> draft-previdi-cdni-footprint-advertisement-01.txt
>>>>>>>> Date: March 8, 2012 8:45:53 PM GMT+01:00
>>>>>>>> To: sprevidi@cisco.com
>>>>>>>> Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com
>>>>>>>>
>>>>>>>> A new version of I-D, draft-previdi-cdni-footprint-advertisement-01.txt has been successfully submitted by Stefano Previdi and posted to the IETF repository.
>>>>>>>>
>>>>>>>> Filename:      draft-previdi-cdni-footprint-advertisement
>>>>>>>> Revision:      01
>>>>>>>> Title:                 CDNI Footprint Advertisement
>>>>>>>> Creation date:         2012-03-08
>>>>>>>> WG ID:                 Individual Submission
>>>>>>>> Number of pages: 27
>>>>>>>>
>>>>>>>> Abstract:
>>>>>>>> This document describes the use of BGP for Content Delivery Networks
>>>>>>>> (CDNs) in order to advertise information about footprint and
>>>>>>>> connectivity to footprint in the context of CDNI.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> This draft is for the CDNI Working Group.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>> s.
>>>>>>>>
>>>>>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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


--------------040503050409040501030507-- From flefauch@cisco.com Wed Mar 14 07:05: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 7900721F87E1 for ; Wed, 14 Mar 2012 07:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.883 X-Spam-Level: X-Spam-Status: No, score=-9.883 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, J_CHICKENPOX_61=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 MIsthc0PgjmU for ; Wed, 14 Mar 2012 07:05:36 -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 F0B7D21F87DC for ; Wed, 14 Mar 2012 07:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=12129; q=dns/txt; s=iport; t=1331733935; x=1332943535; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=uwpQcdC9zNdiJ0Vj2bvzCL6LKudkKXTYJYPPeV77wY0=; b=ADvJaBq54uLgTRHBD8GUWthamtrzegr7HdBgzf5hN/OxoHJLYMOm8cTg zYuXC/hjfZXEWfGBmmGDpWNl9JwQ44uv+qCwAb+w91903V4qSwcCHXC88 /SvmXRfnZzqw0WpglkWcZjpH5UVtY6lTtEQzbt7GRbGzTQgYDnWLZq4/c g=; X-IronPort-AV: E=Sophos;i="4.73,583,1325462400"; d="scan'208";a="132292448" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 14 Mar 2012 14:05:34 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2EE5XJu020667; Wed, 14 Mar 2012 14:05:33 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Francois Le Faucheur In-Reply-To: <9D4A8F77-1A17-409A-83D0-A9E0FB041C7D@jet-stream.com> Date: Wed, 14 Mar 2012 15:05:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <47FE9238-F722-4BFA-B0EF-9450E3CA19C1@cisco.com> References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net> <1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net> <4F5E07FA.5090402@cisco.com> <5826DF56-7335-49C6-997A-AAB109ED0913@jet-stream.com> <2C86FE78-1178-447F-8CB4-5AEA63625679@jet-stream.com> <9D4A8F77-1A17-409A-83D0-A9E0FB041C7D@jet-stream.com> To: Stef van der Ziel X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-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, 14 Mar 2012 14:05:37 -0000 Hi again Stef, On 14 Mar 2012, at 14:45, Stef van der Ziel wrote: > Hi Francois, >=20 > I can understand that from a networking / routing gear vendor = perspective, Cisco looks at BGP (etc) I don't speak for Cisco in the IETF. I just speak for myself.=20 For the record Cisco is also a CDN gear vendor. > for CDN functions. This is not for an existing CDN function, this is for a specific CDN = interconnection function which is "CDN footprint advertisement".=20 > However CDNs aren't necessarily tied into the networking architecture, = instead they are more and more abstracted from the network layer. As I said: I am not sure such sweeping statement are really helping the = discussion at hand much. > I don't favor a particular solution, I want to prevent that a standard = locks in CDN operators into specific environments. That would be a = pitfall for CDN operators. > Using APIs instead, there is no need for a debate Hmm, so you don't favor a particular solution but you recommend that we = don't consider some solutions on the compelling argument that not = considering them would avoid a debate. I guess I am not convinced yet. By the way, I am not saying that the decision for a BGP-based approach = should be made now. What I am saying is that I personally won't exclude = a BGP-based approach because of a sweeping statement. I recommend we = continue document the information exchange requirements and several = candidate approaches in order to make an informed decision. > and there is no risk for the actual CDN operator. I don't understand the basis for that statement. > I would love to share our ideas around CDN capabilities exchange.=20 The most effective way in the IETF to share ideas on a proposed approach = is to document it in an Internet-Draft. I suggest you consider that, or = join one of the existing efforts in documenting an approach. Cheers Francois > Best, Stef >=20 >=20 >=20 > On 14 mrt. 2012, at 14:39, Francois Le Faucheur wrote: >=20 >> Hello Stef, >>=20 >> (as an individual) >>=20 >> On 14 Mar 2012, at 11:38, Stef van der Ziel wrote: >>> Hi, >>>=20 >>> It still looks like you're trying to lock CDNs into networking layer = protocols and use protocols for which they were not intended.=20 >>=20 >> I am not sure such sweeping statement are really helping the = discussion much. Probably no more than saying "considering ALTO for CDN = footprint advertisement is bad because it is trying to lock CDNs into = Peer-to-peer protocols". >>=20 >> I believe the plan of record for the group is : >> * identify the functional requirements of a cdn footprint = advertisement (including notably some potentially challenging aspects of = scaling and dynamic updates) >> * document various solutions to support these requirements and = assess their applicability >> * select one (or potentially more than one) solution based on = applicability >>=20 >>> In most CDNs we deployed, BGP doesn't play any role. >>=20 >> So I think you are saying that regardless of its relative = applicability you favor a particular solution because that is what you = are familiar with. This is a useful datapoint but not necessarily a = killer argument for people who extensively use other base technologies. >>=20 >>> Not even in federated scenarios.=20 >>> Better use proper APIs!=20 >>=20 >> I think there is agreement on that. >> The question remains on what is a proper APIs. >>=20 >> Documenting the "proper API" you have in mind (like is being done for = other approaches) would be helpful in this exercise. >>=20 >> Thanks >>=20 >> Francois >>=20 >>=20 >>>=20 >>> Best, Stef >>>=20 >>>=20 >>> On 14 mrt. 2012, at 11:33, stefano previdi wrote: >>>=20 >>>>=20 >>>> On Mar 14, 2012, at 11:07 AM, Stef van der Ziel wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> I would not recommend using BGP for CDN capabilities sharing. >>>>> BGP is a networking layer protocol. >>>>=20 >>>>=20 >>>> not in the way we propose to use it in the CDNI context. >>>>=20 >>>>=20 >>>>> CDNs can and should run independently from the network, or span = multiple networks. Or run within a part of a network, where BGP is not = the right protocol. >>>>=20 >>>>=20 >>>> well, BGP is to be intended as MP-BGP with a scope of advertising=20= >>>> footprint and capability information. In that respect the semantic=20= >>>> is pretty clear. The fact that BGP is also used in other contexts=20= >>>> such as network layer routing, MPLS-VPN, multicast, etc. doesn't=20 >>>> preclude the use of the same technology into another context. >>>>=20 >>>>=20 >>>>> CDNs should not be locked into networks or become dependent on = networking layered protocols. >>>>=20 >>>>=20 >>>> absolutely agree. As you can see from the proposal, we leverage=20 >>>> what's available in the BGP databases as for footprint information.=20= >>>> However, also described in the proposal, we allow complete freedom=20= >>>> to any CDNI MP-BGP player to define its own policy and elements to=20= >>>> advertise. >>>>=20 >>>> s. >>>>=20 >>>>=20 >>>>> CDN interconnection should be done via APIs. >>>>>=20 >>>>> Kind regards,=20 >>>>>=20 >>>>> Stef van der Ziel >>>>>=20 >>>>>=20 >>>>> On 12 mrt. 2012, at 15:28, Scott Wainner wrote: >>>>>=20 >>>>>> I too am struggling with how 'capabilities' can be advertised = effectively in BGP. I'm inclined to delineate the 'footprint' from the = 'capabilities'. >>>>>>=20 >>>>>> Perhaps one approach is to indicate in the 'capabilities' the = various METHODS for assessing the 'footprint'. In the 'capabilities' = exchange, the options for METHODS of determining 'footprint' might be = BGP AFI or BGP Communities or IGP Distance. Accordingly, a dCDN might = indicate it has the capability of advertising (or allowing discovery of) = different methods of 'footprint' advertisements and those methods might = be weighted. >>>>>>=20 >>>>>> I think the dCDN capabilities (e.g. delivery methods, security = methods, etc.) will become far more complex than can be aggregated into = a representative set of BGP communities. Nevertheless, I do think BGP = communities is a viable method of advertising a 'footprint' ... one that = is well understood by the network operators. >>>>>>=20 >>>>>> Scott Wainner >>>>>>=20 >>>>>> On 3/9/12 6:50 AM, grant.watson@bt.com wrote: >>>>>>> Thanks, understood. >>>>>>>=20 >>>>>>> Then my general feedback would be - I think working out what = capability information needs to be shared between the CDNs would ideally = be worked though prior to deciding the right way to do it. BGP doesn't = feel like an obvious choice for exchanging the kind of CDN Capability = information I'd envisage being passed between CDN. Has a discussion = taken place as to why BGP over other methods? (e.g. API/metadata) There = are drafts discussing metadata right now that propose ways of describing = the capability requirements between CDN (e.g. "deliver this content = using RMTP" etc.), why would we not also exchange capabilities over the = same interface for example? >>>>>>>=20 >>>>>>> It's easier to understand why it may be considered that BGP = should/could be used for the exchange of network footprint information = but less so for CDN Capabilities, IMHO. In some cases CDN may not want = or need to implement footprint advertisement entirely (for example in a = simple bi-lateral relationship the CDN operators could easily elect to = exchange footprint information out-of-band), in this case they = presumably wouldn't want to be dependent on BGP to exchange capability = information. >>>>>>>=20 >>>>>>> g- >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: stefano previdi [mailto:sprevidi@cisco.com] >>>>>>> Sent: 09 March 2012 10:44 >>>>>>> To: Watson,G,Grant,DMK5 R >>>>>>> Cc: cdni@ietf.org >>>>>>> Subject: Re: [CDNi] New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>>>>>>=20 >>>>>>> Hi Grant, >>>>>>>=20 >>>>>>> On Mar 8, 2012, at 11:17 PM, = wrote: >>>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> The document talks about "Capability Advertisements" and the = proposal to use MP-BGP messages to advertise/exchange CDN capabilities. = However, the document does not explicitly define what is ment by "CDN = Capability". >>>>>>>=20 >>>>>>>=20 >>>>>>> indeed... and it is somehow intended... >>>>>>>=20 >>>>>>> As JanS pointed out, there's another draft that should explicit = the semantics of FP/Capabilities. In this proposal we define = the mechanism through which the capability information can be exchanged. >>>>>>>=20 >>>>>>> Obviously, at some point, we'll have to synchronize. >>>>>>>=20 >>>>>>>=20 >>>>>>>> I understand "CDN Capability" to mean things like delivery = technology (for example RTMP or HTTP etc.) or perhaps a specific form of = content authorisation etc. Can you confirm I am correct in assuming this = or if not clarify what the correct meaning is. >>>>>>>=20 >>>>>>>=20 >>>>>>> My understanding goes in the same direction, so far. >>>>>>>=20 >>>>>>> s. >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>>=20 >>>>>>>> g- >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> ________________________________________ >>>>>>>> From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf = Of >>>>>>>> stefano previdi [sprevidi@cisco.com] >>>>>>>> Sent: 08 March 2012 21:23 >>>>>>>> To: cdni@ietf.org >>>>>>>> Subject: [CDNi] Fwd: New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>>>>>>>=20 >>>>>>>> Begin forwarded message: >>>>>>>>=20 >>>>>>>>> From: internet-drafts@ietf.org >>>>>>>>> Subject: New Version Notification for >>>>>>>>> draft-previdi-cdni-footprint-advertisement-01.txt >>>>>>>>> Date: March 8, 2012 8:45:53 PM GMT+01:00 >>>>>>>>> To: sprevidi@cisco.com >>>>>>>>> Cc: allan.guillou@sfr.com, flefauch@cisco.com, = jmedved@cisco.com >>>>>>>>>=20 >>>>>>>>> A new version of I-D, = draft-previdi-cdni-footprint-advertisement-01.txt has been successfully = submitted by Stefano Previdi and posted to the IETF repository. >>>>>>>>>=20 >>>>>>>>> Filename: draft-previdi-cdni-footprint-advertisement >>>>>>>>> Revision: 01 >>>>>>>>> Title: CDNI Footprint Advertisement >>>>>>>>> Creation date: 2012-03-08 >>>>>>>>> WG ID: Individual Submission >>>>>>>>> Number of pages: 27 >>>>>>>>>=20 >>>>>>>>> Abstract: >>>>>>>>> This document describes the use of BGP for Content Delivery = Networks >>>>>>>>> (CDNs) in order to advertise information about footprint and=20= >>>>>>>>> connectivity to footprint in the context of CDNI. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> This draft is for the CDNI Working Group. >>>>>>>>>=20 >>>>>>>>> Thanks. >>>>>>>>> s. >>>>>>>>>=20 >>>>>>>>> The IETF Secretariat >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> CDNi mailing list >>>>>>>> CDNi@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> CDNi mailing list >>>>>>> CDNi@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>>=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 >>>>=20 >>>>=20 >>>=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 From stef@jet-stream.com Wed Mar 14 07:41: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 8C09221F87F9 for ; Wed, 14 Mar 2012 07:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.096 X-Spam-Level: X-Spam-Status: No, score=0.096 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_61=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 VNEDhTvUl68D for ; Wed, 14 Mar 2012 07:41:25 -0700 (PDT) Received: from monitor1.jet-stream.nl (smtp.jet-stream.nl [91.196.106.226]) by ietfa.amsl.com (Postfix) with ESMTP id B1B7021F87F3 for ; Wed, 14 Mar 2012 07:41:24 -0700 (PDT) Received: from stef-jts-imac27.jetstream.office ([193.138.250.6]) (authenticated bits=0) by monitor1.jet-stream.nl (8.13.7/8.13.7) with ESMTP id q2EEfSmu016413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 14 Mar 2012 15:41:29 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Stef van der Ziel In-Reply-To: <47FE9238-F722-4BFA-B0EF-9450E3CA19C1@cisco.com> Date: Wed, 14 Mar 2012 15:41:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <66BC14C5-296B-4526-8757-4065DBB0168C@jet-stream.com> References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net> <1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net> <4F5E07FA.5090402@cisco.com> <5826DF56-7335-49C6-997A-AAB109ED0913@jet-stream.com> <2C86FE78-1178-447F-8CB4-5AEA63625679@jet-stream.com> <9D4A8F77-1A17-409A-83D0-A9E0FB041C7D@jet-stream.com> <47FE9238-F722-4BFA-B0EF-9450E3CA19C1@cisco.com> To: cdni@ietf.org X-Mailer: Apple Mail (2.1257) Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-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, 14 Mar 2012 14:41:26 -0000 Hi, To get more clarity before talking about the protocols: - The definition of footprint, is that network PoP footprint, or CDN = edge PoP footprint? Topology or geography? What granularity: per = country, per ISP, per region, and what is a region? A metro ring? A = mobile cell tower? - What about edge capacity footprint? You can have an edge server or a = huge PoP. A CDN could claim presence in a specific region, but that = doesn't say anything about the installed or actual capacity in terms of = storage and bandwidth. Global CDNs claim to have 'unlimited' bandwidth = but if in reality an edge cache is connected to just 100Mbps, is that = edge the right choice? - What about edge capabilities footprint? A PoP edge can be a basic = cache edge appliance or a full blown unified protocol delivery node. We = all know those global CDNs claiming to have great presence everywhere, = but when you look deeper, it turns out that their edge servers don't = support RTMP and are basic http caches. - What about CDN management capabilities exchange? Capabilities exchange = is about which ingest protocols are supported, which content = distribution controls are supported (delete, distribute, push, = flush...), which live relaying protocols are supported (RTMP, RTSP, = push, pull, remote origin...), which features the request router = supports (output formats, redirect protocols...), which geo blocking = features, and file locking, reporting, log formats, does the CDN only = support passive caching or does it support active dynamic controlled = push of assets? Does the CDN rely on passive DNS geo load balancing or = can it do active per request redirection? Which APIs are available, = where can you connect, how to authenticate, which API specs do they = comply to, which API features are supported?=20 - What about footprint and capabilities transparency? Is one CDN allowed = to pass through the information from another CDN to a third party CDN or = a content publisher? I know that most CDNs act as a black box. I also = know that a lot of premium broadcasters will demand as a mandatory = feature that interconnected / federated CDNs will be completely = transparent about footprint, capacity, capabilities, SLA levels, even if = there is a chain of a dozen interconnected CDNs involved.=20 - What about allowing third party request routers to directly redirect = to an edge node? I know that some vendors have some ideas around it, but = IMHO a CDN operator should always have full autonomous control over = their infrastructure, so at least we should share a restriction that = third parties always must handle requests through our request routers = (in a nice interconnected way). - What about access security management? Some CDNs have very poor = implementations for anti-deep linking. When they turn it on, it kills = their performance by half, or they create tokens based on the end users = IPv4 IP address, destroying their ability to connect in IPv4 / IPv6 dual = mode to various CDN components. Other CDNs do proper full lock-down with = private secure tokens between the delivery nodes and the request = routers, and with private secure tokens between the request routers and = each content owners portal. In interconnected scenarios, multiple CDNs = need to exchange secure tokens on a per account or per CDN basis. How = are these tokens automatically exchanged? I think the above is just the tip of the iceberg. It is a quite = extensive list that should be shared between 2 CDNs before they can = interact... and I don't think BGP was intended to be used for these = purposes, not that it is a practical protocol for it.=20 Best, Stef On 14 mrt. 2012, at 15:05, Francois Le Faucheur wrote: > Hi again Stef, >=20 > On 14 Mar 2012, at 14:45, Stef van der Ziel wrote: >=20 >> Hi Francois, >>=20 >> I can understand that from a networking / routing gear vendor = perspective, Cisco looks at BGP (etc) >=20 > I don't speak for Cisco in the IETF. I just speak for myself.=20 > For the record Cisco is also a CDN gear vendor. >=20 >> for CDN functions. >=20 > This is not for an existing CDN function, this is for a specific CDN = interconnection function which is "CDN footprint advertisement".=20 >=20 >> However CDNs aren't necessarily tied into the networking = architecture, instead they are more and more abstracted from the network = layer. >=20 > As I said: I am not sure such sweeping statement are really helping = the discussion at hand much. >=20 >> I don't favor a particular solution, I want to prevent that a = standard locks in CDN operators into specific environments. That would = be a pitfall for CDN operators. >> Using APIs instead, there is no need for a debate >=20 > Hmm, so you don't favor a particular solution but you recommend that = we don't consider some solutions on the compelling argument that not = considering them would avoid a debate. I guess I am not convinced yet. >=20 > By the way, I am not saying that the decision for a BGP-based approach = should be made now. What I am saying is that I personally won't exclude = a BGP-based approach because of a sweeping statement. I recommend we = continue document the information exchange requirements and several = candidate approaches in order to make an informed decision. >=20 >> and there is no risk for the actual CDN operator. >=20 > I don't understand the basis for that statement. >=20 >> I would love to share our ideas around CDN capabilities exchange.=20 >=20 > The most effective way in the IETF to share ideas on a proposed = approach is to document it in an Internet-Draft. I suggest you consider = that, or join one of the existing efforts in documenting an approach. >=20 > Cheers >=20 > Francois >=20 >> Best, Stef >>=20 >>=20 >>=20 >> On 14 mrt. 2012, at 14:39, Francois Le Faucheur wrote: >>=20 >>> Hello Stef, >>>=20 >>> (as an individual) >>>=20 >>> On 14 Mar 2012, at 11:38, Stef van der Ziel wrote: >>>> Hi, >>>>=20 >>>> It still looks like you're trying to lock CDNs into networking = layer protocols and use protocols for which they were not intended.=20 >>>=20 >>> I am not sure such sweeping statement are really helping the = discussion much. Probably no more than saying "considering ALTO for CDN = footprint advertisement is bad because it is trying to lock CDNs into = Peer-to-peer protocols". >>>=20 >>> I believe the plan of record for the group is : >>> * identify the functional requirements of a cdn footprint = advertisement (including notably some potentially challenging aspects of = scaling and dynamic updates) >>> * document various solutions to support these requirements and = assess their applicability >>> * select one (or potentially more than one) solution based on = applicability >>>=20 >>>> In most CDNs we deployed, BGP doesn't play any role. >>>=20 >>> So I think you are saying that regardless of its relative = applicability you favor a particular solution because that is what you = are familiar with. This is a useful datapoint but not necessarily a = killer argument for people who extensively use other base technologies. >>>=20 >>>> Not even in federated scenarios.=20 >>>> Better use proper APIs!=20 >>>=20 >>> I think there is agreement on that. >>> The question remains on what is a proper APIs. >>>=20 >>> Documenting the "proper API" you have in mind (like is being done = for other approaches) would be helpful in this exercise. >>>=20 >>> Thanks >>>=20 >>> Francois >>>=20 >>>=20 >>>>=20 >>>> Best, Stef >>>>=20 >>>>=20 >>>> On 14 mrt. 2012, at 11:33, stefano previdi wrote: >>>>=20 >>>>>=20 >>>>> On Mar 14, 2012, at 11:07 AM, Stef van der Ziel wrote: >>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> I would not recommend using BGP for CDN capabilities sharing. >>>>>> BGP is a networking layer protocol. >>>>>=20 >>>>>=20 >>>>> not in the way we propose to use it in the CDNI context. >>>>>=20 >>>>>=20 >>>>>> CDNs can and should run independently from the network, or span = multiple networks. Or run within a part of a network, where BGP is not = the right protocol. >>>>>=20 >>>>>=20 >>>>> well, BGP is to be intended as MP-BGP with a scope of advertising=20= >>>>> footprint and capability information. In that respect the semantic=20= >>>>> is pretty clear. The fact that BGP is also used in other contexts=20= >>>>> such as network layer routing, MPLS-VPN, multicast, etc. doesn't=20= >>>>> preclude the use of the same technology into another context. >>>>>=20 >>>>>=20 >>>>>> CDNs should not be locked into networks or become dependent on = networking layered protocols. >>>>>=20 >>>>>=20 >>>>> absolutely agree. As you can see from the proposal, we leverage=20 >>>>> what's available in the BGP databases as for footprint = information.=20 >>>>> However, also described in the proposal, we allow complete freedom=20= >>>>> to any CDNI MP-BGP player to define its own policy and elements to=20= >>>>> advertise. >>>>>=20 >>>>> s. >>>>>=20 >>>>>=20 >>>>>> CDN interconnection should be done via APIs. >>>>>>=20 >>>>>> Kind regards,=20 >>>>>>=20 >>>>>> Stef van der Ziel >>>>>>=20 >>>>>>=20 >>>>>> On 12 mrt. 2012, at 15:28, Scott Wainner wrote: >>>>>>=20 >>>>>>> I too am struggling with how 'capabilities' can be advertised = effectively in BGP. I'm inclined to delineate the 'footprint' from the = 'capabilities'. >>>>>>>=20 >>>>>>> Perhaps one approach is to indicate in the 'capabilities' the = various METHODS for assessing the 'footprint'. In the 'capabilities' = exchange, the options for METHODS of determining 'footprint' might be = BGP AFI or BGP Communities or IGP Distance. Accordingly, a dCDN might = indicate it has the capability of advertising (or allowing discovery of) = different methods of 'footprint' advertisements and those methods might = be weighted. >>>>>>>=20 >>>>>>> I think the dCDN capabilities (e.g. delivery methods, security = methods, etc.) will become far more complex than can be aggregated into = a representative set of BGP communities. Nevertheless, I do think BGP = communities is a viable method of advertising a 'footprint' ... one that = is well understood by the network operators. >>>>>>>=20 >>>>>>> Scott Wainner >>>>>>>=20 >>>>>>> On 3/9/12 6:50 AM, grant.watson@bt.com wrote: >>>>>>>> Thanks, understood. >>>>>>>>=20 >>>>>>>> Then my general feedback would be - I think working out what = capability information needs to be shared between the CDNs would ideally = be worked though prior to deciding the right way to do it. BGP doesn't = feel like an obvious choice for exchanging the kind of CDN Capability = information I'd envisage being passed between CDN. Has a discussion = taken place as to why BGP over other methods? (e.g. API/metadata) There = are drafts discussing metadata right now that propose ways of describing = the capability requirements between CDN (e.g. "deliver this content = using RMTP" etc.), why would we not also exchange capabilities over the = same interface for example? >>>>>>>>=20 >>>>>>>> It's easier to understand why it may be considered that BGP = should/could be used for the exchange of network footprint information = but less so for CDN Capabilities, IMHO. In some cases CDN may not want = or need to implement footprint advertisement entirely (for example in a = simple bi-lateral relationship the CDN operators could easily elect to = exchange footprint information out-of-band), in this case they = presumably wouldn't want to be dependent on BGP to exchange capability = information. >>>>>>>>=20 >>>>>>>> g- >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: stefano previdi [mailto:sprevidi@cisco.com] >>>>>>>> Sent: 09 March 2012 10:44 >>>>>>>> To: Watson,G,Grant,DMK5 R >>>>>>>> Cc: cdni@ietf.org >>>>>>>> Subject: Re: [CDNi] New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>>>>>>>=20 >>>>>>>> Hi Grant, >>>>>>>>=20 >>>>>>>> On Mar 8, 2012, at 11:17 PM, = wrote: >>>>>>>>>=20 >>>>>>>>> Hi, >>>>>>>>>=20 >>>>>>>>> The document talks about "Capability Advertisements" and the = proposal to use MP-BGP messages to advertise/exchange CDN capabilities. = However, the document does not explicitly define what is ment by "CDN = Capability". >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> indeed... and it is somehow intended... >>>>>>>>=20 >>>>>>>> As JanS pointed out, there's another draft that should explicit = the semantics of FP/Capabilities. In this proposal we define = the mechanism through which the capability information can be exchanged. >>>>>>>>=20 >>>>>>>> Obviously, at some point, we'll have to synchronize. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> I understand "CDN Capability" to mean things like delivery = technology (for example RTMP or HTTP etc.) or perhaps a specific form of = content authorisation etc. Can you confirm I am correct in assuming this = or if not clarify what the correct meaning is. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> My understanding goes in the same direction, so far. >>>>>>>>=20 >>>>>>>> s. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Cheers, >>>>>>>>>=20 >>>>>>>>> g- >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> ________________________________________ >>>>>>>>> From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf = Of >>>>>>>>> stefano previdi [sprevidi@cisco.com] >>>>>>>>> Sent: 08 March 2012 21:23 >>>>>>>>> To: cdni@ietf.org >>>>>>>>> Subject: [CDNi] Fwd: New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>>>>>>>>=20 >>>>>>>>> Begin forwarded message: >>>>>>>>>=20 >>>>>>>>>> From: internet-drafts@ietf.org >>>>>>>>>> Subject: New Version Notification for >>>>>>>>>> draft-previdi-cdni-footprint-advertisement-01.txt >>>>>>>>>> Date: March 8, 2012 8:45:53 PM GMT+01:00 >>>>>>>>>> To: sprevidi@cisco.com >>>>>>>>>> Cc: allan.guillou@sfr.com, flefauch@cisco.com, = jmedved@cisco.com >>>>>>>>>>=20 >>>>>>>>>> A new version of I-D, = draft-previdi-cdni-footprint-advertisement-01.txt has been successfully = submitted by Stefano Previdi and posted to the IETF repository. >>>>>>>>>>=20 >>>>>>>>>> Filename: draft-previdi-cdni-footprint-advertisement >>>>>>>>>> Revision: 01 >>>>>>>>>> Title: CDNI Footprint Advertisement >>>>>>>>>> Creation date: 2012-03-08 >>>>>>>>>> WG ID: Individual Submission >>>>>>>>>> Number of pages: 27 >>>>>>>>>>=20 >>>>>>>>>> Abstract: >>>>>>>>>> This document describes the use of BGP for Content Delivery = Networks >>>>>>>>>> (CDNs) in order to advertise information about footprint and=20= >>>>>>>>>> connectivity to footprint in the context of CDNI. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> This draft is for the CDNI Working Group. >>>>>>>>>>=20 >>>>>>>>>> Thanks. >>>>>>>>>> s. >>>>>>>>>>=20 >>>>>>>>>> The IETF Secretariat >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> CDNi mailing list >>>>>>>>> CDNi@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> CDNi mailing list >>>>>>>> CDNi@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>>>=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 >>>>>=20 >>>>>=20 >>>>=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 >=20 >=20 From flefauch@cisco.com Wed Mar 14 08:25: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 63B2B21F8702 for ; Wed, 14 Mar 2012 08:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.887 X-Spam-Level: X-Spam-Status: No, score=-9.887 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, J_CHICKENPOX_61=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 DqUZw38nVS4o for ; Wed, 14 Mar 2012 08:25:22 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id D87F621F86F3 for ; Wed, 14 Mar 2012 08:25:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=20243; q=dns/txt; s=iport; t=1331738722; x=1332948322; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=kY0G0bpJlB/lOqbHA4MeXhLMjsXm3NCegZpGinjSb8g=; b=KomuW9IxgupTO0aRM/QSxPfWZQYJoijtc7UtmD80Vi+T2DUaCFT4xyM1 q1bZoKUmhOXXK7Ke3KX0e1+/HpMzL9+rH49FRMJ0Bvte4gZXMrvtXwLad /XeTxat1zuI75nd9ZtHMv66lCUJZ27YmG5AfZ17quIZQwH5B/wEo4qww6 4=; X-IronPort-AV: E=Sophos;i="4.73,584,1325462400"; d="scan'208";a="68478059" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 14 Mar 2012 15:25:20 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2EFPJ9l008866; Wed, 14 Mar 2012 15:25:19 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Francois Le Faucheur In-Reply-To: <66BC14C5-296B-4526-8757-4065DBB0168C@jet-stream.com> Date: Wed, 14 Mar 2012 16:25:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2FD81B14-FB78-4962-B6C9-A8225DC1FDB5@cisco.com> References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net> <1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net> <4F5E07FA.5090402@cisco.com> <5826DF56-7335-49C6-997A-AAB109ED0913@jet-stream.com> <2C86FE78-1178-447F-8CB4-5AEA63625679@jet-stream.com> <9D4A8F77-1A17-409A-83D0-A9E0FB041C7D@jet-stream.com> <47FE9238-F722-4BFA-B0EF-9450E3CA19C1@cisco.com> <66BC14C5-296B-4526-8757-4065DBB0168C@jet-stream.com> To: Stef van der Ziel X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-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, 14 Mar 2012 15:25:24 -0000 Now we're talking ^). See below: On 14 Mar 2012, at 15:41, Stef van der Ziel wrote: > Hi, >=20 > To get more clarity before talking about the protocols: >=20 > - The definition of footprint, is that network PoP footprint, or CDN = edge PoP footprint? Topology or geography? What granularity: per = country, per ISP, per region, and what is a region? A metro ring? A = mobile cell tower? I'd say any of the above is needed. Prefixes of variable length is one = possible way to support any of these granularity in CDN footprint = advertisement with flexibility between amount of information and = fine-grain. This happen to be very basic operation in BGP. It could also = be supported in other approaches of course. >=20 > - What about edge capacity footprint? You can have an edge server or a = huge PoP. A CDN could claim presence in a specific region, but that = doesn't say anything about the installed or actual capacity in terms of = storage and bandwidth. Global CDNs claim to have 'unlimited' bandwidth = but if in reality an edge cache is connected to just 100Mbps, is that = edge the right choice? I believe this group is under the assumption that CDNs will remain = opaque, so will not advertise stuff like edge server capacity. >=20 > - What about edge capabilities footprint? A PoP edge can be a basic = cache edge appliance or a full blown unified protocol delivery node. We = all know those global CDNs claiming to have great presence everywhere, = but when you look deeper, it turns out that their edge servers don't = support RTMP and are basic http caches. Yes, advertisement of capabilities such as delivery protocols is = required. Tagging something indicating that sort of capabilities along = with a given Prefix in a CDN footprint advertisement is one possible way = to do that. This happen to be very basic operation in BGP = ("communities"). It could also be supported in other approaches of = course. >=20 > - What about CDN management capabilities exchange? Capabilities = exchange is about which ingest protocols are supported, which content = distribution controls are supported (delete, distribute, push, = flush...), which live relaying protocols are supported (RTMP, RTSP, = push, pull, remote origin...), which features the request router = supports (output formats, redirect protocols...), which geo blocking = features, and file locking, reporting, log formats, does the CDN only = support passive caching or does it support active dynamic controlled = push of assets? Does the CDN rely on passive DNS geo load balancing or = can it do active per request redirection? Which APIs are available, = where can you connect, how to authenticate, which API specs do they = comply to, which API features are supported?=20 This question indeed needs more thinking. As phrased this probably = creates a challenging problem for any approach. At this stage, I'd observe that: * it may be possible to reduce the complexity by mandating a set = of base capabilities (geoblocking, logging, purge, ...) supported by all = CDNs participating in a CDNI mesh * some aspects may be helped/handled by other interfaces (for = example, the CDNI metadata interface allows the uCDN to indicate what = are the acquisition methods that can be used to access a given content). I'd need to better understand what is the real set of requirements here = to understand what approach is well or not so well suited. >=20 > - What about footprint and capabilities transparency? Is one CDN = allowed to pass through the information from another CDN to a third = party CDN or a content publisher? I know that most CDNs act as a black = box. I also know that a lot of premium broadcasters will demand as a = mandatory feature that interconnected / federated CDNs will be = completely transparent about footprint, capacity, capabilities, SLA = levels, even if there is a chain of a dozen interconnected CDNs = involved.=20 So you'd need configurable knobs to control what gets re-advertised as = is, what gets re-advertised with some manipulation, what gets hidden, = what gets aggregated .... This happens to be basic operation in BGP. It = could also be supported in other approaches of course. But I'd point out = that this one aspect where a BGP-based approach has attractiveness = because it actually comprises both an interface/API to exchange = information (the BGP protocol) and effectively a very flexible = rule/policy engine (the BGP engine) while other candidate approaches = mentioned so far focus on the interface/API and would have to re-invent = the rule/policy engine required in meshed scenarios (ie to determine = what needs to get readveristed to who with what modification). >=20 > - What about allowing third party request routers to directly redirect = to an edge node? I know that some vendors have some ideas around it, but = IMHO a CDN operator should always have full autonomous control over = their infrastructure, I believe the group is also operating under that assumption. But I see = this as mostly orthogonal to the footprint/capability advertisement = approach discussion. > so at least we should share a restriction that third parties always = must handle requests through our request routers (in a nice = interconnected way). >=20 > - What about access security management? Some CDNs have very poor = implementations for anti-deep linking. When they turn it on, it kills = their performance by half, or they create tokens based on the end users = IPv4 IP address, destroying their ability to connect in IPv4 / IPv6 dual = mode to various CDN components. Other CDNs do proper full lock-down with = private secure tokens between the delivery nodes and the request = routers, and with private secure tokens between the request routers and = each content owners portal. In interconnected scenarios, multiple CDNs = need to exchange secure tokens on a per account or per CDN basis. How = are these tokens automatically exchanged? Not sure this pertain to the footprint/capability advertisement approach = discussion. >=20 > I think the above is just the tip of the iceberg. Yes, there are other considerations. Two major ones that have come up = before: * the requirement to handle large footprints in very scalable = way while at the same time allowing fine-grain advertisement (first = point above)=20 * the requirement to handle dynamic updates of = footprint/capabilities. This happens to be common operation for BGP (particularly when augmented = with the hierarchical model documented in = previdi-cdni-footprint-advertisement. It could also be supported in = other approaches of course. > It is a quite extensive list that should be shared between 2 CDNs = before they can interact... and I don't think BGP was intended to be = used for these purposes, it was certainly not intended for this purpose initially (nor was it = intended for IPv6 routing initially, nor for MPLS L3 VPNs, nor for the = many applications it is now used for ....). > not that it is a practical protocol for it. That is the bit I am still missing. Cheers Francois >=20 >=20 > Best, Stef >=20 >=20 >=20 >=20 > On 14 mrt. 2012, at 15:05, Francois Le Faucheur wrote: >=20 >> Hi again Stef, >>=20 >> On 14 Mar 2012, at 14:45, Stef van der Ziel wrote: >>=20 >>> Hi Francois, >>>=20 >>> I can understand that from a networking / routing gear vendor = perspective, Cisco looks at BGP (etc) >>=20 >> I don't speak for Cisco in the IETF. I just speak for myself.=20 >> For the record Cisco is also a CDN gear vendor. >>=20 >>> for CDN functions. >>=20 >> This is not for an existing CDN function, this is for a specific CDN = interconnection function which is "CDN footprint advertisement".=20 >>=20 >>> However CDNs aren't necessarily tied into the networking = architecture, instead they are more and more abstracted from the network = layer. >>=20 >> As I said: I am not sure such sweeping statement are really helping = the discussion at hand much. >>=20 >>> I don't favor a particular solution, I want to prevent that a = standard locks in CDN operators into specific environments. That would = be a pitfall for CDN operators. >>> Using APIs instead, there is no need for a debate >>=20 >> Hmm, so you don't favor a particular solution but you recommend that = we don't consider some solutions on the compelling argument that not = considering them would avoid a debate. I guess I am not convinced yet. >>=20 >> By the way, I am not saying that the decision for a BGP-based = approach should be made now. What I am saying is that I personally won't = exclude a BGP-based approach because of a sweeping statement. I = recommend we continue document the information exchange requirements and = several candidate approaches in order to make an informed decision. >>=20 >>> and there is no risk for the actual CDN operator. >>=20 >> I don't understand the basis for that statement. >>=20 >>> I would love to share our ideas around CDN capabilities exchange.=20 >>=20 >> The most effective way in the IETF to share ideas on a proposed = approach is to document it in an Internet-Draft. I suggest you consider = that, or join one of the existing efforts in documenting an approach. >>=20 >> Cheers >>=20 >> Francois >>=20 >>> Best, Stef >>>=20 >>>=20 >>>=20 >>> On 14 mrt. 2012, at 14:39, Francois Le Faucheur wrote: >>>=20 >>>> Hello Stef, >>>>=20 >>>> (as an individual) >>>>=20 >>>> On 14 Mar 2012, at 11:38, Stef van der Ziel wrote: >>>>> Hi, >>>>>=20 >>>>> It still looks like you're trying to lock CDNs into networking = layer protocols and use protocols for which they were not intended.=20 >>>>=20 >>>> I am not sure such sweeping statement are really helping the = discussion much. Probably no more than saying "considering ALTO for CDN = footprint advertisement is bad because it is trying to lock CDNs into = Peer-to-peer protocols". >>>>=20 >>>> I believe the plan of record for the group is : >>>> * identify the functional requirements of a cdn footprint = advertisement (including notably some potentially challenging aspects of = scaling and dynamic updates) >>>> * document various solutions to support these requirements and = assess their applicability >>>> * select one (or potentially more than one) solution based on = applicability >>>>=20 >>>>> In most CDNs we deployed, BGP doesn't play any role. >>>>=20 >>>> So I think you are saying that regardless of its relative = applicability you favor a particular solution because that is what you = are familiar with. This is a useful datapoint but not necessarily a = killer argument for people who extensively use other base technologies. >>>>=20 >>>>> Not even in federated scenarios.=20 >>>>> Better use proper APIs!=20 >>>>=20 >>>> I think there is agreement on that. >>>> The question remains on what is a proper APIs. >>>>=20 >>>> Documenting the "proper API" you have in mind (like is being done = for other approaches) would be helpful in this exercise. >>>>=20 >>>> Thanks >>>>=20 >>>> Francois >>>>=20 >>>>=20 >>>>>=20 >>>>> Best, Stef >>>>>=20 >>>>>=20 >>>>> On 14 mrt. 2012, at 11:33, stefano previdi wrote: >>>>>=20 >>>>>>=20 >>>>>> On Mar 14, 2012, at 11:07 AM, Stef van der Ziel wrote: >>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> I would not recommend using BGP for CDN capabilities sharing. >>>>>>> BGP is a networking layer protocol. >>>>>>=20 >>>>>>=20 >>>>>> not in the way we propose to use it in the CDNI context. >>>>>>=20 >>>>>>=20 >>>>>>> CDNs can and should run independently from the network, or span = multiple networks. Or run within a part of a network, where BGP is not = the right protocol. >>>>>>=20 >>>>>>=20 >>>>>> well, BGP is to be intended as MP-BGP with a scope of advertising=20= >>>>>> footprint and capability information. In that respect the = semantic=20 >>>>>> is pretty clear. The fact that BGP is also used in other contexts=20= >>>>>> such as network layer routing, MPLS-VPN, multicast, etc. doesn't=20= >>>>>> preclude the use of the same technology into another context. >>>>>>=20 >>>>>>=20 >>>>>>> CDNs should not be locked into networks or become dependent on = networking layered protocols. >>>>>>=20 >>>>>>=20 >>>>>> absolutely agree. As you can see from the proposal, we leverage=20= >>>>>> what's available in the BGP databases as for footprint = information.=20 >>>>>> However, also described in the proposal, we allow complete = freedom=20 >>>>>> to any CDNI MP-BGP player to define its own policy and elements = to=20 >>>>>> advertise. >>>>>>=20 >>>>>> s. >>>>>>=20 >>>>>>=20 >>>>>>> CDN interconnection should be done via APIs. >>>>>>>=20 >>>>>>> Kind regards,=20 >>>>>>>=20 >>>>>>> Stef van der Ziel >>>>>>>=20 >>>>>>>=20 >>>>>>> On 12 mrt. 2012, at 15:28, Scott Wainner wrote: >>>>>>>=20 >>>>>>>> I too am struggling with how 'capabilities' can be advertised = effectively in BGP. I'm inclined to delineate the 'footprint' from the = 'capabilities'. >>>>>>>>=20 >>>>>>>> Perhaps one approach is to indicate in the 'capabilities' the = various METHODS for assessing the 'footprint'. In the 'capabilities' = exchange, the options for METHODS of determining 'footprint' might be = BGP AFI or BGP Communities or IGP Distance. Accordingly, a dCDN might = indicate it has the capability of advertising (or allowing discovery of) = different methods of 'footprint' advertisements and those methods might = be weighted. >>>>>>>>=20 >>>>>>>> I think the dCDN capabilities (e.g. delivery methods, security = methods, etc.) will become far more complex than can be aggregated into = a representative set of BGP communities. Nevertheless, I do think BGP = communities is a viable method of advertising a 'footprint' ... one that = is well understood by the network operators. >>>>>>>>=20 >>>>>>>> Scott Wainner >>>>>>>>=20 >>>>>>>> On 3/9/12 6:50 AM, grant.watson@bt.com wrote: >>>>>>>>> Thanks, understood. >>>>>>>>>=20 >>>>>>>>> Then my general feedback would be - I think working out what = capability information needs to be shared between the CDNs would ideally = be worked though prior to deciding the right way to do it. BGP doesn't = feel like an obvious choice for exchanging the kind of CDN Capability = information I'd envisage being passed between CDN. Has a discussion = taken place as to why BGP over other methods? (e.g. API/metadata) There = are drafts discussing metadata right now that propose ways of describing = the capability requirements between CDN (e.g. "deliver this content = using RMTP" etc.), why would we not also exchange capabilities over the = same interface for example? >>>>>>>>>=20 >>>>>>>>> It's easier to understand why it may be considered that BGP = should/could be used for the exchange of network footprint information = but less so for CDN Capabilities, IMHO. In some cases CDN may not want = or need to implement footprint advertisement entirely (for example in a = simple bi-lateral relationship the CDN operators could easily elect to = exchange footprint information out-of-band), in this case they = presumably wouldn't want to be dependent on BGP to exchange capability = information. >>>>>>>>>=20 >>>>>>>>> g- >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stefano previdi [mailto:sprevidi@cisco.com] >>>>>>>>> Sent: 09 March 2012 10:44 >>>>>>>>> To: Watson,G,Grant,DMK5 R >>>>>>>>> Cc: cdni@ietf.org >>>>>>>>> Subject: Re: [CDNi] New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>>>>>>>>=20 >>>>>>>>> Hi Grant, >>>>>>>>>=20 >>>>>>>>> On Mar 8, 2012, at 11:17 PM, = wrote: >>>>>>>>>>=20 >>>>>>>>>> Hi, >>>>>>>>>>=20 >>>>>>>>>> The document talks about "Capability Advertisements" and the = proposal to use MP-BGP messages to advertise/exchange CDN capabilities. = However, the document does not explicitly define what is ment by "CDN = Capability". >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> indeed... and it is somehow intended... >>>>>>>>>=20 >>>>>>>>> As JanS pointed out, there's another draft that should = explicit the semantics of FP/Capabilities. In this proposal we = define the mechanism through which the capability information can be = exchanged. >>>>>>>>>=20 >>>>>>>>> Obviously, at some point, we'll have to synchronize. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> I understand "CDN Capability" to mean things like delivery = technology (for example RTMP or HTTP etc.) or perhaps a specific form of = content authorisation etc. Can you confirm I am correct in assuming this = or if not clarify what the correct meaning is. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> My understanding goes in the same direction, so far. >>>>>>>>>=20 >>>>>>>>> s. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Cheers, >>>>>>>>>>=20 >>>>>>>>>> g- >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> ________________________________________ >>>>>>>>>> From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf = Of >>>>>>>>>> stefano previdi [sprevidi@cisco.com] >>>>>>>>>> Sent: 08 March 2012 21:23 >>>>>>>>>> To: cdni@ietf.org >>>>>>>>>> Subject: [CDNi] Fwd: New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>>>>>>>>>=20 >>>>>>>>>> Begin forwarded message: >>>>>>>>>>=20 >>>>>>>>>>> From: internet-drafts@ietf.org >>>>>>>>>>> Subject: New Version Notification for >>>>>>>>>>> draft-previdi-cdni-footprint-advertisement-01.txt >>>>>>>>>>> Date: March 8, 2012 8:45:53 PM GMT+01:00 >>>>>>>>>>> To: sprevidi@cisco.com >>>>>>>>>>> Cc: allan.guillou@sfr.com, flefauch@cisco.com, = jmedved@cisco.com >>>>>>>>>>>=20 >>>>>>>>>>> A new version of I-D, = draft-previdi-cdni-footprint-advertisement-01.txt has been successfully = submitted by Stefano Previdi and posted to the IETF repository. >>>>>>>>>>>=20 >>>>>>>>>>> Filename: draft-previdi-cdni-footprint-advertisement >>>>>>>>>>> Revision: 01 >>>>>>>>>>> Title: CDNI Footprint Advertisement >>>>>>>>>>> Creation date: 2012-03-08 >>>>>>>>>>> WG ID: Individual Submission >>>>>>>>>>> Number of pages: 27 >>>>>>>>>>>=20 >>>>>>>>>>> Abstract: >>>>>>>>>>> This document describes the use of BGP for Content Delivery = Networks >>>>>>>>>>> (CDNs) in order to advertise information about footprint and=20= >>>>>>>>>>> connectivity to footprint in the context of CDNI. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> This draft is for the CDNI Working Group. >>>>>>>>>>>=20 >>>>>>>>>>> Thanks. >>>>>>>>>>> s. >>>>>>>>>>>=20 >>>>>>>>>>> The IETF Secretariat >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> CDNi mailing list >>>>>>>>>> CDNi@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> CDNi mailing list >>>>>>>>> CDNi@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>>>>=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 >>>>>>=20 >>>>>>=20 >>>>>=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 >>=20 >>=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From jon.peterson@neustar.biz Wed Mar 14 10:41: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 DA8FB21F8776 for ; Wed, 14 Mar 2012 10:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.98 X-Spam-Level: X-Spam-Status: No, score=-105.98 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, 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 uIk8ahRL8sck for ; Wed, 14 Mar 2012 10:41:11 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 55C9121F86A7 for ; Wed, 14 Mar 2012 10:41:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1331746894; x=1647095835; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=Q/3VhALmTvA5eboUBZjhr0+4SVMgQYmPDo2RkTud2pM=; b=HYh53cqRD7GZLgNOLSePxpEVTsTHFGlay8El+9e9Q1wxgadA5B2MrH2rxLuXTg 1bpc8Dj+SJm0w5lylqBuq9WQ== Received: from ([10.31.13.228]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.4194630; Wed, 14 Mar 2012 13:41:33 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Wed, 14 Mar 2012 13:41:07 -0400 From: "Peterson, Jon" To: Scott Wainner Date: Wed, 14 Mar 2012 13:41:02 -0400 Thread-Topic: [CDNi] New Version Notification fordraft-previdi-cdni-footprint-advertisement-01.txt Thread-Index: Ac0CCaI2c7PjHoCXSb2PRbNv9R0fug== Message-ID: <6854E730-8B93-447E-83A8-ED0DA7F99824@neustar.biz> References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net><1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net><4F5E07FA.5090402@cisco.com><5826DF56-7335-49C6-997A-AAB109ED0913@jet-stream.com><2C86FE78-1178-447F-8CB4-5AEA63625679@jet-stream.com><86AF8FF6-4BF3-41D9-837F-21A392C87F83@cisco.com> <0CC6542D-0A0E-41FB-B960-6A3763469BC8@jet-stream.com> <4F60A188.7080205@cisco.com> In-Reply-To: <4F60A188.7080205@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: IjbFWaKZO08t+ZSE5UIJlg== Content-Type: multipart/alternative; boundary="_000_6854E7308B93447E83A8ED0DA7F99824neustarbiz_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] New Version Notification fordraft-previdi-cdni-footprint-advertisement-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, 14 Mar 2012 17:41:14 -0000 --_000_6854E7308B93447E83A8ED0DA7F99824neustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Scott that the focus must be on what information is needed - a= nd in particular, what information is needed by the uCDN to make a selectio= n of a dCDN. There may be information that is easy to express syntactically= , or easy to derive from the network layer, but which does not actually pro= vide the uCDN with the tools it needs to make a decision. It is also the ca= se that dCDNs could expose information that will let uCDNs make a far more = granular decision than just picking a dCDN. The discussion of whether we ne= ed geography or topography or reachability or whatever is contingent on wha= t we imagine the logic will be that a uCDN uses to select a dCDN. One of the reasons why I worked with Jan and Stefano on our new draft about= footprint and capability semantics was that it didn't seem to me at the la= st CDNi session that people had a common picture yet of what a uCDN would n= eed to make a decision. In the draft, we consider a couple of alternatives = definitions of "footprint" that might be useful to the uCDN, and also a cou= ple of alternatives that might not be so useful. While I agree at a high le= vel that dCDNs need some way to inform a uCDN of their footprint, we need t= o be careful when we think in terms of coverage or reachability, because a = dCDN might not even be the best judge of how reachable its resources are to= endpoints outside of its intended scope. We also need to decide how deeply= we want a uCDN to understand a dCDNs resources - effectively, we could hav= e very low-level approaches where uCDNs execute the entire request-routing = algorithm down to selecting the particular cache, or high-level approaches = where the uCDN has only a general sense of dCDN resources and defers cache = selection to the dCDN. Once we get some agreement about these points, decid= ing what type and what granularity of information dCDNs should advertise wi= ll be a lot easier. Jon Peterson NeuStar, Inc. On Mar 14, 2012, at 6:47 AM, Scott Wainner wrote: A 'proper API' whether defined by CDN-I or not requires information to = be conveyed. That is the fundamental question in my mind. What informatio= n needs to be conveyed THROUGH that API / interface? We've clearly identified that the 'footprint' of the CDN and the networ= k are not congruent. However, CDN will need to send packets through the ne= twork to reach the client. The best proximity path between any given deliv= ery node and the client is defined by the network topology. I can have two= devices sitting side-by-side while they are topologically connected in vas= tly different manners. We will certainly need some NETWORK INFORMATION con= veyed through the API to discern the proximity of the client to any given d= elivery node. See ALTO. I think the focus is on what INFORMATION is needed. Then we can focus = on the right conduit to convey that information. I suspect the issue is de= lineating between different types of "capabilities". There are CDN capabil= ities (ability to deliver content using HSS or HLS) and there are network c= apabilities (ability to reach a given prefix and cost associated with that = path). Presumably, the CDN will collect BOTH sets of capabilities via vari= ous API / CDN-I and make the 'best' choice of delivery node. What information do we need from the network to make the best content r= outing decision in the uCDN? draft-he-cdni-cap-info-advertising-01 draft-bertrand-cdni-footprint-discovery-00 Question: Do we delineate our work around NETWORK capabilities / footprint = and CDN capabilities / footprint? I see these as a disjoint set of information that the uCDN will need to ass= imilate and make a congruent assessment. We don't want to assign a deliver= y node that is not capable of delivering the content even though it is clos= er. Conversely, we may want to assign a delivery node that is topologicall= y further away because of access costs. Scott On 3/14/12 8:29 AM, Stef van der Ziel wrote: There are too many scenarios where a CDN does not rely on Internet routing. Think of multiple CDNs within a private network, that have to interoperate. A CDN may also have a different footprint than the network topology. I think that it is too easy to assume that BGP could be the right protocol. Proper APIs offer the same function, but with all the freedom that CDNs wil= l need. Best, Stef On 14 mrt. 2012, at 12:25, stefano previdi wrote: > > On Mar 14, 2012, at 11:38 AM, Stef van der Ziel wrote: > >> Hi, >> >> It still looks like you're trying to lock CDNs into networking layer pro= tocols and use protocols for which they were not intended. > > > well, I don't think so. We use the same tool... but differently. > > >> In most CDNs we deployed, BGP doesn't play any role. Not even in federat= ed scenarios. > > > yes, but at the end of the day, the CDN relies on internet routing so > at some point there's a relationship between the CDN and the network > layer. > > In our proposal we just leverage the reachability information you can > get from your local SP/ISP so to figure out footprint information. > > Capabilities, I agree with you, is a different story but since we > don't know yet what is a capability (and which format it should/must/may > have) it's difficult to come with a proper scheme. Having said that, BGP > (as a tool) has all feature you need so to propagate both FP and caps. > > s. > > > >> Better use proper APIs! >> >> Best, Stef >> >> >> On 14 mrt. 2012, at 11:33, stefano previdi wrote: >> >>> >>> On Mar 14, 2012, at 11:07 AM, Stef van der Ziel wrote: >>> >>>> Hi, >>>> >>>> I would not recommend using BGP for CDN capabilities sharing. >>>> BGP is a networking layer protocol. >>> >>> >>> not in the way we propose to use it in the CDNI context. >>> >>> >>>> CDNs can and should run independently from the network, or span multip= le networks. Or run within a part of a network, where BGP is not the right = protocol. >>> >>> >>> well, BGP is to be intended as MP-BGP with a scope of advertising >>> footprint and capability information. In that respect the semantic >>> is pretty clear. The fact that BGP is also used in other contexts >>> such as network layer routing, MPLS-VPN, multicast, etc. doesn't >>> preclude the use of the same technology into another context. >>> >>> >>>> CDNs should not be locked into networks or become dependent on network= ing layered protocols. >>> >>> >>> absolutely agree. As you can see from the proposal, we leverage >>> what's available in the BGP databases as for footprint information. >>> However, also described in the proposal, we allow complete freedom >>> to any CDNI MP-BGP player to define its own policy and elements to >>> advertise. >>> >>> s. >>> >>> >>>> CDN interconnection should be done via APIs. >>>> >>>> Kind regards, >>>> >>>> Stef van der Ziel >>>> >>>> >>>> On 12 mrt. 2012, at 15:28, Scott Wainner wrote: >>>> >>>>> I too am struggling with how 'capabilities' can be advertised effecti= vely in BGP. I'm inclined to delineate the 'footprint' from the 'capabilit= ies'. >>>>> >>>>> Perhaps one approach is to indicate in the 'capabilities' the various= METHODS for assessing the 'footprint'. In the 'capabilities' exchange, th= e options for METHODS of determining 'footprint' might be BGP AFI or BGP Co= mmunities or IGP Distance. Accordingly, a dCDN might indicate it has the c= apability of advertising (or allowing discovery of) different methods of 'f= ootprint' advertisements and those methods might be weighted. >>>>> >>>>> I think the dCDN capabilities (e.g. delivery methods, security method= s, etc.) will become far more complex than can be aggregated into a represe= ntative set of BGP communities. Nevertheless, I do think BGP communities i= s a viable method of advertising a 'footprint' ... one that is well underst= ood by the network operators. >>>>> >>>>> Scott Wainner >>>>> >>>>> On 3/9/12 6:50 AM, grant.watson@bt.com wr= ote: >>>>>> Thanks, understood. >>>>>> >>>>>> Then my general feedback would be - I think working out what capabil= ity information needs to be shared between the CDNs would ideally be worked= though prior to deciding the right way to do it. BGP doesn't feel like an = obvious choice for exchanging the kind of CDN Capability information I'd en= visage being passed between CDN. Has a discussion taken place as to why BGP= over other methods? (e.g. API/metadata) There are drafts discussing metada= ta right now that propose ways of describing the capability requirements be= tween CDN (e.g. "deliver this content using RMTP" etc.), why would we not a= lso exchange capabilities over the same interface for example? >>>>>> >>>>>> It's easier to understand why it may be considered that BGP should/c= ould be used for the exchange of network footprint information but less so = for CDN Capabilities, IMHO. In some cases CDN may not want or need to imple= ment footprint advertisement entirely (for example in a simple bi-lateral r= elationship the CDN operators could easily elect to exchange footprint info= rmation out-of-band), in this case they presumably wouldn't want to be depe= ndent on BGP to exchange capability information. >>>>>> >>>>>> g- >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: stefano previdi [mailto:sprevidi@cisco.com] >>>>>> Sent: 09 March 2012 10:44 >>>>>> To: Watson,G,Grant,DMK5 R >>>>>> Cc: cdni@ietf.org >>>>>> Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-= footprint-advertisement-01.txt >>>>>> >>>>>> Hi Grant, >>>>>> >>>>>> On Mar 8, 2012, at 11:17 PM, wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> The document talks about "Capability Advertisements" and the propos= al to use MP-BGP messages to advertise/exchange CDN capabilities. However, = the document does not explicitly define what is ment by "CDN Capability". >>>>>> >>>>>> >>>>>> indeed... and it is somehow intended... >>>>>> >>>>>> As JanS pointed out, there's another draft that should explicit the = semantics of FP/Capabilities. In this proposal we define the mech= anism through which the capability information can be exchanged. >>>>>> >>>>>> Obviously, at some point, we'll have to synchronize. >>>>>> >>>>>> >>>>>>> I understand "CDN Capability" to mean things like delivery technolo= gy (for example RTMP or HTTP etc.) or perhaps a specific form of content au= thorisation etc. Can you confirm I am correct in assuming this or if not cl= arify what the correct meaning is. >>>>>> >>>>>> >>>>>> My understanding goes in the same direction, so far. >>>>>> >>>>>> s. >>>>>> >>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> g- >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: cdni-bounces@ietf.org [cdni-bou= nces@ietf.org] On Behalf Of >>>>>>> stefano previdi [sprevidi@cisco.com] >>>>>>> Sent: 08 March 2012 21:23 >>>>>>> To: cdni@ietf.org >>>>>>> Subject: [CDNi] Fwd: New Version Notification for draft-previ= di-cdni-footprint-advertisement-01.txt >>>>>>> >>>>>>> Begin forwarded message: >>>>>>> >>>>>>>> From: internet-drafts@ietf.org >>>>>>>> Subject: New Version Notification for >>>>>>>> draft-previdi-cdni-footprint-advertisement-01.txt >>>>>>>> Date: March 8, 2012 8:45:53 PM GMT+01:00 >>>>>>>> To: sprevidi@cisco.com >>>>>>>> Cc: allan.guillou@sfr.com, flefauch@= cisco.com, jmedved@cisco.com >>>>>>>> >>>>>>>> A new version of I-D, draft-previdi-cdni-footprint-advertisement-0= 1.txt has been successfully submitted by Stefano Previdi and posted to the = IETF repository. >>>>>>>> >>>>>>>> Filename: draft-previdi-cdni-footprint-advertisement >>>>>>>> Revision: 01 >>>>>>>> Title: CDNI Footprint Advertisement >>>>>>>> Creation date: 2012-03-08 >>>>>>>> WG ID: Individual Submission >>>>>>>> Number of pages: 27 >>>>>>>> >>>>>>>> Abstract: >>>>>>>> This document describes the use of BGP for Content Delivery Networ= ks >>>>>>>> (CDNs) in order to advertise information about footprint and >>>>>>>> connectivity to footprint in the context of CDNI. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This draft is for the CDNI Working Group. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> s. >>>>>>>> >>>>>>>> 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 >>>> >>>> _______________________________________________ >>>> 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_6854E7308B93447E83A8ED0DA7F99824neustarbiz_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agre= e with Scott that the focus must be on what information is needed - and in = particular, what information is needed by the uCDN to make a selection of a= dCDN. There may be information that is easy to express syntactically, or e= asy to derive from the network layer, but which does not actually provide t= he uCDN with the tools it needs to make a decision. It is also the case tha= t dCDNs could expose information that will let uCDNs make a far more granul= ar decision than just picking a dCDN. The discussion of whether we need geo= graphy or topography or reachability or whatever is contingent on what we i= magine the logic will be that a uCDN uses to select a dCDN.

<= /div>
One of the reasons why I worked with Jan and Stefano on our new d= raft about footprint and capability semantics was that it didn't seem to me= at the last CDNi session that people had a common picture yet of what a uC= DN would need to make a decision. In the draft, we consider a couple of alt= ernatives definitions of "footprint" that might be useful to the uCDN, and = also a couple of alternatives that might not be so useful. While I agree at= a high level that dCDNs need some way to inform a uCDN of their footprint,= we need to be careful when we think in terms of coverage or reachability, = because a dCDN might not even be the best judge of how reachable its resour= ces are to endpoints outside of its intended scope. We also need to decide = how deeply we want a uCDN to understand a dCDNs resources - effectively, we= could have very low-level approaches where uCDNs execute the entire reques= t-routing algorithm down to selecting the particular cache, or high-level a= pproaches where the uCDN has only a general sense of dCDN resources and def= ers cache selection to the dCDN. Once we get some agreement about these poi= nts, deciding what type and what granularity of information dCDNs should ad= vertise will be a lot easier.

Jon Peterson
NeuStar, Inc.

On Mar 14, 2012, at 6:47 AM, Scott Wain= ner wrote:

=20 =20

    A 'proper API' whether defined by CDN-I or not requi= res information to be conveyed.  That is the fundamental question in m= y mind.  What information needs to be conveyed THROUGH that API / interface?

    We've clearly identified that the 'footprint' of the= CDN and the network are not congruent.  However, CDN will need to send packets through the network to reach the client.  The best proximity path between any given delivery node and the client is defined by the network topology.  I can have two devices sitting side-by-side whi= le they are topologically connected in vastly different manners.  We will certainly need some NETWORK INFORMATION conveyed through the API to discern the proximity of the client to any given delivery node. See ALTO.

    I think the focus is on what INFORMATION is needed.&= nbsp; Then we can focus on the right conduit to convey that information.  I suspect the issue is delineating between different types of "capabilities".&nbs= p; There are CDN capabilities (ability to deliver content using HSS or HLS) and there are network capabilities (ability to reach a given prefix and cost associated with that path).  Presumably, the CDN will collect BOTH sets of capabilities via various API / CDN-I and make the 'best' choice of delivery node.

    What information do we need from the network to make= the best content routing decision in the uCDN?

    draft-he-cdni-cap-info-advertising-01
    draft-bertrand-cdni-footprint-discovery-00

Question: Do we delineate our work around NETWORK capabilities / footprint and CDN capabilities / footprint?

I see these as a disjoint set of information that the uCDN will need to assimilate and make a congruent assessment.  We don't want to assign a delivery node that is not capable of delivering the content even though it is closer.  Conversely, we may want to assign a delivery node that is topologically further away because of access costs.

Scott

On 3/14/12 8:29 AM, Stef van der Ziel wrote:
Re: [CDNi] New Version Notification fordraft-previdi-cdni-footprint-advertisement-01.txt

There ar= e too many scenarios where a CDN does not rely on Internet routing.
Think of multiple CDNs within a private network, that have to interoperate.
A CDN may also have a different footprint than the network topology.
I think that it is too easy to assume that BGP could be the right protocol.
Proper APIs offer the same function, but with all the freedom that CDNs will need.

Best, Stef



On 14 mrt. 2012, at 12:25, stefano previdi wrote:

>
> On Mar 14, 2012, at 11:38 AM, Stef van der Ziel wrote:
>
>> Hi,
>>
>> It still looks like you're trying to lock CDNs into networking layer protocols and use protocols for which they were not intended.
>
>
> well, I don't think so. We use the same tool... but differently.
>
>
>> In most CDNs we deployed, BGP doesn't play any role. Not even in federated scenarios.
>
>
> yes, but at the end of the day, the CDN relies on internet routing so
> at some point there's a relationship between the CDN and the network
> layer.
>
> In our proposal we just leverage the reachability information you can
> get from your local SP/ISP so to figure out footprint information.
>
> Capabilities, I agree with you, is a different story but since we
> don't know yet what is a capability (and which format it should/must/may
> have) it's difficult to come with a proper scheme. Having said that, BGP
> (as a tool) has all feature you need so to propagate both FP and caps.
>
> s.
>
>
>
>> Better use proper APIs!
>>
>> Best, Stef
>>
>>
>> On 14 mrt. 2012, at 11:33, stefano previdi wrote:
>>
>>>
>>> On Mar 14, 2012, at 11:07 AM, Stef van der Ziel wrote:
>>>
>>>> Hi,
>>>>
>>>> I would not recommend using BGP for CDN capabilities sharing.
>>>> BGP is a networking layer protocol.
>>>
>>>
>>> not in the way we propose to use it in the CDNI context.
>>>
>>>
>>>> CDNs can and should run independently from the network, or span multiple networks. Or run within a part of a network, where BGP is not the right protocol.
>>>
>>>
>>> well, BGP is to be intended as MP-BGP with a scope of advertising
>>> footprint and capability information. In that respect the semantic
>>> is pretty clear. The fact that BGP is also used in other contexts
>>> such as network layer routing, MPLS-VPN, multicast, etc. doesn't
>>> preclude the use of the same technology into another context.
>>>
>>>
>>>> CDNs should not be locked into networks or become dependent on networking layered protocols.
>>>
>>>
>>> absolutely agree. As you can see from the proposal, we leverage
>>> what's available in the BGP databases as for footprint information.
>>> However, also described in the proposal, we allow complete freedom
>>> to any CDNI MP-BGP player to define its own policy and elements to
>>> advertise.
>>>
>>> s.
>>>
>>>
>>>> CDN interconnection should be done via APIs.
>>>>
>>>> Kind regards,
>>>>
>>>> Stef van der Ziel
>>>>
>>>>
>>>> On 12 mrt. 2012, at 15:28, Scott Wainner wrote:
>>>>
>>>>> I too am struggling with how 'capabilities' can be advertised effectively in BGP.  I'm inclined to delineate the 'footprint' from the 'capabilities'. >>>>>
>>>>> Perhaps one approach is to indicate in the 'capabilities' the various METHODS for assessing the 'footprint'.  In the 'capabilities' exchange, the options fo= r METHODS of determining 'footprint' might be BGP AFI or BGP Communities or IGP Distance.  Accordingly, a dCDN might indicate it has the capability of advertising (or allowing discovery of) different methods of 'footprint' advertisements and those methods might be weighted.
>>>>>
>>>>> I think the dCDN capabilities (e.g. delivery methods, security methods, etc.) will become far more complex than can be aggregated into a representative set of BGP communities.  Nevertheless, I do think BGP communities i= s a viable method of advertising a 'footprint' ... one that is well understood by the network operators.
>>>>>
>>>>> Scott Wainner
>>>>>
>>>>> On 3/9/12 6:50 AM, grant.watson@bt.com wrote:
>>>>>> Thanks, understood.
>>>>>>
>>>>>> Then my general feedback would be - I think working out what capability information needs to be shared between the CDNs would ideally be worked though prior to deciding the right way to do it. BGP doesn't feel like an obvious choice for exchanging the kind of CDN Capability information I'd envisage being passed between CDN. Has a discussion taken place as to why BGP over other methods? (e.g. API/metadata) There are drafts discussing metadata right now that propose ways of describing the capability requirements between CDN (e.g. "deliver this content using RMTP" etc.), why would we not also exchange capabilities over the same interface for example?
>>>>>>
>>>>>> It's easier to understand why it may be considered that BGP should/could be used for the exchange of network footprint information but less so for CDN Capabilities, IMHO. In some cases CDN may not want or need to implement footprint advertisement entirely (for example in a simple bi-lateral relationship the CDN operators could easily elect to exchange footprint information out-of-band), in this case they presumably wouldn't want to be dependent on BGP to exchange capability information.
>>>>>>
>>>>>> g-
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: stefano previdi [mailto:sprevidi@cisco.com= ]
>>>>>> Sent: 09 March 2012 10:44
>>>>>> To: Watson,G,Grant,DMK5 R
>>>>>> Cc: cdni@ietf.org
>>>>>> Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-01.txt
>>>>>>
>>>>>> Hi Grant,
>>>>>>
>>>>>> On Mar 8, 2012, at 11:17 PM, <grant.watson@bt.com> <grant.watson@bt.com> wrote: >>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> The document talks about "Capability Advertisements" and the proposal to use MP-BGP messages to advertise/exchange CDN capabilities. However, the document does not explicitly define what is ment by "CDN Capability".
>>>>>>
>>>>>>
>>>>>> indeed... and it is somehow intended...
>>>>>>
>>>>>> As JanS pointed out, there's another draft that should explicit the semantics of FP/Capabilities. In this proposal we       &nbs= p;   define the mechanism through which the capability information can be exchanged.
>>>>>>
>>>>>> Obviously, at some point, we'll have to synchronize.
>>>>>>
>>>>>>
>>>>>>> I understand "CDN Capability" to mean things like delivery technology (for example RTMP or HTTP etc.) or perhaps a specific form of content authorisation etc. Can you confirm I am correct in assuming this or if not clarify what the        &= nbsp;  correct meaning is.
>>>>>>
>>>>>>
>>>>>> My understanding goes in the same direction, so far.
>>>>>>
>>>>>> s.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> g-
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ________________________________________
>>>>>>> From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf Of
>>>>>>> stefano previdi [sprevidi@cisco.com]
>>>>>>> Sent: 08 March 2012 21:23
>>>>>>> To: cdni@ietf.org
>>>>>>> Subject: [CDNi] Fwd: New Version Notification for       draft-previdi-cdni-footprint-advertisement-01.txt
>>>>>>>
>>>>>>> Begin forwarded message:
>>>>>>>
>>>>>>>> From: internet-drafts@ietf.org
>>>>>>>> Subject: New Version Notification for
>>>>>>>> draft-previdi-cdni-footprint-advertisement-01.txt
>>>>>>>> Date: March 8, 2012 8:45:53 PM GMT+01:00
>>>>>>>> To: sprevidi@cisco.com
>>>>>>>> Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com
>>>>>>>>
>>>>>>>> A new version of I-D, draft-previdi-cdni-footprint-advertisement-01.txt has been successfully submitted by Stefano Previdi and posted to the IETF repository.
>>>>>>>>
>>>>>>>> Filename:    = ;  draft-previdi-cdni-footprint-advertisement
>>>>>>>> Revision:    = ;  01
>>>>>>>> Title:    &n= bsp;            CDNI Footprint Advertisement
>>>>>>>> Creation date:   =       2012-03-08
>>>>>>>> WG ID:    &n= bsp;            Individual Submission
>>>>>>>> Number of pages: 27
>>>>>>>>
>>>>>>>> Abstract:
>>>>>>>> This document describes the use of BGP for Content Delivery Networks
>>>>>>>> (CDNs) in order to advertise information about footprint and
>>>>>>>> connectivity to footprint in the context of CDNI.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> This draft is for the CDNI Working Group.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>> s.
>>>>>>>>
>>>>>>>> The IETF Secretariat
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> CDNi mailing list
>>>>>>> CDNi@ietf.org
>>>>>>> https://www.ietf.org/mailman/li= stinfo/cdni
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> CDNi mailing list
>>>>>> CDNi@ietf.org
>>>>>> https://www.ietf.org/mailman/listin= fo/cdni
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> CDNi mailing list
>>>>> CDNi@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/c= dni
>>>>
>>>> _______________________________________________
>>>> CDNi mailing list
>>>> CDNi@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/cdni<= /a>
>>>
>>>
>>
>> _______________________________________________
>> 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


<ATT00001..txt>

= --_000_6854E7308B93447E83A8ED0DA7F99824neustarbiz_-- From yry@cs.yale.edu Wed Mar 14 11:58: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 A031821F84E2 for ; Wed, 14 Mar 2012 11:58:38 -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, HTML_MESSAGE=0.001, J_CHICKENPOX_61=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 UulyAC5X5vcx for ; Wed, 14 Mar 2012 11:58:36 -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 0618821F84D7 for ; Wed, 14 Mar 2012 11:58:35 -0700 (PDT) Received: from dhcp-128-36-169-62.central.yale.edu (dhcp-128-36-169-62.central.yale.edu [128.36.169.62]) (authenticated bits=0) by vm-emlprdomr-05.its.yale.edu (8.14.4/8.14.4) with ESMTP id q2EIwX7t006143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Mar 2012 14:58:33 -0400 Message-ID: <4F60EA59.6060202@cs.yale.edu> Date: Wed, 14 Mar 2012 14:58:33 -0400 From: "Y. Richard Yang" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: cdni@ietf.org References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net><1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net><4F5E07FA.5090402@cisco.com><5826DF56-7335-49C6-997A-AAB109ED0913@jet-stream.com><2C86FE78-1178-447F-8CB4-5AEA63625679@jet-stream.com><86AF8FF6-4BF3-41D9-837F-21A392C87F83@cisco.com> <0CC6542D-0A0E-41FB-B960-6A3763469BC8@jet-stream.com> <4F60A188.7080205@cisco.com> <6854E730-8B93-447E-83A8-ED0DA7F99824@neustar.biz> In-Reply-To: <6854E730-8B93-447E-83A8-ED0DA7F99824@neustar.biz> Content-Type: multipart/alternative; boundary="------------040503020901040609020103" X-Scanned-By: MIMEDefang 2.71 on 130.132.50.146 Subject: Re: [CDNi] New Version Notification fordraft-previdi-cdni-footprint-advertisement-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, 14 Mar 2012 18:58:38 -0000 This is a multi-part message in MIME format. --------------040503020901040609020103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I will echo that it is important to first understand the information is needed. In particular, I like the comment by Jon that "The discussion of whether we need geography or topography or reachability or whatever is contingent on what we imagine the logic will be that a uCDN uses to select a dCDN". We recently did a study in the context of formulating and solving a *single-hop* CDNi problem. We named the formulation content multihoming optimization problem. A draft of the paper is at: http://www-net.cs.yale.edu/publications/cm12.pdf, and we have not been able to turn it into an ID, but we will try after the IETF. The paper gives a simple design point -- the setting of the paper is in a limited setting of single hop -- on how a uCDN (content publisher) might formulate a problem, and what inputs are needed to solve the problem. You can safely skip the math on the solution part. Some of our measurements could be interesting for this group as well--some CDNs impose rate limits, some CDNs already use CDNi to delegate to other networks. Richard On 3/14/12 1:41 PM, Peterson, Jon wrote: > > I agree with Scott that the focus must be on what information is > needed - and in particular, what information is needed by the uCDN to > make a selection of a dCDN. There may be information that is easy to > express syntactically, or easy to derive from the network layer, but > which does not actually provide the uCDN with the tools it needs to > make a decision. It is also the case that dCDNs could expose > information that will let uCDNs make a far more granular decision than > just picking a dCDN. The discussion of whether we need geography or > topography or reachability or whatever is contingent on what we > imagine the logic will be that a uCDN uses to select a dCDN. > > One of the reasons why I worked with Jan and Stefano on our new draft > about footprint and capability semantics was that it didn't seem to me > at the last CDNi session that people had a common picture yet of what > a uCDN would need to make a decision. In the draft, we consider a > couple of alternatives definitions of "footprint" that might be useful > to the uCDN, and also a couple of alternatives that might not be so > useful. While I agree at a high level that dCDNs need some way to > inform a uCDN of their footprint, we need to be careful when we think > in terms of coverage or reachability, because a dCDN might not even be > the best judge of how reachable its resources are to endpoints outside > of its intended scope. We also need to decide how deeply we want a > uCDN to understand a dCDNs resources - effectively, we could have very > low-level approaches where uCDNs execute the entire request-routing > algorithm down to selecting the particular cache, or high-level > approaches where the uCDN has only a general sense of dCDN resources > and defers cache selection to the dCDN. Once we get some agreement > about these points, deciding what type and what granularity of > information dCDNs should advertise will be a lot easier. > > Jon Peterson > NeuStar, Inc. > > On Mar 14, 2012, at 6:47 AM, Scott Wainner wrote: > >> >> A 'proper API' whether defined by CDN-I or not requires >> information to be conveyed. That is the fundamental question in my >> mind. What information needs to be conveyed THROUGH that API / >> interface? >> >> We've clearly identified that the 'footprint' of the CDN and the >> network are not congruent. However, CDN will need to send packets >> through the network to reach the client. The best proximity path >> between any given delivery node and the client is defined by the >> network topology. I can have two devices sitting side-by-side while >> they are topologically connected in vastly different manners. We >> will certainly need some NETWORK INFORMATION conveyed through the API >> to discern the proximity of the client to any given delivery node. >> See ALTO. >> >> I think the focus is on what INFORMATION is needed. Then we can >> focus on the right conduit to convey that information. I suspect the >> issue is delineating between different types of "capabilities". >> There are CDN capabilities (ability to deliver content using HSS or >> HLS) and there are network capabilities (ability to reach a given >> prefix and cost associated with that path). Presumably, the CDN will >> collect BOTH sets of capabilities via various API / CDN-I and make >> the 'best' choice of delivery node. >> >> What information do we need from the network to make the best >> content routing decision in the uCDN? >> >> draft-he-cdni-cap-info-advertising-01 >> draft-bertrand-cdni-footprint-discovery-00 >> >> Question: Do we delineate our work around NETWORK capabilities / >> footprint and CDN capabilities / footprint? >> >> I see these as a disjoint set of information that the uCDN will need >> to assimilate and make a congruent assessment. We don't want to >> assign a delivery node that is not capable of delivering the content >> even though it is closer. Conversely, we may want to assign a >> delivery node that is topologically further away because of access costs. >> >> Scott >> >> On 3/14/12 8:29 AM, Stef van der Ziel wrote: >>> >>> There are too many scenarios where a CDN does not rely on Internet >>> routing. >>> Think of multiple CDNs within a private network, that have to >>> interoperate. >>> A CDN may also have a different footprint than the network topology. >>> I think that it is too easy to assume that BGP could be the right >>> protocol. >>> Proper APIs offer the same function, but with all the freedom that >>> CDNs will need. >>> >>> Best, Stef >>> >>> >>> >>> On 14 mrt. 2012, at 12:25, stefano previdi wrote: >>> >>> > >>> > On Mar 14, 2012, at 11:38 AM, Stef van der Ziel wrote: >>> > >>> >> Hi, >>> >> >>> >> It still looks like you're trying to lock CDNs into networking >>> layer protocols and use protocols for which they were not intended. >>> > >>> > >>> > well, I don't think so. We use the same tool... but differently. >>> > >>> > >>> >> In most CDNs we deployed, BGP doesn't play any role. Not even in >>> federated scenarios. >>> > >>> > >>> > yes, but at the end of the day, the CDN relies on internet routing so >>> > at some point there's a relationship between the CDN and the network >>> > layer. >>> > >>> > In our proposal we just leverage the reachability information you can >>> > get from your local SP/ISP so to figure out footprint information. >>> > >>> > Capabilities, I agree with you, is a different story but since we >>> > don't know yet what is a capability (and which format it >>> should/must/may >>> > have) it's difficult to come with a proper scheme. Having said >>> that, BGP >>> > (as a tool) has all feature you need so to propagate both FP and caps. >>> > >>> > s. >>> > >>> > >>> > >>> >> Better use proper APIs! >>> >> >>> >> Best, Stef >>> >> >>> >> >>> >> On 14 mrt. 2012, at 11:33, stefano previdi wrote: >>> >> >>> >>> >>> >>> On Mar 14, 2012, at 11:07 AM, Stef van der Ziel wrote: >>> >>> >>> >>>> Hi, >>> >>>> >>> >>>> I would not recommend using BGP for CDN capabilities sharing. >>> >>>> BGP is a networking layer protocol. >>> >>> >>> >>> >>> >>> not in the way we propose to use it in the CDNI context. >>> >>> >>> >>> >>> >>>> CDNs can and should run independently from the network, or span >>> multiple networks. Or run within a part of a network, where BGP is >>> not the right protocol. >>> >>> >>> >>> >>> >>> well, BGP is to be intended as MP-BGP with a scope of advertising >>> >>> footprint and capability information. In that respect the semantic >>> >>> is pretty clear. The fact that BGP is also used in other contexts >>> >>> such as network layer routing, MPLS-VPN, multicast, etc. doesn't >>> >>> preclude the use of the same technology into another context. >>> >>> >>> >>> >>> >>>> CDNs should not be locked into networks or become dependent on >>> networking layered protocols. >>> >>> >>> >>> >>> >>> absolutely agree. As you can see from the proposal, we leverage >>> >>> what's available in the BGP databases as for footprint information. >>> >>> However, also described in the proposal, we allow complete freedom >>> >>> to any CDNI MP-BGP player to define its own policy and elements to >>> >>> advertise. >>> >>> >>> >>> s. >>> >>> >>> >>> >>> >>>> CDN interconnection should be done via APIs. >>> >>>> >>> >>>> Kind regards, >>> >>>> >>> >>>> Stef van der Ziel >>> >>>> >>> >>>> >>> >>>> On 12 mrt. 2012, at 15:28, Scott Wainner wrote: >>> >>>> >>> >>>>> I too am struggling with how 'capabilities' can be advertised >>> effectively in BGP. I'm inclined to delineate the 'footprint' from >>> the 'capabilities'. >>> >>>>> >>> >>>>> Perhaps one approach is to indicate in the 'capabilities' the >>> various METHODS for assessing the 'footprint'. In the >>> 'capabilities' exchange, the options for METHODS of determining >>> 'footprint' might be BGP AFI or BGP Communities or IGP Distance. >>> Accordingly, a dCDN might indicate it has the capability of >>> advertising (or allowing discovery of) different methods of >>> 'footprint' advertisements and those methods might be weighted. >>> >>>>> >>> >>>>> I think the dCDN capabilities (e.g. delivery methods, security >>> methods, etc.) will become far more complex than can be aggregated >>> into a representative set of BGP communities. Nevertheless, I do >>> think BGP communities is a viable method of advertising a >>> 'footprint' ... one that is well understood by the network operators. >>> >>>>> >>> >>>>> Scott Wainner >>> >>>>> >>> >>>>> On 3/9/12 6:50 AM, grant.watson@bt.com wrote: >>> >>>>>> Thanks, understood. >>> >>>>>> >>> >>>>>> Then my general feedback would be - I think working out what >>> capability information needs to be shared between the CDNs would >>> ideally be worked though prior to deciding the right way to do it. >>> BGP doesn't feel like an obvious choice for exchanging the kind of >>> CDN Capability information I'd envisage being passed between CDN. >>> Has a discussion taken place as to why BGP over other methods? (e.g. >>> API/metadata) There are drafts discussing metadata right now that >>> propose ways of describing the capability requirements between CDN >>> (e.g. "deliver this content using RMTP" etc.), why would we not also >>> exchange capabilities over the same interface for example? >>> >>>>>> >>> >>>>>> It's easier to understand why it may be considered that BGP >>> should/could be used for the exchange of network footprint >>> information but less so for CDN Capabilities, IMHO. In some cases >>> CDN may not want or need to implement footprint advertisement >>> entirely (for example in a simple bi-lateral relationship the CDN >>> operators could easily elect to exchange footprint information >>> out-of-band), in this case they presumably wouldn't want to be >>> dependent on BGP to exchange capability information. >>> >>>>>> >>> >>>>>> g- >>> >>>>>> >>> >>>>>> >>> >>>>>> -----Original Message----- >>> >>>>>> From: stefano previdi [mailto:sprevidi@cisco.com] >>> >>>>>> Sent: 09 March 2012 10:44 >>> >>>>>> To: Watson,G,Grant,DMK5 R >>> >>>>>> Cc: cdni@ietf.org >>> >>>>>> Subject: Re: [CDNi] New Version Notification for >>> draft-previdi-cdni-footprint-advertisement-01.txt >>> >>>>>> >>> >>>>>> Hi Grant, >>> >>>>>> >>> >>>>>> On Mar 8, 2012, at 11:17 PM, >>> wrote: >>> >>>>>>> >>> >>>>>>> Hi, >>> >>>>>>> >>> >>>>>>> The document talks about "Capability Advertisements" and the >>> proposal to use MP-BGP messages to advertise/exchange CDN >>> capabilities. However, the document does not explicitly define what >>> is ment by "CDN Capability". >>> >>>>>> >>> >>>>>> >>> >>>>>> indeed... and it is somehow intended... >>> >>>>>> >>> >>>>>> As JanS pointed out, there's another draft that should >>> explicit the semantics of FP/Capabilities. In this proposal >>> we define the mechanism through which the capability >>> information can be exchanged. >>> >>>>>> >>> >>>>>> Obviously, at some point, we'll have to synchronize. >>> >>>>>> >>> >>>>>> >>> >>>>>>> I understand "CDN Capability" to mean things like delivery >>> technology (for example RTMP or HTTP etc.) or perhaps a specific >>> form of content authorisation etc. Can you confirm I am correct in >>> assuming this or if not clarify what the correct meaning is. >>> >>>>>> >>> >>>>>> >>> >>>>>> My understanding goes in the same direction, so far. >>> >>>>>> >>> >>>>>> s. >>> >>>>>> >>> >>>>>> >>> >>>>>>> >>> >>>>>>> Cheers, >>> >>>>>>> >>> >>>>>>> g- >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> ________________________________________ >>> >>>>>>> From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf Of >>> >>>>>>> stefano previdi [sprevidi@cisco.com] >>> >>>>>>> Sent: 08 March 2012 21:23 >>> >>>>>>> To: cdni@ietf.org >>> >>>>>>> Subject: [CDNi] Fwd: New Version Notification for >>> draft-previdi-cdni-footprint-advertisement-01.txt >>> >>>>>>> >>> >>>>>>> Begin forwarded message: >>> >>>>>>> >>> >>>>>>>> From: internet-drafts@ietf.org >>> >>>>>>>> Subject: New Version Notification for >>> >>>>>>>> draft-previdi-cdni-footprint-advertisement-01.txt >>> >>>>>>>> Date: March 8, 2012 8:45:53 PM GMT+01:00 >>> >>>>>>>> To: sprevidi@cisco.com >>> >>>>>>>> Cc: allan.guillou@sfr.com, flefauch@cisco.com, >>> jmedved@cisco.com >>> >>>>>>>> >>> >>>>>>>> A new version of I-D, >>> draft-previdi-cdni-footprint-advertisement-01.txt has been >>> successfully submitted by Stefano Previdi and posted to the IETF >>> repository. >>> >>>>>>>> >>> >>>>>>>> Filename: draft-previdi-cdni-footprint-advertisement >>> >>>>>>>> Revision: 01 >>> >>>>>>>> Title: CDNI Footprint Advertisement >>> >>>>>>>> Creation date: 2012-03-08 >>> >>>>>>>> WG ID: Individual Submission >>> >>>>>>>> Number of pages: 27 >>> >>>>>>>> >>> >>>>>>>> Abstract: >>> >>>>>>>> This document describes the use of BGP for Content Delivery >>> Networks >>> >>>>>>>> (CDNs) in order to advertise information about footprint and >>> >>>>>>>> connectivity to footprint in the context of CDNI. >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> This draft is for the CDNI Working Group. >>> >>>>>>>> >>> >>>>>>>> Thanks. >>> >>>>>>>> s. >>> >>>>>>>> >>> >>>>>>>> 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 >>> >>>> >>> >>>> _______________________________________________ >>> >>>> 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 --------------040503020901040609020103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

I will echo that it is important to first understand the information is needed. In particular, I like the comment by Jon that "The discussion of whether we need geography or topography or reachability or whatever is contingent on what we imagine the logic will be that a uCDN uses to select a dCDN". We recently did a study in the context of formulating and solving a *single-hop* CDNi problem. We named the formulation content multihoming optimization problem. A draft of the paper is at: http://www-net.cs.yale.edu/publications/cm12.pdf, and we have not been able to turn it into an ID, but we will try after the IETF. The paper gives a simple design point -- the setting of the paper is in a limited setting of single hop -- on how a uCDN (content publisher) might formulate a problem, and what inputs are needed to solve the problem. You can safely skip the math on the solution part. Some of our measurements could be interesting for this group as well--some CDNs impose rate limits, some CDNs already use CDNi to delegate to other networks.

Richard

On 3/14/12 1:41 PM, Peterson, Jon wrote:

I agree with Scott that the focus must be on what information is needed - and in particular, what information is needed by the uCDN to make a selection of a dCDN. There may be information that is easy to express syntactically, or easy to derive from the network layer, but which does not actually provide the uCDN with the tools it needs to make a decision. It is also the case that dCDNs could expose information that will let uCDNs make a far more granular decision than just picking a dCDN. The discussion of whether we need geography or topography or reachability or whatever is contingent on what we imagine the logic will be that a uCDN uses to select a dCDN.

One of the reasons why I worked with Jan and Stefano on our new draft about footprint and capability semantics was that it didn't seem to me at the last CDNi session that people had a common picture yet of what a uCDN would need to make a decision. In the draft, we consider a couple of alternatives definitions of "footprint" that might be useful to the uCDN, and also a couple of alternatives that might not be so useful. While I agree at a high level that dCDNs need some way to inform a uCDN of their footprint, we need to be careful when we think in terms of coverage or reachability, because a dCDN might not even be the best judge of how reachable its resources are to endpoints outside of its intended scope. We also need to decide how deeply we want a uCDN to understand a dCDNs resources - effectively, we could have very low-level approaches where uCDNs execute the entire request-routing algorithm down to selecting the particular cache, or high-level approaches where the uCDN has only a general sense of dCDN resources and defers cache selection to the dCDN. Once we get some agreement about these points, deciding what type and what granularity of information dCDNs should advertise will be a lot easier.

Jon Peterson
NeuStar, Inc.

On Mar 14, 2012, at 6:47 AM, Scott Wainner wrote:


    A 'proper API' whether defined by CDN-I or not requires information to be conveyed.  That is the fundamental question in my mind.  What information needs to be conveyed THROUGH that API / interface?

    We've clearly identified that the 'footprint' of the CDN and the network are not congruent.  However, CDN will need to send packets through the network to reach the client.  The best proximity path between any given delivery node and the client is defined by the network topology.  I can have two devices sitting side-by-side while they are topologically connected in vastly different manners.  We will certainly need some NETWORK INFORMATION conveyed through the API to discern the proximity of the client to any given delivery node. See ALTO.

    I think the focus is on what INFORMATION is needed.  Then we can focus on the right conduit to convey that information.  I suspect the issue is delineating between different types of "capabilities".  There are CDN capabilities (ability to deliver content using HSS or HLS) and there are network capabilities (ability to reach a given prefix and cost associated with that path).  Presumably, the CDN will collect BOTH sets of capabilities via various API / CDN-I and make the 'best' choice of delivery node.

    What information do we need from the network to make the best content routing decision in the uCDN?

    draft-he-cdni-cap-info-advertising-01
    draft-bertrand-cdni-footprint-discovery-00

Question: Do we delineate our work around NETWORK capabilities / footprint and CDN capabilities / footprint?

I see these as a disjoint set of information that the uCDN will need to assimilate and make a congruent assessment.  We don't want to assign a delivery node that is not capable of delivering the content even though it is closer.  Conversely, we may want to assign a delivery node that is topologically further away because of access costs.

Scott

On 3/14/12 8:29 AM, Stef van der Ziel wrote:
Re: [CDNi] New Version Notification fordraft-previdi-cdni-footprint-advertisement-01.txt

There are too many scenarios where a CDN does not rely on Internet routing.
Think of multiple CDNs within a private network, that have to interoperate.
A CDN may also have a different footprint than the network topology.
I think that it is too easy to assume that BGP could be the right protocol.
Proper APIs offer the same function, but with all the freedom that CDNs will need.

Best, Stef



On 14 mrt. 2012, at 12:25, stefano previdi wrote:

>
> On Mar 14, 2012, at 11:38 AM, Stef van der Ziel wrote:
>
>> Hi,
>>
>> It still looks like you're trying to lock CDNs into networking layer protocols and use protocols for which they were not intended.
>
>
> well, I don't think so. We use the same tool... but differently.
>
>
>> In most CDNs we deployed, BGP doesn't play any role. Not even in federated scenarios.
>
>
> yes, but at the end of the day, the CDN relies on internet routing so
> at some point there's a relationship between the CDN and the network
> layer.
>
> In our proposal we just leverage the reachability information you can
> get from your local SP/ISP so to figure out footprint information.
>
> Capabilities, I agree with you, is a different story but since we
> don't know yet what is a capability (and which format it should/must/may
> have) it's difficult to come with a proper scheme. Having said that, BGP
> (as a tool) has all feature you need so to propagate both FP and caps.
>
> s.
>
>
>
>> Better use proper APIs!
>>
>> Best, Stef
>>
>>
>> On 14 mrt. 2012, at 11:33, stefano previdi wrote:
>>
>>>
>>> On Mar 14, 2012, at 11:07 AM, Stef van der Ziel wrote:
>>>
>>>> Hi,
>>>>
>>>> I would not recommend using BGP for CDN capabilities sharing.
>>>> BGP is a networking layer protocol.
>>>
>>>
>>> not in the way we propose to use it in the CDNI context.
>>>
>>>
>>>> CDNs can and should run independently from the network, or span multiple networks. Or run within a part of a network, where BGP is not the right protocol.
>>>
>>>
>>> well, BGP is to be intended as MP-BGP with a scope of advertising
>>> footprint and capability information. In that respect the semantic
>>> is pretty clear. The fact that BGP is also used in other contexts
>>> such as network layer routing, MPLS-VPN, multicast, etc. doesn't
>>> preclude the use of the same technology into another context.
>>>
>>>
>>>> CDNs should not be locked into networks or become dependent on networking layered protocols.
>>>
>>>
>>> absolutely agree. As you can see from the proposal, we leverage
>>> what's available in the BGP databases as for footprint information.
>>> However, also described in the proposal, we allow complete freedom
>>> to any CDNI MP-BGP player to define its own policy and elements to
>>> advertise.
>>>
>>> s.
>>>
>>>
>>>> CDN interconnection should be done via APIs.
>>>>
>>>> Kind regards,
>>>>
>>>> Stef van der Ziel
>>>>
>>>>
>>>> On 12 mrt. 2012, at 15:28, Scott Wainner wrote:
>>>>
>>>>> I too am struggling with how 'capabilities' can be advertised effectively in BGP.  I'm inclined to delineate the 'footprint' from the 'capabilities'.
>>>>>
>>>>> Perhaps one approach is to indicate in the 'capabilities' the various METHODS for assessing the 'footprint'.  In the 'capabilities' exchange, the options for METHODS of determining 'footprint' might be BGP AFI or BGP Communities or IGP Distance.  Accordingly, a dCDN might indicate it has the capability of advertising (or allowing discovery of) different methods of 'footprint' advertisements and those methods might be weighted.
>>>>>
>>>>> I think the dCDN capabilities (e.g. delivery methods, security methods, etc.) will become far more complex than can be aggregated into a representative set of BGP communities.  Nevertheless, I do think BGP communities is a viable method of advertising a 'footprint' ... one that is well understood by the network operators.
>>>>>
>>>>> Scott Wainner
>>>>>
>>>>> On 3/9/12 6:50 AM, grant.watson@bt.com wrote:
>>>>>> Thanks, understood.
>>>>>>
>>>>>> Then my general feedback would be - I think working out what capability information needs to be shared between the CDNs would ideally be worked though prior to deciding the right way to do it. BGP doesn't feel like an obvious choice for exchanging the kind of CDN Capability information I'd envisage being passed between CDN. Has a discussion taken place as to why BGP over other methods? (e.g. API/metadata) There are drafts discussing metadata right now that propose ways of describing the capability requirements between CDN (e.g. "deliver this content using RMTP" etc.), why would we not also exchange capabilities over the same interface for example?
>>>>>>
>>>>>> It's easier to understand why it may be considered that BGP should/could be used for the exchange of network footprint information but less so for CDN Capabilities, IMHO. In some cases CDN may not want or need to implement footprint advertisement entirely (for example in a simple bi-lateral relationship the CDN operators could easily elect to exchange footprint information out-of-band), in this case they presumably wouldn't want to be dependent on BGP to exchange capability information.
>>>>>>
>>>>>> g-
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: stefano previdi [mailto:sprevidi@cisco.com]
>>>>>> Sent: 09 March 2012 10:44
>>>>>> To: Watson,G,Grant,DMK5 R
>>>>>> Cc: cdni@ietf.org
>>>>>> Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-01.txt
>>>>>>
>>>>>> Hi Grant,
>>>>>>
>>>>>> On Mar 8, 2012, at 11:17 PM, <grant.watson@bt.com> <grant.watson@bt.com> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> The document talks about "Capability Advertisements" and the proposal to use MP-BGP messages to advertise/exchange CDN capabilities. However, the document does not explicitly define what is ment by "CDN Capability".
>>>>>>
>>>>>>
>>>>>> indeed... and it is somehow intended...
>>>>>>
>>>>>> As JanS pointed out, there's another draft that should explicit the semantics of FP/Capabilities. In this proposal we           define the mechanism through which the capability information can be exchanged.
>>>>>>
>>>>>> Obviously, at some point, we'll have to synchronize.
>>>>>>
>>>>>>
>>>>>>> I understand "CDN Capability" to mean things like delivery technology (for example RTMP or HTTP etc.) or perhaps a specific form of content authorisation etc. Can you confirm I am correct in assuming this or if not clarify what the           correct meaning is.
>>>>>>
>>>>>>
>>>>>> My understanding goes in the same direction, so far.
>>>>>>
>>>>>> s.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> g-
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ________________________________________
>>>>>>> From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf Of
>>>>>>> stefano previdi [sprevidi@cisco.com]
>>>>>>> Sent: 08 March 2012 21:23
>>>>>>> To: cdni@ietf.org
>>>>>>> Subject: [CDNi] Fwd: New Version Notification for       draft-previdi-cdni-footprint-advertisement-01.txt
>>>>>>>
>>>>>>> Begin forwarded message:
>>>>>>>
>>>>>>>> From: internet-drafts@ietf.org
>>>>>>>> Subject: New Version Notification for
>>>>>>>> draft-previdi-cdni-footprint-advertisement-01.txt
>>>>>>>> Date: March 8, 2012 8:45:53 PM GMT+01:00
>>>>>>>> To: sprevidi@cisco.com
>>>>>>>> Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com
>>>>>>>>
>>>>>>>> A new version of I-D, draft-previdi-cdni-footprint-advertisement-01.txt has been successfully submitted by Stefano Previdi and posted to the IETF repository.
>>>>>>>>
>>>>>>>> Filename:      draft-previdi-cdni-footprint-advertisement
>>>>>>>> Revision:      01
>>>>>>>> Title:                 CDNI Footprint Advertisement
>>>>>>>> Creation date:         2012-03-08
>>>>>>>> WG ID:                 Individual Submission
>>>>>>>> Number of pages: 27
>>>>>>>>
>>>>>>>> Abstract:
>>>>>>>> This document describes the use of BGP for Content Delivery Networks
>>>>>>>> (CDNs) in order to advertise information about footprint and
>>>>>>>> connectivity to footprint in the context of CDNI.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> This draft is for the CDNI Working Group.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>> s.
>>>>>>>>
>>>>>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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


<ATT00001..txt>



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

--------------040503020901040609020103-- From flefauch@cisco.com Wed Mar 14 12:30:29 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 D2E0621F84DF for ; Wed, 14 Mar 2012 12:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.89 X-Spam-Level: X-Spam-Status: No, score=-9.89 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_61=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 HfuN5qPsLxgf for ; Wed, 14 Mar 2012 12:30:27 -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 F216521F84DC for ; Wed, 14 Mar 2012 12:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=40023; q=dns/txt; s=iport; t=1331753426; x=1332963026; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=FQhmdN4vfrK7/0/aD2N6t7e8GgRalL/gfOHZlJrAu18=; b=DbYI876vXzFzS2/CeIy2vPR1dkQOG51+KlYx2o6mi6LS3XoUmEc4UZvk D1gX7sR/V31iXq25y0T/nPxF4/GZDjTZ8QGDk3tITOVfB90aJtuenpsiA QZJUIsx7UYqHxb4P165ZtqFAASPuaUrq3aVLpaD5OgJbeV+UEx2TKhZEn 4=; X-IronPort-AV: E=Sophos;i="4.73,585,1325462400"; d="scan'208,217";a="132338169" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 14 Mar 2012 19:30:24 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2EJUMdR030410; Wed, 14 Mar 2012 19:30:22 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-442--888579163 From: Francois Le Faucheur In-Reply-To: <6854E730-8B93-447E-83A8-ED0DA7F99824@neustar.biz> Date: Wed, 14 Mar 2012 20:30:22 +0100 Message-Id: References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net><1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net><4F5E07FA.5090402@cisco.com><5826DF56-7335-49C6-997A-AAB109ED0913@jet-stream.com><2C86FE78-1178-447F-8CB4-5AEA63625679@jet-stream.com><86AF8FF6-4BF3-41D9-837F-21A392C87F83@cisco.com> <0CC6542D-0A0E-41FB-B960-6A3763469BC8@jet-stream.com> <4F60A188.7080205@cisco.com> <6854E730-8B93-447E-83A8-ED0DA7F99824@neustar.biz> To: "Peterson, Jon" X-Mailer: Apple Mail (2.1084) Cc: "cdni@ietf.org" Subject: Re: [CDNi] New Version Notification fordraft-previdi-cdni-footprint-advertisement-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, 14 Mar 2012 19:30:29 -0000 --Apple-Mail-442--888579163 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii (as an individual) On 14 Mar 2012, at 18:41, Peterson, Jon wrote: >=20 > We also need to decide how deeply we want a uCDN to understand a dCDNs = resources - effectively, we could have very low-level approaches where = uCDNs execute the entire request-routing algorithm down to selecting the = particular cache, or high-level approaches where the uCDN has only a = general sense of dCDN resources and defers cache selection to the dCDN. = Once we get some agreement about these points, deciding what type and = what granularity of information dCDNs should advertise will be a lot = easier. I believe this has been discussed and decided by the working group: =46rom draft-ietf-cdni-requirements-02: " GEN-4 [HIGH] The CDNI solution shall not require intra-CDN information to be exposed to other CDNs for effective and efficient delivery of the content. Examples of intra-CDN information include surrogate topology, surrogate status, cached content, etc. " I personally support that decision to focus the current/initial CDNI = work on "high-level approaches where the uCDN has only a general sense = of dCDN resources and defers cache selection to the dCDN". In the = future, once high level approaches are working we can look into "very = low-level approaches where the uCDNs execute the entire request-routing = algorithm down to selecting the particular cache" (if dCDNs are willing = to allow that). Cheers Francois >=20 > Jon Peterson > NeuStar, Inc. >=20 > On Mar 14, 2012, at 6:47 AM, Scott Wainner wrote: >=20 >>=20 >> A 'proper API' whether defined by CDN-I or not requires = information to be conveyed. That is the fundamental question in my = mind. What information needs to be conveyed THROUGH that API / = interface? >>=20 >> We've clearly identified that the 'footprint' of the CDN and the = network are not congruent. However, CDN will need to send packets = through the network to reach the client. The best proximity path = between any given delivery node and the client is defined by the network = topology. I can have two devices sitting side-by-side while they are = topologically connected in vastly different manners. We will certainly = need some NETWORK INFORMATION conveyed through the API to discern the = proximity of the client to any given delivery node. See ALTO. >>=20 >> I think the focus is on what INFORMATION is needed. Then we can = focus on the right conduit to convey that information. I suspect the = issue is delineating between different types of "capabilities". There = are CDN capabilities (ability to deliver content using HSS or HLS) and = there are network capabilities (ability to reach a given prefix and cost = associated with that path). Presumably, the CDN will collect BOTH sets = of capabilities via various API / CDN-I and make the 'best' choice of = delivery node. >>=20 >> What information do we need from the network to make the best = content routing decision in the uCDN? >>=20 >> draft-he-cdni-cap-info-advertising-01 >> draft-bertrand-cdni-footprint-discovery-00 >>=20 >> Question: Do we delineate our work around NETWORK capabilities / = footprint and CDN capabilities / footprint? >>=20 >> I see these as a disjoint set of information that the uCDN will need = to assimilate and make a congruent assessment. We don't want to assign = a delivery node that is not capable of delivering the content even = though it is closer. Conversely, we may want to assign a delivery node = that is topologically further away because of access costs. >>=20 >> Scott >>=20 >> On 3/14/12 8:29 AM, Stef van der Ziel wrote: >>>=20 >>> There are too many scenarios where a CDN does not rely on Internet = routing. >>> Think of multiple CDNs within a private network, that have to = interoperate. >>> A CDN may also have a different footprint than the network topology. >>> I think that it is too easy to assume that BGP could be the right = protocol. >>> Proper APIs offer the same function, but with all the freedom that = CDNs will need. >>>=20 >>> Best, Stef >>>=20 >>>=20 >>>=20 >>> On 14 mrt. 2012, at 12:25, stefano previdi wrote: >>>=20 >>> > >>> > On Mar 14, 2012, at 11:38 AM, Stef van der Ziel wrote: >>> > >>> >> Hi, >>> >> >>> >> It still looks like you're trying to lock CDNs into networking = layer protocols and use protocols for which they were not intended. >>> > >>> > >>> > well, I don't think so. We use the same tool... but differently. >>> > >>> > >>> >> In most CDNs we deployed, BGP doesn't play any role. Not even in = federated scenarios. >>> > >>> > >>> > yes, but at the end of the day, the CDN relies on internet routing = so >>> > at some point there's a relationship between the CDN and the = network >>> > layer. >>> > >>> > In our proposal we just leverage the reachability information you = can >>> > get from your local SP/ISP so to figure out footprint information. >>> > >>> > Capabilities, I agree with you, is a different story but since we >>> > don't know yet what is a capability (and which format it = should/must/may >>> > have) it's difficult to come with a proper scheme. Having said = that, BGP >>> > (as a tool) has all feature you need so to propagate both FP and = caps. >>> > >>> > s. >>> > >>> > >>> > >>> >> Better use proper APIs! >>> >> >>> >> Best, Stef >>> >> >>> >> >>> >> On 14 mrt. 2012, at 11:33, stefano previdi wrote: >>> >> >>> >>> >>> >>> On Mar 14, 2012, at 11:07 AM, Stef van der Ziel wrote: >>> >>> >>> >>>> Hi, >>> >>>> >>> >>>> I would not recommend using BGP for CDN capabilities sharing. >>> >>>> BGP is a networking layer protocol. >>> >>> >>> >>> >>> >>> not in the way we propose to use it in the CDNI context. >>> >>> >>> >>> >>> >>>> CDNs can and should run independently from the network, or span = multiple networks. Or run within a part of a network, where BGP is not = the right protocol. >>> >>> >>> >>> >>> >>> well, BGP is to be intended as MP-BGP with a scope of = advertising >>> >>> footprint and capability information. In that respect the = semantic >>> >>> is pretty clear. The fact that BGP is also used in other = contexts >>> >>> such as network layer routing, MPLS-VPN, multicast, etc. doesn't >>> >>> preclude the use of the same technology into another context. >>> >>> >>> >>> >>> >>>> CDNs should not be locked into networks or become dependent on = networking layered protocols. >>> >>> >>> >>> >>> >>> absolutely agree. As you can see from the proposal, we leverage >>> >>> what's available in the BGP databases as for footprint = information. >>> >>> However, also described in the proposal, we allow complete = freedom >>> >>> to any CDNI MP-BGP player to define its own policy and elements = to >>> >>> advertise. >>> >>> >>> >>> s. >>> >>> >>> >>> >>> >>>> CDN interconnection should be done via APIs. >>> >>>> >>> >>>> Kind regards, >>> >>>> >>> >>>> Stef van der Ziel >>> >>>> >>> >>>> >>> >>>> On 12 mrt. 2012, at 15:28, Scott Wainner wrote: >>> >>>> >>> >>>>> I too am struggling with how 'capabilities' can be advertised = effectively in BGP. I'm inclined to delineate the 'footprint' from the = 'capabilities'. >>> >>>>> >>> >>>>> Perhaps one approach is to indicate in the 'capabilities' the = various METHODS for assessing the 'footprint'. In the 'capabilities' = exchange, the options for METHODS of determining 'footprint' might be = BGP AFI or BGP Communities or IGP Distance. Accordingly, a dCDN might = indicate it has the capability of advertising (or allowing discovery of) = different methods of 'footprint' advertisements and those methods might = be weighted. >>> >>>>> >>> >>>>> I think the dCDN capabilities (e.g. delivery methods, security = methods, etc.) will become far more complex than can be aggregated into = a representative set of BGP communities. Nevertheless, I do think BGP = communities is a viable method of advertising a 'footprint' ... one that = is well understood by the network operators. >>> >>>>> >>> >>>>> Scott Wainner >>> >>>>> >>> >>>>> On 3/9/12 6:50 AM, grant.watson@bt.com wrote: >>> >>>>>> Thanks, understood. >>> >>>>>> >>> >>>>>> Then my general feedback would be - I think working out what = capability information needs to be shared between the CDNs would ideally = be worked though prior to deciding the right way to do it. BGP doesn't = feel like an obvious choice for exchanging the kind of CDN Capability = information I'd envisage being passed between CDN. Has a discussion = taken place as to why BGP over other methods? (e.g. API/metadata) There = are drafts discussing metadata right now that propose ways of describing = the capability requirements between CDN (e.g. "deliver this content = using RMTP" etc.), why would we not also exchange capabilities over the = same interface for example? >>> >>>>>> >>> >>>>>> It's easier to understand why it may be considered that BGP = should/could be used for the exchange of network footprint information = but less so for CDN Capabilities, IMHO. In some cases CDN may not want = or need to implement footprint advertisement entirely (for example in a = simple bi-lateral relationship the CDN operators could easily elect to = exchange footprint information out-of-band), in this case they = presumably wouldn't want to be dependent on BGP to exchange capability = information. >>> >>>>>> >>> >>>>>> g- >>> >>>>>> >>> >>>>>> >>> >>>>>> -----Original Message----- >>> >>>>>> From: stefano previdi [mailto:sprevidi@cisco.com] >>> >>>>>> Sent: 09 March 2012 10:44 >>> >>>>>> To: Watson,G,Grant,DMK5 R >>> >>>>>> Cc: cdni@ietf.org >>> >>>>>> Subject: Re: [CDNi] New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>> >>>>>> >>> >>>>>> Hi Grant, >>> >>>>>> >>> >>>>>> On Mar 8, 2012, at 11:17 PM, = wrote: >>> >>>>>>> >>> >>>>>>> Hi, >>> >>>>>>> >>> >>>>>>> The document talks about "Capability Advertisements" and the = proposal to use MP-BGP messages to advertise/exchange CDN capabilities. = However, the document does not explicitly define what is ment by "CDN = Capability". >>> >>>>>> >>> >>>>>> >>> >>>>>> indeed... and it is somehow intended... >>> >>>>>> >>> >>>>>> As JanS pointed out, there's another draft that should = explicit the semantics of FP/Capabilities. In this proposal we = define the mechanism through which the capability information can be = exchanged. >>> >>>>>> >>> >>>>>> Obviously, at some point, we'll have to synchronize. >>> >>>>>> >>> >>>>>> >>> >>>>>>> I understand "CDN Capability" to mean things like delivery = technology (for example RTMP or HTTP etc.) or perhaps a specific form of = content authorisation etc. Can you confirm I am correct in assuming this = or if not clarify what the correct meaning is. >>> >>>>>> >>> >>>>>> >>> >>>>>> My understanding goes in the same direction, so far. >>> >>>>>> >>> >>>>>> s. >>> >>>>>> >>> >>>>>> >>> >>>>>>> >>> >>>>>>> Cheers, >>> >>>>>>> >>> >>>>>>> g- >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> ________________________________________ >>> >>>>>>> From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On = Behalf Of >>> >>>>>>> stefano previdi [sprevidi@cisco.com] >>> >>>>>>> Sent: 08 March 2012 21:23 >>> >>>>>>> To: cdni@ietf.org >>> >>>>>>> Subject: [CDNi] Fwd: New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>> >>>>>>> >>> >>>>>>> Begin forwarded message: >>> >>>>>>> >>> >>>>>>>> From: internet-drafts@ietf.org >>> >>>>>>>> Subject: New Version Notification for >>> >>>>>>>> draft-previdi-cdni-footprint-advertisement-01.txt >>> >>>>>>>> Date: March 8, 2012 8:45:53 PM GMT+01:00 >>> >>>>>>>> To: sprevidi@cisco.com >>> >>>>>>>> Cc: allan.guillou@sfr.com, flefauch@cisco.com, = jmedved@cisco.com >>> >>>>>>>> >>> >>>>>>>> A new version of I-D, = draft-previdi-cdni-footprint-advertisement-01.txt has been successfully = submitted by Stefano Previdi and posted to the IETF repository. >>> >>>>>>>> >>> >>>>>>>> Filename: draft-previdi-cdni-footprint-advertisement >>> >>>>>>>> Revision: 01 >>> >>>>>>>> Title: CDNI Footprint Advertisement >>> >>>>>>>> Creation date: 2012-03-08 >>> >>>>>>>> WG ID: Individual Submission >>> >>>>>>>> Number of pages: 27 >>> >>>>>>>> >>> >>>>>>>> Abstract: >>> >>>>>>>> This document describes the use of BGP for Content Delivery = Networks >>> >>>>>>>> (CDNs) in order to advertise information about footprint = and >>> >>>>>>>> connectivity to footprint in the context of CDNI. >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> This draft is for the CDNI Working Group. >>> >>>>>>>> >>> >>>>>>>> Thanks. >>> >>>>>>>> s. >>> >>>>>>>> >>> >>>>>>>> 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 >>> >>>> >>> >>>> _______________________________________________ >>> >>>> 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 >>>=20 >>=20 >> >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --Apple-Mail-442--888579163 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii (as = an individual)

On 14 Mar 2012, at 18:41, Peterson, Jon = wrote:

We also need to = decide how deeply we want a uCDN to understand a dCDNs resources - = effectively, we could have very low-level approaches where uCDNs execute = the entire request-routing algorithm down to selecting the particular = cache, or high-level approaches where the uCDN has only a general sense = of dCDN resources and defers cache selection to the dCDN. Once we get = some agreement about these points, deciding what type and what = granularity of information dCDNs should advertise will be a lot = easier.

I believe this has = been discussed and decided by the working = group:

=46rom = draft-ietf-cdni-requirements-02:
"
  =  GEN-4   [HIGH] The CDNI solution shall not require = intra-CDN
           information = to be exposed to other CDNs for effective and
    =        efficient delivery of the content. =  Examples of intra-CDN
          =  information include surrogate topology, surrogate = status,
           cached = content, etc.
"

I personally = support that decision to focus the current/initial CDNI work on = "high-level approaches where the uCDN has only a general sense of dCDN = resources and defers cache selection to the dCDN". In the future, once = high level approaches are working we can look into "very low-level = approaches where the uCDNs execute the entire request-routing algorithm = down to selecting the particular cache" (if dCDNs are willing to allow = that).

Cheers

Francois



Jon Peterson
NeuStar, = Inc.

On Mar 14, 2012, at 6:47 AM, Scott Wainner = wrote:

=20 =20

    A 'proper API' whether defined by CDN-I or not = requires information to be conveyed.  That is the fundamental question = in my mind.  What information needs to be conveyed THROUGH that API / interface?

    We've clearly identified that the 'footprint' of = the CDN and the network are not congruent.  However, CDN will need to send = packets through the network to reach the client.  The best proximity = path between any given delivery node and the client is defined by the network topology.  I can have two devices sitting side-by-side = while they are topologically connected in vastly different manners.  = We will certainly need some NETWORK INFORMATION conveyed through the API to discern the proximity of the client to any given delivery node. See ALTO.

    I think the focus is on what INFORMATION is = needed.  Then we can focus on the right conduit to convey that information.  I = suspect the issue is delineating between different types of = "capabilities".  There are CDN capabilities (ability to deliver content using HSS or HLS) and there are network capabilities (ability to reach a given prefix and cost associated with that path).  Presumably, the = CDN will collect BOTH sets of capabilities via various API / CDN-I and make the 'best' choice of delivery node.

    What information do we need from the network to = make the best content routing decision in the uCDN?

    draft-he-cdni-cap-info-advertising-01
    draft-bertrand-cdni-footprint-discovery-00

Question: Do we delineate our work around NETWORK capabilities / footprint and CDN capabilities / footprint?

I see these as a disjoint set of information that the uCDN will need to assimilate and make a congruent assessment.  We don't want = to assign a delivery node that is not capable of delivering the content even though it is closer.  Conversely, we may want to assign a delivery node that is topologically further away because of access costs.

Scott

On 3/14/12 8:29 AM, Stef van der Ziel wrote:
Re: [CDNi] New Version Notification fordraft-previdi-cdni-footprint-advertisement-01.txt

There = are too many scenarios where a CDN does not rely on Internet routing.
Think of multiple CDNs within a private network, that have to interoperate.
A CDN may also have a different footprint than the network topology.
I think that it is too easy to assume that BGP could be the right protocol.
Proper APIs offer the same function, but with all the freedom that CDNs will need.

Best, Stef



On 14 mrt. 2012, at 12:25, stefano previdi wrote:

>
> On Mar 14, 2012, at 11:38 AM, Stef van der Ziel = wrote:
>
>> Hi,
>>
>> It still looks like you're trying to lock CDNs into networking layer protocols and use protocols for which they were not intended.
>
>
> well, I don't think so. We use the same tool... but differently.
>
>
>> In most CDNs we deployed, BGP doesn't play any role. Not even in federated scenarios.
>
>
> yes, but at the end of the day, the CDN relies on internet routing so
> at some point there's a relationship between the CDN and the network
> layer.
>
> In our proposal we just leverage the reachability information you can
> get from your local SP/ISP so to figure out footprint information.
>
> Capabilities, I agree with you, is a different story but since we
> don't know yet what is a capability (and which format it should/must/may
> have) it's difficult to come with a proper scheme. Having said that, BGP
> (as a tool) has all feature you need so to propagate both FP and caps.
>
> s.
>
>
>
>> Better use proper APIs!
>>
>> Best, Stef
>>
>>
>> On 14 mrt. 2012, at 11:33, stefano previdi wrote:
>>
>>>
>>> On Mar 14, 2012, at 11:07 AM, Stef van der Ziel wrote:
>>>
>>>> Hi,
>>>>
>>>> I would not recommend using BGP for CDN capabilities sharing.
>>>> BGP is a networking layer protocol.
>>>
>>>
>>> not in the way we propose to use it in the CDNI context.
>>>
>>>
>>>> CDNs can and should run independently from the network, or span multiple networks. Or run within a part of a network, where BGP is not the right protocol.
>>>
>>>
>>> well, BGP is to be intended as MP-BGP with a scope of advertising
>>> footprint and capability information. In that respect the semantic
>>> is pretty clear. The fact that BGP is also used in other contexts
>>> such as network layer routing, MPLS-VPN, multicast, etc. doesn't
>>> preclude the use of the same technology into another context.
>>>
>>>
>>>> CDNs should not be locked into networks or become dependent on networking layered protocols.
>>>
>>>
>>> absolutely agree. As you can see from the proposal, we leverage
>>> what's available in the BGP databases as for footprint information.
>>> However, also described in the proposal, we allow complete freedom
>>> to any CDNI MP-BGP player to define its own policy and elements to
>>> advertise.
>>>
>>> s.
>>>
>>>
>>>> CDN interconnection should be done via = APIs.
>>>>
>>>> Kind regards,
>>>>
>>>> Stef van der Ziel
>>>>
>>>>
>>>> On 12 mrt. 2012, at 15:28, Scott Wainner wrote:
>>>>
>>>>> I too am struggling with how 'capabilities' can be advertised effectively in BGP.  I'm inclined to delineate the 'footprint' from the = 'capabilities'.
>>>>>
>>>>> Perhaps one approach is to indicate in the 'capabilities' the various METHODS for assessing the 'footprint'.  In the 'capabilities' exchange, the options = for METHODS of determining 'footprint' might be BGP AFI or BGP Communities or IGP Distance.  Accordingly, a dCDN might indicate it has the capability of advertising (or allowing discovery of) different methods of 'footprint' advertisements and those methods might be weighted.
>>>>>
>>>>> I think the dCDN capabilities (e.g. delivery methods, security methods, etc.) will become far more complex than can be aggregated into a representative set of BGP communities.  Nevertheless, I do think BGP = communities is a viable method of advertising a 'footprint' ... one that is well understood by the network operators.
>>>>>
>>>>> Scott Wainner
>>>>>
>>>>> On 3/9/12 6:50 AM, grant.watson@bt.com wrote:
>>>>>> Thanks, understood.
>>>>>>
>>>>>> Then my general feedback would be - I think working out what capability information needs to be shared between the CDNs would ideally be worked though prior to deciding the right way to do it. BGP doesn't feel like an obvious choice for exchanging the kind of CDN Capability information I'd envisage being passed between CDN. Has a discussion taken place as to why BGP over other methods? (e.g. API/metadata) There are drafts discussing metadata right now that propose ways of describing the capability requirements between CDN (e.g. "deliver this content using RMTP" etc.), why would we not also exchange capabilities over the same interface for example?
>>>>>>
>>>>>> It's easier to understand why it may be considered that BGP should/could be used for the exchange of network footprint information but less so for CDN Capabilities, IMHO. In some cases CDN may not want or need to implement footprint advertisement entirely (for example in a simple bi-lateral relationship the CDN operators could easily elect to exchange footprint information out-of-band), in this case they presumably wouldn't want to be dependent on BGP to exchange capability information.
>>>>>>
>>>>>> g-
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: stefano previdi [mailto:sprevidi@cisco.com]
>>>>>> Sent: 09 March 2012 10:44
>>>>>> To: Watson,G,Grant,DMK5 R
>>>>>> Cc: cdni@ietf.org
>>>>>> Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-01.txt
>>>>>>
>>>>>> Hi Grant,
>>>>>>
>>>>>> On Mar 8, 2012, at 11:17 PM, <grant.watson@bt.com> <grant.watson@bt.com> = wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> The document talks about "Capability Advertisements" and the proposal to use MP-BGP messages to advertise/exchange CDN capabilities. However, the document does not explicitly define what is ment by "CDN Capability".
>>>>>>
>>>>>>
>>>>>> indeed... and it is somehow intended...
>>>>>>
>>>>>> As JanS pointed out, there's another draft that should explicit the semantics of FP/Capabilities. In this proposal = we           define = the mechanism through which the capability information can be exchanged.
>>>>>>
>>>>>> Obviously, at some point, we'll have to synchronize.
>>>>>>
>>>>>>
>>>>>>> I understand "CDN Capability" to mean things like delivery technology (for example RTMP or HTTP etc.) or perhaps a specific form of content authorisation etc. Can you confirm I am correct in assuming this or if not clarify what = the           correct = meaning is.
>>>>>>
>>>>>>
>>>>>> My understanding goes in the same direction, so far.
>>>>>>
>>>>>> s.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> g-
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ________________________________________
>>>>>>> From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On = Behalf Of
>>>>>>> stefano previdi [sprevidi@cisco.com]
>>>>>>> Sent: 08 March 2012 21:23
>>>>>>> To: cdni@ietf.org
>>>>>>> Subject: [CDNi] Fwd: New Version Notification for       draft-previdi-cdni-footprint-advertisement-01.txt
>>>>>>>
>>>>>>> Begin forwarded message:
>>>>>>>
>>>>>>>> From: internet-drafts@ietf.org
>>>>>>>> Subject: New Version Notification for
>>>>>>>> draft-previdi-cdni-footprint-advertisement-01.txt
>>>>>>>> Date: March 8, 2012 8:45:53 PM GMT+01:00
>>>>>>>> To: sprevidi@cisco.com
>>>>>>>> Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com
>>>>>>>>
>>>>>>>> A new version of I-D, draft-previdi-cdni-footprint-advertisement-01.txt has been successfully submitted by Stefano Previdi and posted to the IETF repository.
>>>>>>>>
>>>>>>>> = Filename:      draft-previdi-cdni-footprint-advertisement
>>>>>>>> = Revision:      01
>>>>>>>> = Title:           &n= bsp;     CDNI Footprint Advertisement
>>>>>>>> Creation = date:         2012-03-08
>>>>>>>> WG = ID:            = ;     Individual Submission
>>>>>>>> Number of pages: 27
>>>>>>>>
>>>>>>>> Abstract:
>>>>>>>> This document describes the use of BGP for Content Delivery Networks
>>>>>>>> (CDNs) in order to advertise information about footprint and
>>>>>>>> connectivity to footprint in the context of CDNI.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> This draft is for the CDNI Working Group.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>> s.
>>>>>>>>
>>>>>>>> The IETF Secretariat
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> CDNi mailing list
>>>>>>> CDNi@ietf.org
>>>>>>> https://www.ietf.org/m= ailman/listinfo/cdni
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> CDNi mailing list
>>>>>> CDNi@ietf.org
>>>>>> https://www.ietf.org/m= ailman/listinfo/cdni
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> CDNi mailing list
>>>>> CDNi@ietf.org
>>>>> https://www.ietf.org/m= ailman/listinfo/cdni
>>>>
>>>> _______________________________________________
>>>> CDNi mailing list
>>>> CDNi@ietf.org
>>>> https://www.ietf.org/m= ailman/listinfo/cdni
>>>
>>>
>>
>> _______________________________________________
>> CDNi mailing list
>> CDNi@ietf.org
>> https://www.ietf.org/m= ailman/listinfo/cdni
>>
>
>

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/m= ailman/listinfo/cdni


= <ATT00001..txt>

___________= ____________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/ma= ilman/listinfo/cdni

= --Apple-Mail-442--888579163-- From jon.peterson@neustar.biz Wed Mar 14 12:40: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 83B0E21F85D3 for ; Wed, 14 Mar 2012 12:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.983 X-Spam-Level: X-Spam-Status: No, score=-105.983 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, 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 yPwPlbIDTQmw for ; Wed, 14 Mar 2012 12:40:48 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id BA18321F85B9 for ; Wed, 14 Mar 2012 12:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1331754085; x=1647113842; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=z+0OBMkhqLfUadyp0FA0lFrdNUj5ozpUDyLMe5r60N0=; b=cBC0ZTpgrRSVTWER22G706SuIoKcVqPgjjl2gbSuHwbMDeFGRlNp99PcpZsHMH A27uVaZVz1BAKV8oGReKmpTw== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.6309712; Wed, 14 Mar 2012 15:41:24 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Wed, 14 Mar 2012 15:40:44 -0400 From: "Peterson, Jon" To: Francois Le Faucheur Date: Wed, 14 Mar 2012 15:40:39 -0400 Thread-Topic: [CDNi] New Version Notification fordraft-previdi-cdni-footprint-advertisement-01.txt Thread-Index: Ac0CGli/wlHT2CHfRe2Ef0JmRUAnUg== Message-ID: <7FF9D145-5D9B-4C99-8433-07D340BFA62A@neustar.biz> References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net><1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net><4F5E07FA.5090402@cisco.com><5826DF56-7335-49C6-997A-AAB109ED0913@jet-stream.com><2C86FE78-1178-447F-8CB4-5AEA63625679@jet-stream.com><86AF8FF6-4BF3-41D9-837F-21A392C87F83@cisco.com> <0CC6542D-0A0E-41FB-B960-6A3763469BC8@jet-stream.com> <4F60A188.7080205@cisco.com> <6854E730-8B93-447E-83A8-ED0DA7F99824@neustar.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 8YLL2mIlXxzCEl4vRLQY5Q== Content-Type: multipart/alternative; boundary="_000_7FF9D1455D9B4C99843307D340BFA62Aneustarbiz_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] New Version Notification fordraft-previdi-cdni-footprint-advertisement-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, 14 Mar 2012 19:40:50 -0000 --_000_7FF9D1455D9B4C99843307D340BFA62Aneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable While I think I agree with you about the general strategy we should take, j= udging from the drafts submitted for this IETF and the discussion on the li= st, I would be less confident about saying there is working group consensus= behind it. I think people are still all over the map on this. In part that= 's because there's a pretty slippery slope between the high-level and the l= ow-level, and the words in the requirement GEN-4 that you site - words like= "surrogate topology, surrogate status" - are not precise terms. When we st= art actually trying to define the semantics, be it in terms of geography, t= opology, reachability, cache enumeration, what have you, that's when we sta= rt to see what people are reading into this words. I think today people are= still reading some pretty different things into them. Jon Peterson NeuStar, Inc. On Mar 14, 2012, at 12:30 PM, Francois Le Faucheur wrote: (as an individual) On 14 Mar 2012, at 18:41, Peterson, Jon wrote: We also need to decide how deeply we want a uCDN to understand a dCDNs reso= urces - effectively, we could have very low-level approaches where uCDNs ex= ecute the entire request-routing algorithm down to selecting the particular= cache, or high-level approaches where the uCDN has only a general sense of= dCDN resources and defers cache selection to the dCDN. Once we get some ag= reement about these points, deciding what type and what granularity of info= rmation dCDNs should advertise will be a lot easier. I believe this has been discussed and decided by the working group: >From draft-ietf-cdni-requirements-02: " GEN-4 [HIGH] The CDNI solution shall not require intra-CDN information to be exposed to other CDNs for effective and efficient delivery of the content. Examples of intra-CDN information include surrogate topology, surrogate status, cached content, etc. " I personally support that decision to focus the current/initial CDNI work o= n "high-level approaches where the uCDN has only a general sense of dCDN re= sources and defers cache selection to the dCDN". In the future, once high l= evel approaches are working we can look into "very low-level approaches whe= re the uCDNs execute the entire request-routing algorithm down to selecting= the particular cache" (if dCDNs are willing to allow that). Cheers Francois Jon Peterson NeuStar, Inc. On Mar 14, 2012, at 6:47 AM, Scott Wainner wrote: A 'proper API' whether defined by CDN-I or not requires information to = be conveyed. That is the fundamental question in my mind. What informatio= n needs to be conveyed THROUGH that API / interface? We've clearly identified that the 'footprint' of the CDN and the networ= k are not congruent. However, CDN will need to send packets through the ne= twork to reach the client. The best proximity path between any given deliv= ery node and the client is defined by the network topology. I can have two= devices sitting side-by-side while they are topologically connected in vas= tly different manners. We will certainly need some NETWORK INFORMATION con= veyed through the API to discern the proximity of the client to any given d= elivery node. See ALTO. I think the focus is on what INFORMATION is needed. Then we can focus = on the right conduit to convey that information. I suspect the issue is de= lineating between different types of "capabilities". There are CDN capabil= ities (ability to deliver content using HSS or HLS) and there are network c= apabilities (ability to reach a given prefix and cost associated with that = path). Presumably, the CDN will collect BOTH sets of capabilities via vari= ous API / CDN-I and make the 'best' choice of delivery node. What information do we need from the network to make the best content r= outing decision in the uCDN? draft-he-cdni-cap-info-advertising-01 draft-bertrand-cdni-footprint-discovery-00 Question: Do we delineate our work around NETWORK capabilities / footprint = and CDN capabilities / footprint? I see these as a disjoint set of information that the uCDN will need to ass= imilate and make a congruent assessment. We don't want to assign a deliver= y node that is not capable of delivering the content even though it is clos= er. Conversely, we may want to assign a delivery node that is topologicall= y further away because of access costs. Scott On 3/14/12 8:29 AM, Stef van der Ziel wrote: There are too many scenarios where a CDN does not rely on Internet routing. Think of multiple CDNs within a private network, that have to interoperate. A CDN may also have a different footprint than the network topology. I think that it is too easy to assume that BGP could be the right protocol. Proper APIs offer the same function, but with all the freedom that CDNs wil= l need. Best, Stef On 14 mrt. 2012, at 12:25, stefano previdi wrote: > > On Mar 14, 2012, at 11:38 AM, Stef van der Ziel wrote: > >> Hi, >> >> It still looks like you're trying to lock CDNs into networking layer pro= tocols and use protocols for which they were not intended. > > > well, I don't think so. We use the same tool... but differently. > > >> In most CDNs we deployed, BGP doesn't play any role. Not even in federat= ed scenarios. > > > yes, but at the end of the day, the CDN relies on internet routing so > at some point there's a relationship between the CDN and the network > layer. > > In our proposal we just leverage the reachability information you can > get from your local SP/ISP so to figure out footprint information. > > Capabilities, I agree with you, is a different story but since we > don't know yet what is a capability (and which format it should/must/may > have) it's difficult to come with a proper scheme. Having said that, BGP > (as a tool) has all feature you need so to propagate both FP and caps. > > s. > > > >> Better use proper APIs! >> >> Best, Stef >> >> >> On 14 mrt. 2012, at 11:33, stefano previdi wrote: >> >>> >>> On Mar 14, 2012, at 11:07 AM, Stef van der Ziel wrote: >>> >>>> Hi, >>>> >>>> I would not recommend using BGP for CDN capabilities sharing. >>>> BGP is a networking layer protocol. >>> >>> >>> not in the way we propose to use it in the CDNI context. >>> >>> >>>> CDNs can and should run independently from the network, or span multip= le networks. Or run within a part of a network, where BGP is not the right = protocol. >>> >>> >>> well, BGP is to be intended as MP-BGP with a scope of advertising >>> footprint and capability information. In that respect the semantic >>> is pretty clear. The fact that BGP is also used in other contexts >>> such as network layer routing, MPLS-VPN, multicast, etc. doesn't >>> preclude the use of the same technology into another context. >>> >>> >>>> CDNs should not be locked into networks or become dependent on network= ing layered protocols. >>> >>> >>> absolutely agree. As you can see from the proposal, we leverage >>> what's available in the BGP databases as for footprint information. >>> However, also described in the proposal, we allow complete freedom >>> to any CDNI MP-BGP player to define its own policy and elements to >>> advertise. >>> >>> s. >>> >>> >>>> CDN interconnection should be done via APIs. >>>> >>>> Kind regards, >>>> >>>> Stef van der Ziel >>>> >>>> >>>> On 12 mrt. 2012, at 15:28, Scott Wainner wrote: >>>> >>>>> I too am struggling with how 'capabilities' can be advertised effecti= vely in BGP. I'm inclined to delineate the 'footprint' from the 'capabilit= ies'. >>>>> >>>>> Perhaps one approach is to indicate in the 'capabilities' the various= METHODS for assessing the 'footprint'. In the 'capabilities' exchange, th= e options for METHODS of determining 'footprint' might be BGP AFI or BGP Co= mmunities or IGP Distance. Accordingly, a dCDN might indicate it has the c= apability of advertising (or allowing discovery of) different methods of 'f= ootprint' advertisements and those methods might be weighted. >>>>> >>>>> I think the dCDN capabilities (e.g. delivery methods, security method= s, etc.) will become far more complex than can be aggregated into a represe= ntative set of BGP communities. Nevertheless, I do think BGP communities i= s a viable method of advertising a 'footprint' ... one that is well underst= ood by the network operators. >>>>> >>>>> Scott Wainner >>>>> >>>>> On 3/9/12 6:50 AM, grant.watson@bt.com wr= ote: >>>>>> Thanks, understood. >>>>>> >>>>>> Then my general feedback would be - I think working out what capabil= ity information needs to be shared between the CDNs would ideally be worked= though prior to deciding the right way to do it. BGP doesn't feel like an = obvious choice for exchanging the kind of CDN Capability information I'd en= visage being passed between CDN. Has a discussion taken place as to why BGP= over other methods? (e.g. API/metadata) There are drafts discussing metada= ta right now that propose ways of describing the capability requirements be= tween CDN (e.g. "deliver this content using RMTP" etc.), why would we not a= lso exchange capabilities over the same interface for example? >>>>>> >>>>>> It's easier to understand why it may be considered that BGP should/c= ould be used for the exchange of network footprint information but less so = for CDN Capabilities, IMHO. In some cases CDN may not want or need to imple= ment footprint advertisement entirely (for example in a simple bi-lateral r= elationship the CDN operators could easily elect to exchange footprint info= rmation out-of-band), in this case they presumably wouldn't want to be depe= ndent on BGP to exchange capability information. >>>>>> >>>>>> g- >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: stefano previdi [mailto:sprevidi@cisco.com] >>>>>> Sent: 09 March 2012 10:44 >>>>>> To: Watson,G,Grant,DMK5 R >>>>>> Cc: cdni@ietf.org >>>>>> Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-= footprint-advertisement-01.txt >>>>>> >>>>>> Hi Grant, >>>>>> >>>>>> On Mar 8, 2012, at 11:17 PM, wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> The document talks about "Capability Advertisements" and the propos= al to use MP-BGP messages to advertise/exchange CDN capabilities. However, = the document does not explicitly define what is ment by "CDN Capability". >>>>>> >>>>>> >>>>>> indeed... and it is somehow intended... >>>>>> >>>>>> As JanS pointed out, there's another draft that should explicit the = semantics of FP/Capabilities. In this proposal we define the mech= anism through which the capability information can be exchanged. >>>>>> >>>>>> Obviously, at some point, we'll have to synchronize. >>>>>> >>>>>> >>>>>>> I understand "CDN Capability" to mean things like delivery technolo= gy (for example RTMP or HTTP etc.) or perhaps a specific form of content au= thorisation etc. Can you confirm I am correct in assuming this or if not cl= arify what the correct meaning is. >>>>>> >>>>>> >>>>>> My understanding goes in the same direction, so far. >>>>>> >>>>>> s. >>>>>> >>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> g- >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: cdni-bounces@ietf.org [cdni-bou= nces@ietf.org] On Behalf Of >>>>>>> stefano previdi [sprevidi@cisco.com] >>>>>>> Sent: 08 March 2012 21:23 >>>>>>> To: cdni@ietf.org >>>>>>> Subject: [CDNi] Fwd: New Version Notification for draft-previ= di-cdni-footprint-advertisement-01.txt >>>>>>> >>>>>>> Begin forwarded message: >>>>>>> >>>>>>>> From: internet-drafts@ietf.org >>>>>>>> Subject: New Version Notification for >>>>>>>> draft-previdi-cdni-footprint-advertisement-01.txt >>>>>>>> Date: March 8, 2012 8:45:53 PM GMT+01:00 >>>>>>>> To: sprevidi@cisco.com >>>>>>>> Cc: allan.guillou@sfr.com, flefauch@= cisco.com, jmedved@cisco.com >>>>>>>> >>>>>>>> A new version of I-D, draft-previdi-cdni-footprint-advertisement-0= 1.txt has been successfully submitted by Stefano Previdi and posted to the = IETF repository. >>>>>>>> >>>>>>>> Filename: draft-previdi-cdni-footprint-advertisement >>>>>>>> Revision: 01 >>>>>>>> Title: CDNI Footprint Advertisement >>>>>>>> Creation date: 2012-03-08 >>>>>>>> WG ID: Individual Submission >>>>>>>> Number of pages: 27 >>>>>>>> >>>>>>>> Abstract: >>>>>>>> This document describes the use of BGP for Content Delivery Networ= ks >>>>>>>> (CDNs) in order to advertise information about footprint and >>>>>>>> connectivity to footprint in the context of CDNI. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This draft is for the CDNI Working Group. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> s. >>>>>>>> >>>>>>>> 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 >>>> >>>> _______________________________________________ >>>> 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 --_000_7FF9D1455D9B4C99843307D340BFA62Aneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

While I thi= nk I agree with you about the general strategy we should take, judging from= the drafts submitted for this IETF and the discussion on the list, I would= be less confident about saying there is working group consensus behind it.= I think people are still all over the map on this. In part that's because = there's a pretty slippery slope between the high-level and the low-level, a= nd the words in the requirement GEN-4 that you site - words like "surrogate= topology, surrogate status" - are not precise terms. When we start actuall= y trying to define the semantics, be it in terms of geography, topology, re= achability, cache enumeration, what have you, that's when we start to see w= hat people are reading into this words. I think today people are still read= ing some pretty different things into them.

Jon Peterson=
NeuStar, Inc.

On Mar 14, 2012, = at 12:30 PM, Francois Le Faucheur wrote:

(as an in= dividual)

On 14 Mar 2012, at 18:41, Peterson, Jon wrote:<= /div>

We also need to decide how deep= ly we want a uCDN to understand a dCDNs resources - effectively, we could h= ave very low-level approaches where uCDNs execute the entire request-routin= g algorithm down to selecting the particular cache, or high-level approache= s where the uCDN has only a general sense of dCDN resources and defers cach= e selection to the dCDN. Once we get some agreement about these points, dec= iding what type and what granularity of information dCDNs should advertise = will be a lot easier.

I believe= this has been discussed and decided by the working group:

From draft-ietf-cdni-requirements-02:
"
&= nbsp;  GEN-4   [HIGH] The CDNI solution shall not require intra-C= DN
           information to be exp= osed to other CDNs for effective and
        =    efficient delivery of the content.  Examples of intra-CDN=
           information include sur= rogate topology, surrogate status,
        &n= bsp;  cached content, etc.
"

= I personally support that decision to focus the current/initial CDNI work o= n "high-level approaches where the uCDN has only a general sense of dCDN re= sources and defers cache selection to the dCDN". In the future, once high l= evel approaches are working we can look into "very low-level approaches whe= re the uCDNs execute the entire request-routing algorithm down to selecting= the particular cache" (if dCDNs are willing to allow that).

=
Cheers

Francois


Jon Peterson
NeuStar, Inc.

On Mar 14, 2012, a= t 6:47 AM, Scott Wainner wrote:

=20 =20

    A 'proper API' whether defined by CDN-I or not requi= res information to be conveyed.  That is the fundamental question in m= y mind.  What information needs to be conveyed THROUGH that API / interface?

    We've clearly identified that the 'footprint' of the= CDN and the network are not congruent.  However, CDN will need to send packets through the network to reach the client.  The best proximity path between any given delivery node and the client is defined by the network topology.  I can have two devices sitting side-by-side whi= le they are topologically connected in vastly different manners.  We will certainly need some NETWORK INFORMATION conveyed through the API to discern the proximity of the client to any given delivery node. See ALTO.

    I think the focus is on what INFORMATION is needed.&= nbsp; Then we can focus on the right conduit to convey that information.  I suspect the issue is delineating between different types of "capabilities".&nbs= p; There are CDN capabilities (ability to deliver content using HSS or HLS) and there are network capabilities (ability to reach a given prefix and cost associated with that path).  Presumably, the CDN will collect BOTH sets of capabilities via various API / CDN-I and make the 'best' choice of delivery node.

    What information do we need from the network to make= the best content routing decision in the uCDN?

    draft-he-cdni-cap-info-advertising-01
    draft-bertrand-cdni-footprint-discovery-00

Question: Do we delineate our work around NETWORK capabilities / footprint and CDN capabilities / footprint?

I see these as a disjoint set of information that the uCDN will need to assimilate and make a congruent assessment.  We don't want to assign a delivery node that is not capable of delivering the content even though it is closer.  Conversely, we may want to assign a delivery node that is topologically further away because of access costs.

Scott

On 3/14/12 8:29 AM, Stef van der Ziel wrote:
Re: [CDNi] New Version Notification fordraft-previdi-cdni-footprint-advertisement-01.txt

There ar= e too many scenarios where a CDN does not rely on Internet routing.
Think of multiple CDNs within a private network, that have to interoperate.
A CDN may also have a different footprint than the network topology.
I think that it is too easy to assume that BGP could be the right protocol.
Proper APIs offer the same function, but with all the freedom that CDNs will need.

Best, Stef



On 14 mrt. 2012, at 12:25, stefano previdi wrote:

>
> On Mar 14, 2012, at 11:38 AM, Stef van der Ziel wrote:
>
>> Hi,
>>
>> It still looks like you're trying to lock CDNs into networking layer protocols and use protocols for which they were not intended.
>
>
> well, I don't think so. We use the same tool... but differently.
>
>
>> In most CDNs we deployed, BGP doesn't play any role. Not even in federated scenarios.
>
>
> yes, but at the end of the day, the CDN relies on internet routing so
> at some point there's a relationship between the CDN and the network
> layer.
>
> In our proposal we just leverage the reachability information you can
> get from your local SP/ISP so to figure out footprint information.
>
> Capabilities, I agree with you, is a different story but since we
> don't know yet what is a capability (and which format it should/must/may
> have) it's difficult to come with a proper scheme. Having said that, BGP
> (as a tool) has all feature you need so to propagate both FP and caps.
>
> s.
>
>
>
>> Better use proper APIs!
>>
>> Best, Stef
>>
>>
>> On 14 mrt. 2012, at 11:33, stefano previdi wrote:
>>
>>>
>>> On Mar 14, 2012, at 11:07 AM, Stef van der Ziel wrote:
>>>
>>>> Hi,
>>>>
>>>> I would not recommend using BGP for CDN capabilities sharing.
>>>> BGP is a networking layer protocol.
>>>
>>>
>>> not in the way we propose to use it in the CDNI context.
>>>
>>>
>>>> CDNs can and should run independently from the network, or span multiple networks. Or run within a part of a network, where BGP is not the right protocol.
>>>
>>>
>>> well, BGP is to be intended as MP-BGP with a scope of advertising
>>> footprint and capability information. In that respect the semantic
>>> is pretty clear. The fact that BGP is also used in other contexts
>>> such as network layer routing, MPLS-VPN, multicast, etc. doesn't
>>> preclude the use of the same technology into another context.
>>>
>>>
>>>> CDNs should not be locked into networks or become dependent on networking layered protocols.
>>>
>>>
>>> absolutely agree. As you can see from the proposal, we leverage
>>> what's available in the BGP databases as for footprint information.
>>> However, also described in the proposal, we allow complete freedom
>>> to any CDNI MP-BGP player to define its own policy and elements to
>>> advertise.
>>>
>>> s.
>>>
>>>
>>>> CDN interconnection should be done via APIs.
>>>>
>>>> Kind regards,
>>>>
>>>> Stef van der Ziel
>>>>
>>>>
>>>> On 12 mrt. 2012, at 15:28, Scott Wainner wrote:
>>>>
>>>>> I too am struggling with how 'capabilities' can be advertised effectively in BGP.  I'm inclined to delineate the 'footprint' from the 'capabilities'. >>>>>
>>>>> Perhaps one approach is to indicate in the 'capabilities' the various METHODS for assessing the 'footprint'.  In the 'capabilities' exchange, the options fo= r METHODS of determining 'footprint' might be BGP AFI or BGP Communities or IGP Distance.  Accordingly, a dCDN might indicate it has the capability of advertising (or allowing discovery of) different methods of 'footprint' advertisements and those methods might be weighted.
>>>>>
>>>>> I think the dCDN capabilities (e.g. delivery methods, security methods, etc.) will become far more complex than can be aggregated into a representative set of BGP communities.  Nevertheless, I do think BGP communities i= s a viable method of advertising a 'footprint' ... one that is well understood by the network operators.
>>>>>
>>>>> Scott Wainner
>>>>>
>>>>> On 3/9/12 6:50 AM, grant.watson@bt.com wrote:
>>>>>> Thanks, understood.
>>>>>>
>>>>>> Then my general feedback would be - I think working out what capability information needs to be shared between the CDNs would ideally be worked though prior to deciding the right way to do it. BGP doesn't feel like an obvious choice for exchanging the kind of CDN Capability information I'd envisage being passed between CDN. Has a discussion taken place as to why BGP over other methods? (e.g. API/metadata) There are drafts discussing metadata right now that propose ways of describing the capability requirements between CDN (e.g. "deliver this content using RMTP" etc.), why would we not also exchange capabilities over the same interface for example?
>>>>>>
>>>>>> It's easier to understand why it may be considered that BGP should/could be used for the exchange of network footprint information but less so for CDN Capabilities, IMHO. In some cases CDN may not want or need to implement footprint advertisement entirely (for example in a simple bi-lateral relationship the CDN operators could easily elect to exchange footprint information out-of-band), in this case they presumably wouldn't want to be dependent on BGP to exchange capability information.
>>>>>>
>>>>>> g-
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: stefano previdi [mailto:sprevidi@cisco.com= ]
>>>>>> Sent: 09 March 2012 10:44
>>>>>> To: Watson,G,Grant,DMK5 R
>>>>>> Cc: cdni@ietf.org
>>>>>> Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-01.txt
>>>>>>
>>>>>> Hi Grant,
>>>>>>
>>>>>> On Mar 8, 2012, at 11:17 PM, <grant.watson@bt.com> <grant.watson@bt.com> wrote: >>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> The document talks about "Capability Advertisements" and the proposal to use MP-BGP messages to advertise/exchange CDN capabilities. However, the document does not explicitly define what is ment by "CDN Capability".
>>>>>>
>>>>>>
>>>>>> indeed... and it is somehow intended...
>>>>>>
>>>>>> As JanS pointed out, there's another draft that should explicit the semantics of FP/Capabilities. In this proposal we       &nbs= p;   define the mechanism through which the capability information can be exchanged.
>>>>>>
>>>>>> Obviously, at some point, we'll have to synchronize.
>>>>>>
>>>>>>
>>>>>>> I understand "CDN Capability" to mean things like delivery technology (for example RTMP or HTTP etc.) or perhaps a specific form of content authorisation etc. Can you confirm I am correct in assuming this or if not clarify what the        &= nbsp;  correct meaning is.
>>>>>>
>>>>>>
>>>>>> My understanding goes in the same direction, so far.
>>>>>>
>>>>>> s.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> g-
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ________________________________________
>>>>>>> From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On Behalf Of
>>>>>>> stefano previdi [sprevidi@cisco.com]
>>>>>>> Sent: 08 March 2012 21:23
>>>>>>> To: cdni@ietf.org
>>>>>>> Subject: [CDNi] Fwd: New Version Notification for       draft-previdi-cdni-footprint-advertisement-01.txt
>>>>>>>
>>>>>>> Begin forwarded message:
>>>>>>>
>>>>>>>> From: internet-drafts@ietf.org
>>>>>>>> Subject: New Version Notification for
>>>>>>>> draft-previdi-cdni-footprint-advertisement-01.txt
>>>>>>>> Date: March 8, 2012 8:45:53 PM GMT+01:00
>>>>>>>> To: sprevidi@cisco.com
>>>>>>>> Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com
>>>>>>>>
>>>>>>>> A new version of I-D, draft-previdi-cdni-footprint-advertisement-01.txt has been successfully submitted by Stefano Previdi and posted to the IETF repository.
>>>>>>>>
>>>>>>>> Filename:    = ;  draft-previdi-cdni-footprint-advertisement
>>>>>>>> Revision:    = ;  01
>>>>>>>> Title:    &n= bsp;            CDNI Footprint Advertisement
>>>>>>>> Creation date:   =       2012-03-08
>>>>>>>> WG ID:    &n= bsp;            Individual Submission
>>>>>>>> Number of pages: 27
>>>>>>>>
>>>>>>>> Abstract:
>>>>>>>> This document describes the use of BGP for Content Delivery Networks
>>>>>>>> (CDNs) in order to advertise information about footprint and
>>>>>>>> connectivity to footprint in the context of CDNI.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> This draft is for the CDNI Working Group.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>> s.
>>>>>>>>
>>>>>>>> The IETF Secretariat
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> CDNi mailing list
>>>>>>> CDNi@ietf.org
>>>>>>> https://www.ietf.org/mailman/li= stinfo/cdni
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> CDNi mailing list
>>>>>> CDNi@ietf.org
>>>>>> https://www.ietf.org/mailman/listin= fo/cdni
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> CDNi mailing list
>>>>> CDNi@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/c= dni
>>>>
>>>> _______________________________________________
>>>> CDNi mailing list
>>>> CDNi@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/cdni<= /a>
>>>
>>>
>>
>> _______________________________________________
>> 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


<ATT00001..txt>

____________= ___________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni


= --_000_7FF9D1455D9B4C99843307D340BFA62Aneustarbiz_-- From flefauch@cisco.com Wed Mar 14 13:11: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 5732C21E800E for ; Wed, 14 Mar 2012 13:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.893 X-Spam-Level: X-Spam-Status: No, score=-9.893 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_61=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 1LSfO8JFfxzz for ; Wed, 14 Mar 2012 13:11: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 E447221E8010 for ; Wed, 14 Mar 2012 13:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=45308; q=dns/txt; s=iport; t=1331755886; x=1332965486; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=M+Qld4w6eSSSh1d5Odr0XT9UVuGUBkykvEcfvXOkmKo=; b=LfawvnGDsyZEpgPC5TKACpbkAhtBrGJJhNT36ObKGIg+H1GmFAQqCRLa dFTQyNDkFcva4R6NBxNW6CaDn3Q56Fvp77vZ5lZMD+SM6aTLMVH6JHkVP h+tA3JeLOnCA5dYiLQce++cUOM1GZtW6mR8QursOyc1G0m1ZmEtw5QNVp 0=; X-IronPort-AV: E=Sophos;i="4.73,586,1325462400"; d="scan'208,217";a="132341636" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 14 Mar 2012 20:11:24 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2EKBMrY007314; Wed, 14 Mar 2012 20:11:22 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-467--886120098 From: Francois Le Faucheur In-Reply-To: <7FF9D145-5D9B-4C99-8433-07D340BFA62A@neustar.biz> Date: Wed, 14 Mar 2012 21:11:21 +0100 Message-Id: References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net><1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net><4F5E07FA.5090402@cisco.com><5826DF56-7335-49C6-997A-AAB109ED0913@jet-stream.com><2C86FE78-1178-447F-8CB4-5AEA63625679@jet-stream.com><86AF8FF6-4BF3-41D9-837F-21A392C87F83@cisco.com> <0CC6542D-0A0E-41FB-B960-6A3763469BC8@jet-stream.com> <4F60A188.7080205@cisco.com> <6854E730-8B93-447E-83A8-ED0DA7F99824@neustar.biz> <7FF9D145-5D9B-4C99-8433-07D340BFA62A@neustar.biz> To: "Peterson, Jon" X-Mailer: Apple Mail (2.1084) Cc: "cdni@ietf.org" Subject: Re: [CDNi] New Version Notification fordraft-previdi-cdni-footprint-advertisement-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, 14 Mar 2012 20:11:32 -0000 --Apple-Mail-467--886120098 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Jon, I agree there is some wiggle room about what exact information set a = dCDN would provide to the uCDN which requires further discussion (ie = pick a spot between a very-high-level approach and a high-enough-level = approach). But I believe the requirement below, as well as the intent = when it was discussed, clearly excludes low-level approaches where the = upstream CDNs gets enough information to make the complete cache = selection. I also believe there was consensus that dCDNs did not want = to provide visibility on their CDN resource location/status/load... So to define this exact information set to be advertised by a dCDN, I = think the following are reasonable guiding principles: * stick to information that is helpful to the uCDN for selecting = the dCDN (and not the final cache) * do not expose dCDN caching resources =09 Francois On 14 Mar 2012, at 20:40, Peterson, Jon wrote: >=20 > While I think I agree with you about the general strategy we should = take, judging from the drafts submitted for this IETF and the discussion = on the list, I would be less confident about saying there is working = group consensus behind it. I think people are still all over the map on = this. In part that's because there's a pretty slippery slope between the = high-level and the low-level, and the words in the requirement GEN-4 = that you site - words like "surrogate topology, surrogate status" - are = not precise terms. When we start actually trying to define the = semantics, be it in terms of geography, topology, reachability, cache = enumeration, what have you, that's when we start to see what people are = reading into this words. I think today people are still reading some = pretty different things into them. >=20 > Jon Peterson > NeuStar, Inc. >=20 > On Mar 14, 2012, at 12:30 PM, Francois Le Faucheur wrote: >=20 >> (as an individual) >>=20 >> On 14 Mar 2012, at 18:41, Peterson, Jon wrote: >>>=20 >>> We also need to decide how deeply we want a uCDN to understand a = dCDNs resources - effectively, we could have very low-level approaches = where uCDNs execute the entire request-routing algorithm down to = selecting the particular cache, or high-level approaches where the uCDN = has only a general sense of dCDN resources and defers cache selection to = the dCDN. Once we get some agreement about these points, deciding what = type and what granularity of information dCDNs should advertise will be = a lot easier. >>=20 >> I believe this has been discussed and decided by the working group: >>=20 >> =46rom draft-ietf-cdni-requirements-02: >> " >> GEN-4 [HIGH] The CDNI solution shall not require intra-CDN >> information to be exposed to other CDNs for effective and >> efficient delivery of the content. Examples of intra-CDN >> information include surrogate topology, surrogate status, >> cached content, etc. >> " >>=20 >> I personally support that decision to focus the current/initial CDNI = work on "high-level approaches where the uCDN has only a general sense = of dCDN resources and defers cache selection to the dCDN". In the = future, once high level approaches are working we can look into "very = low-level approaches where the uCDNs execute the entire request-routing = algorithm down to selecting the particular cache" (if dCDNs are willing = to allow that). >>=20 >> Cheers >>=20 >> Francois >>=20 >>=20 >>>=20 >>> Jon Peterson >>> NeuStar, Inc. >>>=20 >>> On Mar 14, 2012, at 6:47 AM, Scott Wainner wrote: >>>=20 >>>>=20 >>>> A 'proper API' whether defined by CDN-I or not requires = information to be conveyed. That is the fundamental question in my = mind. What information needs to be conveyed THROUGH that API / = interface? >>>>=20 >>>> We've clearly identified that the 'footprint' of the CDN and = the network are not congruent. However, CDN will need to send packets = through the network to reach the client. The best proximity path = between any given delivery node and the client is defined by the network = topology. I can have two devices sitting side-by-side while they are = topologically connected in vastly different manners. We will certainly = need some NETWORK INFORMATION conveyed through the API to discern the = proximity of the client to any given delivery node. See ALTO. >>>>=20 >>>> I think the focus is on what INFORMATION is needed. Then we = can focus on the right conduit to convey that information. I suspect = the issue is delineating between different types of "capabilities". = There are CDN capabilities (ability to deliver content using HSS or HLS) = and there are network capabilities (ability to reach a given prefix and = cost associated with that path). Presumably, the CDN will collect BOTH = sets of capabilities via various API / CDN-I and make the 'best' choice = of delivery node. >>>>=20 >>>> What information do we need from the network to make the best = content routing decision in the uCDN? >>>>=20 >>>> draft-he-cdni-cap-info-advertising-01 >>>> draft-bertrand-cdni-footprint-discovery-00 >>>>=20 >>>> Question: Do we delineate our work around NETWORK capabilities / = footprint and CDN capabilities / footprint? >>>>=20 >>>> I see these as a disjoint set of information that the uCDN will = need to assimilate and make a congruent assessment. We don't want to = assign a delivery node that is not capable of delivering the content = even though it is closer. Conversely, we may want to assign a delivery = node that is topologically further away because of access costs. >>>>=20 >>>> Scott >>>>=20 >>>> On 3/14/12 8:29 AM, Stef van der Ziel wrote: >>>>>=20 >>>>> There are too many scenarios where a CDN does not rely on Internet = routing. >>>>> Think of multiple CDNs within a private network, that have to = interoperate. >>>>> A CDN may also have a different footprint than the network = topology. >>>>> I think that it is too easy to assume that BGP could be the right = protocol. >>>>> Proper APIs offer the same function, but with all the freedom that = CDNs will need. >>>>>=20 >>>>> Best, Stef >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 14 mrt. 2012, at 12:25, stefano previdi wrote: >>>>>=20 >>>>> > >>>>> > On Mar 14, 2012, at 11:38 AM, Stef van der Ziel wrote: >>>>> > >>>>> >> Hi, >>>>> >> >>>>> >> It still looks like you're trying to lock CDNs into networking = layer protocols and use protocols for which they were not intended. >>>>> > >>>>> > >>>>> > well, I don't think so. We use the same tool... but differently. >>>>> > >>>>> > >>>>> >> In most CDNs we deployed, BGP doesn't play any role. Not even = in federated scenarios. >>>>> > >>>>> > >>>>> > yes, but at the end of the day, the CDN relies on internet = routing so >>>>> > at some point there's a relationship between the CDN and the = network >>>>> > layer. >>>>> > >>>>> > In our proposal we just leverage the reachability information = you can >>>>> > get from your local SP/ISP so to figure out footprint = information. >>>>> > >>>>> > Capabilities, I agree with you, is a different story but since = we >>>>> > don't know yet what is a capability (and which format it = should/must/may >>>>> > have) it's difficult to come with a proper scheme. Having said = that, BGP >>>>> > (as a tool) has all feature you need so to propagate both FP and = caps. >>>>> > >>>>> > s. >>>>> > >>>>> > >>>>> > >>>>> >> Better use proper APIs! >>>>> >> >>>>> >> Best, Stef >>>>> >> >>>>> >> >>>>> >> On 14 mrt. 2012, at 11:33, stefano previdi wrote: >>>>> >> >>>>> >>> >>>>> >>> On Mar 14, 2012, at 11:07 AM, Stef van der Ziel wrote: >>>>> >>> >>>>> >>>> Hi, >>>>> >>>> >>>>> >>>> I would not recommend using BGP for CDN capabilities sharing. >>>>> >>>> BGP is a networking layer protocol. >>>>> >>> >>>>> >>> >>>>> >>> not in the way we propose to use it in the CDNI context. >>>>> >>> >>>>> >>> >>>>> >>>> CDNs can and should run independently from the network, or = span multiple networks. Or run within a part of a network, where BGP is = not the right protocol. >>>>> >>> >>>>> >>> >>>>> >>> well, BGP is to be intended as MP-BGP with a scope of = advertising >>>>> >>> footprint and capability information. In that respect the = semantic >>>>> >>> is pretty clear. The fact that BGP is also used in other = contexts >>>>> >>> such as network layer routing, MPLS-VPN, multicast, etc. = doesn't >>>>> >>> preclude the use of the same technology into another context. >>>>> >>> >>>>> >>> >>>>> >>>> CDNs should not be locked into networks or become dependent = on networking layered protocols. >>>>> >>> >>>>> >>> >>>>> >>> absolutely agree. As you can see from the proposal, we = leverage >>>>> >>> what's available in the BGP databases as for footprint = information. >>>>> >>> However, also described in the proposal, we allow complete = freedom >>>>> >>> to any CDNI MP-BGP player to define its own policy and = elements to >>>>> >>> advertise. >>>>> >>> >>>>> >>> s. >>>>> >>> >>>>> >>> >>>>> >>>> CDN interconnection should be done via APIs. >>>>> >>>> >>>>> >>>> Kind regards, >>>>> >>>> >>>>> >>>> Stef van der Ziel >>>>> >>>> >>>>> >>>> >>>>> >>>> On 12 mrt. 2012, at 15:28, Scott Wainner wrote: >>>>> >>>> >>>>> >>>>> I too am struggling with how 'capabilities' can be = advertised effectively in BGP. I'm inclined to delineate the = 'footprint' from the 'capabilities'. >>>>> >>>>> >>>>> >>>>> Perhaps one approach is to indicate in the 'capabilities' = the various METHODS for assessing the 'footprint'. In the = 'capabilities' exchange, the options for METHODS of determining = 'footprint' might be BGP AFI or BGP Communities or IGP Distance. = Accordingly, a dCDN might indicate it has the capability of advertising = (or allowing discovery of) different methods of 'footprint' = advertisements and those methods might be weighted. >>>>> >>>>> >>>>> >>>>> I think the dCDN capabilities (e.g. delivery methods, = security methods, etc.) will become far more complex than can be = aggregated into a representative set of BGP communities. Nevertheless, = I do think BGP communities is a viable method of advertising a = 'footprint' ... one that is well understood by the network operators. >>>>> >>>>> >>>>> >>>>> Scott Wainner >>>>> >>>>> >>>>> >>>>> On 3/9/12 6:50 AM, grant.watson@bt.com wrote: >>>>> >>>>>> Thanks, understood. >>>>> >>>>>> >>>>> >>>>>> Then my general feedback would be - I think working out = what capability information needs to be shared between the CDNs would = ideally be worked though prior to deciding the right way to do it. BGP = doesn't feel like an obvious choice for exchanging the kind of CDN = Capability information I'd envisage being passed between CDN. Has a = discussion taken place as to why BGP over other methods? (e.g. = API/metadata) There are drafts discussing metadata right now that = propose ways of describing the capability requirements between CDN (e.g. = "deliver this content using RMTP" etc.), why would we not also exchange = capabilities over the same interface for example? >>>>> >>>>>> >>>>> >>>>>> It's easier to understand why it may be considered that BGP = should/could be used for the exchange of network footprint information = but less so for CDN Capabilities, IMHO. In some cases CDN may not want = or need to implement footprint advertisement entirely (for example in a = simple bi-lateral relationship the CDN operators could easily elect to = exchange footprint information out-of-band), in this case they = presumably wouldn't want to be dependent on BGP to exchange capability = information. >>>>> >>>>>> >>>>> >>>>>> g- >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> -----Original Message----- >>>>> >>>>>> From: stefano previdi [mailto:sprevidi@cisco.com] >>>>> >>>>>> Sent: 09 March 2012 10:44 >>>>> >>>>>> To: Watson,G,Grant,DMK5 R >>>>> >>>>>> Cc: cdni@ietf.org >>>>> >>>>>> Subject: Re: [CDNi] New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>>>> >>>>>> >>>>> >>>>>> Hi Grant, >>>>> >>>>>> >>>>> >>>>>> On Mar 8, 2012, at 11:17 PM, = wrote: >>>>> >>>>>>> >>>>> >>>>>>> Hi, >>>>> >>>>>>> >>>>> >>>>>>> The document talks about "Capability Advertisements" and = the proposal to use MP-BGP messages to advertise/exchange CDN = capabilities. However, the document does not explicitly define what is = ment by "CDN Capability". >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> indeed... and it is somehow intended... >>>>> >>>>>> >>>>> >>>>>> As JanS pointed out, there's another draft that should = explicit the semantics of FP/Capabilities. In this proposal we = define the mechanism through which the capability information can be = exchanged. >>>>> >>>>>> >>>>> >>>>>> Obviously, at some point, we'll have to synchronize. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>>> I understand "CDN Capability" to mean things like delivery = technology (for example RTMP or HTTP etc.) or perhaps a specific form of = content authorisation etc. Can you confirm I am correct in assuming this = or if not clarify what the correct meaning is. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> My understanding goes in the same direction, so far. >>>>> >>>>>> >>>>> >>>>>> s. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>>> >>>>> >>>>>>> Cheers, >>>>> >>>>>>> >>>>> >>>>>>> g- >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> ________________________________________ >>>>> >>>>>>> From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On = Behalf Of >>>>> >>>>>>> stefano previdi [sprevidi@cisco.com] >>>>> >>>>>>> Sent: 08 March 2012 21:23 >>>>> >>>>>>> To: cdni@ietf.org >>>>> >>>>>>> Subject: [CDNi] Fwd: New Version Notification for = draft-previdi-cdni-footprint-advertisement-01.txt >>>>> >>>>>>> >>>>> >>>>>>> Begin forwarded message: >>>>> >>>>>>> >>>>> >>>>>>>> From: internet-drafts@ietf.org >>>>> >>>>>>>> Subject: New Version Notification for >>>>> >>>>>>>> draft-previdi-cdni-footprint-advertisement-01.txt >>>>> >>>>>>>> Date: March 8, 2012 8:45:53 PM GMT+01:00 >>>>> >>>>>>>> To: sprevidi@cisco.com >>>>> >>>>>>>> Cc: allan.guillou@sfr.com, flefauch@cisco.com, = jmedved@cisco.com >>>>> >>>>>>>> >>>>> >>>>>>>> A new version of I-D, = draft-previdi-cdni-footprint-advertisement-01.txt has been successfully = submitted by Stefano Previdi and posted to the IETF repository. >>>>> >>>>>>>> >>>>> >>>>>>>> Filename: draft-previdi-cdni-footprint-advertisement >>>>> >>>>>>>> Revision: 01 >>>>> >>>>>>>> Title: CDNI Footprint Advertisement >>>>> >>>>>>>> Creation date: 2012-03-08 >>>>> >>>>>>>> WG ID: Individual Submission >>>>> >>>>>>>> Number of pages: 27 >>>>> >>>>>>>> >>>>> >>>>>>>> Abstract: >>>>> >>>>>>>> This document describes the use of BGP for Content = Delivery Networks >>>>> >>>>>>>> (CDNs) in order to advertise information about footprint = and >>>>> >>>>>>>> connectivity to footprint in the context of CDNI. >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> This draft is for the CDNI Working Group. >>>>> >>>>>>>> >>>>> >>>>>>>> Thanks. >>>>> >>>>>>>> s. >>>>> >>>>>>>> >>>>> >>>>>>>> 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 >>>>> >>>> >>>>> >>>> _______________________________________________ >>>>> >>>> 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 >>>>>=20 >>>>=20 >>>> >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >=20 --Apple-Mail-467--886120098 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii * stick = to information that is helpful to the uCDN for selecting the dCDN (and = not the final cache)
* do not expose dCDN caching = resources  =

Francois

On 14 = Mar 2012, at 20:40, Peterson, Jon wrote:


While I think I = agree with you about the general strategy we should take, judging from = the drafts submitted for this IETF and the discussion on the list, I = would be less confident about saying there is working group consensus = behind it. I think people are still all over the map on this. In part = that's because there's a pretty slippery slope between the high-level = and the low-level, and the words in the requirement GEN-4 that you site = - words like "surrogate topology, surrogate status" - are not precise = terms. When we start actually trying to define the semantics, be it in = terms of geography, topology, reachability, cache enumeration, what have = you, that's when we start to see what people are reading into this = words. I think today people are still reading some pretty different = things into them.

Jon Peterson
NeuStar, = Inc.

On Mar 14, 2012, at 12:30 PM, = Francois Le Faucheur wrote:

(as an = individual)

On 14 Mar 2012, at 18:41, Peterson, Jon = wrote:

We also need to = decide how deeply we want a uCDN to understand a dCDNs resources - = effectively, we could have very low-level approaches where uCDNs execute = the entire request-routing algorithm down to selecting the particular = cache, or high-level approaches where the uCDN has only a general sense = of dCDN resources and defers cache selection to the dCDN. Once we get = some agreement about these points, deciding what type and what = granularity of information dCDNs should advertise will be a lot = easier.

I believe this has = been discussed and decided by the working = group:

=46rom = draft-ietf-cdni-requirements-02:
"
  =  GEN-4   [HIGH] The CDNI solution shall not require = intra-CDN
           information = to be exposed to other CDNs for effective and
    =        efficient delivery of the content. =  Examples of intra-CDN
          =  information include surrogate topology, surrogate = status,
           cached = content, etc.
"

I personally = support that decision to focus the current/initial CDNI work on = "high-level approaches where the uCDN has only a general sense of dCDN = resources and defers cache selection to the dCDN". In the future, once = high level approaches are working we can look into "very low-level = approaches where the uCDNs execute the entire request-routing algorithm = down to selecting the particular cache" (if dCDNs are willing to allow = that).

Cheers

Francois



Jon Peterson
NeuStar, = Inc.

On Mar 14, 2012, at 6:47 AM, Scott Wainner = wrote:

=20 =20

    A 'proper API' whether defined by CDN-I or not = requires information to be conveyed.  That is the fundamental question = in my mind.  What information needs to be conveyed THROUGH that API / interface?

    We've clearly identified that the 'footprint' of = the CDN and the network are not congruent.  However, CDN will need to send = packets through the network to reach the client.  The best proximity = path between any given delivery node and the client is defined by the network topology.  I can have two devices sitting side-by-side = while they are topologically connected in vastly different manners.  = We will certainly need some NETWORK INFORMATION conveyed through the API to discern the proximity of the client to any given delivery node. See ALTO.

    I think the focus is on what INFORMATION is = needed.  Then we can focus on the right conduit to convey that information.  I = suspect the issue is delineating between different types of = "capabilities".  There are CDN capabilities (ability to deliver content using HSS or HLS) and there are network capabilities (ability to reach a given prefix and cost associated with that path).  Presumably, the = CDN will collect BOTH sets of capabilities via various API / CDN-I and make the 'best' choice of delivery node.

    What information do we need from the network to = make the best content routing decision in the uCDN?

    draft-he-cdni-cap-info-advertising-01
    draft-bertrand-cdni-footprint-discovery-00

Question: Do we delineate our work around NETWORK capabilities / footprint and CDN capabilities / footprint?

I see these as a disjoint set of information that the uCDN will need to assimilate and make a congruent assessment.  We don't want = to assign a delivery node that is not capable of delivering the content even though it is closer.  Conversely, we may want to assign a delivery node that is topologically further away because of access costs.

Scott

On 3/14/12 8:29 AM, Stef van der Ziel wrote:
Re: [CDNi] New Version Notification fordraft-previdi-cdni-footprint-advertisement-01.txt

There = are too many scenarios where a CDN does not rely on Internet routing.
Think of multiple CDNs within a private network, that have to interoperate.
A CDN may also have a different footprint than the network topology.
I think that it is too easy to assume that BGP could be the right protocol.
Proper APIs offer the same function, but with all the freedom that CDNs will need.

Best, Stef



On 14 mrt. 2012, at 12:25, stefano previdi wrote:

>
> On Mar 14, 2012, at 11:38 AM, Stef van der Ziel = wrote:
>
>> Hi,
>>
>> It still looks like you're trying to lock CDNs into networking layer protocols and use protocols for which they were not intended.
>
>
> well, I don't think so. We use the same tool... but differently.
>
>
>> In most CDNs we deployed, BGP doesn't play any role. Not even in federated scenarios.
>
>
> yes, but at the end of the day, the CDN relies on internet routing so
> at some point there's a relationship between the CDN and the network
> layer.
>
> In our proposal we just leverage the reachability information you can
> get from your local SP/ISP so to figure out footprint information.
>
> Capabilities, I agree with you, is a different story but since we
> don't know yet what is a capability (and which format it should/must/may
> have) it's difficult to come with a proper scheme. Having said that, BGP
> (as a tool) has all feature you need so to propagate both FP and caps.
>
> s.
>
>
>
>> Better use proper APIs!
>>
>> Best, Stef
>>
>>
>> On 14 mrt. 2012, at 11:33, stefano previdi wrote:
>>
>>>
>>> On Mar 14, 2012, at 11:07 AM, Stef van der Ziel wrote:
>>>
>>>> Hi,
>>>>
>>>> I would not recommend using BGP for CDN capabilities sharing.
>>>> BGP is a networking layer protocol.
>>>
>>>
>>> not in the way we propose to use it in the CDNI context.
>>>
>>>
>>>> CDNs can and should run independently from the network, or span multiple networks. Or run within a part of a network, where BGP is not the right protocol.
>>>
>>>
>>> well, BGP is to be intended as MP-BGP with a scope of advertising
>>> footprint and capability information. In that respect the semantic
>>> is pretty clear. The fact that BGP is also used in other contexts
>>> such as network layer routing, MPLS-VPN, multicast, etc. doesn't
>>> preclude the use of the same technology into another context.
>>>
>>>
>>>> CDNs should not be locked into networks or become dependent on networking layered protocols.
>>>
>>>
>>> absolutely agree. As you can see from the proposal, we leverage
>>> what's available in the BGP databases as for footprint information.
>>> However, also described in the proposal, we allow complete freedom
>>> to any CDNI MP-BGP player to define its own policy and elements to
>>> advertise.
>>>
>>> s.
>>>
>>>
>>>> CDN interconnection should be done via = APIs.
>>>>
>>>> Kind regards,
>>>>
>>>> Stef van der Ziel
>>>>
>>>>
>>>> On 12 mrt. 2012, at 15:28, Scott Wainner wrote:
>>>>
>>>>> I too am struggling with how 'capabilities' can be advertised effectively in BGP.  I'm inclined to delineate the 'footprint' from the = 'capabilities'.
>>>>>
>>>>> Perhaps one approach is to indicate in the 'capabilities' the various METHODS for assessing the 'footprint'.  In the 'capabilities' exchange, the options = for METHODS of determining 'footprint' might be BGP AFI or BGP Communities or IGP Distance.  Accordingly, a dCDN might indicate it has the capability of advertising (or allowing discovery of) different methods of 'footprint' advertisements and those methods might be weighted.
>>>>>
>>>>> I think the dCDN capabilities (e.g. delivery methods, security methods, etc.) will become far more complex than can be aggregated into a representative set of BGP communities.  Nevertheless, I do think BGP = communities is a viable method of advertising a 'footprint' ... one that is well understood by the network operators.
>>>>>
>>>>> Scott Wainner
>>>>>
>>>>> On 3/9/12 6:50 AM, grant.watson@bt.com wrote:
>>>>>> Thanks, understood.
>>>>>>
>>>>>> Then my general feedback would be - I think working out what capability information needs to be shared between the CDNs would ideally be worked though prior to deciding the right way to do it. BGP doesn't feel like an obvious choice for exchanging the kind of CDN Capability information I'd envisage being passed between CDN. Has a discussion taken place as to why BGP over other methods? (e.g. API/metadata) There are drafts discussing metadata right now that propose ways of describing the capability requirements between CDN (e.g. "deliver this content using RMTP" etc.), why would we not also exchange capabilities over the same interface for example?
>>>>>>
>>>>>> It's easier to understand why it may be considered that BGP should/could be used for the exchange of network footprint information but less so for CDN Capabilities, IMHO. In some cases CDN may not want or need to implement footprint advertisement entirely (for example in a simple bi-lateral relationship the CDN operators could easily elect to exchange footprint information out-of-band), in this case they presumably wouldn't want to be dependent on BGP to exchange capability information.
>>>>>>
>>>>>> g-
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: stefano previdi [mailto:sprevidi@cisco.com]
>>>>>> Sent: 09 March 2012 10:44
>>>>>> To: Watson,G,Grant,DMK5 R
>>>>>> Cc: cdni@ietf.org
>>>>>> Subject: Re: [CDNi] New Version Notification for draft-previdi-cdni-footprint-advertisement-01.txt
>>>>>>
>>>>>> Hi Grant,
>>>>>>
>>>>>> On Mar 8, 2012, at 11:17 PM, <grant.watson@bt.com> <grant.watson@bt.com> = wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> The document talks about "Capability Advertisements" and the proposal to use MP-BGP messages to advertise/exchange CDN capabilities. However, the document does not explicitly define what is ment by "CDN Capability".
>>>>>>
>>>>>>
>>>>>> indeed... and it is somehow intended...
>>>>>>
>>>>>> As JanS pointed out, there's another draft that should explicit the semantics of FP/Capabilities. In this proposal = we           define = the mechanism through which the capability information can be exchanged.
>>>>>>
>>>>>> Obviously, at some point, we'll have to synchronize.
>>>>>>
>>>>>>
>>>>>>> I understand "CDN Capability" to mean things like delivery technology (for example RTMP or HTTP etc.) or perhaps a specific form of content authorisation etc. Can you confirm I am correct in assuming this or if not clarify what = the           correct = meaning is.
>>>>>>
>>>>>>
>>>>>> My understanding goes in the same direction, so far.
>>>>>>
>>>>>> s.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> g-
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ________________________________________
>>>>>>> From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] On = Behalf Of
>>>>>>> stefano previdi [sprevidi@cisco.com]
>>>>>>> Sent: 08 March 2012 21:23
>>>>>>> To: cdni@ietf.org
>>>>>>> Subject: [CDNi] Fwd: New Version Notification for       draft-previdi-cdni-footprint-advertisement-01.txt
>>>>>>>
>>>>>>> Begin forwarded message:
>>>>>>>
>>>>>>>> From: internet-drafts@ietf.org
>>>>>>>> Subject: New Version Notification for
>>>>>>>> draft-previdi-cdni-footprint-advertisement-01.txt
>>>>>>>> Date: March 8, 2012 8:45:53 PM GMT+01:00
>>>>>>>> To: sprevidi@cisco.com
>>>>>>>> Cc: allan.guillou@sfr.com, flefauch@cisco.com, jmedved@cisco.com
>>>>>>>>
>>>>>>>> A new version of I-D, draft-previdi-cdni-footprint-advertisement-01.txt has been successfully submitted by Stefano Previdi and posted to the IETF repository.
>>>>>>>>
>>>>>>>> = Filename:      draft-previdi-cdni-footprint-advertisement
>>>>>>>> = Revision:      01
>>>>>>>> = Title:           &n= bsp;     CDNI Footprint Advertisement
>>>>>>>> Creation = date:         2012-03-08
>>>>>>>> WG = ID:            = ;     Individual Submission
>>>>>>>> Number of pages: 27
>>>>>>>>
>>>>>>>> Abstract:
>>>>>>>> This document describes the use of BGP for Content Delivery Networks
>>>>>>>> (CDNs) in order to advertise information about footprint and
>>>>>>>> connectivity to footprint in the context of CDNI.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> This draft is for the CDNI Working Group.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>> s.
>>>>>>>>
>>>>>>>> The IETF Secretariat
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> CDNi mailing list
>>>>>>> CDNi@ietf.org
>>>>>>> https://www.ietf.org/m= ailman/listinfo/cdni
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> CDNi mailing list
>>>>>> CDNi@ietf.org
>>>>>> https://www.ietf.org/m= ailman/listinfo/cdni
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> CDNi mailing list
>>>>> CDNi@ietf.org
>>>>> https://www.ietf.org/m= ailman/listinfo/cdni
>>>>
>>>> _______________________________________________
>>>> CDNi mailing list
>>>> CDNi@ietf.org
>>>> https://www.ietf.org/m= ailman/listinfo/cdni
>>>
>>>
>>
>> _______________________________________________
>> CDNi mailing list
>> CDNi@ietf.org
>> https://www.ietf.org/m= ailman/listinfo/cdni
>>
>
>

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/m= ailman/listinfo/cdni


= <ATT00001..txt>

___________= ____________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/m= ailman/listinfo/cdni



= --Apple-Mail-467--886120098-- From flefauch@cisco.com Fri Mar 16 03:41: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 B77CC21F8650 for ; Fri, 16 Mar 2012 03:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.196 X-Spam-Level: X-Spam-Status: No, score=-10.196 tagged_above=-999 required=5 tests=[AWL=0.403, 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 EQllgCQX0EMT for ; Fri, 16 Mar 2012 03:41:57 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id B3E6A21F8645 for ; Fri, 16 Mar 2012 03:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=178; q=dns/txt; s=iport; t=1331894518; x=1333104118; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=1qK/AC104Nki7i7h2U8E6pwhtpFp8zLzB10NYDhPMJ4=; b=NScozalAu9g9/yWr9ZcO6VVMZVhLHaVnCcnQtL1pOBAdnAr0AvIypDwU viTbvVIHVsaLrFxtAZyOua7WghfIfyMgh8+j5IrALLESrBPUGxQb+r9c+ 254P4/hifUcleIbzT0ZmN3lDDWIGrSTW0b8IrXzhVJZ8C+geSYtbah2MN E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlxQAMkXY0+Q/khR/2dsb2JhbABCgxuqQYdOAQMBA4ENgQeCIgEnghkZh2gLnS6BJ5crjVuCP2MElWaOP4Fogmc X-IronPort-AV: E=Sophos;i="4.73,597,1325462400"; d="scan'208";a="68636149" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 16 Mar 2012 10:41:57 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2GAftPN014982 for ; Fri, 16 Mar 2012 10:41:55 GMT From: Francois Le Faucheur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 16 Mar 2012 11:42:03 +0100 Message-Id: <4B1697F9-A3D7-4BCF-BD2A-654CDCB6A830@cisco.com> To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [CDNi] CDNI - IETF83 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: Fri, 16 Mar 2012 10:41:57 -0000 Hi, The draft CDNI agenda for IETF-83 has been posted: http://www.ietf.org/proceedings/83/agenda/agenda-83-cdni.html Let us know if you have comments. Francois & Rich From haibin.song@huawei.com Mon Mar 19 05:43: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 999FC21F86B1 for ; Mon, 19 Mar 2012 05:43:35 -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 Vu7MgXYYdrM0 for ; Mon, 19 Mar 2012 05:43:34 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 29C0121F86B0 for ; Mon, 19 Mar 2012 05:43:34 -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 AEN01480; Mon, 19 Mar 2012 08:43:33 -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; Mon, 19 Mar 2012 05:41:36 -0700 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Mar 2012 05:41:35 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.30]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 19 Mar 2012 20:41:30 +0800 From: Songhaibin To: Jan Seedorf , "cdni@ietf.org" Thread-Topic: [CDNi] FW: New Version Notification for draft-seedorf-cdni-request-routing-alto-01.txt Thread-Index: Acz+G8Im/HSC35/xQiO9JoAXRYKYjgHre01Q Date: Mon, 19 Mar 2012 12:41:52 +0000 Message-ID: References: <2779C9F0771F974CAD742BAE6D9904FE24F1886D@DAPHNIS.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE24F1886D@DAPHNIS.office.hd> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CDNi] FW: New Version Notification for draft-seedorf-cdni-request-routing-alto-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, 19 Mar 2012 12:43:35 -0000 I just read this document and find it proposes a good way to use ALTO infor= mation for downstream CDN selection. The concepts of PIDs and costs between= PIDs are useful to express the footprint and delivery preferences. Here ar= e two comments that I have: 1) monetary cost might be sensitive and not simple information to be convey= ed. Existing CDN charges different content providers differently, with cons= ideration of many factors. 2) the ALTO information provided by dCDN A and dCDN B might be from differe= nt ALTO servers, so the same PID or cost value might have different meaning= s and are not comparable. I think when comparing the two, we need to make s= ure they are from the same ALTO server.=20 BR, -Haibin > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of J= an > Seedorf > Sent: Saturday, March 10, 2012 1:43 AM > To: cdni@ietf.org > Subject: [CDNi] FW: New Version Notification for > draft-seedorf-cdni-request-routing-alto-01.txt >=20 > Hi all, >=20 > I have uploaded a new version of the CDNI Request Routing with ALTO draft= . I > changed the name to draft-seedorf-cdni-request-routing-alto so that it is= listed in > the CDNI status pages; we agreed at last IETF that the discussions should= happen > mostly in the CDNI WG. As discussed in Taipei, the draft now focusses on = dCDN > selection with ALTO. The draft gives an example how it could work, and di= scusses > some assumptions / considerations for using ALTO. >=20 > - Jan >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, March 09, 2012 6:40 PM > To: Jan Seedorf > Subject: New Version Notification for > draft-seedorf-cdni-request-routing-alto-01.txt >=20 > A new version of I-D, draft-seedorf-cdni-request-routing-alto-01.txt has = been > successfully submitted by Jan Seedorf and posted to the IETF repository. >=20 > Filename: draft-seedorf-cdni-request-routing-alto > Revision: 01 > Title: CDNI Request Routing with ALTO > Creation date: 2012-03-09 > WG ID: Individual Submission > Number of pages: 14 >=20 > Abstract: > Network Service Providers (NSPs) are currently considering to deploy > Content Delivery Networks (CDNs) within their networks. As a > consequence of this development, there is a need for interconnecting > these local CDNs. The necessary interfaces for inter-connecting CDNs > are currently being defined in the Content Delivery Networks > Interconnection (CDNI) WG. This document focusses on the Request > Routing Interface of CDNI, and more specifically on how the solutions > currently being defined in the Application Layer Traffic Optimization > (ALTO) WG can improve CDNI request routing. The overall intention > behind this document is to foster discussions (in the CDNI as well as > in the ALTO WG) regarding if, how, and under what conditions ALTO can > be useful to optimize CDNI request routing. As basis for this > discussion, this document provides concrete examples of how ALTO can > be integrated within CDNI request routing and in particular in the > process of selecting a downstream CDN. The examples in this document > are based on the use cases and examples currently being discussed in > the CDNI WG. >=20 >=20 >=20 >=20 > The IETF Secretariat > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From swainner@cisco.com Mon Mar 19 11:44: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 DEAF921F8870 for ; Mon, 19 Mar 2012 11:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.904 X-Spam-Level: X-Spam-Status: No, score=-9.904 tagged_above=-999 required=5 tests=[AWL=0.694, 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 o0x2a8nS5PtE for ; Mon, 19 Mar 2012 11:44:44 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7394121F8790 for ; Mon, 19 Mar 2012 11:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=19309; q=dns/txt; s=iport; t=1332182684; x=1333392284; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=5iG6pBhQYB9SEviMQ/hS9p/eaLU+8juv9iWYO8YUCcc=; b=c+mxXAEyAIRn2H8Y7xJVLpsdxlKXf7nYFwYjoQZ/FcMpTXsulm/77AGI ED24FBTZRdgrfkR+xaHYeiOADAXV2q1QLNSDgqVacNljMDHJFm3wtMBIQ 7/vbRIoH8gSH3DCi9CbuXRIspVl03EEjsoyBk21GT/bvQ++y9v5+pr/UT I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACx+Z0+rRDoJ/2dsb2JhbABCtmGBB4IJAQEBBAEBAQ8BGkEEBhELGAkWBAsJAwIBAgEVMBMGAgEBEA6HZwyfNY8AiAyQZQSVaI5AgWiDAg X-IronPort-AV: E=Sophos;i="4.73,611,1325462400"; d="scan'208,217";a="36667534" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 19 Mar 2012 18:44:23 +0000 Received: from stealth-10-32-245-62.cisco.com (stealth-10-32-245-62.cisco.com [10.32.245.62]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2JIiMgu024941 for ; Mon, 19 Mar 2012 18:44:23 GMT Message-ID: <4F677E85.9060301@cisco.com> Date: Mon, 19 Mar 2012 14:44:21 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: cdni@ietf.org References: <2779C9F0771F974CAD742BAE6D9904FE24F15792@DAPHNIS.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE24F15792@DAPHNIS.office.hd> Content-Type: multipart/alternative; boundary="------------000807060404070702050904" Subject: Re: [CDNi] New draft on Semantics for CDNI Request Routing - Footprint and Capabilities 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, 19 Mar 2012 18:44:46 -0000 This is a multi-part message in MIME format. --------------000807060404070702050904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jan, Comments on the draft: draft-spp-cdni-rr-foot-cap-semantics-00 Section 4: Bullet 1: Footprint could be defined by ... similar boundary I think this is where we get into trouble because the definition of a boundary is arbitrary. Clearly, IP addresses are not arbitrary; however, the address ranges may be assigned, partitioned, re-allocated, and distributed. If a portion of a prefix is allocated and distributed downstream, then it may extend beyond the definition of the 'boundary'. At a macro level, it is easy to map a set of prefixes to an AS which has a well defined 'boundary' of peering points. The caches and client are either in the same AS or they are not. What is interesting is the fact that a client and cache in the same AS may not provide the 'best' path. The client in AS 1 may leverage a peering point to AS 2 where the cache of AS-2 is closer than the cache of AS-1. In contrast, the use of a geographic 'boundary' such as a city may also create a problem. A client in AS-1 may be in close proximity to a cache in AS-2 as defined by the geographic boundary - the same city; however, the network topology affords no peering between the two AS anywhere close to that defined 'boundary'. I'm inclined to say that a 'boundary' must be confined to a portion of an AS (which represents a contiguous network infrastructure). The semantics of the 'boundary' must be agreed upon between the dCDN and uCDN. By using an abstract representation of a 'boundary' the two parties can agree upon the scope. The 'boundary' could be defined as a particular location, city, province, or country. Given the uCDN is making a decision between itself and various dCDN, the uCDN can weight the routing accordingly. The relationship between uCDN-dCDN1 and uCDN-dCDN2 might have different weights. Section 4: Bullet 2: Footprint could be defined as the set of the IP addresses ... I think this is problematic as the dCDN may be changing these addresses and may not want to expose exactly how many caches are used. Section 4: Bullet 4: Footprint could alternatively be defined as "a class of end user requests" ... I associate that 'class' label to mean a type of delivery service or type of environment that does not necessarily define a footprint. I'm inclined to say that "a class of end user requests" might be more representative of a CDN capability. While the footprint is still relevant. In most cases, a dCDN will want to make all their caches capable of streaming all for all services at all locations; however, that may not be the case. I'm inclined to associate a 'capability' to a footprint boundary. While we might have an aggregate capability (eg. dCDN can deliver HSS), we may have filtered set where some defined 'boundary' portion of the dCDN is not capable of delivering a particular class of traffic. So now we're starting to correlate capabilities to footprint. I think these generalized capabilities might have a slow rate of change. Section 5: Bullet 1: Capabilities are types of information ... I would define this as the aggregate capability. There is likely a 'per boundary' capability which the uCDN may also assess. This granularity (capability per boundary) should be allowed by the protocol while use of this granularity should be optional. If we use the query model you defined previously, the uCDN might see that the dCDN has an aggregate capability to delivery a type of service; therefore, it inquires of the dCDN the option to use the dCDN's services. The uCDN might include in the query the 'conditions' upon which the dCDN should respond (e.g. 'request for this capability in this boundary'). The dCDN may reject the request in the query model or accept it. If we use the notify model you defined previously, the dCDN might have to indicate there are exceptions to the aggregate capability where certain 'boundaries' are included in the aggregate or excluded from the aggregate. Section 5: Bullet 2: Some capabilities may change dynamically ... I'm inclined to keep the use of the notify model to a minimum. The uCDN would need only sufficient knowledge to know that the dCDN USUALLY has a capability for a given boundary. State transient delivery capabilities within the boundary would be handled at the time of query. Section 6: Bullet 1: a) dCDN push general capabilities for 'boundaries' and persistent exceptions to capabilities b) uCDN query for current state of capabilities given previous statement of dCDN general capabilities Ex. dCDN says it can service HSS and HLS for a given boundary; uCDN may query dCDN for current state of capabilities for a given session setup Section 6: Bullet 2: I'm inclined to go with an abstract 'boundary'. It is incumbent upon the uCDN to define the 'boundary' It is incumbent upon the dCDN to indicate the capabilities according to the defined boundary Boundary could be prefix_range, AS, city, country; I do think AS's make a good candidate for aggregate boundaries I think BGP Extended Communities make good good candidates for 'specific boundaries' The uCDN and dCDN can agree that a BGP Extended Community will represent a site, city, or country Section 6: Bullet 3: I'm inclined to have the dCDN advertise static capabilities I'm inclined to have the uCDN query about dynamic state of those capabilities as needed Section 6: Bullet 4: Use abstract representation of 'costs' by means of unit weight The uCDN and dCDN can negotiate the value of unit weights Section 6: Bullet 5: I think monetary delivery costs should not be included. Units should be used (streams, packets, GB, PPS) Section 6: Bullet 6: I think this is the 'cascaded' dCDN. I think the 'footprint' of the tier3 dCDN would have to be represented in a manner that the tier2 dCDN could aggregate and represent to the uCDN. The uCDN shouldn't know about the details of the tier3 dCDN. Eg. tier3 dCDN supports country_x/city_1 and country_x/city_2. Tier2 dCDN supports country_y and country_x. uCDN (Tier1) knows that country_x and country_y have coverage via the Tier2 dCDN. Jan, good questions that need to be answered ... Scott On 3/6/12 11:09 AM, Jan Seedorf wrote: > > CDNI Folks, > > As discussed in Taipei, we have submitted a draft that tries to define > the semantics for the "Footprint and Capabilities Advertisement" part > of CDNI Request Routing, see > http://tools.ietf.org/html/draft-spp-cdni-rr-foot-cap-semantics-00. In > Taipei, Martin had agreed to put effort into this (and indeed he > started the draft, thanks!), but since he is currently busy with other > tasks, I have contributed some text together with Jon and Stefano. > Currently, the draft has a lot of open issues and questions, which is > probably a good thing to get discussions going. > > Abstract: > This document tries to capture the semantics of the "Footprint and > Capabilities Advertisment" part of the CDNI Request Routing interface, > i.e. the desired meaning and what "Footprint and Capabilities > Advertisment" is expected to offer within CDNI. The discussion in > this document has the goal to facilitate the choosing of one or more > suitable protocols for "Footprint and Capabilities Advertisment" > within CDNI Request Routing. > > If you can think of any other key questions/issues you think need to > be discussed (which are not contained in the draft yet), please let us > know; we can add them in a future version and will try to remember > them for the discussion in Paris. > > Looking forward to comments and discussions, > > - Jan > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --------------000807060404070702050904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jan,

    Comments on the draft:
    draft-spp-cdni-rr-foot-cap-semantics-00

Section 4: Bullet 1:  Footprint could be defined by ... similar boundary

    I think this is where we get into trouble because the definition of a boundary is arbitrary.  Clearly, IP addresses are not arbitrary; however, the address ranges may be assigned, partitioned, re-allocated, and distributed.  If a portion of a prefix is allocated and distributed downstream, then it may extend beyond the definition of the 'boundary'.

    At a macro level, it is easy to map a set of prefixes to an AS which has a well defined 'boundary' of peering points.  The caches and client are either in the same AS or they are not.  What is interesting is the fact that a client and cache in the same AS may not provide the 'best' path.  The client in AS 1 may leverage a peering point to AS 2 where the cache of AS-2 is closer than the cache of AS-1.

    In contrast, the use of a geographic 'boundary' such as a city may also create a problem.  A client in AS-1 may be in close proximity to a cache in AS-2 as defined by the geographic boundary - the same city; however, the network topology affords no peering between the two AS anywhere close to that defined 'boundary'.

    I'm inclined to say that a 'boundary' must be confined to a portion of an AS (which represents a contiguous network infrastructure).  The semantics of the 'boundary' must be agreed upon between the dCDN and uCDN.  By using an abstract representation of a 'boundary' the two parties can agree upon the scope.  The 'boundary' could be defined as a particular location, city, province, or country.  Given the uCDN is making a decision between itself and various dCDN, the uCDN can weight the routing accordingly.  The relationship between uCDN-dCDN1 and uCDN-dCDN2 might have different weights.

Section 4: Bullet 2:  Footprint could be defined as the set of the IP addresses ...

    I think this is problematic as the dCDN may be changing these addresses and may not want to expose exactly how many caches are used.

Section 4: Bullet 4:  Footprint could alternatively be defined as "a class of end user requests" ...

    I associate that 'class' label to mean a type of delivery service or type of environment that does not necessarily define a footprint.  I'm inclined to say that "a class of end user requests" might be more representative of a CDN capability.  While the footprint is still relevant.  In most cases, a dCDN will want to make all their caches capable of streaming all for all services at all locations; however, that may not be the case.  I'm inclined to associate a 'capability' to a footprint boundary.  While we might have an aggregate capability (eg. dCDN can deliver HSS), we may have filtered set where some defined 'boundary' portion of the dCDN is not capable of delivering a particular class of traffic.  So now we're starting to correlate capabilities to footprint.  I think these generalized capabilities might have a slow rate of change.

Section 5: Bullet 1:  Capabilities are types of information ...

    I would define this as the aggregate capability.  There is likely a 'per boundary' capability which the uCDN may also assess.  This granularity (capability per boundary) should be allowed by the protocol while use of this granularity should be optional.

    If we use the query model you defined previously, the uCDN might see that the dCDN has an aggregate capability to delivery a type of service; therefore, it inquires of the dCDN the option to use the dCDN's services.  The uCDN might include in the query the 'conditions' upon which the dCDN should respond (e.g. 'request for this capability in this boundary').  The dCDN may reject the request in the query model or accept it.

    If we use the notify model you defined previously, the dCDN might have to indicate there are exceptions to the aggregate capability where certain 'boundaries' are included in the aggregate or excluded from the aggregate.

Section 5: Bullet 2:  Some capabilities may change dynamically ...

    I'm inclined to keep the use of the notify model to a minimum.  The uCDN would need only sufficient knowledge to know that the dCDN USUALLY has a capability for a given boundary.  State transient delivery capabilities within the boundary would be handled at the time of query.

Section 6: Bullet 1:

    a) dCDN push general capabilities for 'boundaries' and persistent exceptions to capabilities
    b) uCDN query for current state of capabilities given previous statement of dCDN general capabilities
    Ex. dCDN says it can service HSS and HLS for a given boundary;
        uCDN may query dCDN for current state of capabilities for a given session setup

Section 6: Bullet 2:

    I'm inclined to go with an abstract 'boundary'.
    It is incumbent upon the uCDN to define the 'boundary'
    It is incumbent upon the dCDN to indicate the capabilities according to the defined boundary

    Boundary could be prefix_range, AS, city, country;
    I do think AS's make a good candidate for aggregate boundaries
    I think BGP Extended Communities make good good candidates for 'specific boundaries'
    The uCDN and dCDN can agree that a BGP Extended Community will represent a site, city, or country

Section 6: Bullet 3:

    I'm inclined to have the dCDN advertise static capabilities
    I'm inclined to have the uCDN query about dynamic state of those capabilities as needed

Section 6: Bullet 4:

    Use abstract representation of 'costs' by means of unit weight
    The uCDN and dCDN can negotiate the value of unit weights

Section 6: Bullet 5:

    I think monetary delivery costs should not be included.  Units should be used (streams, packets, GB, PPS)

Section 6: Bullet 6:

    I think this is the 'cascaded' dCDN.  I think the 'footprint' of the tier3 dCDN would have to be represented in a manner that the tier2 dCDN could aggregate and represent to the uCDN.  The uCDN shouldn't know about the details of the tier3 dCDN.  Eg. tier3 dCDN supports country_x/city_1 and country_x/city_2.  Tier2 dCDN supports country_y and country_x.  uCDN (Tier1) knows that country_x and country_y have coverage via the Tier2 dCDN.

Jan, good questions that need to be answered ...

Scott


On 3/6/12 11:09 AM, Jan Seedorf wrote:
[CDNi] New draft on Semantics for CDNI Request Routing - Footprint and Capabilities Advertisement

CDNI Folks,

As discussed in Taipei, we have submitted a draft that tries to define the semantics for the "Footprint and Capabilities Advertisement" part of CDNI Request Routing, see http://tools.ietf.org/html/draft-spp-cdni-rr-foot-cap-semantics-00. In Taipei, Martin had agreed to put effort into this (and indeed he started the draft, thanks!), but since he is currently busy with other tasks, I have contributed some text together with Jon and Stefano. Currently, the draft has a lot of open issues and questions, which is probably a good thing to get discussions going.

Abstract:
This document tries to capture the semantics of the "Footprint and Capabilities Advertisment" part of the CDNI Request Routing interface, i.e. the desired meaning and what "Footprint and Capabilities Advertisment" is expected to offer within CDNI.  The discussion in this document has the goal to facilitate the choosing of one or more suitable protocols for "Footprint and Capabilities Advertisment" within CDNI Request Routing.

If you can think of any other key questions/issues you think need to be discussed (which are not contained in the draft yet), please let us know; we can add them in a future version and will try to remember them for the discussion in Paris.

Looking forward to comments and discussions,

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



--------------000807060404070702050904-- From flefauch@cisco.com Tue Mar 20 02:22: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 5249C21F87B0 for ; Tue, 20 Mar 2012 02:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.207 X-Spam-Level: X-Spam-Status: No, score=-10.207 tagged_above=-999 required=5 tests=[AWL=0.392, 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 VVDfRQQ8slgO for ; Tue, 20 Mar 2012 02:22:53 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4568321F87B5 for ; Tue, 20 Mar 2012 02:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=5858; q=dns/txt; s=iport; t=1332235373; x=1333444973; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=c0gdG3gEZYppoNIR84m7S7lO30pZoRb8soj/XCIJqDk=; b=ElHwfjVjQ7+3/1crwcCMlwF07fG0qHUUVcT3M83uN2h6PZW3mr2zZz8D 89kQeoPUWzE4beFgkPTzxYgjfWFMA3CWtext0SBU5UCXZUwSF+Msk6ZuJ ZR+IBPjmmL9mob+SRyJN3PolHwoAdx/BE3LjSLNEXkKPy36e0Njl0N9MC Y=; X-IronPort-AV: E=Sophos;i="4.73,617,1325462400"; d="scan'208";a="68866653" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 20 Mar 2012 09:22:52 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2K9Mpmp030174; Tue, 20 Mar 2012 09:22:51 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Francois Le Faucheur In-Reply-To: <20120305160316.5234.87849.idtracker@ietfa.amsl.com> Date: Tue, 20 Mar 2012 10:22:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <73AF50D3-F8ED-41E7-B7F1-F5F590D31B5B@cisco.com> References: <20120305160316.5234.87849.idtracker@ietfa.amsl.com> To: cdni@ietf.org X-Mailer: Apple Mail (2.1084) Subject: [CDNi] Few high level comments re draft-spp-cdni-rr-foot-cap-semantics-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, 20 Mar 2012 09:22:57 -0000 (As an individual), In my opinion, the content of the cdni-requirements document can be = reflected more accurately and can be leveraged more extensively to start = answering some of the questions. For example: * when listing the cdni-requirements requirements, I recommend = the HIGH/MED/LOW prioritization be stated, as this is very significant = information on the current consensus of what is seen as essential for = the initial WG deliverables and what is not=09 * the "summary" of REQ-1 is misleading and needs to be changed. = It only quotes communicate "excessive load or failure condition" = suggesting the requirement is about exchanging load information, when = the requirement is actually about "coarse information about the = Downstream CDN ability and/or willingness to handle requests from the = Upstream CDN" and when mentioning load as _an example_ it qualifies it = as a "binary signal" -aka an aggregate CDN level busy-tone. * the requirement related to support of cascaded CDNs must be = included as it impacts the overall solution: " REQ-3 [MED] In the case of cascaded redirection, the CDNI Request- Routing interface shall allow the Downstream CDN to also include in the information communicated to the Upstream CDN, information on the capabilities, resources and affinities of CDNs to which the Downstream CDN may (in turn) redirect requests received by the Upstream CDN. In that case, the CDNI Request-Routing interface shall prevent looping of such information exchange. " * the generic requirements of cdni-requirements that strongly = affect the footprint & capabilities advertisement interface should be = included. In particular: " GEN-4 [HIGH] The CDNI solution shall not require intra-CDN information to be exposed to other CDNs for effective and efficient delivery of the content. Examples of intra-CDN information include surrogate topology, surrogate status, cached content, etc. " In line with GEN-4, I believe the 2nd of the "candidates for definitions = of a footprint" listed in section 4 (ie "o Footprint could be defined = as the set of the IP addresses of the caches deployed by a CDN.") can be = excluded (at least for initial CDNI WG work). In line with GEN-4, I believe some of the candidate "capabilities" = listed in section 5 (ie individual "Cache Capabilities are: o load, = or "excessive load", o available resources, storage resources, o = failure conditions) can be excluded (at least for initial CDNI WG work). In line with REQ-3, the 3rd bullet of section 4 should not read = "Potentially, a footprint may include ..." but something like "A = footprint needs to be able to include....". Also, I don't look at this = 3rd bullet as an alternative candidate definition to the others: it is a = qualifier to the other definitions (ie whatever "footprint is", a given = footprint advertised by a CDN need to be able to reflect cascaded CDN = footprints in addition to the advertising CDN footprint). =20 As per the recent email thread, I believe there is consensus that the = CDNI footprint & capabilities advertisement interface is all about = helping the uCDN select a dCDN, and not about helping the uCDN to select = a specific cache in the dCDN (at least for the initial CDNI WG work). = While this is already implicitly reflected in the wording of = requirements and description, I would recommend stating this explicitly = to avoid confusion. Regarding the section 1 statement "Footprint advertisement and = capability advertisement need not use the same underlying protocol." : While this is true, it is interesting to consider this in light of the = following statement in section 5 "The dCDN must be able to express = particular capabilities for the delivery in a particular footprint = area." Perhaps, it may be worth expanding the section 5 statement to = point out that where capabilities are to be expressed on a per footprint = area there _may_ be benefit in combining the footprint and capability = advertisements. Cheers Francois On 5 Mar 2012, at 17:03, Internet-Drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : CDNI Request Routing: Footprint and = Capabilities Semantics > Author(s) : Jan Seedorf > Jon Peterson > Stefano Previdi > Filename : draft-spp-cdni-rr-foot-cap-semantics-00.txt > Pages : 17 > Date : 2012-03-05 >=20 > This document tries to capture the semantics of the "Footprint and > Capabilities Advertisment" part of the CDNI Request Routing > interface, i.e. the desired meaning and what "Footprint and > Capabilities Advertisment" is expected to offer within CDNI. The > discussion in this document has the goal to facilitate the choosing > of one or more suitable protocols for "Footprint and Capabilities > Advertisment" within CDNI Request Routing. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-spp-cdni-rr-foot-cap-semantics-0= 0.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-spp-cdni-rr-foot-cap-semantics-00= .txt >=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 Tue Mar 20 02:58: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 904FE21F8792 for ; Tue, 20 Mar 2012 02:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.217 X-Spam-Level: X-Spam-Status: No, score=-10.217 tagged_above=-999 required=5 tests=[AWL=0.381, 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 KVew1r3KqqQp for ; Tue, 20 Mar 2012 02:58:01 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 71B7F21F8776 for ; Tue, 20 Mar 2012 02:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=2259; q=dns/txt; s=iport; t=1332237481; x=1333447081; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=e4jH9nGpVu9Tb54NjgW6QPLMpYNszoEU28t0uz9JlGk=; b=WOrOaBr68LbwI2pHMHvZJI4EjktlZtT4mUmvm5fBe0I3HyXVDR+SyvQG 6Oj1AkPcBJADotScg5y3QGF90rpMTA6yprBbWrj0uiQx0fpo4iTEhhueU 9Ny+Pn5n6RbAu3HArvIZiFSn8heD/VRbmqL3m38ARd+YyGlhGsoAjEUSc o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGhTaE+Q/khN/2dsb2JhbABBtk2BB4IJAQEBBBIBZAIQCwQBEy5OCQY1h2iZIJ8mkBtjBJVfjj+BaIJo X-IronPort-AV: E=Sophos;i="4.73,617,1325462400"; d="scan'208,217";a="68871821" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 20 Mar 2012 09:57:54 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2K9vrA5000686; Tue, 20 Mar 2012 09:57:53 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-651--404537808 From: Francois Le Faucheur In-Reply-To: Date: Tue, 20 Mar 2012 10:57:43 +0100 Message-Id: <39A3F648-AFEA-423D-808A-9B97D616FA99@cisco.com> References: <2779C9F0771F974CAD742BAE6D9904FE24F1886D@DAPHNIS.office.hd> To: Songhaibin X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org Subject: Re: [CDNi] FW: New Version Notification for draft-seedorf-cdni-request-routing-alto-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, 20 Mar 2012 09:58:02 -0000 --Apple-Mail-651--404537808 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 19 Mar 2012, at 13:41, Songhaibin wrote: >=20 > 1) monetary cost might be sensitive and not simple information to be = conveyed. Existing CDN charges different content providers differently, = with consideration of many factors. I agree with Songhaibin: I suspect it is not realistic to try convey = "cost" information as this may be complex, multi-dimensional (eg = depending on volume, time of day, peak streaming bandwidth,..) and not = constrainable to pre-defined rules. I also suspect this would open a = "pandora's box" (or probably better described as a "can of worms") in = the area of litigation ("I received an advertisement update saying it = was cheap and now you say I missed the update saying it was expensive = and you want to charge me a lot"). Cheers Francois =20= --Apple-Mail-651--404537808 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

1) monetary cost = might be sensitive and not simple information to be conveyed. Existing = CDN charges different content providers differently, with consideration = of many factors.

I agree with = Songhaibin: I suspect it is not realistic to try convey "cost" = information as this may be complex, multi-dimensional (eg depending on = volume, time of day, peak streaming bandwidth,..) and not constrainable = to pre-defined rules. I also suspect this would open a "pandora's box" = (or probably better described as a "can of worms") in the area of = litigation ("I received an advertisement update saying it was cheap and = now you say I missed the update saying it was expensive and you want to = charge me a = lot").

Cheers

Francois =  
= --Apple-Mail-651--404537808-- From oran@cisco.com Tue Mar 20 07:16: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 97BA421F8743 for ; Tue, 20 Mar 2012 07:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 ubPgpqiY0l46 for ; Tue, 20 Mar 2012 07:16:34 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id CA07E21F8702 for ; Tue, 20 Mar 2012 07:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=oran@cisco.com; l=4255; q=dns/txt; s=iport; t=1332252994; x=1333462594; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5hxdR62ltriOuK+46klZoP19+POom9BDzJ8/kp32Uws=; b=LmJq7slo5skaDx+z6xwB2JrtdyALtepKw0F3dmBBjSAXJ0ADAo5uVKbe QRwfkhdRuvczJ9ZCZVxqNrzw45HYH6po9BfjA/zsEjK6ms56Fx5F3H74M OypgroLtLVy8fZzMfFSEVodxEz+7VmX8oXM7KXWqggHJlqiKTN/52inHx w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMeQaE+rRDoI/2dsb2JhbABCtlKBB4IJAQEBBAEBAQ8BWwkCEAIBCAQ7BycLFAgJAgQOBQkZh2cBC5gbnyOQG2MElV+OP4Fogmc X-IronPort-AV: E=Sophos;i="4.73,618,1325462400"; d="scan'208,217";a="36884285" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 20 Mar 2012 14:16:34 +0000 Received: from xht-rcd-x02-p.cisco.com (xht-rcd-x02-p.cisco.com [173.37.178.213]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2KEGYZ0012098; Tue, 20 Mar 2012 14:16:34 GMT Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.120]) by xht-rcd-x02-p.cisco.com ([173.37.178.213]) with mapi id 14.02.0283.003; Tue, 20 Mar 2012 07:16:33 -0700 From: "Dave Oran (oran)" To: "Francois Le Faucheur (flefauch)" Thread-Topic: [CDNi] FW: New Version Notification for draft-seedorf-cdni-request-routing-alto-01.txt Thread-Index: AQHNBn/yCDLjOQIVnUaGT98pe0XGIJZzsIUA Date: Tue, 20 Mar 2012 14:16:33 +0000 Message-ID: References: <2779C9F0771F974CAD742BAE6D9904FE24F1886D@DAPHNIS.office.hd> <39A3F648-AFEA-423D-808A-9B97D616FA99@cisco.com> In-Reply-To: <39A3F648-AFEA-423D-808A-9B97D616FA99@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.178.200] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18784.004 x-tm-as-result: No--34.432700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E2C5BD3CEFD640259946586403FB6F64ciscocom_" MIME-Version: 1.0 Cc: "" Subject: Re: [CDNi] FW: New Version Notification for draft-seedorf-cdni-request-routing-alto-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, 20 Mar 2012 14:16:35 -0000 --_000_E2C5BD3CEFD640259946586403FB6F64ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 20, 2012, at 5:57 AM, Francois Le Faucheur wrote: On 19 Mar 2012, at 13:41, Songhaibin wrote: 1) monetary cost might be sensitive and not simple information to be convey= ed. Existing CDN charges different content providers differently, with cons= ideration of many factors. I agree with Songhaibin: I suspect it is not realistic to try convey "cost"= information as this may be complex, multi-dimensional (eg depending on vol= ume, time of day, peak streaming bandwidth,..) and not constrainable to pre= -defined rules. I also suspect this would open a "pandora's box" (or probab= ly better described as a "can of worms") in the area of litigation ("I rece= ived an advertisement update saying it was cheap and now you say I missed t= he update saying it was expensive and you want to charge me a lot"). We faced this exact issue in the design of TRIP 10+ years ago and reached t= he identical conclusion. Don't go there. c.f. (TRIP) (RFC 3219) - Internet Engineering Task Force Cheers Francois _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_E2C5BD3CEFD640259946586403FB6F64ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5A1A107EDC118846BD8696AB6AA45230@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On Mar 20, 2012, at 5:57 AM, Francois Le Faucheur wrote:


On 19 Mar 2012, at 13:41, Songhaibin wrote:

1) monetary cost might be sensitive and not simple information to be= conveyed. Existing CDN charges different content providers differently, wi= th consideration of many factors.

I agree with Songhaibin: I suspect it is not realistic to try convey &= quot;cost" information as this may be complex, multi-dimensional (eg d= epending on volume, time of day, peak streaming bandwidth,..) and not const= rainable to pre-defined rules. I also suspect this would open a "pandora's box" (or probably better described = as a "can of worms") in the area of litigation ("I received = an advertisement update saying it was cheap and now you say I missed the up= date saying it was expensive and you want to charge me a lot").

We faced this exact issue in the design of TRIP 10+ years ago and reach= ed the identical conclusion. Don't go there.


Cheers

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

--_000_E2C5BD3CEFD640259946586403FB6F64ciscocom_-- From Jan.Seedorf@neclab.eu Wed Mar 21 09:46:55 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 E60DC21E805D for ; Wed, 21 Mar 2012 09:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 4EFT8fBrJMrQ for ; Wed, 21 Mar 2012 09:46:51 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7C32C21E804D for ; Wed, 21 Mar 2012 09:46:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 3796A100A04; Wed, 21 Mar 2012 17:48:29 +0100 (CET) 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 U6n9SCZLabjD; Wed, 21 Mar 2012 17:48:29 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 1A99A1009FE; Wed, 21 Mar 2012 17:48:19 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.36]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 21 Mar 2012 17:46:19 +0100 From: Jan Seedorf To: HeXiaoyan , "cdni@ietf.org" Thread-Topic: [CDNi] New draft on Semantics for CDNI Request Routing - Footprint and Capabilities Advertisement Thread-Index: Acz7s1q92FnFNKytTgaKbNcl4d1JmQESWxYAAeEB3/A= Date: Wed, 21 Mar 2012 16:46:19 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24F3B5FE@Polydeuces.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE24F15792@DAPHNIS.office.hd> <016201cd0020$bdfd9b00$39f8d100$@com> In-Reply-To: <016201cd0020$bdfd9b00$39f8d100$@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 Subject: Re: [CDNi] New draft on Semantics for CDNI Request Routing - Footprint and Capabilities 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: Wed, 21 Mar 2012 16:46:56 -0000 Hi Xiaoyan, Thanks for your input, those are the opinions from the WG we are looking fo= r and would like to have discussed. See my answers inline: > -Section 1 Introduction assumption "Footprint advertisement and capabilit= y > advertisement need not use the same underlying protocol." > If capability needs to be associated with a footprint like what is descri= bed > in section 5 of this draft "The dCDN must be able to express particular > capabilities for the delivery in a particular footprint area." , then the > easiest way is to advertise the capability and footprint through one same > message of a protocol. This might be true, and you provide an argument for having both exchanged w= ith one protocol. But the point here is that - for now, at least - we shoul= d not limit ourselves to the assumption that one protocol must be found tha= t does both. It might turn out that protocol A is very suitable for footpri= nt advertisement, but B is much better for capabilities advertisement. > -3.3 Advertisement versus Queries. > Does the concept of this section mean that a uCDN does not store any > capability information of dCDNs in advance, once it receives a routing > request, it queries capabilities of all dCDNs, if there are multiple dCDN= s, > the uCDN needs to query all of them and wait for responses from all of th= em > eventually before making the final decision? Moreover, it will take mor= e > time if one dCDN has its own dCDNs further? To not compromise end user'= s > experience in much advertisement looks better from this perspective. Good point with the timing. I agree that one disadvantage of the "query on = each request" model is that it introduces an additional RTT to the overall = service request. One advantage would be - as written in the section - that = the dCDN might use more information (that it does not want to disclose or t= hat is changing dynamically) for answering a request when it is queried tha= n it would provide through advertisement. The whole point of the section is= that we need to discuss which model we are implicitly assuming. - Jan > -----Original Message----- > From: HeXiaoyan [mailto:hexiaoyan@huawei.com] > Sent: Monday, March 12, 2012 8:21 AM > To: Jan Seedorf; cdni@ietf.org > Subject: RE: [CDNi] New draft on Semantics for CDNI Request Routing - > Footprint and Capabilities Advertisement >=20 > Hi Jan, > Although not having certain answers for most of the listed questions and > looking forward to the working group discussion on them, I'd like to put = my > two cents on this draft here. >=20 > -Section 1 Introduction assumption "Footprint advertisement and capabilit= y > advertisement need not use the same underlying protocol." > If capability needs to be associated with a footprint like what is descri= bed > in section 5 of this draft "The dCDN must be able to express particular > capabilities for the delivery in a particular footprint area." , then the > easiest way is to advertise the capability and footprint through one same > message of a protocol. >=20 >=20 > -3.3 Advertisement versus Queries. > Does the concept of this section mean that a uCDN does not store any > capability information of dCDNs in advance, once it receives a routing > request, it queries capabilities of all dCDNs, if there are multiple dCDN= s, > the uCDN needs to query all of them and wait for responses from all of th= em > eventually before making the final decision? Moreover, it will take mor= e > time if one dCDN has its own dCDNs further? To not compromise end user'= s > experience in much advertisement looks better from this perspective. >=20 >=20 > Best Regards > Xiaoyan(Susan) He >=20 > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Jan > > Seedorf > > Sent: Wednesday, March 07, 2012 12:10 AM > > To: cdni@ietf.org > > Subject: [CDNi] New draft on Semantics for CDNI Request Routing - > Footprint > > and Capabilities Advertisement > > > > CDNI Folks, > > > > As discussed in Taipei, we have submitted a draft that tries to define = the > > semantics for the "Footprint and Capabilities Advertisement" part of CD= NI > > Request Routing, see > > http://tools.ietf.org/html/draft-spp-cdni-rr-foot-cap-semantics-00. In > Taipei, > > Martin had agreed to put effort into this (and indeed he started the > draft, > > thanks!), but since he is currently busy with other tasks, I have > contributed > > some text together with Jon and Stefano. Currently, the draft has a lot= of > open > > issues and questions, which is probably a good thing to get discussions > going. > > > > Abstract: > > This document tries to capture the semantics of the "Footprint and > Capabilities > > Advertisment" part of the CDNI Request Routing interface, i.e. the desi= red > > meaning and what "Footprint and Capabilities Advertisment" is expected = to > > offer within CDNI. The discussion in this document has the goal to > facilitate > > the choosing of one or more suitable protocols for "Footprint and > Capabilities > > Advertisment" within CDNI Request Routing. > > > > If you can think of any other key questions/issues you think need to be > > discussed (which are not contained in the draft yet), please let us kno= w; > we can > > add them in a future version and will try to remember them for the > discussion > > in Paris. > > > > Looking forward to comments and discussions, > > > > - Jan > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From spencer@wonderhamster.org Wed Mar 21 10:05:22 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 B3BF121F85A4; Wed, 21 Mar 2012 10:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 lzd0-eBg2F1n; Wed, 21 Mar 2012 10:05:22 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 1285A21F84F7; Wed, 21 Mar 2012 10:05:22 -0700 (PDT) Received: from [192.168.2.9] (cpe-76-182-255-76.tx.res.rr.com [76.182.255.76]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MGis5-1S6KVm1sxN-00EE8B; Wed, 21 Mar 2012 13:05:21 -0400 Message-ID: <4F6A0A41.3050006@wonderhamster.org> Date: Wed, 21 Mar 2012 12:05:05 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org, opsawg@ietf.org, tsvwg@ietf.org, cdni@ietf.org, dc@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:37kwmDyh1PGtEv1+GuK5JGGumWHU/GEI1BmdmoUug8c hWnMw72RwkhAxsiU6NG7N79qlJQ2XV6Z5awI9Cd48xzXeg5xFU 776j0JR0CGgz/Me5v58EWM1FwIxl3WeJpt1rC5lVJTGIRDApNj Y5EGXhxNayCTqYWx4P27UPyH5xJ2sNZ6axI84XY2/21DUaEibd X2jyXDdNbpDdekwqfzSMsiWaa0wMb7Wy87HIiScZG9r+c85VYG tfT5MBRwtPWjQlRfl1m4rnht0aaWMtrR59lQpOw2/QpT5+wlQu epn5Vg7T+8MSL4TRS9TDCWCg16mEyA/Z8zH6ksI23CL/SnqZNv P5TKeqNw8EBjZjP2pah70i10iOL6ag912CaluRy5Y Subject: [CDNi] Announcing the i2aex BoF 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, 21 Mar 2012 17:05:22 -0000 Hi all, David Harrington asked me to act as BoF Shepherd for the Infrastructure-to-application Information Exposure (i2aex) BoF, and I wanted to make sure that a broad community of interest was aware of this BoF, especially since the BoF is scheduled for Monday, Afternoon Session 1, at 1300 PM. Preliminary discussion has been going on for some time now on the altoext@ietf.org mailing list, mainly among people in some way involved in the standardization the ALTO protocol. In order to have a conversation that's as productive as possible in Paris, we would really like to invite people who are involved on different sides of the same problem to bring their perspective as well. Here's a short description, with the usual pointers. Follow-ups to altoext@ietf.org, please. The goal of the (non-WG-forming) BoF is to investigate infrastructure- to-application information exposure and communications requirements in fully controlled (e.g., data centers) or partially controlled environments (e.g. CDN). Existing mechanisms such as SNMP, IGP, BGP and other protocols that monitor and manage infrastructure may reveal much if not all of the possibly required information, but are typically only accessible to the operators of the network infrastructure. CDNs and data center applications have some requirements to operate over the Internet, possibly between administrative domains. On the other hand, the ALTO protocol was initially designed to address peer-to-peer application requirements, but was designed to be extensible and could be quite easily adapted to export the pieces of information that CDN and data center applications would benefit from. The BoF will thus primarily seek an answer to the following questions: + do CDN and data center applications require (or benefit in a significant way from) accessing to information that cannot be made available through existing mechanisms in a practical way? + is an extension to the ALTO protocol (or to any other protocol) a viable way to address such requirements? Additional information about the topic is available on the BoF wiki entry: http://trac.tools.ietf.org/bof/trac/#Transport The provisional agenda for the meeting is online at: http://www.ietf.org/proceedings/83/agenda/agenda-83-i2aex.txt From Jan.Seedorf@neclab.eu Wed Mar 21 10:50: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 2FB8521E8085 for ; Wed, 21 Mar 2012 10:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, 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 lbUfQqHui+Lk for ; Wed, 21 Mar 2012 10:50:10 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 64EB821E8040 for ; Wed, 21 Mar 2012 10:50:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 959C81009FE; Wed, 21 Mar 2012 18:51:47 +0100 (CET) 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 oXqlAdXy7N41; Wed, 21 Mar 2012 18:51:47 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 7B1971009FD; Wed, 21 Mar 2012 18:51:32 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.36]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 21 Mar 2012 18:49:32 +0100 From: Jan Seedorf To: "Dave Oran (oran)" , "Francois Le Faucheur (flefauch)" Thread-Topic: [CDNi] FW: New Version Notification for draft-seedorf-cdni-request-routing-alto-01.txt Thread-Index: AQHNBqQnvToTz+gTgECezwFkeyRIdpZ1At+g Date: Wed, 21 Mar 2012 17:49:31 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24F3B6C5@Polydeuces.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE24F1886D@DAPHNIS.office.hd> <39A3F648-AFEA-423D-808A-9B97D616FA99@cisco.com> In-Reply-To: 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: "" Subject: Re: [CDNi] FW: New Version Notification for draft-seedorf-cdni-request-routing-alto-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, 21 Mar 2012 17:50:11 -0000 Haibin, Francois, Dave, Thanks for your feedback. I actually share some of your concerns regarding = monetary costs, especially the litigation problem. I am not arguing strongl= y for having monetary costs being advertised by the dCDN. I simply thought,= at the end of the day, a uCDN not only selects a dCDN based on capabilitie= s or footprint, but also on how much it has to pay to the dCDN for deliveri= ng the content (sorry, CDN is a business, and that means money plays a role= ...). Such monetary costs might not be universal and static for a dCDN. He= nce, why not convey e.g. per region delivery costs or similar that can chan= ge e.g. on a daily basis. ALTO could do that. Anyway, I see that it can be problematic and if the WG is having consensus = for not including monetary costs in the advertisement I am fine with it. Ot= her opinions on this topic? - Jan > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Dave Oran (oran) > Sent: Tuesday, March 20, 2012 3:17 PM > To: Francois Le Faucheur (flefauch) > Cc: > Subject: Re: [CDNi] FW: New Version Notification for draft-seedorf-cdni- > request-routing-alto-01.txt >=20 >=20 > On Mar 20, 2012, at 5:57 AM, Francois Le Faucheur wrote: >=20 >=20 >=20 > On 19 Mar 2012, at 13:41, Songhaibin wrote: >=20 >=20 > 1) monetary cost might be sensitive and not simple > information to be conveyed. Existing CDN charges different content > providers differently, with consideration of many factors. >=20 >=20 >=20 > I agree with Songhaibin: I suspect it is not realistic to try convey "co= st" > information as this may be complex, multi-dimensional (eg depending on > volume, time of day, peak streaming bandwidth,..) and not constrainable t= o > pre-defined rules. I also suspect this would open a "pandora's box" (or > probably better described as a "can of worms") in the area of litigation = ("I > received an advertisement update saying it was cheap and now you say I > missed the update saying it was expensive and you want to charge me a > lot"). >=20 >=20 > We faced this exact issue in the design of TRIP 10+ years ago and reached= the > identical conclusion. Don't go there. >=20 > c.f. (TRIP) (RFC 3219) - Internet Engineering Task Force > &ved=3D0CCEQFjAA&url=3Dhttp://www.ietf.org/rfc/rfc3219.txt&ei=3DFpFoT9j- > LsGeiQLXzeTzBg&usg=3DAFQjCNGHASfE2iY89vvrv1g1d_EvtUrsRA> >=20 >=20 > Cheers >=20 > Francois > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 >=20 From vumip1@gmail.com Wed Mar 21 10:50: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 9C90421E808C; Wed, 21 Mar 2012 10:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 Wd0wZ7JN4zPv; Wed, 21 Mar 2012 10:50:31 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 381DB21E8040; Wed, 21 Mar 2012 10:50:31 -0700 (PDT) Received: by yenm5 with SMTP id m5so1308124yen.31 for ; Wed, 21 Mar 2012 10:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zC0cm5QYiRjo5405z/iXCy1JqbVw+rHCtRUW70A0pPs=; b=NP27W+seIGqA/JW8UnZjgNF7vOZqgqPG14AV1VMOkwJNGyLAd/ZqB+4FqhiGkRyY4s aOIeEkHFf1l2GZq6iOhKxR1r8yAoLez+rpVVtfDSZU2D+uICDGnDRah5AlIwRx25Rjkd qwjgTH5llq7Ck5jbhHKg4xlNRpXG2yNAaWMdRnvj3vI5r5ESAZCqBxN5Ks6/VMmTo1yG 36BoxmMVlnNOeK/7oAgGV6uauoWZyYA/gfbTTq2u9lR6Uyizye0S1RLbZVedXLo+T+9G jRTYP8qX1ROLmY/r1jpHpIMkOi07DC0n3DvoRSvqoaYQhows1SrKqq/wY+0Jds0HQs1U JBhw== MIME-Version: 1.0 Received: by 10.182.54.114 with SMTP id i18mr5776882obp.49.1332352230691; Wed, 21 Mar 2012 10:50:30 -0700 (PDT) Received: by 10.182.12.234 with HTTP; Wed, 21 Mar 2012 10:50:30 -0700 (PDT) In-Reply-To: <4F6A0A41.3050006@wonderhamster.org> References: <4F6A0A41.3050006@wonderhamster.org> Date: Wed, 21 Mar 2012 13:50:30 -0400 Message-ID: From: Bhumip Khasnabish To: Spencer Dawkins Content-Type: multipart/alternative; boundary=14dae93a122f6d130b04bbc46d8a Cc: dc@ietf.org, opsawg@ietf.org, cdni@ietf.org, tsvwg@ietf.org, apps-discuss@ietf.org Subject: Re: [CDNi] [dc] Announcing the i2aex BoF 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, 21 Mar 2012 17:50:32 -0000 --14dae93a122f6d130b04bbc46d8a Content-Type: text/plain; charset=ISO-8859-1 Hi Spencer, Is this similar to Cloud Infrastructure Management Interface (CIMI) Model and REST Interface over HTTP An Interface for Managing Cloud Infrastructure( http://dmtf.org/standards/cloud)? What is the trigger for this?! Thanks for clarifying. Best. Bhumip On Wed, Mar 21, 2012 at 1:05 PM, Spencer Dawkins wrote: > Hi all, > > David Harrington asked me to act as BoF Shepherd for the > Infrastructure-to-application Information Exposure (i2aex) BoF, and I > wanted to make sure that a broad community of interest was aware of this > BoF, especially since the BoF is scheduled for Monday, Afternoon Session 1, > at 1300 PM. > > Preliminary discussion has been going on for some time now on the > altoext@ietf.org mailing list, mainly among people in some way involved > in the standardization the ALTO protocol. In order to have a conversation > that's as productive as possible in Paris, we would really like to invite > people who are involved on different sides of the same problem to bring > their perspective as well. > > Here's a short description, with the usual pointers. Follow-ups to > altoext@ietf.org, please. > > The goal of the (non-WG-forming) BoF is to investigate infrastructure- > to-application information exposure and communications requirements in > fully controlled (e.g., data centers) or partially controlled > environments (e.g. CDN). Existing mechanisms such as SNMP, IGP, BGP and > other protocols that monitor and manage infrastructure may reveal much > if not all of the possibly required information, but are typically only > accessible to the operators of the network infrastructure. CDNs and data > center applications have some requirements to operate over the Internet, > possibly between administrative domains. On the other hand, the ALTO > protocol was initially designed to address peer-to-peer application > requirements, but was designed to be extensible and could be quite > easily adapted to export the pieces of information that CDN and data > center applications would benefit from. > > The BoF will thus primarily seek an answer to the following questions: > > + do CDN and data center applications require (or benefit in a > significant way from) accessing to information that cannot be made > available through existing mechanisms in a practical way? > > + is an extension to the ALTO protocol (or to any other protocol) a > viable way to address such requirements? > > Additional information about the topic is available on the BoF wiki > entry: http://trac.tools.ietf.org/**bof/trac/#Transport > > The provisional agenda for the meeting is online at: > http://www.ietf.org/**proceedings/83/agenda/agenda-**83-i2aex.txt > ______________________________**_________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/**listinfo/dc > --14dae93a122f6d130b04bbc46d8a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Spencer,
=A0
Is this similar to Cloud Infrastructure Management Interface (CIMI) Model and REST Interface= over HTTP An Interface for Managing Cloud In= frastructure (http://dmtf.org/standards/cloud)?
=A0
What is the trigger for this?!
=A0
Thanks for clarifying.
=A0
Best.
=A0
Bhumip
=A0

=A0



On Wed, Mar 21, 2012 at 1:05 PM, Spencer Dawkins= <spencer= @wonderhamster.org> wrote:
Hi all,

David Harrington asked= me to act as BoF Shepherd for the Infrastructure-to-application Informatio= n Exposure (i2aex) BoF, and I wanted to make sure that a broad community of= interest was aware of this BoF, especially since the BoF is scheduled for = Monday, Afternoon Session 1, at 1300 PM.

Preliminary discussion has been going on for some time now on the altoext@ietf.org maili= ng list, mainly among people in some way involved in the standardization th= e ALTO protocol. In order to have a conversation that's as productive a= s possible in Paris, we would really like to invite people who are involved= on different sides of the same problem to bring their perspective as well.=

Here's a short description, with the usual pointers. Follow-ups to = altoext@ietf.org,= please.

The goal of the (non-WG-forming) BoF is to investigate infr= astructure-
to-application information exposure and communications requirements in
f= ully controlled (e.g., data centers) or partially controlled
environment= s (e.g. CDN). Existing mechanisms such as SNMP, IGP, BGP and
other proto= cols that monitor and manage infrastructure may reveal much
if not all of the possibly required information, but are typically only
= accessible to the operators of the network infrastructure. CDNs and datacenter applications have some requirements to operate over the Internet, possibly between administrative domains. On the other hand, the ALTO
pro= tocol was initially designed to address peer-to-peer application
require= ments, but was designed to be extensible and could be quite
easily adapt= ed to export the pieces of information that CDN and data
center applications would benefit from.

The BoF will thus primarily = seek an answer to the following questions:

=A0+ do CDN and data cent= er applications require (or benefit in a
=A0 =A0significant way from) ac= cessing to information that cannot be made
=A0 =A0available through existing mechanisms in a practical way?

=A0= + is an extension to the ALTO protocol (or to any other protocol) a
=A0 = =A0viable way to address such requirements?

Additional information a= bout the topic is available on the BoF wiki
entry: http://trac.tools.ietf.org/bof/trac/#Transport

T= he provisional agenda for the meeting is online at:
htt= p://www.ietf.org/proceedings/83/agenda/agenda-83-i2aex.txt
_______________________________________________
dc mailing listdc@ietf.org
https://w= ww.ietf.org/mailman/listinfo/dc


=A0 --14dae93a122f6d130b04bbc46d8a-- From swainner@cisco.com Wed Mar 21 11:05: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 210AF21F857A for ; Wed, 21 Mar 2012 11:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.003 X-Spam-Level: X-Spam-Status: No, score=-10.003 tagged_above=-999 required=5 tests=[AWL=0.595, 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 QE-cU31NZvFU for ; Wed, 21 Mar 2012 11:05:50 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id CC5A321F8578 for ; Wed, 21 Mar 2012 11:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=17633; q=dns/txt; s=iport; t=1332353151; x=1333562751; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=9rg4NDOHSt7pKkuwnIQeyUHvPqBkZLFz6/grZYQZ/5U=; b=WHqWFSNrL5fCRGSJ8+duCFfVlxGaWg4dFd6Z/9Rmczzkn5cvqhEN4Gfa kytpepSL20TSfDsWZT2V648tymJtiYzGhoAufnsdvkotLe51rtU3Ib/e/ gbVAsap9nBp3P9DUa3robloo701fn1X0eDDIGj6+yzt2sQT64vjkuX0bi Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGMXak+rRDoH/2dsb2JhbABEtwmBB4IJAQEBAwEBAQEPARpBCg0ECxEEAQEBCRYEBAcJAwIBAgEVHwkIEwYCAQEeh2MEDJh1nw2KXYYkBJVfjj+BaIMDgTgBFg X-IronPort-AV: E=Sophos;i="4.73,623,1325462400"; d="scan'208,217";a="37097127" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 21 Mar 2012 18:05:50 +0000 Received: from stealth-10-32-245-62.cisco.com (stealth-10-32-245-62.cisco.com [10.32.245.62]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2LI5n5R012668 for ; Wed, 21 Mar 2012 18:05:49 GMT Message-ID: <4F6A187D.5010803@cisco.com> Date: Wed, 21 Mar 2012 14:05:49 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: cdni@ietf.org References: <2779C9F0771F974CAD742BAE6D9904FE24F15792@DAPHNIS.office.hd><016201cd0020$bdfd9b00$39f8d100$@com> <2779C9F0771F974CAD742BAE6D9904FE24F3B5FE@Polydeuces.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE24F3B5FE@Polydeuces.office.hd> Content-Type: multipart/alternative; boundary="------------090401020500090505000209" Subject: Re: [CDNi] New draft on Semantics for CDNI Request Routing - Footprint and Capabilities 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: Wed, 21 Mar 2012 18:05:52 -0000 This is a multi-part message in MIME format. --------------090401020500090505000209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hybrid approach seems appropriate to me. dCDN advertises static aggregate capabilities and footprint to uCDN uCDN can use dCDN static info to choose among many candidate CDN (prioritized) uCDN can query chosen dCDN for current capabilities / footprint If the dCDN capabilities / footprint haven't changed, then the query would likely succeed. If the dCDN capabilities / footprint have temporarily changed, then the uCDN can query the next prioritized dCDN Scott On 3/21/12 12:46 PM, Jan Seedorf wrote: > > Hi Xiaoyan, > > Thanks for your input, those are the opinions from the WG we are > looking for and would like to have discussed. See my answers inline: > > > -Section 1 Introduction assumption "Footprint advertisement and > capability > > advertisement need not use the same underlying protocol." > > If capability needs to be associated with a footprint like what is > described > > in section 5 of this draft "The dCDN must be able to express particular > > capabilities for the delivery in a particular footprint area." , > then the > > easiest way is to advertise the capability and footprint through one > same > > message of a protocol. > This might be true, and you provide an argument for having both > exchanged with one protocol. But the point here is that - for now, at > least - we should not limit ourselves to the assumption that one > protocol must be found that does both. It might turn out that protocol > A is very suitable for footprint advertisement, but B is much better > for capabilities advertisement. > > > -3.3 Advertisement versus Queries. > > Does the concept of this section mean that a uCDN does not store any > > capability information of dCDNs in advance, once it receives a routing > > request, it queries capabilities of all dCDNs, if there are multiple > dCDNs, > > the uCDN needs to query all of them and wait for responses from all > of them > > eventually before making the final decision? Moreover, it will > take more > > time if one dCDN has its own dCDNs further? To not compromise end > user's > > experience in much advertisement looks better from this perspective. > Good point with the timing. I agree that one disadvantage of the > "query on each request" model is that it introduces an additional RTT > to the overall service request. One advantage would be - as written in > the section - that the dCDN might use more information (that it does > not want to disclose or that is changing dynamically) for answering a > request when it is queried than it would provide through > advertisement. The whole point of the section is that we need to > discuss which model we are implicitly assuming. > > - Jan > > > -----Original Message----- > > From: HeXiaoyan [mailto:hexiaoyan@huawei.com] > > Sent: Monday, March 12, 2012 8:21 AM > > To: Jan Seedorf; cdni@ietf.org > > Subject: RE: [CDNi] New draft on Semantics for CDNI Request Routing - > > Footprint and Capabilities Advertisement > > > > Hi Jan, > > Although not having certain answers for most of the listed questions and > > looking forward to the working group discussion on them, I'd like to > put my > > two cents on this draft here. > > > > -Section 1 Introduction assumption "Footprint advertisement and > capability > > advertisement need not use the same underlying protocol." > > If capability needs to be associated with a footprint like what is > described > > in section 5 of this draft "The dCDN must be able to express particular > > capabilities for the delivery in a particular footprint area." , > then the > > easiest way is to advertise the capability and footprint through one > same > > message of a protocol. > > > > > > -3.3 Advertisement versus Queries. > > Does the concept of this section mean that a uCDN does not store any > > capability information of dCDNs in advance, once it receives a routing > > request, it queries capabilities of all dCDNs, if there are multiple > dCDNs, > > the uCDN needs to query all of them and wait for responses from all > of them > > eventually before making the final decision? Moreover, it will > take more > > time if one dCDN has its own dCDNs further? To not compromise end > user's > > experience in much advertisement looks better from this perspective. > > > > > > Best Regards > > Xiaoyan(Susan) He > > > > > -----Original Message----- > > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On > Behalf Of > > Jan > > > Seedorf > > > Sent: Wednesday, March 07, 2012 12:10 AM > > > To: cdni@ietf.org > > > Subject: [CDNi] New draft on Semantics for CDNI Request Routing - > > Footprint > > > and Capabilities Advertisement > > > > > > CDNI Folks, > > > > > > As discussed in Taipei, we have submitted a draft that tries to > define the > > > semantics for the "Footprint and Capabilities Advertisement" part > of CDNI > > > Request Routing, see > > > http://tools.ietf.org/html/draft-spp-cdni-rr-foot-cap-semantics-00. In > > Taipei, > > > Martin had agreed to put effort into this (and indeed he started the > > draft, > > > thanks!), but since he is currently busy with other tasks, I have > > contributed > > > some text together with Jon and Stefano. Currently, the draft has > a lot of > > open > > > issues and questions, which is probably a good thing to get > discussions > > going. > > > > > > Abstract: > > > This document tries to capture the semantics of the "Footprint and > > Capabilities > > > Advertisment" part of the CDNI Request Routing interface, i.e. the > desired > > > meaning and what "Footprint and Capabilities Advertisment" is > expected to > > > offer within CDNI. The discussion in this document has the goal to > > facilitate > > > the choosing of one or more suitable protocols for "Footprint and > > Capabilities > > > Advertisment" within CDNI Request Routing. > > > > > > If you can think of any other key questions/issues you think need > to be > > > discussed (which are not contained in the draft yet), please let > us know; > > we can > > > add them in a future version and will try to remember them for the > > discussion > > > in Paris. > > > > > > Looking forward to comments and discussions, > > > > > > - Jan > > > _______________________________________________ > > > 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 > --------------090401020500090505000209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hybrid approach seems appropriate to me.

dCDN advertises static aggregate capabilities and footprint to uCDN
uCDN can use dCDN static info to choose among many candidate CDN (prioritized)
uCDN can query chosen dCDN for current capabilities / footprint

If the dCDN capabilities / footprint haven't changed, then the query would likely succeed.

If the dCDN capabilities / footprint have temporarily changed, then the uCDN can query the next prioritized dCDN

Scott

On 3/21/12 12:46 PM, Jan Seedorf wrote:
Re: [CDNi] New draft on Semantics for CDNI Request Routing - Footprint and Capabilities Advertisement

Hi Xiaoyan,

Thanks for your input, those are the opinions from the WG we are looking for and would like to have discussed. See my answers inline:

> -Section 1 Introduction assumption "Footprint advertisement and capability
> advertisement need not use the same underlying protocol."
> If capability needs to be associated with a footprint like what is described
> in section 5 of this draft "The dCDN must be able to express particular
> capabilities for the delivery in a particular footprint area." , then the
> easiest way is to advertise the capability and footprint through one same
> message of a protocol.
This might be true, and you provide an argument for having both exchanged with one protocol. But the point here is that - for now, at least - we should not limit ourselves to the assumption that one protocol must be found that does both. It might turn out that protocol A is very suitable for footprint advertisement, but B is much better for capabilities advertisement.

> -3.3 Advertisement versus Queries.
> Does the concept of this section mean that a uCDN does not store any
> capability information of dCDNs in advance, once it receives a routing
> request, it queries capabilities of all dCDNs, if there are multiple dCDNs,
> the uCDN needs to query all of them and wait for responses from all of them
> eventually before making the final decision?  Moreover,  it will take more
> time if one dCDN has its own dCDNs further?   To not compromise end user's
> experience in much advertisement looks better from this perspective.
Good point with the timing. I agree that one disadvantage of the "query on each request" model is that it introduces an additional RTT to the overall service request. One advantage would be - as written in the section - that the dCDN might use more information (that it does not want to disclose or that is changing dynamically) for answering a request when it is queried than it would provide through advertisement. The whole point of the section is that we need to discuss which model we are implicitly assuming.

 - Jan

> -----Original Message-----
> From: HeXiaoyan [mailto:hexiaoyan@huawei.com]
> Sent: Monday, March 12, 2012 8:21 AM
> To: Jan Seedorf; cdni@ietf.org
> Subject: RE: [CDNi] New draft on Semantics for CDNI Request Routing -
> Footprint and Capabilities Advertisement
>
> Hi Jan,
> Although not having certain answers for most of the listed questions and
> looking forward to the working group discussion on them, I'd like to put my
> two cents on this draft here.
>
> -Section 1 Introduction assumption "Footprint advertisement and capability
> advertisement need not use the same underlying protocol."
> If capability needs to be associated with a footprint like what is described
> in section 5 of this draft "The dCDN must be able to express particular
> capabilities for the delivery in a particular footprint area." , then the
> easiest way is to advertise the capability and footprint through one same
> message of a protocol.
>
>
> -3.3 Advertisement versus Queries.
> Does the concept of this section mean that a uCDN does not store any
> capability information of dCDNs in advance, once it receives a routing
> request, it queries capabilities of all dCDNs, if there are multiple dCDNs,
> the uCDN needs to query all of them and wait for responses from all of them
> eventually before making the final decision?  Moreover,  it will take more
> time if one dCDN has its own dCDNs further?   To not compromise end user's
> experience in much advertisement looks better from this perspective.
>
>
> Best Regards
> Xiaoyan(Susan) He
>
> > -----Original Message-----
> > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of
> Jan
> > Seedorf
> > Sent: Wednesday, March 07, 2012 12:10 AM
> > To: cdni@ietf.org
> > Subject: [CDNi] New draft on Semantics for CDNI Request Routing -
> Footprint
> > and Capabilities Advertisement
> >
> > CDNI Folks,
> >
> > As discussed in Taipei, we have submitted a draft that tries to define the
> > semantics for the "Footprint and Capabilities Advertisement" part of CDNI
> > Request Routing, see
> > http://tools.ietf.org/html/draft-spp-cdni-rr-foot-cap-semantics-00. In
> Taipei,
> > Martin had agreed to put effort into this (and indeed he started the
> draft,
> > thanks!), but since he is currently busy with other tasks, I have
> contributed
> > some text together with Jon and Stefano. Currently, the draft has a lot of
> open
> > issues and questions, which is probably a good thing to get discussions
> going.
> >
> > Abstract:
> > This document tries to capture the semantics of the "Footprint and
> Capabilities
> > Advertisment" part of the CDNI Request Routing interface, i.e. the desired
> > meaning and what "Footprint and Capabilities Advertisment" is expected to
> > offer within CDNI.  The discussion in this document has the goal to
> facilitate
> > the choosing of one or more suitable protocols for "Footprint and
> Capabilities
> > Advertisment" within CDNI Request Routing.
> >
> > If you can think of any other key questions/issues you think need to be
> > discussed (which are not contained in the draft yet), please let us know;
> we can
> > add them in a future version and will try to remember them for the
> discussion
> > in Paris.
> >
> > Looking forward to comments and discussions,
> >
> >  - Jan
> > _______________________________________________
> > 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


--------------090401020500090505000209-- From richard_woundy@cable.comcast.com Wed Mar 21 11:55: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 1DACA21E80A4 for ; Wed, 21 Mar 2012 11:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[AWL=-1.142, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 N6c8RCGoJ8dj for ; Wed, 21 Mar 2012 11:55:09 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7C521E8054 for ; Wed, 21 Mar 2012 11:55:09 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.10343714; Wed, 21 Mar 2012 12:43:09 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Wed, 21 Mar 2012 14:55:05 -0400 From: "Woundy, Richard" To: "cdni@ietf.org" Thread-Topic: Presentations for CDNI sessions at IETF 83 Thread-Index: Ac0HlBksheYoQmBvRhCvnR/DFLCA9w== Date: Wed, 21 Mar 2012 18:55:04 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1319FD2A8@PACDCEXMB05.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.173] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD1319FD2A8PACDCEXMB05cabl_" MIME-Version: 1.0 Subject: [CDNi] Presentations for CDNI sessions at IETF 83 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 18:55:10 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD1319FD2A8PACDCEXMB05cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Presenters, Please send a draft copy of your presentation to Francois and myself by Tue= sday March 27 at 1200 CET. This process will allow the chairs to review your presentations, and to pos= t the slides for participants to read prior to our sessions on Thursday and= Friday. -- Rich --_000_1CA25301D2219F40B3AA37201F0EACD1319FD2A8PACDCEXMB05cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Presenters,

 

Please send a draft copy of your presentation to Fra= ncois and myself by Tuesday March 27 at 1200 CET.

 

This process will allow the chairs to review your pr= esentations, and to post the slides for participants to read prior to our s= essions on Thursday and Friday.

 

-- Rich

--_000_1CA25301D2219F40B3AA37201F0EACD1319FD2A8PACDCEXMB05cabl_-- From Jan.Seedorf@neclab.eu Thu Mar 22 05:38: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 BE18F21F8542 for ; Thu, 22 Mar 2012 05:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 kfzKExtfzKQg for ; Thu, 22 Mar 2012 05:38:59 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id A335A21F853A for ; Thu, 22 Mar 2012 05:38:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id D3E0C100A23; Thu, 22 Mar 2012 13:40:43 +0100 (CET) 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 wPxN8t9n6Tz1; Thu, 22 Mar 2012 13:40:43 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id B112D100A1E; Thu, 22 Mar 2012 13:40:33 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.36]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 22 Mar 2012 13:38:46 +0100 From: Jan Seedorf To: Scott Wainner , "cdni@ietf.org" Thread-Topic: [CDNi] New draft on Semantics for CDNI Request Routing - Footprint and Capabilities Advertisement Thread-Index: Acz7s1q92FnFNKytTgaKbNcl4d1JmQESWxYAAeEB3/AAAQOhgAAozvkQ Date: Thu, 22 Mar 2012 12:38:46 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24F4E3AB@Polydeuces.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE24F15792@DAPHNIS.office.hd><016201cd0020$bdfd9b00$39f8d100$@com> <2779C9F0771F974CAD742BAE6D9904FE24F3B5FE@Polydeuces.office.hd> <4F6A187D.5010803@cisco.com> In-Reply-To: <4F6A187D.5010803@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 Subject: Re: [CDNi] New draft on Semantics for CDNI Request Routing - Footprint and Capabilities 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: Thu, 22 Mar 2012 12:38:59 -0000 Good point, the approaches are not necessarily mutually exclusive. For a hy= brid model you describe below "static aggregate capabilities and footprint"= might actually have a slightly different semantic than the more dynamic / = current footprint & capabilities that a uCDN would query for. So it is prob= ably important to distinguish the two cases; in the end, for the hybrid cas= e different protocols could turn out appropriate for different parts of suc= h a hybrid model. - Jan > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Scott Wainner > Sent: Wednesday, March 21, 2012 7:06 PM > To: cdni@ietf.org > Subject: Re: [CDNi] New draft on Semantics for CDNI Request Routing - > Footprint and Capabilities Advertisement >=20 > Hybrid approach seems appropriate to me. >=20 > dCDN advertises static aggregate capabilities and footprint to uCDN > uCDN can use dCDN static info to choose among many candidate CDN > (prioritized) > uCDN can query chosen dCDN for current capabilities / footprint >=20 > If the dCDN capabilities / footprint haven't changed, then the query woul= d > likely succeed. >=20 > If the dCDN capabilities / footprint have temporarily changed, then the u= CDN > can query the next prioritized dCDN >=20 > Scott >=20 > On 3/21/12 12:46 PM, Jan Seedorf wrote: >=20 > Hi Xiaoyan, >=20 > Thanks for your input, those are the opinions from the WG we are > looking for and would like to have discussed. See my answers inline: >=20 > > -Section 1 Introduction assumption "Footprint advertisement and > capability > > advertisement need not use the same underlying protocol." > > If capability needs to be associated with a footprint like what is > described > > in section 5 of this draft "The dCDN must be able to express > particular > > capabilities for the delivery in a particular footprint area." , then = the > > easiest way is to advertise the capability and footprint through one > same > > message of a protocol. > This might be true, and you provide an argument for having both > exchanged with one protocol. But the point here is that - for now, at lea= st - > we should not limit ourselves to the assumption that one protocol must be > found that does both. It might turn out that protocol A is very suitable = for > footprint advertisement, but B is much better for capabilities advertisem= ent. >=20 > > -3.3 Advertisement versus Queries. > > Does the concept of this section mean that a uCDN does not store > any > > capability information of dCDNs in advance, once it receives a > routing > > request, it queries capabilities of all dCDNs, if there are multiple > dCDNs, > > the uCDN needs to query all of them and wait for responses from > all of them > > eventually before making the final decision? Moreover, it will take > more > > time if one dCDN has its own dCDNs further? To not compromise > end user's > > experience in much advertisement looks better from this > perspective. > Good point with the timing. I agree that one disadvantage of the > "query on each request" model is that it introduces an additional RTT to = the > overall service request. One advantage would be - as written in the secti= on - > that the dCDN might use more information (that it does not want to disclo= se > or that is changing dynamically) for answering a request when it is queri= ed > than it would provide through advertisement. The whole point of the secti= on > is that we need to discuss which model we are implicitly assuming. >=20 > - Jan >=20 > > -----Original Message----- > > From: HeXiaoyan [mailto:hexiaoyan@huawei.com] > > Sent: Monday, March 12, 2012 8:21 AM > > To: Jan Seedorf; cdni@ietf.org > > Subject: RE: [CDNi] New draft on Semantics for CDNI Request > Routing - > > Footprint and Capabilities Advertisement > > > > Hi Jan, > > Although not having certain answers for most of the listed > questions and > > looking forward to the working group discussion on them, I'd like to > put my > > two cents on this draft here. > > > > -Section 1 Introduction assumption "Footprint advertisement and > capability > > advertisement need not use the same underlying protocol." > > If capability needs to be associated with a footprint like what is > described > > in section 5 of this draft "The dCDN must be able to express > particular > > capabilities for the delivery in a particular footprint area." , then = the > > easiest way is to advertise the capability and footprint through one > same > > message of a protocol. > > > > > > -3.3 Advertisement versus Queries. > > Does the concept of this section mean that a uCDN does not store > any > > capability information of dCDNs in advance, once it receives a > routing > > request, it queries capabilities of all dCDNs, if there are multiple > dCDNs, > > the uCDN needs to query all of them and wait for responses from > all of them > > eventually before making the final decision? Moreover, it will take > more > > time if one dCDN has its own dCDNs further? To not compromise > end user's > > experience in much advertisement looks better from this > perspective. > > > > > > Best Regards > > Xiaoyan(Susan) He > > > > > -----Original Message----- > > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On > Behalf Of > > Jan > > > Seedorf > > > Sent: Wednesday, March 07, 2012 12:10 AM > > > To: cdni@ietf.org > > > Subject: [CDNi] New draft on Semantics for CDNI Request > Routing - > > Footprint > > > and Capabilities Advertisement > > > > > > CDNI Folks, > > > > > > As discussed in Taipei, we have submitted a draft that tries to > define the > > > semantics for the "Footprint and Capabilities Advertisement" part > of CDNI > > > Request Routing, see > > > http://tools.ietf.org/html/draft-spp-cdni-rr-foot-cap-semantics- > 00. In > > Taipei, > > > Martin had agreed to put effort into this (and indeed he started > the > > draft, > > > thanks!), but since he is currently busy with other tasks, I have > > contributed > > > some text together with Jon and Stefano. Currently, the draft has > a lot of > > open > > > issues and questions, which is probably a good thing to get > discussions > > going. > > > > > > Abstract: > > > This document tries to capture the semantics of the "Footprint > and > > Capabilities > > > Advertisment" part of the CDNI Request Routing interface, i.e. > the desired > > > meaning and what "Footprint and Capabilities Advertisment" is > expected to > > > offer within CDNI. The discussion in this document has the goal > to > > facilitate > > > the choosing of one or more suitable protocols for "Footprint and > > Capabilities > > > Advertisment" within CDNI Request Routing. > > > > > > If you can think of any other key questions/issues you think need > to be > > > discussed (which are not contained in the draft yet), please let us > know; > > we can > > > add them in a future version and will try to remember them for > the > > discussion > > > in Paris. > > > > > > Looking forward to comments and discussions, > > > > > > - Jan > > > _______________________________________________ > > > 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 From Jan.Seedorf@neclab.eu Thu Mar 22 05:54: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 DE02521F8585 for ; Thu, 22 Mar 2012 05:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 OI3KXHl52Hfu for ; Thu, 22 Mar 2012 05:54:59 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id CF4B721F857F for ; Thu, 22 Mar 2012 05:54:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id F2F54100A25; Thu, 22 Mar 2012 13:56:37 +0100 (CET) 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 Uo85SCoew6ej; Thu, 22 Mar 2012 13:56:37 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id CF9E7100A24; Thu, 22 Mar 2012 13:56:27 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.36]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Thu, 22 Mar 2012 13:54:20 +0100 From: Jan Seedorf To: Songhaibin , "cdni@ietf.org" Thread-Topic: [CDNi] FW: New Version Notification for draft-seedorf-cdni-request-routing-alto-01.txt Thread-Index: Acz+G8Im/HSC35/xQiO9JoAXRYKYjgHre01QAJfFHRA= Date: Thu, 22 Mar 2012 12:54:19 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24F4E3F9@Polydeuces.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE24F1886D@DAPHNIS.office.hd> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] FW: New Version Notification for draft-seedorf-cdni-request-routing-alto-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, 22 Mar 2012 12:55:00 -0000 Hi Haibin, > I just read this document and find it proposes a good way to use ALTO > information for downstream CDN selection. The concepts of PIDs and costs > between PIDs are useful to express the footprint and delivery preferences= . > Here are two comments that I have: Thanks! > 2) the ALTO information provided by dCDN A and dCDN B might be from > different ALTO servers, so the same PID or cost value might have differen= t > meanings and are not comparable. I think when comparing the two, we need > to make sure they are from the same ALTO server. Not necessarily. I actually would envision that each dCDN hosts its own ALT= O server. Section 10.2. of the ALTO protocol draft defines an "ALTO Cost Ty= pe Registry", where it reads "it provides references to particular semantic= s of allocated Cost Types to be applied by both ALTO Servers and applicatio= ns utilizing ALTO Clients." So there is a way to ensure a unified meaning a= cross different ALTO servers. - Jan > -----Original Message----- > From: Songhaibin [mailto:haibin.song@huawei.com] > Sent: Monday, March 19, 2012 1:42 PM > To: Jan Seedorf; cdni@ietf.org > Subject: RE: [CDNi] FW: New Version Notification for draft-seedorf-cdni- > request-routing-alto-01.txt >=20 >=20 > I just read this document and find it proposes a good way to use ALTO > information for downstream CDN selection. The concepts of PIDs and costs > between PIDs are useful to express the footprint and delivery preferences= . > Here are two comments that I have: >=20 > 1) monetary cost might be sensitive and not simple information to be > conveyed. Existing CDN charges different content providers differently, w= ith > consideration of many factors. >=20 > 2) the ALTO information provided by dCDN A and dCDN B might be from > different ALTO servers, so the same PID or cost value might have differen= t > meanings and are not comparable. I think when comparing the two, we need > to make sure they are from the same ALTO server. >=20 > BR, > -Haibin >=20 > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Jan > > Seedorf > > Sent: Saturday, March 10, 2012 1:43 AM > > To: cdni@ietf.org > > Subject: [CDNi] FW: New Version Notification for > > draft-seedorf-cdni-request-routing-alto-01.txt > > > > Hi all, > > > > I have uploaded a new version of the CDNI Request Routing with ALTO > draft. I > > changed the name to draft-seedorf-cdni-request-routing-alto so that it = is > listed in > > the CDNI status pages; we agreed at last IETF that the discussions shou= ld > happen > > mostly in the CDNI WG. As discussed in Taipei, the draft now focusses o= n > dCDN > > selection with ALTO. The draft gives an example how it could work, and > discusses > > some assumptions / considerations for using ALTO. > > > > - Jan > > > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Friday, March 09, 2012 6:40 PM > > To: Jan Seedorf > > Subject: New Version Notification for > > draft-seedorf-cdni-request-routing-alto-01.txt > > > > A new version of I-D, draft-seedorf-cdni-request-routing-alto-01.txt ha= s > been > > successfully submitted by Jan Seedorf and posted to the IETF repository= . > > > > Filename: draft-seedorf-cdni-request-routing-alto > > Revision: 01 > > Title: CDNI Request Routing with ALTO > > Creation date: 2012-03-09 > > WG ID: Individual Submission > > Number of pages: 14 > > > > Abstract: > > Network Service Providers (NSPs) are currently considering to deploy > > Content Delivery Networks (CDNs) within their networks. As a > > consequence of this development, there is a need for interconnecting > > these local CDNs. The necessary interfaces for inter-connecting CDN= s > > are currently being defined in the Content Delivery Networks > > Interconnection (CDNI) WG. This document focusses on the Request > > Routing Interface of CDNI, and more specifically on how the solution= s > > currently being defined in the Application Layer Traffic Optimizatio= n > > (ALTO) WG can improve CDNI request routing. The overall intention > > behind this document is to foster discussions (in the CDNI as well a= s > > in the ALTO WG) regarding if, how, and under what conditions ALTO ca= n > > be useful to optimize CDNI request routing. As basis for this > > discussion, this document provides concrete examples of how ALTO can > > be integrated within CDNI request routing and in particular in the > > process of selecting a downstream CDN. The examples in this documen= t > > are based on the use cases and examples currently being discussed in > > the CDNI WG. > > > > > > > > > > The IETF Secretariat > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From Jan.Seedorf@neclab.eu Thu Mar 22 06:15: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 3793421F858B for ; Thu, 22 Mar 2012 06:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 Cp9tTwUImgFh for ; Thu, 22 Mar 2012 06:15:44 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id F18D921F856F for ; Thu, 22 Mar 2012 06:15:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 3E41310096D; Thu, 22 Mar 2012 14:17:30 +0100 (CET) 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 8XvjBk41Dw4s; Thu, 22 Mar 2012 14:17:30 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 08A27100A2A; Thu, 22 Mar 2012 14:17:20 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.36]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 22 Mar 2012 14:15:32 +0100 From: Jan Seedorf To: Scott Wainner , "cdni@ietf.org" Thread-Topic: [CDNi] New draft on Semantics for CDNI Request Routing - Footprint and Capabilities Advertisement Thread-Index: Acz7s1q92FnFNKytTgaKbNcl4d1JmQKRI+WAAI0GyPA= Date: Thu, 22 Mar 2012 13:15:32 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24F4E43F@Polydeuces.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE24F15792@DAPHNIS.office.hd> <4F677E85.9060301@cisco.com> In-Reply-To: <4F677E85.9060301@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 Subject: Re: [CDNi] New draft on Semantics for CDNI Request Routing - Footprint and Capabilities 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: Thu, 22 Mar 2012 13:15:45 -0000 Hi Scott, Thanks for reading the draft and your detailed comments/views on the issues= . This is exactly the discussion we need to have. Let me comment only to a = few parts of your mail (where I want to add something) below: > Section 4: Bullet 2: Footprint could be defined as the set of the IP add= resses > ... >=20 > I think this is problematic as the dCDN may be changing these address= es > and may not want to expose exactly how many caches are used. In my understanding, the IP-addresses would relate to what kind of end user= requests the dCDN could serve, and not disclose the location of its caches= . > Section 6: Bullet 2: >=20 > I'm inclined to go with an abstract 'boundary'. > It is incumbent upon the uCDN to define the 'boundary' Do you mean the uCDN should specify the boundary type (e.g. AS # vd. IP-pre= fix)? I think the boundary itself, i.e. what IP-prefix a dCDN can serve, ca= n only be defines by the dCDN, not? > I do think AS's make a good candidate for aggregate boundaries What about a situation where an ISP has a very large AS in which multiple C= DNs are deployed, each of these CDNs not covering the whole AS? - Jan > Section 4: Bullet 1: Footprint could be defined by ... similar boundary >=20 > I think this is where we get into trouble because the definition of a > boundary is arbitrary. Clearly, IP addresses are not arbitrary; however,= the > address ranges may be assigned, partitioned, re-allocated, and distribute= d. If > a portion of a prefix is allocated and distributed downstream, then it ma= y > extend beyond the definition of the 'boundary'. >=20 > At a macro level, it is easy to map a set of prefixes to an AS which = has a well > defined 'boundary' of peering points. The caches and client are either i= n the > same AS or they are not. What is interesting is the fact that a client a= nd cache > in the same AS may not provide the 'best' path. The client in AS 1 may > leverage a peering point to AS 2 where the cache of AS-2 is closer than t= he > cache of AS-1. >=20 > In contrast, the use of a geographic 'boundary' such as a city may al= so > create a problem. A client in AS-1 may be in close proximity to a cache = in AS-2 > as defined by the geographic boundary - the same city; however, the > network topology affords no peering between the two AS anywhere close to > that defined 'boundary'. >=20 > I'm inclined to say that a 'boundary' must be confined to a portion o= f an AS > (which represents a contiguous network infrastructure). The semantics of > the 'boundary' must be agreed upon between the dCDN and uCDN. By using > an abstract representation of a 'boundary' the two parties can agree upon > the scope. The 'boundary' could be defined as a particular location, cit= y, > province, or country. Given the uCDN is making a decision between itself > and various dCDN, the uCDN can weight the routing accordingly. The > relationship between uCDN-dCDN1 and uCDN-dCDN2 might have different > weights. >=20 > Section 4: Bullet 2: Footprint could be defined as the set of the IP add= resses > ... >=20 > I think this is problematic as the dCDN may be changing these address= es > and may not want to expose exactly how many caches are used. >=20 > Section 4: Bullet 4: Footprint could alternatively be defined as "a clas= s of end > user requests" ... >=20 > I associate that 'class' label to mean a type of delivery service or = type of > environment that does not necessarily define a footprint. I'm inclined t= o say > that "a class of end user requests" might be more representative of a CDN > capability. While the footprint is still relevant. In most cases, a dCD= N will > want to make all their caches capable of streaming all for all services a= t all > locations; however, that may not be the case. I'm inclined to associate = a > 'capability' to a footprint boundary. While we might have an aggregate > capability (eg. dCDN can deliver HSS), we may have filtered set where som= e > defined 'boundary' portion of the dCDN is not capable of delivering a > particular class of traffic. So now we're starting to correlate capabili= ties to > footprint. I think these generalized capabilities might have a slow rate= of > change. >=20 > Section 5: Bullet 1: Capabilities are types of information ... >=20 > I would define this as the aggregate capability. There is likely a '= per > boundary' capability which the uCDN may also assess. This granularity > (capability per boundary) should be allowed by the protocol while use of = this > granularity should be optional. >=20 > If we use the query model you defined previously, the uCDN might see > that the dCDN has an aggregate capability to delivery a type of service; > therefore, it inquires of the dCDN the option to use the dCDN's services.= The > uCDN might include in the query the 'conditions' upon which the dCDN > should respond (e.g. 'request for this capability in this boundary'). Th= e dCDN > may reject the request in the query model or accept it. >=20 > If we use the notify model you defined previously, the dCDN might hav= e to > indicate there are exceptions to the aggregate capability where certain > 'boundaries' are included in the aggregate or excluded from the aggregate= . >=20 > Section 5: Bullet 2: Some capabilities may change dynamically ... >=20 > I'm inclined to keep the use of the notify model to a minimum. The u= CDN > would need only sufficient knowledge to know that the dCDN USUALLY has a > capability for a given boundary. State transient delivery capabilities w= ithin > the boundary would be handled at the time of query. >=20 > Section 6: Bullet 1: >=20 > a) dCDN push general capabilities for 'boundaries' and persistent > exceptions to capabilities > b) uCDN query for current state of capabilities given previous statem= ent of > dCDN general capabilities > Ex. dCDN says it can service HSS and HLS for a given boundary; > uCDN may query dCDN for current state of capabilities for a given= session > setup >=20 > Section 6: Bullet 2: >=20 > I'm inclined to go with an abstract 'boundary'. > It is incumbent upon the uCDN to define the 'boundary' > It is incumbent upon the dCDN to indicate the capabilities according = to the > defined boundary >=20 > Boundary could be prefix_range, AS, city, country; > I do think AS's make a good candidate for aggregate boundaries > I think BGP Extended Communities make good good candidates for > 'specific boundaries' > The uCDN and dCDN can agree that a BGP Extended Community will > represent a site, city, or country >=20 > Section 6: Bullet 3: >=20 > I'm inclined to have the dCDN advertise static capabilities > I'm inclined to have the uCDN query about dynamic state of those > capabilities as needed >=20 > Section 6: Bullet 4: >=20 > Use abstract representation of 'costs' by means of unit weight > The uCDN and dCDN can negotiate the value of unit weights >=20 > Section 6: Bullet 5: >=20 > I think monetary delivery costs should not be included. Units should= be > used (streams, packets, GB, PPS) >=20 > Section 6: Bullet 6: >=20 > I think this is the 'cascaded' dCDN. I think the 'footprint' of the = tier3 dCDN > would have to be represented in a manner that the tier2 dCDN could > aggregate and represent to the uCDN. The uCDN shouldn't know about the > details of the tier3 dCDN. Eg. tier3 dCDN supports country_x/city_1 and > country_x/city_2. Tier2 dCDN supports country_y and country_x. uCDN > (Tier1) knows that country_x and country_y have coverage via the Tier2 > dCDN. >=20 > Jan, good questions that need to be answered ... >=20 > Scott >=20 >=20 > On 3/6/12 11:09 AM, Jan Seedorf wrote: >=20 > CDNI Folks, >=20 > As discussed in Taipei, we have submitted a draft that tries to define > the semantics for the "Footprint and Capabilities Advertisement" part of > CDNI Request Routing, see http://tools.ietf.org/html/draft-spp-cdni-rr-fo= ot- > cap-semantics-00. In Taipei, Martin had agreed to put effort into this (a= nd > indeed he started the draft, thanks!), but since he is currently busy wit= h > other tasks, I have contributed some text together with Jon and Stefano. > Currently, the draft has a lot of open issues and questions, which is pro= bably > a good thing to get discussions going. >=20 > Abstract: > This document tries to capture the semantics of the "Footprint and > Capabilities Advertisment" part of the CDNI Request Routing interface, i.= e. > the desired meaning and what "Footprint and Capabilities Advertisment" is > expected to offer within CDNI. The discussion in this document has the g= oal > to facilitate the choosing of one or more suitable protocols for "Footpri= nt and > Capabilities Advertisment" within CDNI Request Routing. >=20 > If you can think of any other key questions/issues you think need to > be discussed (which are not contained in the draft yet), please let us kn= ow; > we can add them in a future version and will try to remember them for the > discussion in Paris. >=20 > Looking forward to comments and discussions, >=20 > - Jan > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 >=20 >=20 From Jan.Seedorf@neclab.eu Thu Mar 22 06:29: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 3E48721F8622 for ; Thu, 22 Mar 2012 06:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 B3cpwVU8a7hB for ; Thu, 22 Mar 2012 06:29:24 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id DAC3221F8578 for ; Thu, 22 Mar 2012 06:29:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 45994100A0B; Thu, 22 Mar 2012 14:31:10 +0100 (CET) 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 aLPQj3FuLRk8; Thu, 22 Mar 2012 14:31:10 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 243891009E0; Thu, 22 Mar 2012 14:31:00 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.36]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Thu, 22 Mar 2012 14:29:13 +0100 From: Jan Seedorf To: Jan Seedorf , Scott Wainner , "cdni@ietf.org" Thread-Topic: [CDNi] New draft on Semantics for CDNI Request Routing - Footprint and Capabilities Advertisement Thread-Index: Acz7s1q92FnFNKytTgaKbNcl4d1JmQKRI+WAAI0GyPAAAOFPkA== Date: Thu, 22 Mar 2012 13:29:12 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24F4E46A@Polydeuces.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE24F15792@DAPHNIS.office.hd> <4F677E85.9060301@cisco.com> <2779C9F0771F974CAD742BAE6D9904FE24F4E43F@Polydeuces.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE24F4E43F@Polydeuces.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] New draft on Semantics for CDNI Request Routing - Footprint and Capabilities 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: Thu, 22 Mar 2012 13:29:25 -0000 Correction: > > Section 4: Bullet 2: Footprint could be defined as the set of the IP > addresses > > ... > > > > I think this is problematic as the dCDN may be changing these addre= sses > > and may not want to expose exactly how many caches are used. > In my understanding, the IP-addresses would relate to what kind of end us= er > requests the dCDN could serve, and not disclose the location of its cache= s. I just read again the full text of that bullet and it indeed talks about "I= P addresses of the caches deployed by a CDN". That is indeed most likely no= t in scope for the initial CDNI work, as also pointed out by Francois. - Jan > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Jan Seedorf > Sent: Thursday, March 22, 2012 2:16 PM > To: Scott Wainner; cdni@ietf.org > Subject: Re: [CDNi] New draft on Semantics for CDNI Request Routing - > Footprint and Capabilities Advertisement >=20 > Hi Scott, >=20 > Thanks for reading the draft and your detailed comments/views on the > issues. This is exactly the discussion we need to have. Let me comment on= ly > to a few parts of your mail (where I want to add something) below: >=20 > > Section 4: Bullet 2: Footprint could be defined as the set of the IP > addresses > > ... > > > > I think this is problematic as the dCDN may be changing these addre= sses > > and may not want to expose exactly how many caches are used. > In my understanding, the IP-addresses would relate to what kind of end us= er > requests the dCDN could serve, and not disclose the location of its cache= s. >=20 > > Section 6: Bullet 2: > > > > I'm inclined to go with an abstract 'boundary'. > > It is incumbent upon the uCDN to define the 'boundary' > Do you mean the uCDN should specify the boundary type (e.g. AS # vd. IP- > prefix)? I think the boundary itself, i.e. what IP-prefix a dCDN can serv= e, can > only be defines by the dCDN, not? >=20 > > I do think AS's make a good candidate for aggregate boundaries > What about a situation where an ISP has a very large AS in which multiple > CDNs are deployed, each of these CDNs not covering the whole AS? >=20 >=20 >=20 > - Jan >=20 >=20 >=20 >=20 > > Section 4: Bullet 1: Footprint could be defined by ... similar boundar= y > > > > I think this is where we get into trouble because the definition of= a > > boundary is arbitrary. Clearly, IP addresses are not arbitrary; howeve= r, the > > address ranges may be assigned, partitioned, re-allocated, and distribu= ted. > If > > a portion of a prefix is allocated and distributed downstream, then it = may > > extend beyond the definition of the 'boundary'. > > > > At a macro level, it is easy to map a set of prefixes to an AS whic= h has a > well > > defined 'boundary' of peering points. The caches and client are either= in > the > > same AS or they are not. What is interesting is the fact that a client= and > cache > > in the same AS may not provide the 'best' path. The client in AS 1 may > > leverage a peering point to AS 2 where the cache of AS-2 is closer than= the > > cache of AS-1. > > > > In contrast, the use of a geographic 'boundary' such as a city may = also > > create a problem. A client in AS-1 may be in close proximity to a cach= e in > AS-2 > > as defined by the geographic boundary - the same city; however, the > > network topology affords no peering between the two AS anywhere close > to > > that defined 'boundary'. > > > > I'm inclined to say that a 'boundary' must be confined to a portion= of an > AS > > (which represents a contiguous network infrastructure). The semantics = of > > the 'boundary' must be agreed upon between the dCDN and uCDN. By > using > > an abstract representation of a 'boundary' the two parties can agree up= on > > the scope. The 'boundary' could be defined as a particular location, c= ity, > > province, or country. Given the uCDN is making a decision between itse= lf > > and various dCDN, the uCDN can weight the routing accordingly. The > > relationship between uCDN-dCDN1 and uCDN-dCDN2 might have different > > weights. > > > > Section 4: Bullet 2: Footprint could be defined as the set of the IP > addresses > > ... > > > > I think this is problematic as the dCDN may be changing these addre= sses > > and may not want to expose exactly how many caches are used. > > > > Section 4: Bullet 4: Footprint could alternatively be defined as "a cl= ass of > end > > user requests" ... > > > > I associate that 'class' label to mean a type of delivery service o= r type of > > environment that does not necessarily define a footprint. I'm inclined= to > say > > that "a class of end user requests" might be more representative of a C= DN > > capability. While the footprint is still relevant. In most cases, a d= CDN will > > want to make all their caches capable of streaming all for all services= at all > > locations; however, that may not be the case. I'm inclined to associat= e a > > 'capability' to a footprint boundary. While we might have an aggregate > > capability (eg. dCDN can deliver HSS), we may have filtered set where > some > > defined 'boundary' portion of the dCDN is not capable of delivering a > > particular class of traffic. So now we're starting to correlate capabi= lities to > > footprint. I think these generalized capabilities might have a slow ra= te of > > change. > > > > Section 5: Bullet 1: Capabilities are types of information ... > > > > I would define this as the aggregate capability. There is likely a= 'per > > boundary' capability which the uCDN may also assess. This granularity > > (capability per boundary) should be allowed by the protocol while use o= f > this > > granularity should be optional. > > > > If we use the query model you defined previously, the uCDN might se= e > > that the dCDN has an aggregate capability to delivery a type of service= ; > > therefore, it inquires of the dCDN the option to use the dCDN's service= s. > The > > uCDN might include in the query the 'conditions' upon which the dCDN > > should respond (e.g. 'request for this capability in this boundary'). = The > dCDN > > may reject the request in the query model or accept it. > > > > If we use the notify model you defined previously, the dCDN might h= ave > to > > indicate there are exceptions to the aggregate capability where certain > > 'boundaries' are included in the aggregate or excluded from the aggrega= te. > > > > Section 5: Bullet 2: Some capabilities may change dynamically ... > > > > I'm inclined to keep the use of the notify model to a minimum. The= uCDN > > would need only sufficient knowledge to know that the dCDN USUALLY has > a > > capability for a given boundary. State transient delivery capabilities= within > > the boundary would be handled at the time of query. > > > > Section 6: Bullet 1: > > > > a) dCDN push general capabilities for 'boundaries' and persistent > > exceptions to capabilities > > b) uCDN query for current state of capabilities given previous stat= ement > of > > dCDN general capabilities > > Ex. dCDN says it can service HSS and HLS for a given boundary; > > uCDN may query dCDN for current state of capabilities for a giv= en > session > > setup > > > > Section 6: Bullet 2: > > > > I'm inclined to go with an abstract 'boundary'. > > It is incumbent upon the uCDN to define the 'boundary' > > It is incumbent upon the dCDN to indicate the capabilities accordin= g to > the > > defined boundary > > > > Boundary could be prefix_range, AS, city, country; > > I do think AS's make a good candidate for aggregate boundaries > > I think BGP Extended Communities make good good candidates for > > 'specific boundaries' > > The uCDN and dCDN can agree that a BGP Extended Community will > > represent a site, city, or country > > > > Section 6: Bullet 3: > > > > I'm inclined to have the dCDN advertise static capabilities > > I'm inclined to have the uCDN query about dynamic state of those > > capabilities as needed > > > > Section 6: Bullet 4: > > > > Use abstract representation of 'costs' by means of unit weight > > The uCDN and dCDN can negotiate the value of unit weights > > > > Section 6: Bullet 5: > > > > I think monetary delivery costs should not be included. Units shou= ld be > > used (streams, packets, GB, PPS) > > > > Section 6: Bullet 6: > > > > I think this is the 'cascaded' dCDN. I think the 'footprint' of th= e tier3 dCDN > > would have to be represented in a manner that the tier2 dCDN could > > aggregate and represent to the uCDN. The uCDN shouldn't know about > the > > details of the tier3 dCDN. Eg. tier3 dCDN supports country_x/city_1 an= d > > country_x/city_2. Tier2 dCDN supports country_y and country_x. uCDN > > (Tier1) knows that country_x and country_y have coverage via the Tier2 > > dCDN. > > > > Jan, good questions that need to be answered ... > > > > Scott > > > > > > On 3/6/12 11:09 AM, Jan Seedorf wrote: > > > > CDNI Folks, > > > > As discussed in Taipei, we have submitted a draft that tries to define > > the semantics for the "Footprint and Capabilities Advertisement" part o= f > > CDNI Request Routing, see http://tools.ietf.org/html/draft-spp-cdni-rr- > foot- > > cap-semantics-00. In Taipei, Martin had agreed to put effort into this = (and > > indeed he started the draft, thanks!), but since he is currently busy w= ith > > other tasks, I have contributed some text together with Jon and Stefano= . > > Currently, the draft has a lot of open issues and questions, which is > probably > > a good thing to get discussions going. > > > > Abstract: > > This document tries to capture the semantics of the "Footprint and > > Capabilities Advertisment" part of the CDNI Request Routing interface, = i.e. > > the desired meaning and what "Footprint and Capabilities Advertisment" = is > > expected to offer within CDNI. The discussion in this document has the > goal > > to facilitate the choosing of one or more suitable protocols for "Footp= rint > and > > Capabilities Advertisment" within CDNI Request Routing. > > > > If you can think of any other key questions/issues you think need to > > be discussed (which are not contained in the draft yet), please let us = know; > > we can add them in a future version and will try to remember them for t= he > > discussion in Paris. > > > > Looking forward to comments and discussions, > > > > - Jan > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni > > > > > > >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From Jan.Seedorf@neclab.eu Thu Mar 22 06:37: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 3611E21F861E for ; Thu, 22 Mar 2012 06:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 LC3+h1F-rmf8 for ; Thu, 22 Mar 2012 06:37:15 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0312D21F861D for ; Thu, 22 Mar 2012 06:37:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 68BDF100A24; Thu, 22 Mar 2012 14:39:01 +0100 (CET) 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 T0dgCHsGSl8s; Thu, 22 Mar 2012 14:39:01 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 42300100A0B; Thu, 22 Mar 2012 14:38:51 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.36]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Thu, 22 Mar 2012 14:37:04 +0100 From: Jan Seedorf To: Francois Le Faucheur , "cdni@ietf.org" Thread-Topic: [CDNi] Few high level comments re draft-spp-cdni-rr-foot-cap-semantics-00.txt Thread-Index: AQHNBnsfkKviFZMPOECEVZKyxrLdSZZ2Tvig Date: Thu, 22 Mar 2012 13:37:03 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24F4E47D@Polydeuces.office.hd> References: <20120305160316.5234.87849.idtracker@ietfa.amsl.com> <73AF50D3-F8ED-41E7-B7F1-F5F590D31B5B@cisco.com> In-Reply-To: <73AF50D3-F8ED-41E7-B7F1-F5F590D31B5B@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 Subject: Re: [CDNi] Few high level comments re draft-spp-cdni-rr-foot-cap-semantics-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, 22 Mar 2012 13:37:16 -0000 Hi Francois, Thanks for reading the draft and your comments. Let me answer inline below: > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Francois Le Faucheur > Sent: Tuesday, March 20, 2012 10:23 AM > To: cdni@ietf.org > Subject: [CDNi] Few high level comments re draft-spp-cdni-rr-foot-cap- > semantics-00.txt >=20 > (As an individual), >=20 > In my opinion, the content of the cdni-requirements document can be > reflected more accurately and can be leveraged more extensively to start > answering some of the questions. >=20 > For example: >=20 > * when listing the cdni-requirements requirements, I recommend > the HIGH/MED/LOW prioritization be stated, as this is very significant > information on the current consensus of what is seen as essential for the > initial WG deliverables and what is not Ok, we will do that in the next revision >=20 > * the "summary" of REQ-1 is misleading and needs to be changed. It > only quotes communicate "excessive load or failure condition" suggesting > the requirement is about exchanging load information, when the > requirement is actually about "coarse information about the Downstream > CDN ability and/or willingness to handle requests from the Upstream CDN" > and when mentioning load as _an example_ it qualifies it as a "binary sig= nal" - > aka an aggregate CDN level busy-tone. Ok, true. The intention for section 2 of our draft was simply to give some = examples that have been mentioned in existing documents regarding the term = "footprint" and "capability". Probably that was not precise in this case, w= ill update it. >=20 > * the requirement related to support of cascaded CDNs must be > included as it impacts the overall solution: > " REQ-3 [MED] In the case of cascaded redirection, the CDNI Request- > Routing interface shall allow the Downstream CDN to also > include in the information communicated to the Upstream CDN, > information on the capabilities, resources and affinities of > CDNs to which the Downstream CDN may (in turn) redirect > requests received by the Upstream CDN. In that case, the > CDNI Request-Routing interface shall prevent looping of such > information exchange. > " Not sure about this one. I read the requirement that the overall CDNI reque= st routing needs to support cascaded CDNs, and that information exchanged n= eeds to include cascaded dCDNs. The question at hand is if the "advertiseme= nt" part also needs to signal such cascading information EXPLICITLY, or if = cascading CDNs merely need to be supported by the redirection part of the r= equest routing interface, i.e. the cascading information is IMPLICITLY incl= uded in the advertisement information. This is to me the open question, whi= ch we try to raise in the draft. But it is probably a good idea to clarify = that a bit more in the draft and to cite the requirement above. >=20 > * the generic requirements of cdni-requirements that strongly affect > the footprint & capabilities advertisement interface should be included. = In > particular: > " GEN-4 [HIGH] The CDNI solution shall not require intra-CDN > information to be exposed to other CDNs for effective and > efficient delivery of the content. Examples of intra-CDN > information include surrogate topology, surrogate status, > cached content, etc. > " >=20 Ok, good idea. Again, we only looked for example definitions in the reqs do= cument for now, that's why it is not included so far. But you are right tha= t this requirement probably precludes certain capabilities. >=20 > In line with GEN-4, I believe the 2nd of the "candidates for definitions = of a > footprint" listed in section 4 (ie "o Footprint could be defined as the = set of > the IP addresses of the caches deployed by a CDN.") can be excluded (at > least for initial CDNI WG work). Agree, true. >=20 > In line with GEN-4, I believe some of the candidate "capabilities" listed= in > section 5 (ie individual "Cache Capabilities are: o load, or "excessi= ve load", > o available resources, storage resources, o failure conditions) can b= e > excluded (at least for initial CDNI WG work). Not sure. In my view, the dCDN could in principle express load not for indi= vidual caches but for caches in a certain region without disclosing details= about its caches. >=20 > In line with REQ-3, the 3rd bullet of section 4 should not read "Potentia= lly, a > footprint may include ..." but something like "A footprint needs to be ab= le to > include....". Also, I don't look at this 3rd bullet as an alternative can= didate > definition to the others: it is a qualifier to the other definitions (ie = whatever > "footprint is", a given footprint advertised by a CDN need to be able to > reflect cascaded CDN footprints in addition to the advertising CDN footpr= int). Good suggestions, we will try to incorporate them. >=20 > As per the recent email thread, I believe there is consensus that the CDN= I > footprint & capabilities advertisement interface is all about helping the= uCDN > select a dCDN, and not about helping the uCDN to select a specific cache = in > the dCDN (at least for the initial CDNI WG work). While this is already > implicitly reflected in the wording of requirements and description, I wo= uld > recommend stating this explicitly to avoid confusion. Ok, we can add a reference to this current consensus. Still, we are trying = to explain the extreme cases of advertisement details, that's why I would l= ike to have the extreme case example with direct redirection to caches in t= he dCDN still in the document. >=20 >=20 > Regarding the section 1 statement "Footprint advertisement and capability > advertisement need not use the same underlying protocol." : > While this is true, it is interesting to consider this in light of the fo= llowing > statement in section 5 "The dCDN must be able to express particular > capabilities for the delivery in a particular footprint area." Perhaps, i= t may be > worth expanding the section 5 statement to point out that where capabilit= ies > are to be expressed on a per footprint area there _may_ be benefit in > combining the footprint and capability advertisements. Sure, we can add that. Again, thanks for the detailed comments that will surely improve the draft. - Jan >=20 >=20 > Cheers >=20 > Francois >=20 >=20 > On 5 Mar 2012, at 17:03, Internet-Drafts@ietf.org wrote: >=20 > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > Title : CDNI Request Routing: Footprint and Capabilities > Semantics > > Author(s) : Jan Seedorf > > Jon Peterson > > Stefano Previdi > > Filename : draft-spp-cdni-rr-foot-cap-semantics-00.txt > > Pages : 17 > > Date : 2012-03-05 > > > > This document tries to capture the semantics of the "Footprint and > > Capabilities Advertisment" part of the CDNI Request Routing > > interface, i.e. the desired meaning and what "Footprint and > > Capabilities Advertisment" is expected to offer within CDNI. The > > discussion in this document has the goal to facilitate the choosing > > of one or more suitable protocols for "Footprint and Capabilities > > Advertisment" within CDNI Request Routing. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-spp-cdni-rr-foot-cap-semantic= s- > 00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-spp-cdni-rr-foot-cap-semantics= - > 00.txt > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From kleung@cisco.com Thu Mar 22 09:00: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 D0B6321F86A3 for ; Thu, 22 Mar 2012 09:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.523 X-Spam-Level: X-Spam-Status: No, score=-9.523 tagged_above=-999 required=5 tests=[AWL=1.076, 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 Ozw6kalMc6Hz for ; Thu, 22 Mar 2012 09:00:06 -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 DEDEF21F85CC for ; Thu, 22 Mar 2012 09:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=2694; q=dns/txt; s=iport; t=1332432005; x=1333641605; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=UZIOxbvJdTSuWYvxUZQSwfkC+34HqByeD2GhLn6sLWo=; b=Q5l7WXcrtlWt24ipGnaWQ3I5UQQPtCfoUWuoJpKJoDwdxpcd3aPOd2ol Z+eMXeoAGyF4pJAR7e3DMgG5cvktJbD8T8rIsjh+ZjyIuLgrMxV0mWbfl CbUsm+qYVqu2woD8oZQg0KPFRjxzrOEOWmYJFDXc5PMPIN39bCYxZB52P Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAO5La0+tJV2Y/2dsb2JhbAA6Crc8gQeCCQEBAQQSAR1JDAQCARkEAQELBhgGAU4IAQEEEwgTB4domVGfKIpagmiCP2MEiCMzm0mBaIMH X-IronPort-AV: E=Sophos;i="4.73,630,1325462400"; d="scan'208";a="68622194" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 22 Mar 2012 16:00:04 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2MG03Sx012898; Thu, 22 Mar 2012 16:00:04 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Mar 2012 09:00:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Mar 2012 09:00:02 -0700 Message-ID: <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1DD4@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: CDNI Requirements for ABR content Thread-Index: Ac0BSJhyMA6ZY4c+Q3uSDuyuYRmJ/QG+E8Pg References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> From: "Kent Leung (kleung)" To: X-OriginalArrivalTime: 22 Mar 2012 16:00:03.0508 (UTC) FILETIME=[D7CF0740:01CD0844] Subject: [CDNi] CDNI Requirements for ABR content 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, 22 Mar 2012 16:00:10 -0000 Tracking requirements from CDNI Interface drafts. Based on the = discussion for draft-lefaucheur-cdni-logging-delivery, we need some = inputs from the WG on the CDNI Logging requirements. Options for logging requirements for ABR content: =A0 1) Event-Based Logging shall be supported [HIGH], Segment-Based Logging = should be supported [MED], and Summary-Based Logging may be supported = [LOW].=20 Reason: The dCDN needs to be aware of ABR content and should log = delivery with the ABR-related fields. ABR is expected to be a very = common delivery format and requires some form of log compression over = very voluminous per-segment logging. ABR content needs to be supported = by CDNs. Related requirement is "GEN-14 [HIGH] The CDNI solution shall = support HTTP Adaptive Bit Rate (ABR) content." OR 2) Event-Based Logging, Segment-Based Logging, and Summary-Based = Logging may be supported [LOW].=20 =09 Reason: Eliminate the need for dCDN to be aware of ABR content. For = example, dCDN is acting in a pure HTTP reverse proxy mode and may not be = aware of that level of information and/or because the control of how to = identify those fields is owned by the CSP and none of CDNs may have = visibility of that mapping information. Such a requirement to force CDNs = and CDNI in general to require such mappings seems to be overkill. Thoughts? Kent -----Original Message----- From: Francois Le Faucheur (flefauch)=20 Sent: Tuesday, March 13, 2012 11:39 AM To: Kent Leung (kleung); Niven-Jenkins Ben Cc: Francois Le Faucheur (flefauch); cdni@ietf.org; Mahesh Viveganandhan = (mvittal) Subject: Re: [CDNi] Comments on = draft-lefaucheur-cdni-logging-delivery-00 Ben, Kent, Trying to extract the key points from the thread: 1) level of requirement for support of HTTP Adaptive Streaming Logging = Session (ie ABR-aware logs): This is a valid question.=20 The I-D proposes that some form of ABR-aware logging be mandatory. The = rationale is that ABR is expected to be a very common delivery format = and requires some form of log compression over very voluminous = per-segment logging. (BTW the I-D currently proposes that both = Segment-Based Logging format and Event-Based Logging format be = mandatory. But come to think of it, having only Event-Based Logging = format mandatory would be sufficient from my viewpoint).=20 Ben argues that ABR-aware logging should not be mandatory as it requires = extra awareness. To get more input, I'd propose we move that requirement level discussion = to the cdni-requirements document, and have the logging I-D only talks = about what such logs would look like. From kleung@cisco.com Thu Mar 22 09:44:29 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 1A14F21F852D for ; Thu, 22 Mar 2012 09:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.613 X-Spam-Level: X-Spam-Status: No, score=-9.613 tagged_above=-999 required=5 tests=[AWL=0.985, 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 XYAzFkOeJEoP for ; Thu, 22 Mar 2012 09:44:26 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3C49321F85EC for ; Thu, 22 Mar 2012 09:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=19655; q=dns/txt; s=iport; t=1332434666; x=1333644266; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=oJG5cVh4MysvsTq5d2LZrpTuxJJGAmuCWxQ6frvGLw4=; b=jpld7nrE+YhEa8aCYL4ocarPWJdv7KsJ8oZX+2gVnzw+rIv0mQHUcurg 2qLraPaasGC7K6DNyEsj9B14aCqkec0q5biFpG23sIRgDMSZkyll1oUGI anEWM2OwHnod5B6ABIDE2EnvPr47IYYhw9WeQFXCrtMHcXa9Tls/Mameo 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMVVa0+rRDoG/2dsb2JhbABEgka0dYEHggkBAQEEEgEJEQNJEAIBGQQBAQsGFwEGAUUJCAEBBBMIEweHZwGZY58pkAFjBIhWm0mBaIMH X-IronPort-AV: E=Sophos;i="4.73,630,1325462400"; d="scan'208,217";a="34668052" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 22 Mar 2012 16:44:25 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2MGiPtA018394; Thu, 22 Mar 2012 16:44:25 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Mar 2012 09:44:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-puzzleid: {03214B59-78CD-4755-AC59-CA49EB539F14} MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD084B.0A468678" x-cr-hashedpuzzle: F4Ik K7oD MfB8 Nf+E N/Gb OBL8 OT9S QlKn RhUw TRHO TpXY VIHe WJT5 WTXk WnJg W639; 2; YwBkAG4AaQBAAGkAZQB0AGYALgBvAHIAZwA7AGoAbwBuAC4AcABlAHQAZQByAHMAbwBuAEAAbgBlAHUAcwB0AGEAcgAuAGIAaQB6AA==; Sosha1_v1; 7; {03214B59-78CD-4755-AC59-CA49EB539F14}; awBsAGUAdQBuAGcAQABjAGkAcwBjAG8ALgBjAG8AbQA=; Thu, 22 Mar 2012 16:44:13 GMT; QwBEAE4ASQAgAFIAZQBxAHUAaQByAGUAbQBlAG4AdABzACAAZgBvAHIAIABkAEMARABOACAAUwB1AHIAcgBvAGcAYQB0AGUAIABlAHgAcABvAHMAdQByAGUA Content-class: urn:content-classes:message Date: Thu, 22 Mar 2012 09:44:13 -0700 Message-ID: <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1E2F@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: CDNI Requirements for dCDN Surrogate exposure Thread-Index: Ac0CHqo7pLfLjllBRUiZiBaKOlUynQGJmaMQ References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net><1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net><4F5E07FA.5090402@cisco.com><5826DF56-7335-49C6-997A-AAB109ED0913@jet-stream.com><2C86FE78-1178-447F-8CB4-5AEA63625679@jet-stream.com><86AF8FF6-4BF3-41D9-837F-21A392C87F83@cisco.com><0CC6542D-0A0E-41FB-B960-6A3763469BC8@jet-stream.com><4F60A188.7080205@cisco.com><6854E730-8B93-447E-83A8-ED0DA7F99824@neustar.biz><7FF9D145-5D9B-4C99-8433-07D340BFA62A@neustar.biz> From: "Kent Leung (kleung)" To: "Francois Le Faucheur (flefauch)" , "Peterson, Jon" X-OriginalArrivalTime: 22 Mar 2012 16:44:25.0661 (UTC) FILETIME=[0A9356D0:01CD084B] Cc: cdni@ietf.org Subject: [CDNi] CDNI Requirements for dCDN Surrogate exposure 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, 22 Mar 2012 16:44:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD084B.0A468678 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tracking requirements from CDNI Interface drafts. Based on the discussion for draft-previdi-cdni-footprint-advertisement, I'd like to confirm if there is any updates needed for the requirements.=20 =20 Is the GEN-4 requirement sufficiently clear? =20 GEN-4 [HIGH] The CDNI solution shall not require intra-CDN information to be exposed to other CDNs for effective and efficient delivery of the content. Examples of intra-CDN information include surrogate topology, surrogate status, cached content, etc. =20 Terminology: =20 Surrogate: A device/function (often called a cache) that interacts with other elements of the CDN for the control and distribution of Content within the CDN and interacts with User Agents for the delivery of the Content. =20 So this is not the debate about high level vs. low level. Just want to confirm the level of description is sufficient for the requirement? Or need additional text for clarification?=20 =20 =20 Kent =20 From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch) Sent: Wednesday, March 14, 2012 1:11 PM To: Peterson, Jon Cc: cdni@ietf.org Subject: Re: [CDNi] New Version Notificationfordraft-previdi-cdni-footprint-advertisement-01.txt =20 Hi Jon, =20 I agree there is some wiggle room about what exact information set a dCDN would provide to the uCDN which requires further discussion (ie pick a spot between a very-high-level approach and a high-enough-level approach). But I believe the requirement below, as well as the intent when it was discussed, clearly excludes low-level approaches where the upstream CDNs gets enough information to make the complete cache selection. I also believe there was consensus that dCDNs did not want to provide visibility on their CDN resource location/status/load... So to define this exact information set to be advertised by a dCDN, I think the following are reasonable guiding principles: * stick to information that is helpful to the uCDN for selecting the dCDN (and not the final cache) * do not expose dCDN caching resources =20 =20 Francois =20 On 14 Mar 2012, at 20:40, Peterson, Jon wrote: =20 While I think I agree with you about the general strategy we should take, judging from the drafts submitted for this IETF and the discussion on the list, I would be less confident about saying there is working group consensus behind it. I think people are still all over the map on this. In part that's because there's a pretty slippery slope between the high-level and the low-level, and the words in the requirement GEN-4 that you site - words like "surrogate topology, surrogate status" - are not precise terms. When we start actually trying to define the semantics, be it in terms of geography, topology, reachability, cache enumeration, what have you, that's when we start to see what people are reading into this words. I think today people are still reading some pretty different things into them. =20 Jon Peterson NeuStar, Inc. =20 On Mar 14, 2012, at 12:30 PM, Francois Le Faucheur wrote: (as an individual) =20 On 14 Mar 2012, at 18:41, Peterson, Jon wrote: =20 We also need to decide how deeply we want a uCDN to understand a dCDNs resources - effectively, we could have very low-level approaches where uCDNs execute the entire request-routing algorithm down to selecting the particular cache, or high-level approaches where the uCDN has only a general sense of dCDN resources and defers cache selection to the dCDN. Once we get some agreement about these points, deciding what type and what granularity of information dCDNs should advertise will be a lot easier. =20 I believe this has been discussed and decided by the working group: =20 >From draft-ietf-cdni-requirements-02: " GEN-4 [HIGH] The CDNI solution shall not require intra-CDN information to be exposed to other CDNs for effective and efficient delivery of the content. Examples of intra-CDN information include surrogate topology, surrogate status, cached content, etc. " =20 I personally support that decision to focus the current/initial CDNI work on "high-level approaches where the uCDN has only a general sense of dCDN resources and defers cache selection to the dCDN". In the future, once high level approaches are working we can look into "very low-level approaches where the uCDNs execute the entire request-routing algorithm down to selecting the particular cache" (if dCDNs are willing to allow that). =20 Cheers =20 Francois =20 =20 Jon Peterson NeuStar, Inc. =20 =20 ------_=_NextPart_001_01CD084B.0A468678 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [CDNi] New Version Notification = fordraft-previdi-cdni-footprint-advertisement-01.txt

Tracking requirements from CDNI Interface drafts. Based on the = discussion for draft-previdi-cdni-footprint-advertisement, I’d = like to confirm if there is any updates needed for the requirements. =

 

Is the GEN-4 requirement sufficiently clear?

 

   GEN-4   [HIGH] The CDNI solution shall not = require intra-CDN

           = information to be exposed to other CDNs for effective = and

           = efficient delivery of the content.  Examples of = intra-CDN

           = information include surrogate topology, surrogate = status,

           cached = content, etc.

 

Terminology:

 

Surrogate: A device/function (often called a cache) that = interacts

   with other elements of the CDN for the control and = distribution of

   Content within the CDN and interacts with User Agents = for the

   delivery of the Content.

 

So this is not the debate about high level vs. low level. Just want = to confirm the level of description is sufficient for the requirement? = Or need additional text for clarification?

 

 

Kent

 

From:= = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Francois Le Faucheur (flefauch)
Sent: Wednesday, March 14, = 2012 1:11 PM
To: Peterson, Jon
Cc: = cdni@ietf.org
Subject: Re: [CDNi] New Version = Notificationfordraft-previdi-cdni-footprint-advertisement-01.txt

 

Hi = Jon,

 

I = agree there is some wiggle room about what exact information set a dCDN = would provide to the uCDN which requires further discussion (ie pick a = spot between a very-high-level approach and a high-enough-level = approach). But I believe the requirement below, as well as the = intent when it was discussed, clearly excludes low-level approaches = where the upstream CDNs gets enough information to make the complete = cache selection. I also believe there was consensus  that dCDNs did = not want to provide visibility on their CDN resource = location/status/load...

So = to define this exact information set to be advertised by a dCDN, I think = the following are reasonable guiding = principles:

        &n= bsp;   * stick to information that is helpful to the = uCDN for selecting the dCDN (and not the final = cache)

        &n= bsp;   * do not expose dCDN caching = resources        =

 

Francois

 

On = 14 Mar 2012, at 20:40, Peterson, Jon wrote:



 

While = I think I agree with you about the general strategy we should take, = judging from the drafts submitted for this IETF and the discussion on = the list, I would be less confident about saying there is working group = consensus behind it. I think people are still all over the map on this. = In part that's because there's a pretty slippery slope between the = high-level and the low-level, and the words in the requirement GEN-4 = that you site - words like "surrogate topology, surrogate = status" - are not precise terms. When we start actually trying to = define the semantics, be it in terms of geography, topology, = reachability, cache enumeration, what have you, that's when we start to = see what people are reading into this words. I think today people are = still reading some pretty different things into = them.

 

Jon Peterson

NeuStar, Inc.

 

On Mar 14, 2012, at 12:30 PM, Francois Le Faucheur = wrote:



(as = an individual)

 

On = 14 Mar 2012, at 18:41, Peterson, Jon = wrote:

 

We also need to decide how deeply we want a uCDN to = understand a dCDNs resources - effectively, we could have very low-level = approaches where uCDNs execute the entire request-routing algorithm down = to selecting the particular cache, or high-level approaches where the = uCDN has only a general sense of dCDN resources and defers cache = selection to the dCDN. Once we get some agreement about these points, = deciding what type and what granularity of information dCDNs should = advertise will be a lot = easier.

 

I = believe this has been discussed and decided by the working = group:

 

From = draft-ietf-cdni-requirements-02:

"

   GEN-4   [HIGH] The CDNI solution = shall not require intra-CDN

           information = to be exposed to other CDNs for effective = and

      =      efficient delivery of the content.  Examples of = intra-CDN

    =        information include surrogate topology, = surrogate status,

  =          cached content, = etc.

"

 

I = personally support that decision to focus the current/initial CDNI work = on "high-level approaches where the uCDN has only a general sense = of dCDN resources and defers cache selection to the dCDN". In the = future, once high level approaches are working we can look into = "very low-level approaches where the uCDNs execute the entire = request-routing algorithm down to selecting the particular cache" = (if dCDNs are willing to allow that).

 

Cheers

 

Francois

 



 

Jon Peterson

NeuStar, Inc.

 

<snip>

 

------_=_NextPart_001_01CD084B.0A468678-- From ietfdbh@comcast.net Thu Mar 22 09:51: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 EECC021F8690 for ; Thu, 22 Mar 2012 09:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.019 X-Spam-Level: X-Spam-Status: No, score=-102.019 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, J_CHICKENPOX_62=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 mGAkUbTVCS5m for ; Thu, 22 Mar 2012 09:50:55 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE5D21F8673 for ; Thu, 22 Mar 2012 09:50:55 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta13.westchester.pa.mail.comcast.net with comcast id ogow1i0031HzFnQ5Dgqv5e; Thu, 22 Mar 2012 16:50:55 +0000 Received: from [192.168.1.33] ([71.233.85.150]) by omta14.westchester.pa.mail.comcast.net with comcast id ogqd1i0073Ecudz3agqlo1; Thu, 22 Mar 2012 16:50:55 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Thu, 22 Mar 2012 12:50:34 -0400 From: David Harrington To: Bhumip Khasnabish , Spencer Dawkins Message-ID: Thread-Topic: [dc] Announcing the i2aex BoF In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: apps-discuss@ietf.org, opsawg@ietf.org, cdni@ietf.org, Tsvwg , dc@ietf.org Subject: Re: [CDNi] [dc] Announcing the i2aex BoF 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, 22 Mar 2012 16:51:07 -0000 Hi Bhumip, Your input would be more helpful if you did the research to answer the question your self and prepared a detailed analysis for the community to review (I.e., write a draft). Is this similar to dmtf's CIMI? I suggest you read the documents on the agenda and read the CIMI spec and compare them to see if they are or are not similar. My experience has been that DMTF works top-down - they tend to develop and abstract architecture first and then encourage implementers to develop detailed specs that fit within the architecture. That sometimes leads to abstract systems that implementers choose not to implement, because the architecture is too all-inclusive, or implementers cherry-pick the features, with the result that different implementations choose different feature sets and then do not interoperate. The IETF uses a bottom-up model; we prefer detailed proposals based on actual experience in the field, and developing highly focused specifications with a small number of mandatory-to-implement features, to ensure cross-vendor interoperation. The result can be messy as compared to a nice top-down architecture, but the IETF has been very successful using this approach, and the Internet community seems to want to keep using this approach. Is the REST interface similar to interfaces being proposed in i2aex? Have you done a feature comparison between the i2aex proposals and the DMTF proposals? I have a concern that the DMTF REST interface might be based on a DMTF abstract architectural model that may or may not actually be used by operators in real-world deployments. A major part of this BOF is to get feedback from real-world operators about what bottom=up technologies they actually use in real-world deployments to mitigate the problems of CDN and DC optimization, and whether operators would benefit from IETF standardization of these bottom-up optimization approaches. Ultimately, the i2aex BOF is about understanding whether IETF should develop extensions to Internet protocols to meet CDN and DC optimization needs when running over the Internet. It is not about developing an abstract all-encompassing architecture for managing clouds. So I have doubts about how much actual overlap exists between the DMTF proposals and the i2aex proposals. I do encourage people involved in this effort to consider whether there is overlap, but they should avoid being sidetracked into some mission that is not an IETF or i2aex BOF mission. My $.04 as Responsible AD for this BOF. -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 3/21/12 1:50 PM, "Bhumip Khasnabish" wrote: >Hi Spencer, > >Is this similar to Cloud Infrastructure Management Interface (CIMI) Model >and REST Interface over HTTP An Interface for Managing Cloud >Infrastructure (http://dmtf.org/standards/cloud)? > >What is the trigger for this?! > >Thanks for clarifying. > >Best. > >Bhumip > > > > >On Wed, Mar 21, 2012 at 1:05 PM, Spencer Dawkins > wrote: > >Hi all, > >David Harrington asked me to act as BoF Shepherd for the >Infrastructure-to-application Information Exposure (i2aex) BoF, and I >wanted to make sure that a broad community of interest was aware of this >BoF, especially since the BoF is scheduled for Monday, Afternoon Session >1, at 1300 PM. > >Preliminary discussion has been going on for some time now on the >altoext@ietf.org mailing list, mainly among people in some way involved >in the standardization the ALTO protocol. In order to have a conversation >that's as productive as possible in Paris, we would really like to invite >people who are involved on different sides of the same problem to bring >their perspective as well. > >Here's a short description, with the usual pointers. Follow-ups to >altoext@ietf.org, please. > >The goal of the (non-WG-forming) BoF is to investigate infrastructure- >to-application information exposure and communications requirements in >fully controlled (e.g., data centers) or partially controlled >environments (e.g. CDN). Existing mechanisms such as SNMP, IGP, BGP and >other protocols that monitor and manage infrastructure may reveal much >if not all of the possibly required information, but are typically only >accessible to the operators of the network infrastructure. CDNs and data >center applications have some requirements to operate over the Internet, >possibly between administrative domains. On the other hand, the ALTO >protocol was initially designed to address peer-to-peer application >requirements, but was designed to be extensible and could be quite >easily adapted to export the pieces of information that CDN and data >center applications would benefit from. > >The BoF will thus primarily seek an answer to the following questions: > > + do CDN and data center applications require (or benefit in a > significant way from) accessing to information that cannot be made > available through existing mechanisms in a practical way? > > + is an extension to the ALTO protocol (or to any other protocol) a > viable way to address such requirements? > >Additional information about the topic is available on the BoF wiki >entry: http://trac.tools.ietf.org/bof/trac/#Transport > >The provisional agenda for the meeting is online at: >http://www.ietf.org/proceedings/83/agenda/agenda-83-i2aex.txt >_______________________________________________ >dc mailing list >dc@ietf.org >https://www.ietf.org/mailman/listinfo/dc > > > > > > From kleung@cisco.com Thu Mar 22 11:11: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 AA9FC21E8028 for ; Thu, 22 Mar 2012 11:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.689 X-Spam-Level: X-Spam-Status: No, score=-9.689 tagged_above=-999 required=5 tests=[AWL=0.910, 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 9jYTZ+ESVcxD for ; Thu, 22 Mar 2012 11:11:44 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E5E1521E8027 for ; Thu, 22 Mar 2012 11:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=2912; q=dns/txt; s=iport; t=1332439904; x=1333649504; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=KNfkpX9IWWlJou5ZVdUBeHcdldLzlUHgK929V9ccyXk=; b=F6AJ58HmcCjAJARUsn0Hsb+/ZygvN4zEmpEhBw3vbIuXg55DMH/L2W6B UsceiovHu9L3M9Oe9VysdESdY6FAnen8slg/xYNIpmv+SzxhLmwsq6uYB ZbSuuId2Z2qYyoBS0UuBWCEsTyRB8742/DUyJVOssAj3pC12z6x77Nq6h M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOVqa0+rRDoI/2dsb2JhbABEtz2BB4IJAQEBBAEBAQ8BHQo0FwQCAQgOAwQBAQsGFwEGASYfCQgCBAESCBqHZwELmVqfHZABYwSIVptJgWiDB4E2Fw X-IronPort-AV: E=Sophos;i="4.73,630,1325462400"; d="scan'208";a="34683542" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 22 Mar 2012 18:11:44 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2MIBixF024999; Thu, 22 Mar 2012 18:11:44 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Mar 2012 11:11:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Mar 2012 11:11:42 -0700 Message-ID: <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1F16@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [CDNi] CDNI Triggers interface Thread-Index: AQHM9yiS9f5MjNMAgUyVfS/GL0lNnZZ2jEQg References: <20120229193726.22156.55872.idtracker@ietfa.amsl.com> From: "Kent Leung (kleung)" To: "Rob Murray" , X-OriginalArrivalTime: 22 Mar 2012 18:11:44.0405 (UTC) FILETIME=[3D1C3C50:01CD0857] Subject: Re: [CDNi] CDNI Triggers interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 18:11:45 -0000 Hi Rob. Nice write-up. Here are some comments on the draft.=20 1. Sect. 2: Nit for "The trigger may request action on either metadata or on content". Reword to "The trigger may request action on either metadata or content"? 2. Sect. 2: Any thoughts on the scalability aspect of using RESTful web service assuming there will be many dCDNs providing delivery service for a uCDN? These triggers will likely apply on all the dCDNs.=20 3. Sect. 4: Typo in "For example, is anticipated that decisions on use of HTTPS for other CDNI interfaces will be adopted for Triggers." 4. Sect. 4.1: The Trigger Request must be processed in the sequence as triggered by the uCDN? Is there a message sequencing method defined? For example, uCDN wants to purge a specific content, then preposition that content. What happens when the message arrives at dCDN out of order? 5. Sect. 4.2: Nit for ".. to cheaply check for change .." Maybe " .. to inherently check for change .."? 6. Sect 4.2: Reword " to indicate the frequency it would like uCDN to poll at." to " to indicate the frequency of polling by the uCDN"? Kent -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Rob Murray Sent: Wednesday, February 29, 2012 1:25 PM To: cdni@ietf.org Subject: [CDNi] CDNI Triggers interface Hi all, I've just uploaded a new draft that proposes a CDNI Triggers interface ... http://datatracker.ietf.org/doc/draft-murray-cdni-triggers/ There was some discussion at the last WG meeting about whether triggers fit best as part of the control or metadata interface - the suggestion was that concrete proposals for the interface might help us spot commonality with one or the other, so let's see! Please take a look, your comments are welcome. Best regards, Rob. On 29/02/2012 19:37, "internet-drafts@ietf.org" wrote: >A new version of I-D, draft-murray-cdni-triggers-00.txt has been >successfully submitted by Rob Murray and posted to the IETF repository. > >Filename: draft-murray-cdni-triggers >Revision: 00 >Title: CDN Interconnect Triggers >Creation date: 2012-02-29 >WG ID: Individual Submission >Number of pages: 33 > >Abstract: > This document proposes a mechanism for a CDN to trigger activity in > an interconnected CDN that is configured to deliver content on its > behalf. The upstream CDN can use this mechanism to request that the > downstream CDN pre-positions metadata or content, or that it re- > validate or purge metadata or content. The upstream CDN can monitor > the status of activity that it has triggered in the downstream CDN. > > > =20 > =20 > > >The IETF Secretariat _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From kleung@cisco.com Thu Mar 22 11:57: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 E2E2921E8028 for ; Thu, 22 Mar 2012 11:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.754 X-Spam-Level: X-Spam-Status: No, score=-9.754 tagged_above=-999 required=5 tests=[AWL=0.845, 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 Ll6QvLf6qjPR for ; Thu, 22 Mar 2012 11:57:40 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id C756621E802A for ; Thu, 22 Mar 2012 11:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=6658; q=dns/txt; s=iport; t=1332442660; x=1333652260; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=We1YA2JxikQ1oo/UFyz5JrhOFcVSrlsC96EGHMUL9P4=; b=WmIH3UxgCfjwrIuoQb+SBRpRIY4C5KFB/9Y7OV68VvSW0hYdt4eI6r10 lFfVaG9WNn9NKS2HW7y3zIBVIxQEs5YXCimkvM02eM3bOjuvbSFGIFWMx bfPN33OKDgahVBPn5U4CWG5LVi9s1siDVet+G9jmsWnGEYAbdyFisDWi8 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPp0a0+rRDoI/2dsb2JhbABEtz2BB4IJAQEBAwEBAQEPAR0KNAsMBAIBGQQBAQsGFwEGASYfCQgBAQQTCAESB4djBAELmUyfHIpohRljBIhWmDuDDoFogweBNQc X-IronPort-AV: E=Sophos;i="4.73,630,1325462400"; d="scan'208";a="37178067" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 22 Mar 2012 18:57:40 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2MIvePH025027 for ; Thu, 22 Mar 2012 18:57:40 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Mar 2012 11:57:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Mar 2012 11:57:39 -0700 Message-ID: <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1F8C@xmb-sjc-235.amer.cisco.com> In-Reply-To: <73AF50D3-F8ED-41E7-B7F1-F5F590D31B5B@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: CDNI Requirements for RRI Thread-Index: Ac0Gew08j+Od3/I2Q5CkqPLnMUZ5dwB4c3Qw References: <20120305160316.5234.87849.idtracker@ietfa.amsl.com> <73AF50D3-F8ED-41E7-B7F1-F5F590D31B5B@cisco.com> From: "Kent Leung (kleung)" To: X-OriginalArrivalTime: 22 Mar 2012 18:57:40.0419 (UTC) FILETIME=[A7D29930:01CD085D] Subject: [CDNi] CDNI Requirements for RRI 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, 22 Mar 2012 18:57:42 -0000 Tracking requirements from CDNI Interface drafts. Based on the discussion for draft-spp-cdni-rr-foot-cap-semantics, I see numerous requirements that were referenced. I noted that they were used as clarifications in reviewing the draft. No comments required updates to the requirements. Just a note to CDNI Interface authors to provide me any requirement issues encountered during the draft review. I may have missed some issues following the topics. Thanks. Kent -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch) Sent: Tuesday, March 20, 2012 2:23 AM To: cdni@ietf.org Subject: [CDNi] Few high level comments redraft-spp-cdni-rr-foot-cap-semantics-00.txt (As an individual), In my opinion, the content of the cdni-requirements document can be reflected more accurately and can be leveraged more extensively to start answering some of the questions. For example: * when listing the cdni-requirements requirements, I recommend the HIGH/MED/LOW prioritization be stated, as this is very significant information on the current consensus of what is seen as essential for the initial WG deliverables and what is not=09 * the "summary" of REQ-1 is misleading and needs to be changed. It only quotes communicate "excessive load or failure condition" suggesting the requirement is about exchanging load information, when the requirement is actually about "coarse information about the Downstream CDN ability and/or willingness to handle requests from the Upstream CDN" and when mentioning load as _an example_ it qualifies it as a "binary signal" -aka an aggregate CDN level busy-tone. * the requirement related to support of cascaded CDNs must be included as it impacts the overall solution: " REQ-3 [MED] In the case of cascaded redirection, the CDNI Request- Routing interface shall allow the Downstream CDN to also include in the information communicated to the Upstream CDN, information on the capabilities, resources and affinities of CDNs to which the Downstream CDN may (in turn) redirect requests received by the Upstream CDN. In that case, the CDNI Request-Routing interface shall prevent looping of such information exchange. " * the generic requirements of cdni-requirements that strongly affect the footprint & capabilities advertisement interface should be included. In particular: " GEN-4 [HIGH] The CDNI solution shall not require intra-CDN information to be exposed to other CDNs for effective and efficient delivery of the content. Examples of intra-CDN information include surrogate topology, surrogate status, cached content, etc. " In line with GEN-4, I believe the 2nd of the "candidates for definitions of a footprint" listed in section 4 (ie "o Footprint could be defined as the set of the IP addresses of the caches deployed by a CDN.") can be excluded (at least for initial CDNI WG work). In line with GEN-4, I believe some of the candidate "capabilities" listed in section 5 (ie individual "Cache Capabilities are: o load, or "excessive load", o available resources, storage resources, o failure conditions) can be excluded (at least for initial CDNI WG work). In line with REQ-3, the 3rd bullet of section 4 should not read "Potentially, a footprint may include ..." but something like "A footprint needs to be able to include....". Also, I don't look at this 3rd bullet as an alternative candidate definition to the others: it is a qualifier to the other definitions (ie whatever "footprint is", a given footprint advertised by a CDN need to be able to reflect cascaded CDN footprints in addition to the advertising CDN footprint). =20 As per the recent email thread, I believe there is consensus that the CDNI footprint & capabilities advertisement interface is all about helping the uCDN select a dCDN, and not about helping the uCDN to select a specific cache in the dCDN (at least for the initial CDNI WG work). While this is already implicitly reflected in the wording of requirements and description, I would recommend stating this explicitly to avoid confusion. Regarding the section 1 statement "Footprint advertisement and capability advertisement need not use the same underlying protocol." : While this is true, it is interesting to consider this in light of the following statement in section 5 "The dCDN must be able to express particular capabilities for the delivery in a particular footprint area." Perhaps, it may be worth expanding the section 5 statement to point out that where capabilities are to be expressed on a per footprint area there _may_ be benefit in combining the footprint and capability advertisements. Cheers Francois On 5 Mar 2012, at 17:03, Internet-Drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directories. >=20 > Title : CDNI Request Routing: Footprint and Capabilities Semantics > Author(s) : Jan Seedorf > Jon Peterson > Stefano Previdi > Filename : draft-spp-cdni-rr-foot-cap-semantics-00.txt > Pages : 17 > Date : 2012-03-05 >=20 > This document tries to capture the semantics of the "Footprint and > Capabilities Advertisment" part of the CDNI Request Routing > interface, i.e. the desired meaning and what "Footprint and > Capabilities Advertisment" is expected to offer within CDNI. The > discussion in this document has the goal to facilitate the choosing > of one or more suitable protocols for "Footprint and Capabilities > Advertisment" within CDNI Request Routing. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-spp-cdni-rr-foot-cap-semantics -00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-spp-cdni-rr-foot-cap-semantics- 00.txt >=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 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Thu Mar 22 12:27: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 0DAC721F8584 for ; Thu, 22 Mar 2012 12:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.227 X-Spam-Level: X-Spam-Status: No, score=-10.227 tagged_above=-999 required=5 tests=[AWL=0.371, 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 8+eEp9Y7eplC for ; Thu, 22 Mar 2012 12:27:48 -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 3E71121F8548 for ; Thu, 22 Mar 2012 12:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=11374; q=dns/txt; s=iport; t=1332444467; x=1333654067; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=M2XA+0ZVk+HNk9VqIYOqE37A0JrFqRyxwvtQyj45FYg=; b=mmwmCKAC7bXozfKhZj0X02dD5mbXtk9EsbhQ47tdI1E1DybUdKyUbaLH iDBaJwPYeMECego4T4GrKh4TL98L0cWOOaIksNOMr2zAoILKUO6K9jw8U D6+c4lRZ/cqulLTjNzvzl3IIIZUCIFATSgEnIu1wBrNcC63rEX49dILxF 8=; X-IronPort-AV: E=Sophos;i="4.73,630,1325462400"; d="scan'208,217";a="133105021" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 22 Mar 2012 19:27:46 +0000 Received: from ams-flefauch-8711.cisco.com (ams-flefauch-8711.cisco.com [10.55.161.194]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2MJRjOn002955; Thu, 22 Mar 2012 19:27:45 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-411--197531014 From: Francois Le Faucheur In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE24F4E47D@Polydeuces.office.hd> Date: Thu, 22 Mar 2012 20:27:50 +0100 Message-Id: <2A1DB62E-0EC6-4667-A7F5-386A6FF86AD7@cisco.com> References: <20120305160316.5234.87849.idtracker@ietfa.amsl.com> <73AF50D3-F8ED-41E7-B7F1-F5F590D31B5B@cisco.com> <2779C9F0771F974CAD742BAE6D9904FE24F4E47D@Polydeuces.office.hd> To: Jan Seedorf X-Mailer: Apple Mail (2.1084) Cc: "cdni@ietf.org" Subject: Re: [CDNi] Few high level comments re draft-spp-cdni-rr-foot-cap-semantics-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, 22 Mar 2012 19:27:49 -0000 --Apple-Mail-411--197531014 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Jan, Looks like we've converged on most points. On the remaining ones: On 22 Mar 2012, at 14:37, Jan Seedorf wrote: >=20 >>=20 >> * the requirement related to support of cascaded CDNs must be >> included as it impacts the overall solution: >> " REQ-3 [MED] In the case of cascaded redirection, the CDNI = Request- >> Routing interface shall allow the Downstream CDN to also >> include in the information communicated to the Upstream = CDN, >> information on the capabilities, resources and affinities = of >> CDNs to which the Downstream CDN may (in turn) redirect >> requests received by the Upstream CDN. In that case, the >> CDNI Request-Routing interface shall prevent looping of = such >> information exchange. >> " > Not sure about this one. I read the requirement that the overall CDNI = request routing needs to support cascaded CDNs, and that information = exchanged needs to include cascaded dCDNs. The question at hand is if = the "advertisement" part also needs to signal such cascading information = EXPLICITLY, or if cascading CDNs merely need to be supported by the = redirection part of the request routing interface, I believe the "advertisement" part also needs to convey the cascaded = information (but flowing in the opposite direction to request = redirection of course). Let's say we have a cascaded CDN scenario where CDN1 may use CDN2 as a = dCDN, and where CDN2 may use CDN3 as a dCDN. Then CDN3 would advertise its footprint to CDN2, and CDN2 would = advertise to CDN1 a footprint that covers CDN2/s footprint and CDN3's = footprint. This is necessary so that CDN1 can select CDN2 for a request = that is within CDN3's footprint. So the CDNI footprint advertisement problem comprises: * an interface between two CDNs to exchange footprint = information * a logic to process incoming footprint information form a dCDN = and decide if/how it is to be re-advertised/aggregated when advertising = footprint to another CDN. I recommend you discuss that aspect. > i.e. the cascading information is IMPLICITLY included in the = advertisement information. This is to me the open question, which we try = to raise in the draft. But it is probably a good idea to clarify that a = bit more in the draft and to cite the requirement above. >=20 >=20 >>=20 >> In line with GEN-4, I believe some of the candidate "capabilities" = listed in >> section 5 (ie individual "Cache Capabilities are: o load, or = "excessive load", >> o available resources, storage resources, o failure conditions) = can be >> excluded (at least for initial CDNI WG work). > Not sure. In my view, the dCDN could in principle express load not for = individual caches but for caches in a certain region without disclosing = details about its caches. Fair enough. Some aggregated information may be reasonable. I suggest = you change text which can currently be understood to mean per-cache = information, into something explaining that aggregate info may be an = interesting trade-off between not "disclosing too much" and being = helpful for CDN selection by uCDN. In fact, the binary/busy signal already mentioned in REQ-1 can be seen = as a very aggregated "excessive load" signal. >=20 > As per the recent email thread, I believe there is consensus that the = CDNI >> footprint & capabilities advertisement interface is all about helping = the uCDN >> select a dCDN, and not about helping the uCDN to select a specific = cache in >> the dCDN (at least for the initial CDNI WG work). While this is = already >> implicitly reflected in the wording of requirements and description, = I would >> recommend stating this explicitly to avoid confusion. > Ok, we can add a reference to this current consensus. Still, we are = trying to explain the extreme cases of advertisement details, > that's why I would like to have the extreme case example with direct = redirection to caches in the dCDN still in the document. Personally, I'm more interested in documenting the consensus on what we = want to do, than extreme cases we don't really want to do, but I am fine = if you want to bring them up as long as you identify them as such (ie = extreme cases we can think of but know we don't want to do). Cheers. Francois --Apple-Mail-411--197531014 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello = Jan,

Looks like we've converged on most points. On = the remaining ones:

On 22 Mar 2012, at 14:37, = Jan Seedorf wrote:


* the = requirement related to support of cascaded CDNs must = be
included as it impacts the = overall solution:
" =   REQ-3   [MED] In the case of cascaded redirection, = the CDNI Request-
=           Routing = interface shall allow the Downstream CDN to = also
=           include in = the information communicated to the Upstream = CDN,
=           information = on the capabilities, resources and affinities = of
=           CDNs to = which the Downstream CDN may (in turn) = redirect
=           requests = received by the Upstream CDN.  In that case, = the
=           CDNI = Request-Routing interface shall prevent looping of = such
=           information = exchange.
"
Not = sure about this one. I read the requirement that the overall CDNI = request routing needs to support cascaded CDNs, and that information = exchanged needs to include cascaded dCDNs. The question at hand is if = the "advertisement" part also needs to signal such cascading information = EXPLICITLY, or if cascading CDNs merely need to be supported by the = redirection part of the request routing = interface,

I believe the = "advertisement" part also needs to convey the cascaded information (but = flowing in the opposite direction to request redirection of = course).
Let's say we have a cascaded CDN scenario where CDN1 = may use CDN2 as a dCDN, and where CDN2 may use CDN3 as a = dCDN.
Then CDN3 would advertise its footprint to CDN2, and = CDN2 would advertise to CDN1 a footprint that covers CDN2/s footprint = and CDN3's footprint. This is necessary so that CDN1 can select CDN2 for = a request that is within CDN3's footprint.
So the CDNI = footprint advertisement problem comprises:
* an = interface between two CDNs to exchange footprint = information
* a logic to process incoming = footprint information form a dCDN and decide if/how it is to be = re-advertised/aggregated when advertising footprint to another = CDN.
I recommend you discuss that aspect.

i.e. the cascading information is IMPLICITLY = included in the advertisement information. This is to me the open = question, which we try to raise in the draft. But it is probably a good = idea to clarify that a bit more in the draft and to cite the requirement = above.



In line with GEN-4, I believe some of the candidate = "capabilities" listed in
section= 5 (ie  individual "Cache Capabilities are:   o =  load, or "excessive load",
o  available resources, storage resources, =   o  failure conditions) can = be
excluded (at least for = initial CDNI WG work).
Not sure. In my view, the dCDN = could in principle express load not for individual caches but for caches = in a certain region without disclosing details about its = caches.

Fair enough. Some = aggregated information may be reasonable. I suggest you change text = which can currently be understood to mean per-cache information, into = something explaining that aggregate info may be an interesting trade-off = between not "disclosing too much" and being helpful for CDN selection by = uCDN.

In fact, the binary/busy signal already = mentioned in REQ-1 can be seen as a very aggregated "excessive load" = signal.


As per = the recent email thread, I believe there is consensus that the = CDNI
footprint & capabilities = advertisement interface is all about helping the = uCDN
select a dCDN, and not = about helping the uCDN to select a specific cache = in
the dCDN (at least for the = initial CDNI WG work). While this is already
implicitly reflected in the wording of requirements and = description, I would
recommend = stating this explicitly to avoid confusion.
Ok, we can = add a reference to this current consensus. Still, we are trying to = explain the extreme cases of advertisement = details,
that's why I = would like to have the extreme case example with direct redirection to = caches in the dCDN still in the = document.

Personally, I'm more = interested in documenting the consensus on what we want to do, than = extreme cases we don't really want to do, but I am fine if you want to = bring them up as long as you identify them as such (ie extreme cases we = can think of but know we don't want to = do).

Cheers.

Francois

= --Apple-Mail-411--197531014-- From ben@niven-jenkins.co.uk Thu Mar 22 19:35: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 3B1D221E8041 for ; Thu, 22 Mar 2012 19:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 nu5by5Rs74rf for ; Thu, 22 Mar 2012 19:35:43 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0A521E804A for ; Thu, 22 Mar 2012 19:35:43 -0700 (PDT) Received: from static-72-71-250-37.cncdnh.fast04.myfairpoint.net ([72.71.250.37] helo=[10.110.1.6]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SAuLt-0005k4-EB; Fri, 23 Mar 2012 02:35:42 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> Date: Fri, 23 Mar 2012 02:35:38 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3DD114F7-40AD-4C42-B964-92D28C48A2A7@niven-jenkins.co.uk> References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> To: Kent Leung (kleung) X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-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: Fri, 23 Mar 2012 02:35:44 -0000 Kent, Comments inline On 8 Mar 2012, at 23:48, Kent Leung (kleung) wrote: >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > Of >>=20 >> Some comments on draft-lefaucheur-cdni-logging-delivery-00. >>=20 >> 1) In section 3.2.1.2 (Segment-Based Log fields) and section 3.2.2.1 >> (Event Based Log Triggers) you mandate support for a number of log >> fields such as abr-protocol, representation, manifest-id and > content-id >> that a downstream CDN may have no ability to generate, for example >> because the downstream CDN is acting in a pure HTTP reverse proxy = mode >> and may not be aware of that level of information and/or because the >> control of how to identify those fields is owned by the CSP and none > of >> CDNs may have visibility of that mapping information. >>=20 >> Such a requirement to force CDNs and CDNI in general to require such >> mappings seems overkill to me. >>=20 >> KL> As stated, "... such aggregation requires a degree of application >> awareness in dCDN to recognize that the many HTTP requests correspond > to >> a single video." So the premise is that the dCDN knows that it's >> delivering ABR content. In some cases, it's possible that the >> representation may not be known. >=20 > And my point is that I don't think that premise holds true and reality > is the opposite, i.e. in general the dCDN will not know what it's > delivering and only some dCDNs will have the application awareness to > produce the log fields you suggest. >=20 > KL> Hmm, if the dCDN is not aware about the ABR session, then Section > 3.2 would not apply since the dCDN considers itself to be delivering > non-ABR content. Non-ABR content delivery does not require the log > fields specified in this section. I don't agree with this logic. If what is being delivered is ABR content = then it is ABR content regardless of whether the dCDN is aware or not = that what it is delivering is ABR content. >> But in general, the log fields contain >> information that are pertinent to an ABR content. >=20 > I am not exactly sure what you mean by this. I agree the fields you > suggest would be useful but I don't think having the application > awareness to generate them should be a mandatory requirement for > interoperability as suggested by section 3.2 >=20 > An implementation of the CDNI Logging interface MUST support logging > for delivery of content using HTTP adaptive streaming in the = Segment- > Based Logging format and the Event-Based Logging format, and MAY > support logging in the Summary-Based Logging format. >=20 > KL> Are these fields in Sect 3.2 useful or applicable for non-ABR > content delivery? No. I sense that I'm still missing your point. If the content is non-ABR the ABR specific fields are obviously not = useful but that's not the point. What the text in the draft is saying is if the *content* that is = delivered is ABR then the dCDN MUST support logging the ABR specific = fields. What it does not say (which might be what you actually mean) is that if = the *content* that is delivered is ABR and if the dCDN is *aware that it = is ABR* then it MUST support logging the ABR specific fields. Anyway I think we're approaching this from the wrong angle. I think we = should agree what needs to be logged for individual HTTP deliveries in = general (whether or not they are ABR) where in the case of ABR a single = delivery corresponds to a single ABR segment request/response. That is = the base level absolutely required for interoperability. If, after that, the group decides to define an optimisation in addition = (or as a replacement in certain cases) for ABR then that is something we = can look at. Ben From ben@niven-jenkins.co.uk Thu Mar 22 20:02: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 DF6E621E8020 for ; Thu, 22 Mar 2012 20:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 BxEQql0b3j19 for ; Thu, 22 Mar 2012 20:02:41 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 15BDD21E8017 for ; Thu, 22 Mar 2012 20:02:41 -0700 (PDT) Received: from static-72-71-250-37.cncdnh.fast04.myfairpoint.net ([72.71.250.37] helo=[10.110.1.6]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SAulz-0003HT-Od; Fri, 23 Mar 2012 03:02:40 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Fri, 23 Mar 2012 03:02:36 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <9871DFEE-4302-4B34-967D-91B333DF1011@niven-jenkins.co.uk> References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> To: Francois Le Faucheur X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org, Viveganandhan Mahesh Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-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: Fri, 23 Mar 2012 03:02:42 -0000 Francois, On 13 Mar 2012, at 18:39, Francois Le Faucheur wrote: > Ben, Kent, >=20 > Trying to extract the key points from the thread: >=20 > 1) level of requirement for support of HTTP Adaptive Streaming Logging = Session (ie ABR-aware logs): > This is a valid question.=20 > The I-D proposes that some form of ABR-aware logging be mandatory. The = rationale is that ABR is expected to be a very common delivery format = and requires some form of log compression over very voluminous = per-segment logging. I agree that ABR produces large volumes of log entries when the dCDN = creates a log entry per HTTP delivery (HTTP response). I agree that compressing those logs in some way before distributing to = uCDNs would be more efficient that not doing so provided the compression = does not result in the loss of information. > (BTW the I-D currently proposes that both Segment-Based Logging format = and Event-Based Logging format be mandatory. But come to think of it, = having only Event-Based Logging format mandatory would be sufficient = from my viewpoint).=20 Some of the confusion from my side might be that I'm not entirely = certain what you are proposing the logging behaviour of the dCDN should = be, i.e. are you arguing that in the case where the dCDN is "ABR aware": 1) We log every single HTTP delivery (HTTP response) individually (let's = ignore whether the format is just "plain" HTTP log fields or "plain" = HTTP log field plus your proposed Segment-Based log fields) and we = produce Event-Based Logs 2) We just produce Event-Based Logs > 4) summarization of Logging info for Adaptive Streaming delivery > I believe some form of summarization is required. The Event-Based = Logging seems like a nice sweet-spot because it achieves a high = summarization gain without losing any info (ie any change in = bandwidth/quality is logged). Except that if all the dCDN produces for ABR content is an Event-Based = Log, the proposed Event-Based Log does lose information compared to a = "plain" HTTP delivery log. For example the proposed Event-Based Log does = not contain all the URLs that were requested by the client, or the = timings of the individual requests/responses, or the sizes of the = individual responses or the cache disposition/Action (TCP_HIT, TCP_MISS, = etc.) of the individual responses. Furthermore, the draft as written does say that, for example an = Event-Based Log entry contains a Cache Disposition/Action field but the = semantics of that field are not clear, i.e. a single event potentially = consists of a >1 HTTP delivery (HTTP response) and in the case where = some of those deliveries/responses were hits and others were misses what = is the correct value to log? The semantics of several other fields in = the Event-Based Log are also unclear. > Ben, it'd be interesting to provide a brief write-up on the = summarization approach you mention so we can evaluate it (an email to = the list woudl be just fine). I will post something to the mailing list when I get a chance. Ben= From hexiaoyan@huawei.com Thu Mar 22 20:24: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 9E92D21F8446 for ; Thu, 22 Mar 2012 20:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=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 LWDNI1UkL0F6 for ; Thu, 22 Mar 2012 20:24:00 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9C20421F8445 for ; Thu, 22 Mar 2012 20:24:00 -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 AEP91328; Thu, 22 Mar 2012 23:24:00 -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; Thu, 22 Mar 2012 20:22:26 -0700 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Mar 2012 20:22:24 -0700 Received: from w36710x (10.144.4.134) by smtpscn.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Mar 2012 11:22:17 +0800 From: HeXiaoyan To: 'Jan Seedorf' , 'Francois Le Faucheur' , References: <20120305160316.5234.87849.idtracker@ietfa.amsl.com> <73AF50D3-F8ED-41E7-B7F1-F5F590D31B5B@cisco.com> <2779C9F0771F974CAD742BAE6D9904FE24F4E47D@Polydeuces.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE24F4E47D@Polydeuces.office.hd> Date: Fri, 23 Mar 2012 11:22:15 +0800 Message-ID: <000901cd08a4$2603bb90$720b32b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: zh-cn Thread-index: AQHNBnsfkKviFZMPOECEVZKyxrLdSZZ2TviggADrHgA= X-Originating-IP: [10.144.4.134] X-CFilter-Loop: Reflected Subject: Re: [CDNi] Few high level comments re draft-spp-cdni-rr-foot-cap-semantics-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, 23 Mar 2012 03:24:01 -0000 Hi, Following the discussion on load, I share the view with Jan that load of caches in a certain region(not any individual cache) make sense for an uCDN to select a dCDN especially while assesses on other factors are quite similar. >> In line with GEN-4, I believe some of the candidate "capabilities" listed in > >section 5 (ie individual "Cache Capabilities are: o load, or "excessive load", > >o available resources, storage resources, o failure conditions) can be > >excluded (at least for initial CDNI WG work). >Not sure. In my view, the dCDN could in principle express load not for individual caches but for caches in a certain region without disclosing details about its caches. Best Regards Xiaoyan(Susan) He > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Jan > Seedorf > Sent: Thursday, March 22, 2012 9:37 PM > To: Francois Le Faucheur; cdni@ietf.org > Subject: Re: [CDNi] Few high level comments re > draft-spp-cdni-rr-foot-cap-semantics-00.txt > > Hi Francois, > > Thanks for reading the draft and your comments. Let me answer inline below: > > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > > Francois Le Faucheur > > Sent: Tuesday, March 20, 2012 10:23 AM > > To: cdni@ietf.org > > Subject: [CDNi] Few high level comments re draft-spp-cdni-rr-foot-cap- > > semantics-00.txt > > > > (As an individual), > > > > In my opinion, the content of the cdni-requirements document can be > > reflected more accurately and can be leveraged more extensively to start > > answering some of the questions. > > > > For example: > > > > * when listing the cdni-requirements requirements, I recommend > > the HIGH/MED/LOW prioritization be stated, as this is very significant > > information on the current consensus of what is seen as essential for the > > initial WG deliverables and what is not > Ok, we will do that in the next revision > > > > > > * the "summary" of REQ-1 is misleading and needs to be changed. It > > only quotes communicate "excessive load or failure condition" suggesting > > the requirement is about exchanging load information, when the > > requirement is actually about "coarse information about the Downstream > > CDN ability and/or willingness to handle requests from the Upstream CDN" > > and when mentioning load as _an example_ it qualifies it as a "binary signal" - > > aka an aggregate CDN level busy-tone. > Ok, true. The intention for section 2 of our draft was simply to give some > examples that have been mentioned in existing documents regarding the term > "footprint" and "capability". Probably that was not precise in this case, will > update it. > > > > > > * the requirement related to support of cascaded CDNs must be > > included as it impacts the overall solution: > > " REQ-3 [MED] In the case of cascaded redirection, the CDNI Request- > > Routing interface shall allow the Downstream CDN to also > > include in the information communicated to the Upstream > CDN, > > information on the capabilities, resources and affinities of > > CDNs to which the Downstream CDN may (in turn) redirect > > requests received by the Upstream CDN. In that case, the > > CDNI Request-Routing interface shall prevent looping of such > > information exchange. > > " > Not sure about this one. I read the requirement that the overall CDNI request > routing needs to support cascaded CDNs, and that information exchanged > needs to include cascaded dCDNs. The question at hand is if the > "advertisement" part also needs to signal such cascading information > EXPLICITLY, or if cascading CDNs merely need to be supported by the > redirection part of the request routing interface, i.e. the cascading information > is IMPLICITLY included in the advertisement information. This is to me the open > question, which we try to raise in the draft. But it is probably a good idea to > clarify that a bit more in the draft and to cite the requirement above. > > > > > > * the generic requirements of cdni-requirements that strongly affect > > the footprint & capabilities advertisement interface should be included. In > > particular: > > " GEN-4 [HIGH] The CDNI solution shall not require intra-CDN > > information to be exposed to other CDNs for effective and > > efficient delivery of the content. Examples of intra-CDN > > information include surrogate topology, surrogate status, > > cached content, etc. > > " > > > Ok, good idea. Again, we only looked for example definitions in the reqs > document for now, that's why it is not included so far. But you are right that > this requirement probably precludes certain capabilities. > > > > > In line with GEN-4, I believe the 2nd of the "candidates for definitions of a > > footprint" listed in section 4 (ie "o Footprint could be defined as the set of > > the IP addresses of the caches deployed by a CDN.") can be excluded (at > > least for initial CDNI WG work). > Agree, true. > > > > > In line with GEN-4, I believe some of the candidate "capabilities" listed in > > section 5 (ie individual "Cache Capabilities are: o load, or "excessive > load", > > o available resources, storage resources, o failure conditions) can be > > excluded (at least for initial CDNI WG work). > Not sure. In my view, the dCDN could in principle express load not for individual > caches but for caches in a certain region without disclosing details about its > caches. > > > > > > In line with REQ-3, the 3rd bullet of section 4 should not read "Potentially, a > > footprint may include ..." but something like "A footprint needs to be able to > > include....". Also, I don't look at this 3rd bullet as an alternative candidate > > definition to the others: it is a qualifier to the other definitions (ie whatever > > "footprint is", a given footprint advertised by a CDN need to be able to > > reflect cascaded CDN footprints in addition to the advertising CDN footprint). > Good suggestions, we will try to incorporate them. > > > > > As per the recent email thread, I believe there is consensus that the CDNI > > footprint & capabilities advertisement interface is all about helping the uCDN > > select a dCDN, and not about helping the uCDN to select a specific cache in > > the dCDN (at least for the initial CDNI WG work). While this is already > > implicitly reflected in the wording of requirements and description, I would > > recommend stating this explicitly to avoid confusion. > Ok, we can add a reference to this current consensus. Still, we are trying to > explain the extreme cases of advertisement details, that's why I would like to > have the extreme case example with direct redirection to caches in the dCDN > still in the document. > > > > > > > > > Regarding the section 1 statement "Footprint advertisement and capability > > advertisement need not use the same underlying protocol." : > > While this is true, it is interesting to consider this in light of the following > > statement in section 5 "The dCDN must be able to express particular > > capabilities for the delivery in a particular footprint area." Perhaps, it may be > > worth expanding the section 5 statement to point out that where capabilities > > are to be expressed on a per footprint area there _may_ be benefit in > > combining the footprint and capability advertisements. > Sure, we can add that. > > Again, thanks for the detailed comments that will surely improve the draft. > > - Jan > > > > > > > Cheers > > > > Francois > > > > > > On 5 Mar 2012, at 17:03, Internet-Drafts@ietf.org wrote: > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : CDNI Request Routing: Footprint and Capabilities > > Semantics > > > Author(s) : Jan Seedorf > > > Jon Peterson > > > Stefano Previdi > > > Filename : draft-spp-cdni-rr-foot-cap-semantics-00.txt > > > Pages : 17 > > > Date : 2012-03-05 > > > > > > This document tries to capture the semantics of the "Footprint and > > > Capabilities Advertisment" part of the CDNI Request Routing > > > interface, i.e. the desired meaning and what "Footprint and > > > Capabilities Advertisment" is expected to offer within CDNI. The > > > discussion in this document has the goal to facilitate the choosing > > > of one or more suitable protocols for "Footprint and Capabilities > > > Advertisment" within CDNI Request Routing. > > > > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-spp-cdni-rr-foot-cap-semantics- > > 00.txt > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > This Internet-Draft can be retrieved at: > > > ftp://ftp.ietf.org/internet-drafts/draft-spp-cdni-rr-foot-cap-semantics- > > 00.txt > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > Internet-Draft directories: http://www.ietf.org/shadow.html > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > > 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 stef@jet-stream.com Fri Mar 23 03:25: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 1353421F84D7 for ; Fri, 23 Mar 2012 03:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[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 OkLHSdZRQ8kP for ; Fri, 23 Mar 2012 03:25:05 -0700 (PDT) Received: from monitor1.jet-stream.nl (smtp.jet-stream.nl [91.196.106.226]) by ietfa.amsl.com (Postfix) with ESMTP id D53D121F8541 for ; Fri, 23 Mar 2012 03:25:04 -0700 (PDT) Received: from [192.168.1.123] (62.82.216.150.static.user.ono.com [62.82.216.150]) (authenticated bits=0) by monitor1.jet-stream.nl (8.13.7/8.13.7) with ESMTP id q2NAP26F023179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 23 Mar 2012 11:25:03 +0100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Stef van der Ziel In-Reply-To: <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1DD4@xmb-sjc-235.amer.cisco.com> Date: Fri, 23 Mar 2012 11:27:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <40E520C4-3637-41D5-8A60-EB3015824E7D@jet-stream.com> References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1DD4@xmb-sjc-235.amer.cisco.com> To: cdni@ietf.org X-Mailer: Apple Mail (2.1257) Subject: Re: [CDNi] CDNI Requirements for ABR content 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, 23 Mar 2012 10:25:09 -0000 Hi, One of the fundamental problems of ABR technologies in general is lack = of true sessions. It's stateless technology. Session control and session logging are lost. Delivery nodes simply log = every segment request without any correlation.=20 Making it impossible to 100% reconstruct a true user session in reports.=20= A side effect is that the number of log entries explode, stressing log = processing and analytics tools. We have seen many CDNs cope with log = processing problems after their content customers switched to ABR. To resolve both problems we have worked with various delivery vendors = for caching / reverse proxy services / appliances to keep track of = actual sessions. They can do this by inserting a session ID to the = manifest and subsequent chunk access logs and then have a separate log = processing service to aggregate all logs back into a single session log. = Alternatively (and preferred) their delivery software or appliance = aggregates these into a true session access log itself. It scales better = and this approach is less prone to errors. (So the claim that any reverse proxy can be used for ABR is false in = real life scenarios since off the shelves proxies and caches don't have = this feature). uCDNs will need to know whether dCDNs support session logging for ABR = content. Since this is a must have requirement for uCDNs, analytics = providers and content providers.=20 If the dCDN does not support this feature then the uCDN will not use the = dCDN. uCDNs and their content providers will not accept bulks of logs = without any correlation to sessions and will not accept educated guessed = session logs but demand actual, 100% exact session information based on = access logs. Their business case depends on this. Therefore I would like to see true ABR session logs this mandatory, or = at least a preferred option, that should be shared via capabilities = exchange.=20 We also have some ideas around instructing clients about sessions so = clients can switch mid-stream between mulitple delivery nodes and = multiple CDNs while keeping the CDNs abilities to track actual user = sessions. But that is a second topic I guess :) Hope this input helps. Best Stef On 22 mrt. 2012, at 17:00, "Kent Leung (kleung)" = wrote: > Tracking requirements from CDNI Interface drafts. Based on the = discussion for draft-lefaucheur-cdni-logging-delivery, we need some = inputs from the WG on the CDNI Logging requirements. >=20 > Options for logging requirements for ABR content: >=20 > 1) Event-Based Logging shall be supported [HIGH], Segment-Based = Logging should be supported [MED], and Summary-Based Logging may be = supported [LOW].=20 >=20 > Reason: The dCDN needs to be aware of ABR content and should log = delivery with the ABR-related fields. ABR is expected to be a very = common delivery format and requires some form of log compression over = very voluminous per-segment logging. ABR content needs to be supported = by CDNs. Related requirement is "GEN-14 [HIGH] The CDNI solution shall = support HTTP Adaptive Bit Rate (ABR) content." >=20 > OR >=20 > 2) Event-Based Logging, Segment-Based Logging, and Summary-Based = Logging may be supported [LOW].=20 >=20 > Reason: Eliminate the need for dCDN to be aware of ABR content. For = example, dCDN is acting in a pure HTTP reverse proxy mode and may not be = aware of that level of information and/or because the control of how to = identify those fields is owned by the CSP and none of CDNs may have = visibility of that mapping information. Such a requirement to force CDNs = and CDNI in general to require such mappings seems to be overkill. >=20 >=20 > Thoughts? >=20 > Kent >=20 >=20 > -----Original Message----- > From: Francois Le Faucheur (flefauch)=20 > Sent: Tuesday, March 13, 2012 11:39 AM > To: Kent Leung (kleung); Niven-Jenkins Ben > Cc: Francois Le Faucheur (flefauch); cdni@ietf.org; Mahesh = Viveganandhan (mvittal) > Subject: Re: [CDNi] Comments on = draft-lefaucheur-cdni-logging-delivery-00 >=20 > Ben, Kent, >=20 > Trying to extract the key points from the thread: >=20 > 1) level of requirement for support of HTTP Adaptive Streaming Logging = Session (ie ABR-aware logs): > This is a valid question.=20 > The I-D proposes that some form of ABR-aware logging be mandatory. The = rationale is that ABR is expected to be a very common delivery format = and requires some form of log compression over very voluminous = per-segment logging. (BTW the I-D currently proposes that both = Segment-Based Logging format and Event-Based Logging format be = mandatory. But come to think of it, having only Event-Based Logging = format mandatory would be sufficient from my viewpoint).=20 > Ben argues that ABR-aware logging should not be mandatory as it = requires extra awareness. > To get more input, I'd propose we move that requirement level = discussion to the cdni-requirements document, and have the logging I-D = only talks about what such logs would look like. > >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 From stef@jet-stream.com Fri Mar 23 03:43: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 49F3D21F854B for ; Fri, 23 Mar 2012 03:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.354 X-Spam-Level: X-Spam-Status: No, score=-0.354 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, SARE_WEOFFER=0.3] 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 sGz1OQBJJiZW for ; Fri, 23 Mar 2012 03:43:10 -0700 (PDT) Received: from monitor1.jet-stream.nl (smtp.jet-stream.nl [91.196.106.226]) by ietfa.amsl.com (Postfix) with ESMTP id 96F3221F8541 for ; Fri, 23 Mar 2012 03:43:09 -0700 (PDT) Received: from [192.168.1.123] (62.82.216.150.static.user.ono.com [62.82.216.150]) (authenticated bits=0) by monitor1.jet-stream.nl (8.13.7/8.13.7) with ESMTP id q2NAh7Th032270 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 23 Mar 2012 11:43:08 +0100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_A800F598-D31D-472F-9D37-5F0267392552" From: Stef van der Ziel In-Reply-To: <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1E2F@xmb-sjc-235.amer.cisco.com> Date: Fri, 23 Mar 2012 11:45:08 +0100 Message-Id: <018F2793-F51E-46E9-BB5A-A1ADE1FFBCBF@jet-stream.com> References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net><1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net><4F5E07FA.5090402@cisco.com><5826DF56-7335-49C6-997A-AAB109ED0913@jet-stream.com><2C86FE78-1178-447F-8CB4-5AEA63625679@jet-stream.com><86AF8FF6-4BF3-41D9-837F-21A392C87F83@cisco.com><0CC6542D-0A0E-41FB-B960-6A3763469BC8@jet-stream.com><4F60A188.7080205@cisco.com><6854E730-8B93-447E-83A8-ED0DA7F99824@neustar.biz><7FF9D145-5D9B-4C99-8433-07D340BFA62A@neustar.biz> <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1E2F@xmb-sjc-235.amer.cisco.com> To: cdni@ietf.org X-Mailer: Apple Mail (2.1257) Subject: Re: [CDNi] CDNI Requirements for dCDN Surrogate exposure 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, 23 Mar 2012 10:43:14 -0000 --Apple-Mail=_A800F598-D31D-472F-9D37-5F0267392552 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Todays CDNs act like black boxes. Content owners ingest content and = somewhere it gets out. The content owners have no idea about what is happening within the CDN = and which delivery nodes have which capabilities, and whether they have = capacity, and they also don't know about the topological / geographical = location of delivery nodes. Well, that is about to change :) Content publishers demand full transparency and control over where their = content is stored. For licensing and legal reasons for instance: content = may not be stored in specific countries or networks, or may not be = stored within the CDN of a certain company from a specific country due = to legal or licensing limitations. Today that is not really an issue: = they select a CDN and can arrange an agreement about this subject. = However, when in the future CDNs start to offload content and traffic = into other CDNs, the content publisher must be made aware of this, and = must have full insight about which dCDNs are used to store delivery = their content. Content publishers also require the tools to block = certain dCDNs from storing and delivering their content even thought = their uCDN prefers to use this dCDN. Content publishers also want more control over popularity and = distribution within CDNs. We for instance allow content publishers to = see per object and live stream on which delivery nodes these are = present. We give insights in the status of these objects: whether there = are issues, whether the object is being distributed to additional = servers, and whether the object is already checked for integrity. We = allow content publishers to pre-push objects and live streams to edge = and bursting servers if they expect the content to be popular. We offer = all kinds of transparent tools and distribution and management tools. = Content publishers can use our REST/SOAP based APIs to fully integrate = their media workflow with the CDNs workflow. That is easy within a = single CDN, but the feature must be extended to interconnected CDNs as = well. These are just two arguments for exposure, if needed, I can share more = arguments. It is important that a CDN interconnection standard should not just = focus on todays needs and todays limitations of 'black box CDNs', but = should be prepared for tomorrows requirements and technologies as well. = The risk is that the CDNi statement that CDNs should not expose details = about inner details will limit future CDNs and CDN interconnection = possibilities because of the assumption that CDNs need not expose = details. So it is my recommendation to extend exposure of delivery nodes, = availability of delivery nodes, capabilities of delivery nodes, status = feedback about objects and live relays per delivery node, distribution = controls of delivery nodes, into CDNi, via a proper CDN capabilities = exchange API. Kind regards,=20 Stef van der Ziel On 22 mrt. 2012, at 17:44, Kent Leung (kleung) wrote: > Tracking requirements from CDNI Interface drafts. Based on the = discussion for draft-previdi-cdni-footprint-advertisement, I=92d like to = confirm if there is any updates needed for the requirements. > =20 > Is the GEN-4 requirement sufficiently clear? > =20 > GEN-4 [HIGH] The CDNI solution shall not require intra-CDN > information to be exposed to other CDNs for effective and > efficient delivery of the content. Examples of intra-CDN > information include surrogate topology, surrogate status, > cached content, etc. > =20 > Terminology: > =20 > Surrogate: A device/function (often called a cache) that interacts > with other elements of the CDN for the control and distribution of > Content within the CDN and interacts with User Agents for the > delivery of the Content. > =20 > So this is not the debate about high level vs. low level. Just want to = confirm the level of description is sufficient for the requirement? Or = need additional text for clarification? > =20 > =20 > Kent > =20 > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Francois Le Faucheur (flefauch) > Sent: Wednesday, March 14, 2012 1:11 PM > To: Peterson, Jon > Cc: cdni@ietf.org > Subject: Re: [CDNi] New Version = Notificationfordraft-previdi-cdni-footprint-advertisement-01.txt > =20 > Hi Jon, > =20 > I agree there is some wiggle room about what exact information set a = dCDN would provide to the uCDN which requires further discussion (ie = pick a spot between a very-high-level approach and a high-enough-level = approach). But I believe the requirement below, as well as the intent = when it was discussed, clearly excludes low-level approaches where the = upstream CDNs gets enough information to make the complete cache = selection. I also believe there was consensus that dCDNs did not want = to provide visibility on their CDN resource location/status/load... > So to define this exact information set to be advertised by a dCDN, I = think the following are reasonable guiding principles: > * stick to information that is helpful to the uCDN for = selecting the dCDN (and not the final cache) > * do not expose dCDN caching resources =20 > =20 > Francois > =20 > On 14 Mar 2012, at 20:40, Peterson, Jon wrote: >=20 >=20 > =20 > While I think I agree with you about the general strategy we should = take, judging from the drafts submitted for this IETF and the discussion = on the list, I would be less confident about saying there is working = group consensus behind it. I think people are still all over the map on = this. In part that's because there's a pretty slippery slope between the = high-level and the low-level, and the words in the requirement GEN-4 = that you site - words like "surrogate topology, surrogate status" - are = not precise terms. When we start actually trying to define the = semantics, be it in terms of geography, topology, reachability, cache = enumeration, what have you, that's when we start to see what people are = reading into this words. I think today people are still reading some = pretty different things into them. > =20 > Jon Peterson > NeuStar, Inc. > =20 > On Mar 14, 2012, at 12:30 PM, Francois Le Faucheur wrote: >=20 >=20 > (as an individual) > =20 > On 14 Mar 2012, at 18:41, Peterson, Jon wrote: > =20 > We also need to decide how deeply we want a uCDN to understand a dCDNs = resources - effectively, we could have very low-level approaches where = uCDNs execute the entire request-routing algorithm down to selecting the = particular cache, or high-level approaches where the uCDN has only a = general sense of dCDN resources and defers cache selection to the dCDN. = Once we get some agreement about these points, deciding what type and = what granularity of information dCDNs should advertise will be a lot = easier. > =20 > I believe this has been discussed and decided by the working group: > =20 > =46rom draft-ietf-cdni-requirements-02: > " > GEN-4 [HIGH] The CDNI solution shall not require intra-CDN > information to be exposed to other CDNs for effective and > efficient delivery of the content. Examples of intra-CDN > information include surrogate topology, surrogate status, > cached content, etc. > " > =20 > I personally support that decision to focus the current/initial CDNI = work on "high-level approaches where the uCDN has only a general sense = of dCDN resources and defers cache selection to the dCDN". In the = future, once high level approaches are working we can look into "very = low-level approaches where the uCDNs execute the entire request-routing = algorithm down to selecting the particular cache" (if dCDNs are willing = to allow that). > =20 > Cheers > =20 > Francois > =20 >=20 >=20 > =20 > Jon Peterson > NeuStar, Inc. > =20 > > =20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --Apple-Mail=_A800F598-D31D-472F-9D37-5F0267392552 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi,

Todays CDNs act = like black boxes. Content owners ingest content and somewhere it gets = out.
The content owners have no idea about what is happening = within the CDN and which delivery nodes have which capabilities, and = whether they have capacity, and they also don't know about the = topological / geographical location of delivery = nodes.

Well, that is about to change = :)

Content publishers demand full transparency = and control over where their content is stored. For licensing and legal = reasons for instance: content may not be stored in specific countries or = networks, or may not be stored within the CDN of a certain company from = a specific country due to legal or licensing limitations.  Today = that is not really an issue: they select a CDN and can arrange an = agreement about this subject. However, when in the future CDNs start to = offload content and traffic into other CDNs, the content publisher must = be made aware of this, and must have full insight about which dCDNs are = used to store delivery their content. Content publishers also require = the tools to block certain dCDNs from storing and delivering their = content even thought their uCDN prefers to use this = dCDN.

Content publishers also want more control = over popularity and distribution within CDNs. We for instance allow = content publishers to see per object and live stream on which delivery = nodes these are present. We give insights in the status of these = objects: whether there are issues, whether the object is being = distributed to additional servers, and whether the object is already = checked for integrity. We allow content publishers to pre-push objects = and live streams to edge and bursting servers if they expect the content = to be popular. We offer all kinds of transparent tools and distribution = and management tools. Content publishers can use our REST/SOAP based = APIs to fully integrate their media workflow with the CDNs workflow. = That is easy within a single CDN, but the feature must be extended to = interconnected CDNs as well.

These are just two = arguments for exposure, if needed, I can share more = arguments.

It is important that a CDN = interconnection standard should not just focus on todays needs and = todays limitations of 'black box CDNs', but should be prepared for = tomorrows requirements and technologies as well. The risk is that the = CDNi statement that CDNs should not expose details about inner details = will limit future CDNs and CDN interconnection possibilities because of = the assumption that CDNs need not expose = details.

So it is my recommendation to extend = exposure of delivery nodes, availability of delivery nodes, capabilities = of delivery nodes, status feedback about objects and live relays per = delivery node, distribution controls of delivery nodes, into CDNi, via a = proper CDN capabilities exchange = API.


Kind = regards, 

Stef van der = Ziel



On 22 mrt. 2012, = at 17:44, Kent Leung (kleung) wrote:

Tracking requirements = from CDNI Interface drafts. Based on the discussion for = draft-previdi-cdni-footprint-advertisement, I=92d like to confirm if = there is any updates needed for the = requirements.
 
Is the GEN-4 requirement = sufficiently clear?
 
   GEN-4   = [HIGH] The CDNI solution shall not require = intra-CDN
 
 
Surrogate: A device/function = (often called a cache) that interacts
   with other elements = of the CDN for the control and distribution = of
So this is not the debate about high level vs. low = level. Just want to confirm the level of description is sufficient for = the requirement? Or need additional text for = clarification?
 
Kent
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org= ] On Behalf Of Francois Le Faucheur = (flefauch)
Sent: Wednesday, March 14, 2012 = 1:11 PM
To: Peterson, = Jon
Cc: cdni@ietf.org
Subject: Re: [CDNi] New Version = Notificationfordraft-previdi-cdni-footprint-advertisement-01.txt
 
Hi Jon,
I agree there is some = wiggle room about what exact information set a dCDN would provide to the = uCDN which requires further discussion (ie pick a spot between a = very-high-level approach and a high-enough-level approach). But I = believe the requirement below, as well as the intent when it was = discussed, clearly excludes low-level approaches where the upstream CDNs = gets enough information to make the complete cache selection. I also = believe there was consensus  that dCDNs did not want to provide = visibility on their CDN resource = location/status/load...
So to define this exact information set to be advertised by = a dCDN, I think the following are reasonable guiding = principles:
        &= nbsp;   * stick to = information that is helpful to the uCDN for selecting the dCDN (and not = the final cache)
        &= nbsp;   * do not expose dCDN = caching resources       <= /o:p>
 
Francois
 
On 14 Mar 2012, at = 20:40, Peterson, Jon wrote:


While I think I agree = with you about the general strategy we should take, judging from the = drafts submitted for this IETF and the discussion on the list, I would = be less confident about saying there is working group consensus behind = it. I think people are still all over the map on this. In part that's = because there's a pretty slippery slope between the high-level and the = low-level, and the words in the requirement GEN-4 that you site - words = like "surrogate topology, surrogate status" - are not precise terms. = When we start actually trying to define the semantics, be it in terms of = geography, topology, reachability, cache enumeration, what have you, = that's when we start to see what people are reading into this words. I = think today people are still reading some pretty different things into = them.
 
Jon Peterson
NeuStar, Inc.
On Mar 14, 2012, at = 12:30 PM, Francois Le Faucheur wrote:


(as an = individual)
On 14 Mar 2012, at = 18:41, Peterson, Jon wrote:
 
We also need to decide how deeply we want a uCDN to = understand a dCDNs resources - effectively, we could have very low-level = approaches where uCDNs execute the entire request-routing algorithm down = to selecting the particular cache, or high-level approaches where the = uCDN has only a general sense of dCDN resources and defers cache = selection to the dCDN. Once we get some agreement about these points, = deciding what type and what granularity of information dCDNs should = advertise will be a lot = easier.
 
I believe this has = been discussed and decided by the working = group:
=46rom = draft-ietf-cdni-requirements-02:
"
   GEN-4 =   [HIGH] The CDNI solution shall not require = intra-CDN
      =      information to be exposed to other CDNs for = effective and
      =      efficient delivery of the content.  Examples of = intra-CDN
      =      information include surrogate topology, surrogate = status,
      =      cached content, = etc.
I personally support = that decision to focus the current/initial CDNI work on "high-level = approaches where the uCDN has only a general sense of dCDN resources and = defers cache selection to the dCDN". In the future, once high level = approaches are working we can look into "very low-level approaches where = the uCDNs execute the entire request-routing algorithm down to selecting = the particular cache" (if dCDNs are willing to allow = that).
Jon = Peterson
NeuStar, = Inc.
 
_____________________________________= __________
CDNi mailing list
List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 11:03:33 -0000 Hi Francois, Here are my arguments why BGP is not the right protocol for CDNi = capabilities exchange: Modern CDNs are layered structures: - Content owners workflow - CDN control plane - CDN delivery node - Underlying IP network Content owners typically interact and automate their workflow with the = CDN control plane. They do this via modern APIs, based upon REST or SOAP = for instance (plus webdav, FTP, etc).=20 CDN control planes typically interacte and automate their workflow with = the CDN delivery nodes. They do this via modern APIs, based upon REST or = SOAP for instance. (plus webdav, FTP, etc).=20 CDN delivery nodes can be anything: cloud services, virtual services, = COTS based servers, appliances or embedded servers/blades within a = switch or router or mobile gateway. Logically they are not locked within = the IP network. They are running on top of IP networks: whether it is = within a local LAN, a RNC, GGSN, WAN, a metro, a telco network, or = spanning multiple networks such as the Internet. When CDNs start to interconnect, the layering could look like this: - Content owners workflow - uCDN control plane - dCDN control plane - dCDN delivery node - Underlying IP network Since all communication between the content owners workflow, the CDN = control planes and the CDN delivery nodes are done via modern REST/SOAP = based APIs anyway, why introduce a less modern, less fitting, other = protocol such as BGP? CDN capabilities exchange is not a feature that should be limited to = interconnected CDNs. CDN control planes need to be able to understand = CDN delivery nodes capabilities as well. Modern CDN control planes and = CDN delivery nodes don't communicate via BGP but via SOAP/REST based = unified APIs. We work with many vendors for delivery software and = hardware and none of them will start using BGP. =46rom a CDN control plane point of view, a delivery node is just a = delivery node. It can actually be an account on another CDN, pretending = to be a logical delivery node. It doesn't make sense to use BGP in such = scenarios. Unified capabilities, reporting and control APIs based upon = REST or SOAP are the way forward. CDN capabilities exchange is not a feature that should be limited to = interconnected CDNs. Content publishers need to be able to understand = CDN capabilities as well. Their wish is to be able to connect to their = CDN account via REST/SOAP based APIs and automatically read out the CDN = not just for status but also for capabilities and use the same unified = APIs to instruct the CDN for setup of origin backends, publishing = points, object distribution, etc. Content publishers will never accept = BGP.=20 Best, Stef From vkg@bell-labs.com Fri Mar 23 08:35: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 E86D221F851A; Fri, 23 Mar 2012 08:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.988 X-Spam-Level: X-Spam-Status: No, score=-106.988 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogNqsSmsbBGd; Fri, 23 Mar 2012 08:34:55 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7324321F8518; Fri, 23 Mar 2012 08:34:55 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q2NFXhLm011780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Mar 2012 10:33:43 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2NFXgUK024564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Mar 2012 10:33:43 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q2NFXg6h019406; Fri, 23 Mar 2012 10:33:42 -0500 (CDT) Message-ID: <4F6C98F6.5020302@bell-labs.com> Date: Fri, 23 Mar 2012 10:38:30 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: Linda Dunbar References: <4F6A0A41.3050006@wonderhamster.org> <4A95BA014132FF49AE685FAB4B9F17F632E4F713@dfweml505-mbx> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F632E4F713@dfweml505-mbx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "apps-discuss@ietf.org" , "dc@ietf.org" , "opsawg@ietf.org" , "cdni@ietf.org" , "tsvwg@ietf.org" Subject: Re: [CDNi] [apps-discuss] [dc] Announcing the i2aex BoF 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, 23 Mar 2012 15:35:00 -0000 On 03/22/2012 02:42 PM, Linda Dunbar wrote: > Are there specific applications in mind for the Intra-structure to > expose to? Yes; there are what we call 3 high-level use cases ("applications" in your terminology above). These are: CDN, data centers, and large bandwidth. Please see http://www.ietf.org/proceedings/83/agenda/agenda-83-i2aex.txt for an agenda and a reading list. Thanks! - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From kleung@cisco.com Sun Mar 25 03:30: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 ABCEB21F84E2 for ; Sun, 25 Mar 2012 03:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.81 X-Spam-Level: X-Spam-Status: No, score=-9.81 tagged_above=-999 required=5 tests=[AWL=0.789, 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 SPAdi8rlfIni for ; Sun, 25 Mar 2012 03:30:53 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id C676B21F84B3 for ; Sun, 25 Mar 2012 03:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=3216; q=dns/txt; s=iport; t=1332671453; x=1333881053; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=ATH5LwWgQI707U0eatZqtmdq+TxwUDCYQacY6a6lMdY=; b=DxQ9P9x/4jevxAWyu2F9b4DCqTL6otHeOHmDa/wkgvAj8C16YS47jmEh qj+2PVCfcBrKhabOotWlyFoCt9XlEN0HxjXh20Ar+uAM4xjt/DN7hi2yR xbiqYHILCUsPO7z250SlsdMWbE0+27dAVn61peuBWzk2wpD+oenqRDFNe c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKXybk+rRDoI/2dsb2JhbABEuCKBB4IJAQEBBAEBAQ8BHT4XBAIBCBEBAwEBCwYXAQYBJh8DBggBAQQBEggBGYVvgXgBC5l3ngyQRWMEiCQzjhqKI4MRgWiDB4E8 X-IronPort-AV: E=Sophos;i="4.73,646,1325462400"; d="scan'208";a="37476700" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 25 Mar 2012 10:30:53 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2PAUrC6015157; Sun, 25 Mar 2012 10:30:53 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Mar 2012 03:30:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 25 Mar 2012 03:30:50 -0700 Message-ID: <7A2D6D1F6AC99243A77D32820D8ABBC20E95C618@xmb-sjc-235.amer.cisco.com> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF03231555@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [CDNi] TR: I-D Action: draft-bertrand-cdni-logging-00.txt Thread-Index: AczqV04P2kj58bv3Su2UKn4mvvPeCwAAGnzQCAWYkVA= References: <8E09C72DBC577D489F13A71228C0B7BF03231555@ftrdmel0.rd.francetelecom.fr> From: "Kent Leung (kleung)" To: , X-OriginalArrivalTime: 25 Mar 2012 10:30:53.0481 (UTC) FILETIME=[5B1D5190:01CD0A72] Subject: Re: [CDNi] TR: I-D Action: draft-bertrand-cdni-logging-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 10:30:54 -0000 Hi Gilles and Stephan. A few comments on your draft. 1. Sect. 3: Should the Logging Architecture include on-demand access to = logging information (see LOG-9 requirement)? So it's not only CoDR = Selection from uCDN to dCDN, but also CoDR Request. 2. Sect. 6.2: Not clear how Cascaded CDNs are supported in the = Information Elements in the logging records? The CDNI Logging interface = is between uCDN and dCDN. Some clarification on how cascaded CDNs are = handled would be helpful (see LOG-3 requirement). 3. Sect. 7: Should there be logging for Metadata acquisition and = purging? Also, logging for Triggers (Control Interface) for = content/metadata acquisition and purging? 4. Not sure if support for batch/offline exchange of logging records was = mentioned (LOG-5 requirement)? 5. Not sure if resource consumption reporting is covered (LOG-12 = requirement)? 6. Sect. 8.1.1: Just a note that draft-lefaucheur-cdni-logging-delivery = has more details for ABR. Kent -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = gilles.bertrand@orange.com Sent: Monday, February 13, 2012 6:04 AM To: cdni@ietf.org Subject: [CDNi] TR: I-D Action: draft-bertrand-cdni-logging-00.txt Hi everyone, We have submitted a new draft on the Logging interface: http://tools.ietf.org/html/draft-bertrand-cdni-logging-00=20 "This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN). It introduces a framework, an architecture design and a set of new requirements. Then it drafts an information model." Best regards, Gilles -----Message d'origine----- De=A0: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] De la part de = internet-drafts@ietf.org Envoy=E9=A0: lundi 13 f=E9vrier 2012 14:56 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-bertrand-cdni-logging-00.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : CDNI Logging Interface Author(s) : Gilles Bertrand Stephan Emile Filename : draft-bertrand-cdni-logging-00.txt Pages : 26 Date : 2012-02-13 This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN). It introduces a framework, an architecture design and a set of new requirements. Then it drafts an information model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bertrand-cdni-logging-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-bertrand-cdni-logging-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From kleung@cisco.com Sun Mar 25 03:54: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 09B6421F8564 for ; Sun, 25 Mar 2012 03:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.86 X-Spam-Level: X-Spam-Status: No, score=-9.86 tagged_above=-999 required=5 tests=[AWL=0.739, 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 cqANzwP7ESSy for ; Sun, 25 Mar 2012 03:54:19 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 99F3621F855A for ; Sun, 25 Mar 2012 03:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=4671; q=dns/txt; s=iport; t=1332672859; x=1333882459; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=gKRVpnoPreds0iMS8ZrsFRrwx6g0MJWosY7as0H1kbQ=; b=KQyhPqzwzgtWbGJRTAbc0R6GtjuncYI0vJgpEoChNQzgl8fTqa2HGre2 rGjKJ9dbKcnLv/wk8AAaxWgfdLYwMsHXX1vP14oed74kwrMXQOuzPh60Q LE4W3Z2tSTZb0QkYlO3Y+dnZcFH2q8FttsOJ6MzpTQEAI22hlOCHexUVc U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPD4bk+rRDoJ/2dsb2JhbAA6CrgigQeCCQEBAQMBAQEBDwEdCjQLBQcEAgEIEQQBAQsGFwEGASYfCQgBAQQTCBECB4djBAELmXmeBwSKXoVnYwSIV5tOgWiDBw X-IronPort-AV: E=Sophos;i="4.73,646,1325462400"; d="scan'208";a="34990166" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 25 Mar 2012 10:54:19 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2PAsJ94024513; Sun, 25 Mar 2012 10:54:19 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Mar 2012 03:54:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 25 Mar 2012 03:54:14 -0700 Message-ID: <7A2D6D1F6AC99243A77D32820D8ABBC20E95C61B@xmb-sjc-235.amer.cisco.com> In-Reply-To: <21F2D75D-EFDE-4086-87BE-1CE511EE8A38@jet-stream.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [CDNi] CDNI Requirements for ABR content Thread-Index: Ac0ISaidJkbjiRLUQF+X7FIQumheZACKdDRA References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1DD4@xmb-sjc-235.amer.cisco.com> <21F2D75D-EFDE-4086-87BE-1CE511EE8A38@jet-stream.nl> From: "Kent Leung (kleung)" To: "Stef van der Ziel" X-OriginalArrivalTime: 25 Mar 2012 10:54:19.0247 (UTC) FILETIME=[A1042FF0:01CD0A75] Cc: cdni@ietf.org Subject: Re: [CDNi] CDNI Requirements for ABR content 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: Sun, 25 Mar 2012 10:54:21 -0000 Hi Stef. So would you prefer that dCDN is required to support session state for ABR content to participate in CDNI OR that CDNI interfaces provide information elements (e.g. RRI capability advertisement, optional Metadata/Logging ABR-related fields) that allows dCDN to be a member of CDNI without being ABR-aware? I think that's the decision that we need to make. From a requirement's perspective #1 or #2 below, or another option? Kent -----Original Message----- From: Stef van der Ziel [mailto:stef@jet-stream.nl]=20 Sent: Thursday, March 22, 2012 9:34 AM To: Kent Leung (kleung) Cc: Subject: Re: [CDNi] CDNI Requirements for ABR content One of the fundamental problems of ABR is lack of true sessions. Session control and session logging is lost. Delivery nodes simply log every segment request without any correlation. Making it impossible to 100% reconstruct a true user session in reports.=20 A side effect is that the number of log entries explode, stressing log processing and analytics tools. To resolve both problems we ask delivery vendors for caching / reverse proxy services to keep track of actual sessions, insert a session ID to the manifest and subsequent chunk access logs and aggregating back these into a true session access log. (So the claim that any reverse proxy can be used for ABR is false in real life scenarios). uCDNs will need to know whether dCDNs support session logging for ABR content. Since this is a must have requirement for uCDNs, analytics providers and content providers.=20 If the dCDN does not support this then the uCDN will not use the dCDN. Hope this input helps! Best Stef On 22 mrt. 2012, at 17:00, "Kent Leung (kleung)" wrote: > Tracking requirements from CDNI Interface drafts. Based on the discussion for draft-lefaucheur-cdni-logging-delivery, we need some inputs from the WG on the CDNI Logging requirements. >=20 > Options for logging requirements for ABR content: > =20 > 1) Event-Based Logging shall be supported [HIGH], Segment-Based Logging should be supported [MED], and Summary-Based Logging may be supported [LOW].=20 >=20 > Reason: The dCDN needs to be aware of ABR content and should log delivery with the ABR-related fields. ABR is expected to be a very common delivery format and requires some form of log compression over very voluminous per-segment logging. ABR content needs to be supported by CDNs. Related requirement is "GEN-14 [HIGH] The CDNI solution shall support HTTP Adaptive Bit Rate (ABR) content." >=20 > OR >=20 > 2) Event-Based Logging, Segment-Based Logging, and Summary-Based Logging may be supported [LOW].=20 > =20 > Reason: Eliminate the need for dCDN to be aware of ABR content. For example, dCDN is acting in a pure HTTP reverse proxy mode and may not be aware of that level of information and/or because the control of how to identify those fields is owned by the CSP and none of CDNs may have visibility of that mapping information. Such a requirement to force CDNs and CDNI in general to require such mappings seems to be overkill. >=20 >=20 > Thoughts? >=20 > Kent >=20 >=20 > -----Original Message----- > From: Francois Le Faucheur (flefauch)=20 > Sent: Tuesday, March 13, 2012 11:39 AM > To: Kent Leung (kleung); Niven-Jenkins Ben > Cc: Francois Le Faucheur (flefauch); cdni@ietf.org; Mahesh Viveganandhan (mvittal) > Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 >=20 > Ben, Kent, >=20 > Trying to extract the key points from the thread: >=20 > 1) level of requirement for support of HTTP Adaptive Streaming Logging Session (ie ABR-aware logs): > This is a valid question.=20 > The I-D proposes that some form of ABR-aware logging be mandatory. The rationale is that ABR is expected to be a very common delivery format and requires some form of log compression over very voluminous per-segment logging. (BTW the I-D currently proposes that both Segment-Based Logging format and Event-Based Logging format be mandatory. But come to think of it, having only Event-Based Logging format mandatory would be sufficient from my viewpoint).=20 > Ben argues that ABR-aware logging should not be mandatory as it requires extra awareness. > To get more input, I'd propose we move that requirement level discussion to the cdni-requirements document, and have the logging I-D only talks about what such logs would look like. > >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 From kleung@cisco.com Sun Mar 25 03:56: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 7167B21F858E for ; Sun, 25 Mar 2012 03:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.903 X-Spam-Level: X-Spam-Status: No, score=-9.903 tagged_above=-999 required=5 tests=[AWL=0.696, 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 loYhgojizy6f for ; Sun, 25 Mar 2012 03:56:27 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0597621F856F for ; Sun, 25 Mar 2012 03:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=1688; q=dns/txt; s=iport; t=1332672987; x=1333882587; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=RQjs9CFmFhNj2ps8RjcBtfMlzB+kgA/yZEy3zZIWeJQ=; b=AolSMeEVuQsIGX3I0dGin94Rb535SznVW8ftooF6v33yKSUVhkof9A23 YH1jCM5v1hZ4eQlFtliZ7XtJb6ftev/Y/ISDorCZOcqVco9Q4lnaY5OqC IIi2oi5vMtU+NsEwhrfYGk6hIPW8A7NsSQSTIdAWotU0hwi7YWhyejKHO 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPD4bk+rRDoI/2dsb2JhbAA6CrgigQeCCQEBAQMBEgEdCkQLAgEIIgYYBgFWAQEEARoTB4djBAGaBJ4Lil6FZ2MEiFebToFogwc X-IronPort-AV: E=Sophos;i="4.73,646,1325462400"; d="scan'208";a="34990236" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 25 Mar 2012 10:56:27 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2PAuQ0a021837; Sun, 25 Mar 2012 10:56:26 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Mar 2012 03:56:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 25 Mar 2012 03:56:25 -0700 Message-ID: <7A2D6D1F6AC99243A77D32820D8ABBC20E95C61C@xmb-sjc-235.amer.cisco.com> In-Reply-To: <40E520C4-3637-41D5-8A60-EB3015824E7D@jet-stream.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [CDNi] CDNI Requirements for ABR content Thread-Index: Ac0I3zW0TsWgEesOTRGjJnuF/X0aTgBlo0tg References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1DD4@xmb-sjc-235.amer.cisco.com> <40E520C4-3637-41D5-8A60-EB3015824E7D@jet-stream.com> From: "Kent Leung (kleung)" To: "Stef van der Ziel" , X-OriginalArrivalTime: 25 Mar 2012 10:56:26.0696 (UTC) FILETIME=[ECFB5C80:01CD0A75] Subject: Re: [CDNi] CDNI Requirements for ABR content 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: Sun, 25 Mar 2012 10:56:27 -0000 Therefore I would like to see true ABR session logs this mandatory, or at least a preferred option, that should be shared via capabilities exchange.=20 KL> OK. Your vote would be #1 then. Thanks for your inputs. Kent > Tracking requirements from CDNI Interface drafts. Based on the discussion for draft-lefaucheur-cdni-logging-delivery, we need some inputs from the WG on the CDNI Logging requirements. >=20 > Options for logging requirements for ABR content: >=20 > 1) Event-Based Logging shall be supported [HIGH], Segment-Based Logging should be supported [MED], and Summary-Based Logging may be supported [LOW].=20 >=20 > Reason: The dCDN needs to be aware of ABR content and should log delivery with the ABR-related fields. ABR is expected to be a very common delivery format and requires some form of log compression over very voluminous per-segment logging. ABR content needs to be supported by CDNs. Related requirement is "GEN-14 [HIGH] The CDNI solution shall support HTTP Adaptive Bit Rate (ABR) content." >=20 > OR >=20 > 2) Event-Based Logging, Segment-Based Logging, and Summary-Based Logging may be supported [LOW].=20 >=20 > Reason: Eliminate the need for dCDN to be aware of ABR content. For example, dCDN is acting in a pure HTTP reverse proxy mode and may not be aware of that level of information and/or because the control of how to identify those fields is owned by the CSP and none of CDNs may have visibility of that mapping information. Such a requirement to force CDNs and CDNI in general to require such mappings seems to be overkill. >=20 >=20 > Thoughts? >=20 > Kent >=20 > =20 From kleung@cisco.com Sun Mar 25 04:12: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 33DF421F856F for ; Sun, 25 Mar 2012 04:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.791 X-Spam-Level: X-Spam-Status: No, score=-9.791 tagged_above=-999 required=5 tests=[AWL=0.507, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_WEOFFER=0.3] 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 9TaU3SWoS0K0 for ; Sun, 25 Mar 2012 04:12:04 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1381421F85C7 for ; Sun, 25 Mar 2012 04:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=31542; q=dns/txt; s=iport; t=1332673924; x=1333883524; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=8bQqImy7Ou1aggylph3h9XtxkMtrVy6Zh8SVUpyfPeA=; b=el7BqRN8tDJuWQ1mNbF2DqZWjc8NqxsRXQSbYb0Sg3Vn4dLNUgIIXjyA bQT0jb28KNZCghchC6ofdIGs74UfHODLS+wMtpBeQCK7eqwN5qlAMJc0/ nkXclj+l+CJRgxIbkyaMWtLWySJi6FtPZDm1691We91DEZcdWVAFwh8Pz s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHX8bk+rRDoI/2dsb2JhbABEgka1XIEHggkBAQEEAQEBDwEJEQM+CxACAQgRBAEBCwYQAQYBBgEmHwkIAQEEARIIEweHZwELmXiPBI8DBIpjhWJjBIhXiSWSKYFogweBNQ X-IronPort-AV: E=Sophos;i="4.73,646,1325462400"; d="scan'208,217";a="34991029" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 25 Mar 2012 11:12:03 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2PBC3oE026937; Sun, 25 Mar 2012 11:12:03 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Mar 2012 04:12:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0A78.1AF89967" Date: Sun, 25 Mar 2012 04:12:00 -0700 Message-ID: <7A2D6D1F6AC99243A77D32820D8ABBC20E95C61F@xmb-sjc-235.amer.cisco.com> In-Reply-To: <018F2793-F51E-46E9-BB5A-A1ADE1FFBCBF@jet-stream.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [CDNi] CDNI Requirements for dCDN Surrogate exposure Thread-Index: Ac0I4b3zsvRfjAbLSH6Pw7jZM7RiRABlI1Rw References: <20120308194553.11977.96424.idtracker@ietfa.amsl.com>, <1F3DE948AD28CB4D905D51039D081AF626C92DE6AE@EMV64-UKRD.domain1.systemhost.net><1F3DE948AD28CB4D905D51039D081AF626C963402D@EMV64-UKRD.domain1.systemhost.net><4F5E07FA.5090402@cisco.com><5826DF56-7335-49C6-997A-AAB109ED0913@jet-stream.com><2C86FE78-1178-447F-8CB4-5AEA63625679@jet-stream.com><86AF8FF6-4BF3-41D9-837F-21A392C87F83@cisco.com><0CC6542D-0A0E-41FB-B960-6A3763469BC8@jet-stream.com><4F60A188.7080205@cisco.com><6854E730-8B93-447E-83A8-ED0DA7F99824@neustar.biz><7FF9D145-5D9B-4C99-8433-07D340BFA62A@neustar.biz> <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1E2F@xmb-sjc-235.amer.cisco.com> <018F2793-F51E-46E9-BB5A-A1ADE1FFBCBF@jet-stream.com> From: "Kent Leung (kleung)" To: "Stef van der Ziel" , X-OriginalArrivalTime: 25 Mar 2012 11:12:03.0152 (UTC) FILETIME=[1B273500:01CD0A78] Subject: Re: [CDNi] CDNI Requirements for dCDN Surrogate exposure 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: Sun, 25 Mar 2012 11:12:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0A78.1AF89967 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stef. Thanks for your inputs. =20 I think the priority level was set for the requirement to focus on getting things done and avoid over-complicating the base functions. The key question is can the exposure be supported later by extensions to the CDNI interfaces. If there are no obstacles to prevent providing the details of the dCDN internals in the solution, then we are still ok with the current requirement. For example, footprint advertisement may contain the AS of the dCDN for now but extensible to specific IP prefixes or addresses of the Surrogates later. The uCDN can select the dCDN based on the level of information provided.=20 =20 Kent =20 From: Stef van der Ziel [mailto:stef@jet-stream.com]=20 Sent: Friday, March 23, 2012 3:45 AM To: cdni@ietf.org Cc: Francois Le Faucheur (flefauch); Kent Leung (kleung); Peterson, Jon Subject: Re: [CDNi] CDNI Requirements for dCDN Surrogate exposure =20 Hi, =20 Todays CDNs act like black boxes. Content owners ingest content and somewhere it gets out. The content owners have no idea about what is happening within the CDN and which delivery nodes have which capabilities, and whether they have capacity, and they also don't know about the topological / geographical location of delivery nodes. =20 Well, that is about to change :) =20 Content publishers demand full transparency and control over where their content is stored. For licensing and legal reasons for instance: content may not be stored in specific countries or networks, or may not be stored within the CDN of a certain company from a specific country due to legal or licensing limitations. Today that is not really an issue: they select a CDN and can arrange an agreement about this subject. However, when in the future CDNs start to offload content and traffic into other CDNs, the content publisher must be made aware of this, and must have full insight about which dCDNs are used to store delivery their content. Content publishers also require the tools to block certain dCDNs from storing and delivering their content even thought their uCDN prefers to use this dCDN. =20 Content publishers also want more control over popularity and distribution within CDNs. We for instance allow content publishers to see per object and live stream on which delivery nodes these are present. We give insights in the status of these objects: whether there are issues, whether the object is being distributed to additional servers, and whether the object is already checked for integrity. We allow content publishers to pre-push objects and live streams to edge and bursting servers if they expect the content to be popular. We offer all kinds of transparent tools and distribution and management tools. Content publishers can use our REST/SOAP based APIs to fully integrate their media workflow with the CDNs workflow. That is easy within a single CDN, but the feature must be extended to interconnected CDNs as well. =20 These are just two arguments for exposure, if needed, I can share more arguments. =20 It is important that a CDN interconnection standard should not just focus on todays needs and todays limitations of 'black box CDNs', but should be prepared for tomorrows requirements and technologies as well. The risk is that the CDNi statement that CDNs should not expose details about inner details will limit future CDNs and CDN interconnection possibilities because of the assumption that CDNs need not expose details. =20 So it is my recommendation to extend exposure of delivery nodes, availability of delivery nodes, capabilities of delivery nodes, status feedback about objects and live relays per delivery node, distribution controls of delivery nodes, into CDNi, via a proper CDN capabilities exchange API. =20 =20 Kind regards,=20 =20 Stef van der Ziel =20 =20 =20 On 22 mrt. 2012, at 17:44, Kent Leung (kleung) wrote: Tracking requirements from CDNI Interface drafts. Based on the discussion for draft-previdi-cdni-footprint-advertisement, I'd like to confirm if there is any updates needed for the requirements. =20 Is the GEN-4 requirement sufficiently clear? =20 GEN-4 [HIGH] The CDNI solution shall not require intra-CDN information to be exposed to other CDNs for effective and efficient delivery of the content. Examples of intra-CDN information include surrogate topology, surrogate status, cached content, etc. =20 Terminology: =20 Surrogate: A device/function (often called a cache) that interacts with other elements of the CDN for the control and distribution of Content within the CDN and interacts with User Agents for the delivery of the Content. =20 So this is not the debate about high level vs. low level. Just want to confirm the level of description is sufficient for the requirement? Or need additional text for clarification? =20 =20 Kent =20 From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch) Sent: Wednesday, March 14, 2012 1:11 PM To: Peterson, Jon Cc: cdni@ietf.org Subject: Re: [CDNi] New Version Notificationfordraft-previdi-cdni-footprint-advertisement-01.txt =20 Hi Jon, =20 I agree there is some wiggle room about what exact information set a dCDN would provide to the uCDN which requires further discussion (ie pick a spot between a very-high-level approach and a high-enough-level approach). But I believe the requirement below, as well as the intent when it was discussed, clearly excludes low-level approaches where the upstream CDNs gets enough information to make the complete cache selection. I also believe there was consensus that dCDNs did not want to provide visibility on their CDN resource location/status/load... So to define this exact information set to be advertised by a dCDN, I think the following are reasonable guiding principles: * stick to information that is helpful to the uCDN for selecting the dCDN (and not the final cache) * do not expose dCDN caching resources =20 =20 Francois =20 On 14 Mar 2012, at 20:40, Peterson, Jon wrote: =20 While I think I agree with you about the general strategy we should take, judging from the drafts submitted for this IETF and the discussion on the list, I would be less confident about saying there is working group consensus behind it. I think people are still all over the map on this. In part that's because there's a pretty slippery slope between the high-level and the low-level, and the words in the requirement GEN-4 that you site - words like "surrogate topology, surrogate status" - are not precise terms. When we start actually trying to define the semantics, be it in terms of geography, topology, reachability, cache enumeration, what have you, that's when we start to see what people are reading into this words. I think today people are still reading some pretty different things into them. =20 Jon Peterson NeuStar, Inc. =20 On Mar 14, 2012, at 12:30 PM, Francois Le Faucheur wrote: (as an individual) =20 On 14 Mar 2012, at 18:41, Peterson, Jon wrote: =20 We also need to decide how deeply we want a uCDN to understand a dCDNs resources - effectively, we could have very low-level approaches where uCDNs execute the entire request-routing algorithm down to selecting the particular cache, or high-level approaches where the uCDN has only a general sense of dCDN resources and defers cache selection to the dCDN. Once we get some agreement about these points, deciding what type and what granularity of information dCDNs should advertise will be a lot easier. =20 I believe this has been discussed and decided by the working group: =20 >From draft-ietf-cdni-requirements-02: " GEN-4 [HIGH] The CDNI solution shall not require intra-CDN information to be exposed to other CDNs for effective and efficient delivery of the content. Examples of intra-CDN information include surrogate topology, surrogate status, cached content, etc. " =20 I personally support that decision to focus the current/initial CDNI work on "high-level approaches where the uCDN has only a general sense of dCDN resources and defers cache selection to the dCDN". In the future, once high level approaches are working we can look into "very low-level approaches where the uCDNs execute the entire request-routing algorithm down to selecting the particular cache" (if dCDNs are willing to allow that). =20 Cheers =20 Francois =20 =20 Jon Peterson NeuStar, Inc. =20 =20 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni =20 ------_=_NextPart_001_01CD0A78.1AF89967 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stef. Thanks for your inputs.

 

I think the priority level was set for the requirement to focus on = getting things done and avoid over-complicating the base functions. The = key question is can the exposure be supported later by extensions to the = CDNI interfaces. If there are no obstacles to prevent providing the = details of the dCDN internals in the solution, then we are still ok with = the current requirement. For example, footprint advertisement may = contain the AS of the dCDN for now but extensible to specific IP = prefixes or  addresses of the Surrogates later. The uCDN can select = the dCDN based on the level of information provided. =

 

Kent

 

From:= = Stef van der Ziel [mailto:stef@jet-stream.com]
Sent: Friday, = March 23, 2012 3:45 AM
To: cdni@ietf.org
Cc: = Francois Le Faucheur (flefauch); Kent Leung (kleung); Peterson, = Jon
Subject: Re: [CDNi] CDNI Requirements for dCDN Surrogate = exposure

 

Hi,

 

Todays CDNs act like black boxes. Content owners = ingest content and somewhere it gets out.

The content owners have no idea about what is = happening within the CDN and which delivery nodes have which = capabilities, and whether they have capacity, and they also don't know = about the topological / geographical location of delivery = nodes.

 

Well, that is about to change = :)

 

Content publishers demand full transparency and = control over where their content is stored. For licensing and legal = reasons for instance: content may not be stored in specific countries or = networks, or may not be stored within the CDN of a certain company from = a specific country due to legal or licensing limitations.  Today = that is not really an issue: they select a CDN and can arrange an = agreement about this subject. However, when in the future CDNs start to = offload content and traffic into other CDNs, the content publisher must = be made aware of this, and must have full insight about which dCDNs are = used to store delivery their content. Content publishers also require = the tools to block certain dCDNs from storing and delivering their = content even thought their uCDN prefers to use this = dCDN.

 

Content publishers also want more control over = popularity and distribution within CDNs. We for instance allow content = publishers to see per object and live stream on which delivery nodes = these are present. We give insights in the status of these objects: = whether there are issues, whether the object is being distributed to = additional servers, and whether the object is already checked for = integrity. We allow content publishers to pre-push objects and live = streams to edge and bursting servers if they expect the content to be = popular. We offer all kinds of transparent tools and distribution and = management tools. Content publishers can use our REST/SOAP based APIs to = fully integrate their media workflow with the CDNs workflow. That is = easy within a single CDN, but the feature must be extended to = interconnected CDNs as well.

 

These are just two arguments for exposure, if needed, = I can share more arguments.

 

It is important that a CDN interconnection standard = should not just focus on todays needs and todays limitations of 'black = box CDNs', but should be prepared for tomorrows requirements and = technologies as well. The risk is that the CDNi statement that CDNs = should not expose details about inner details will limit future CDNs and = CDN interconnection possibilities because of the assumption that CDNs = need not expose details.

 

So it is my recommendation to extend exposure of = delivery nodes, availability of delivery nodes, capabilities of delivery = nodes, status feedback about objects and live relays per delivery node, = distribution controls of delivery nodes, into CDNi, via a proper CDN = capabilities exchange API.

 

 

Kind regards, 

 

Stef van der Ziel

 

 

 

On = 22 mrt. 2012, at 17:44, Kent Leung (kleung) = wrote:



Tracking requirements from CDNI Interface drafts. Based on the = discussion for draft-previdi-cdni-footprint-advertisement, I’d = like to confirm if there is any updates needed for the = requirements.

 

Is the GEN-4 requirement sufficiently = clear?

 

   GEN-4   [HIGH] The CDNI solution shall not = require intra-CDN

           = information to be exposed to other CDNs for effective = and

           = efficient delivery of the content.  Examples of = intra-CDN

           = information include surrogate topology, surrogate = status,

           cached = content, etc.

 

Terminology:

 

Surrogate: A device/function (often called a cache) that = interacts

   with other elements of the CDN for the control and = distribution of

   Content within the CDN and interacts with User Agents = for the

   delivery of the = Content.

 

So this is not the debate about high level vs. low level. Just want = to confirm the level of description is sufficient for the requirement? = Or need additional text for = clarification?

 

 

Kent

 

From:=  cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org]=  On Behalf Of Francois Le Faucheur = (flefauch)
Sent: Wednesday, March 14, 2012 = 1:11 PM
To: Peterson, = Jon
Cc: cdni@ietf.org
Subject: Re: [CDNi] New Version = Notificationfordraft-previdi-cdni-footprint-advertisement-01.txt

 

Hi Jon,

 

I agree there is some wiggle room about what exact = information set a dCDN would provide to the uCDN which requires further = discussion (ie pick a spot between a very-high-level approach and a = high-enough-level approach). But I believe the requirement below, = as well as the intent when it was discussed, clearly excludes low-level = approaches where the upstream CDNs gets enough information to make the = complete cache selection. I also believe there was consensus  that = dCDNs did not want to provide visibility on their CDN resource = location/status/load...

So to define this exact information set to be = advertised by a dCDN, I think the following are reasonable guiding = principles:

        &n= bsp;   * stick to information that = is helpful to the uCDN for selecting the dCDN (and not the final = cache)

        &n= bsp;   * do not expose dCDN caching = resources       

 

Francois

 

On 14 Mar 2012, at 20:40, Peterson, Jon = wrote:




 

While I think I agree with you about the general = strategy we should take, judging from the drafts submitted for this IETF = and the discussion on the list, I would be less confident about saying = there is working group consensus behind it. I think people are still all = over the map on this. In part that's because there's a pretty slippery = slope between the high-level and the low-level, and the words in the = requirement GEN-4 that you site - words like "surrogate topology, = surrogate status" - are not precise terms. When we start actually = trying to define the semantics, be it in terms of geography, topology, = reachability, cache enumeration, what have you, that's when we start to = see what people are reading into this words. I think today people are = still reading some pretty different things into = them.

 

Jon Peterson

NeuStar, Inc.

 

On Mar 14, 2012, at 12:30 PM, Francois Le Faucheur = wrote:




(as an individual)

 

On 14 Mar 2012, at 18:41, Peterson, Jon = wrote:

 

We also need to decide how deeply we want a uCDN to = understand a dCDNs resources - effectively, we could have very low-level = approaches where uCDNs execute the entire request-routing algorithm down = to selecting the particular cache, or high-level approaches where the = uCDN has only a general sense of dCDN resources and defers cache = selection to the dCDN. Once we get some agreement about these points, = deciding what type and what granularity of information dCDNs should = advertise will be a lot = easier.

 

I believe this has been discussed and decided by the = working group:

 

From = draft-ietf-cdni-requirements-02:

"

   GEN-4   [HIGH] The CDNI solution = shall not require intra-CDN

           information = to be exposed to other CDNs for effective = and

  =          efficient delivery of the content. =  Examples of intra-CDN

           information = include surrogate topology, surrogate = status,

  =          cached content, = etc.

"

 

I personally support that decision to focus the = current/initial CDNI work on "high-level approaches where the uCDN = has only a general sense of dCDN resources and defers cache selection to = the dCDN". In the future, once high level approaches are working we = can look into "very low-level approaches where the uCDNs execute = the entire request-routing algorithm down to selecting the particular = cache" (if dCDNs are willing to allow = that).

 

Cheers

 

Francois

 




 

Jon Peterson

NeuStar, Inc.

 

<snip>

 

_________= ______________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/= mailman/listinfo/cdni

 

------_=_NextPart_001_01CD0A78.1AF89967-- From RMurray@velocix.com Sun Mar 25 04:43: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 7A19521F85F0 for ; Sun, 25 Mar 2012 04:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.496, 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 98tmrJgEDRWn for ; Sun, 25 Mar 2012 04:43:01 -0700 (PDT) Received: from owa.velocix.com (mail-out.velocix.com [212.44.61.56]) by ietfa.amsl.com (Postfix) with ESMTP id E8F3421F84D1 for ; Sun, 25 Mar 2012 04:43:00 -0700 (PDT) Received: from EXB04CAM.corp.velocix.com ([169.254.1.160]) by exc01cam.corp.velocix.com ([212.44.61.56]) with mapi id 14.02.0247.003; Sun, 25 Mar 2012 12:42:55 +0100 From: Rob Murray To: "Kent Leung (kleung)" , "cdni@ietf.org" Thread-Topic: [CDNi] CDNI Triggers interface Thread-Index: AQHM9ylJjw/I9226gUqTKwJkpHCC05Z2wCQAgARJ3wA= Date: Sun, 25 Mar 2012 11:42:55 +0000 Message-ID: In-Reply-To: <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1F16@xmb-sjc-235.amer.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.16.16.169] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] CDNI Triggers interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 11:43:02 -0000 Thanks Kent - replies inline ... On 22/03/2012 18:11, "Kent Leung (kleung)" wrote: >Hi Rob. Nice write-up. Here are some comments on the draft. > >1. Sect. 2: Nit for "The trigger may request action on either metadata >or on content". Reword to "The trigger may request action on either >metadata or content"? Will do. >2. Sect. 2: Any thoughts on the scalability aspect of using RESTful web >service assuming there will be many dCDNs providing delivery service for >a uCDN? These triggers will likely apply on all the dCDNs. Since uCDN has the contract with the Content Owner (or with another uCDN that does), it has ultimate responsibility for ensuring that triggers are acted upon - I think it will need to track which dCDNs have its data and which have completed its triggers, for auditing purposes if nothing else? Because it's got that responsibility, uCDN will want a way to interrogate dCDN for status of triggers so, correspondingly, dCDN will need to track and report state of triggers. So, I'd say per-trigger, per-interconnect state will exist at both ends of the interface whether it's RESTful or not. Does that answer the concern? I can add some descriptive text to the draft along those lines if it does. Do you have a feel for the numbers of interconnects a given CDN is likely to have? I can't find an indication in the problem-statement or requirements - but I'd imagine each CDN will have a relatively small number of interconnect agreements, perhaps up to low tens? Generally I'd think CDNs will have many fewer interconnects than Delivery Surrogates, but an exception might be a "broker" CDN that owns content but doesn't do the actual delivery itself. In that case, I'd guess we're not talking about thousands of interconnects but perhaps it might get into hundreds? I don't have any actual facts or data to cloud my thinking though (!), so I'd be interested to hear other views. >3. Sect. 4: Typo in "For example, is anticipated that decisions on use >of HTTPS for other CDNI interfaces will be adopted for Triggers." Will fix. >4. Sect. 4.1: The Trigger Request must be processed in the sequence as >triggered by the uCDN? Is there a message sequencing method defined? For >example, uCDN wants to purge a specific content, then preposition that >content. What happens when the message arrives at dCDN out of order? Good point, thanks, I've not covered that. If we define the invalidate/purge triggers to mean "invalidate or purge data obtained before this trigger was created" (before "ctime" of the Trigger Status Resource), I think that solves the problem. For example, a use-case for "invalidate" followed by "preposition" would be an emergency fix to some metadata or content - with this change, by issuing triggers in order after the data is repaired, uCDN can be sure incorrect data is deleted. But, data acquired from the same location after the repair (either as a result of pre-positioning or normal operation) will not need to be re-fetched. The invalidate/purge and the preposition triggers can run concurrently. I makes the semantics of invalidate/purge cleaner anyway. If (repaired) data can still obtained from affected URL, it'd be hard for uCDN to guarantee that when a purge completes no data from affected URLs exists in dCDN. Much easier for it to say that data acquired before a given time has been invalidated/purged from the network. >5. Sect. 4.2: Nit for ".. to cheaply check for change .." Maybe " .. to >inherently check for change .."? How about "... to check for change in status of a resource or collection of resources without re-fetching the whole resource or collection." > >6. Sect 4.2: Reword " to indicate the frequency it would like uCDN to >poll at." to " to indicate the frequency of polling by the uCDN"? How about "The dCDN should use the cache control headers for responses to GETs for Trigger Status Resources and Collections to indicate the frequency at which it recommends uCDN should poll for change." >Kent > >-----Original Message----- >From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of >Rob Murray >Sent: Wednesday, February 29, 2012 1:25 PM >To: cdni@ietf.org >Subject: [CDNi] CDNI Triggers interface > >Hi all, > >I've just uploaded a new draft that proposes a CDNI Triggers interface >... > > http://datatracker.ietf.org/doc/draft-murray-cdni-triggers/ > > >There was some discussion at the last WG meeting about whether triggers >fit best as part of the control or metadata interface - the suggestion >was >that concrete proposals for the interface might help us spot commonality >with one or the other, so let's see! > >Please take a look, your comments are welcome. > >Best regards, >Rob. > > >On 29/02/2012 19:37, "internet-drafts@ietf.org" > >wrote: > >>A new version of I-D, draft-murray-cdni-triggers-00.txt has been >>successfully submitted by Rob Murray and posted to the IETF repository. >> >>Filename: draft-murray-cdni-triggers >>Revision: 00 >>Title: CDN Interconnect Triggers >>Creation date: 2012-02-29 >>WG ID: Individual Submission >>Number of pages: 33 >> >>Abstract: >> This document proposes a mechanism for a CDN to trigger activity in >> an interconnected CDN that is configured to deliver content on its >> behalf. The upstream CDN can use this mechanism to request that the >> downstream CDN pre-positions metadata or content, or that it re- >> validate or purge metadata or content. The upstream CDN can monitor >> the status of activity that it has triggered in the downstream CDN. >> >> >> =20 >> =20 >> >> >>The IETF Secretariat > >_______________________________________________ >CDNi mailing list >CDNi@ietf.org >https://www.ietf.org/mailman/listinfo/cdni From gilles.bertrand@orange.com Mon Mar 26 01:24: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 CE97821F855A for ; Mon, 26 Mar 2012 01:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Znce85aR1DeQ for ; Mon, 26 Mar 2012 01:24:16 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4341021F8546 for ; Mon, 26 Mar 2012 01:24:11 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D05315D86EA; Mon, 26 Mar 2012 10:24:09 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id C5DB85D86E6; Mon, 26 Mar 2012 10:24:09 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Mar 2012 10:24:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Mar 2012 10:23:34 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF033E0C52@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1DD4@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] CDNI Requirements for ABR content Thread-Index: Ac0BSJhyMA6ZY4c+Q3uSDuyuYRmJ/QG+E8PgALkWbsA= References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com><7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1DD4@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 26 Mar 2012 08:24:09.0655 (UTC) FILETIME=[D14B4C70:01CD0B29] Subject: Re: [CDNi] CDNI Requirements for ABR content 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, 26 Mar 2012 08:24:19 -0000 Hi Kent, About the tagging as "High" of Event-Based Logging support, I would like = to understand what it implies=20 - for the CDN and=20 - for the client.=20 I see the following differences between Event-Based Logging and = "file-based logging": - Session: I am not an expert of all adaptive streaming flavors; do = existing clients provide a usable session id to the server? - other service level information:=20 # Manifest-uri: could the CDN derive it from the session data? # Content-id: How could the CDN derive this information: From the = content URL? From the session data? Other? # Representation: How could the CDN derive this information: From = the content URL? From the session data?=20 About the tagging as "Med" of segment based logging, I would also like = to understand the impact on the CDN/client: - the CDN sees the chunk requests (except the ones served by a = caching-proxy or the browser cache). So I think this logging format is = not more complex than event based logging for the client (it does not = have to send specific information). For the CDN, the support of this = format only requires the additional ability to: - understand the URL formats to detect the representation changes=20 - detect session ends? Best regards, Gilles -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part = de Kent Leung (kleung) Envoy=E9=A0: jeudi 22 mars 2012 17:00 =C0=A0: cdni@ietf.org Objet=A0: [CDNi] CDNI Requirements for ABR content Tracking requirements from CDNI Interface drafts. Based on the = discussion for draft-lefaucheur-cdni-logging-delivery, we need some = inputs from the WG on the CDNI Logging requirements. Options for logging requirements for ABR content: =A0 1) Event-Based Logging shall be supported [HIGH], Segment-Based Logging = should be supported [MED], and Summary-Based Logging may be supported = [LOW].=20 Reason: The dCDN needs to be aware of ABR content and should log = delivery with the ABR-related fields. ABR is expected to be a very = common delivery format and requires some form of log compression over = very voluminous per-segment logging. ABR content needs to be supported = by CDNs. Related requirement is "GEN-14 [HIGH] The CDNI solution shall = support HTTP Adaptive Bit Rate (ABR) content." OR 2) Event-Based Logging, Segment-Based Logging, and Summary-Based = Logging may be supported [LOW].=20 =09 Reason: Eliminate the need for dCDN to be aware of ABR content. For = example, dCDN is acting in a pure HTTP reverse proxy mode and may not be = aware of that level of information and/or because the control of how to = identify those fields is owned by the CSP and none of CDNs may have = visibility of that mapping information. Such a requirement to force CDNs = and CDNI in general to require such mappings seems to be overkill. Thoughts? Kent -----Original Message----- From: Francois Le Faucheur (flefauch)=20 Sent: Tuesday, March 13, 2012 11:39 AM To: Kent Leung (kleung); Niven-Jenkins Ben Cc: Francois Le Faucheur (flefauch); cdni@ietf.org; Mahesh Viveganandhan = (mvittal) Subject: Re: [CDNi] Comments on = draft-lefaucheur-cdni-logging-delivery-00 Ben, Kent, Trying to extract the key points from the thread: 1) level of requirement for support of HTTP Adaptive Streaming Logging = Session (ie ABR-aware logs): This is a valid question.=20 The I-D proposes that some form of ABR-aware logging be mandatory. The = rationale is that ABR is expected to be a very common delivery format = and requires some form of log compression over very voluminous = per-segment logging. (BTW the I-D currently proposes that both = Segment-Based Logging format and Event-Based Logging format be = mandatory. But come to think of it, having only Event-Based Logging = format mandatory would be sufficient from my viewpoint).=20 Ben argues that ABR-aware logging should not be mandatory as it requires = extra awareness. To get more input, I'd propose we move that requirement level discussion = to the cdni-requirements document, and have the logging I-D only talks = about what such logs would look like. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From internet-drafts@ietf.org Mon Mar 26 03:11: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 6DE3621F860E; Mon, 26 Mar 2012 03:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.159, 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 FZZPh32rpXD9; Mon, 26 Mar 2012 03:11:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C581F21F858F; Mon, 26 Mar 2012 03:11:29 -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.00 Message-ID: <20120326101129.7317.73358.idtracker@ietfa.amsl.com> Date: Mon, 26 Mar 2012 03:11:29 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-use-cases-04.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, 26 Mar 2012 10:11:30 -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 Interconnec= tion Working Group of the IETF. Title : Use Cases for Content Delivery Network Interconnection Author(s) : Gilles Bertrand Stephan Emile Grant Watson Trevor Burbridge Philip Eardley Kevin Ma Filename : draft-ietf-cdni-use-cases-04.txt Pages : 18 Date : 2012-03-26 Content Delivery Networks (CDNs) are commonly used for improving the End User experience of a content delivery service, at a reasonable cost. 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 CDNI interfaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-04.txt From kleung@cisco.com Mon Mar 26 08:12: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 2344E21E8097 for ; Mon, 26 Mar 2012 08:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.968 X-Spam-Level: X-Spam-Status: No, score=-9.968 tagged_above=-999 required=5 tests=[AWL=0.631, 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 D6tjADXNd8yr for ; Mon, 26 Mar 2012 08:12:30 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 09A8821F8418 for ; Mon, 26 Mar 2012 08:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=5790; q=dns/txt; s=iport; t=1332774728; x=1333984328; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=gyrj3GoJQuV0MmDTJxPRQX8EtDJL9tM+XGp6DtSkGIE=; b=WtuSeB241VAPDUxjvBtyj0udWePNUixQISyTnlBoRkwH41wgwPHzy5+i 6nCdNhJ9DuCx80SWMQnc9xlbbXpfHPqlav+VXWKsIQlM/XxWDIVC71ekl THlOUFkVfWFCFXz2oPwZBArCBn1qdex1Qx4c7i1ocrDsk5fUL42Aw8O5s 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALOGcE+rRDoH/2dsb2JhbAA6CrgqgQeCCQEBAQQBAQEPAR07AxcEAgEIEQQBAQsGFwEGASYfCQgBAQQBEggTB4dnAQuaF55eBIpehWdjBIgkM5tOgWiDB4E0Bw X-IronPort-AV: E=Sophos;i="4.73,650,1325462400"; d="scan'208";a="35112506" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 26 Mar 2012 15:12:07 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2QFC7Ab008162; Mon, 26 Mar 2012 15:12:07 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Mar 2012 08:12:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Mar 2012 08:09:09 -0700 Message-ID: <7A2D6D1F6AC99243A77D32820D8ABBC20E95C703@xmb-sjc-235.amer.cisco.com> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF033E0C52@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [CDNi] CDNI Requirements for ABR content Thread-Index: Ac0BSJhyMA6ZY4c+Q3uSDuyuYRmJ/QG+E8PgALkWbsAADdK2MA== References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com><7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1DD4@xmb-sjc-235.amer.cisco.com> <8E09C72DBC577D489F13A71228C0B7BF033E0C52@ftrdmel0.rd.francetelecom.fr> From: "Kent Leung (kleung)" To: , X-OriginalArrivalTime: 26 Mar 2012 15:12:07.0677 (UTC) FILETIME=[CF550AD0:01CD0B62] Subject: Re: [CDNi] CDNI Requirements for ABR content 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, 26 Mar 2012 15:12:32 -0000 Hi Gilles. The client has to be ABR-aware to obtain the ABR content. So = the question is only pertinent for the CDN. The methods for CDN to = associate delivery of contents for the ABR session are based on cookie = or URI tag (BTW, client just passes this info back to the CDN). Also, = CDN needs to understand the manifest file (for HLS/HDS/HSS) to determine = the abr-protocol, representation, manifest-uri, and content-id. Both Event-Based Logging and Session-Based Logging require CDN to = understand the ABR content type. So the implications or impact to the = CDN is basically the same for either logging mode. For file-based = logging, the CDN treats each content delivery as a file and unaware that = it is really a segment/chunk/fragment of the whole content. There's no = knowledge that there is a manifest file or different representations or = when representation changed. I believe the reason for Event-Based Logging as [HIGH] and Session-Based = Logging as [MED] is the expectation that most of the content for the ABR = session will be delivered at a steady rate after the initial buffering. Does that answer your questions? Kent -----Original Message----- From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com]=20 Sent: Monday, March 26, 2012 1:24 AM To: Kent Leung (kleung); cdni@ietf.org Subject: RE: [CDNi] CDNI Requirements for ABR content Hi Kent, About the tagging as "High" of Event-Based Logging support, I would like = to understand what it implies=20 - for the CDN and=20 - for the client.=20 I see the following differences between Event-Based Logging and = "file-based logging": - Session: I am not an expert of all adaptive streaming flavors; do = existing clients provide a usable session id to the server? - other service level information:=20 # Manifest-uri: could the CDN derive it from the session data? # Content-id: How could the CDN derive this information: From the = content URL? From the session data? Other? # Representation: How could the CDN derive this information: From = the content URL? From the session data?=20 About the tagging as "Med" of segment based logging, I would also like = to understand the impact on the CDN/client: - the CDN sees the chunk requests (except the ones served by a = caching-proxy or the browser cache). So I think this logging format is = not more complex than event based logging for the client (it does not = have to send specific information). For the CDN, the support of this = format only requires the additional ability to: - understand the URL formats to detect the representation changes=20 - detect session ends? Best regards, Gilles -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part = de Kent Leung (kleung) Envoy=E9=A0: jeudi 22 mars 2012 17:00 =C0=A0: cdni@ietf.org Objet=A0: [CDNi] CDNI Requirements for ABR content Tracking requirements from CDNI Interface drafts. Based on the = discussion for draft-lefaucheur-cdni-logging-delivery, we need some = inputs from the WG on the CDNI Logging requirements. Options for logging requirements for ABR content: =A0 1) Event-Based Logging shall be supported [HIGH], Segment-Based Logging = should be supported [MED], and Summary-Based Logging may be supported = [LOW].=20 Reason: The dCDN needs to be aware of ABR content and should log = delivery with the ABR-related fields. ABR is expected to be a very = common delivery format and requires some form of log compression over = very voluminous per-segment logging. ABR content needs to be supported = by CDNs. Related requirement is "GEN-14 [HIGH] The CDNI solution shall = support HTTP Adaptive Bit Rate (ABR) content." OR 2) Event-Based Logging, Segment-Based Logging, and Summary-Based = Logging may be supported [LOW].=20 =09 Reason: Eliminate the need for dCDN to be aware of ABR content. For = example, dCDN is acting in a pure HTTP reverse proxy mode and may not be = aware of that level of information and/or because the control of how to = identify those fields is owned by the CSP and none of CDNs may have = visibility of that mapping information. Such a requirement to force CDNs = and CDNI in general to require such mappings seems to be overkill. Thoughts? Kent -----Original Message----- From: Francois Le Faucheur (flefauch)=20 Sent: Tuesday, March 13, 2012 11:39 AM To: Kent Leung (kleung); Niven-Jenkins Ben Cc: Francois Le Faucheur (flefauch); cdni@ietf.org; Mahesh Viveganandhan = (mvittal) Subject: Re: [CDNi] Comments on = draft-lefaucheur-cdni-logging-delivery-00 Ben, Kent, Trying to extract the key points from the thread: 1) level of requirement for support of HTTP Adaptive Streaming Logging = Session (ie ABR-aware logs): This is a valid question.=20 The I-D proposes that some form of ABR-aware logging be mandatory. The = rationale is that ABR is expected to be a very common delivery format = and requires some form of log compression over very voluminous = per-segment logging. (BTW the I-D currently proposes that both = Segment-Based Logging format and Event-Based Logging format be = mandatory. But come to think of it, having only Event-Based Logging = format mandatory would be sufficient from my viewpoint).=20 Ben argues that ABR-aware logging should not be mandatory as it requires = extra awareness. To get more input, I'd propose we move that requirement level discussion = to the cdni-requirements document, and have the logging I-D only talks = about what such logs would look like. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From ray.vanbrandenburg@tno.nl Mon Mar 26 08:26: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 8416621E80CF for ; Mon, 26 Mar 2012 08:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.143 X-Spam-Level: X-Spam-Status: No, score=0.143 tagged_above=-999 required=5 tests=[AWL=0.647, 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 3oXy46vi6R6u for ; Mon, 26 Mar 2012 08:26:14 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC4721E80D6 for ; Mon, 26 Mar 2012 08:26:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,650,1325458800"; d="scan'208";a="14878017" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 26 Mar 2012 17:25:59 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.232]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.02.0283.003; Mon, 26 Mar 2012 17:25:59 +0200 From: "Brandenburg, R. (Ray) van" To: "Kent Leung (kleung)" , "gilles.bertrand@orange.com" , "cdni@ietf.org" Thread-Topic: [CDNi] CDNI Requirements for ABR content Thread-Index: AQHNCETi17ClXLSrq0e902XpETmVi5Z8IWcAgABxUYCAACPkYA== Date: Mon, 26 Mar 2012 15:25:58 +0000 Message-ID: References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com><7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1DD4@xmb-sjc-235.amer.cisco.com> <8E09C72DBC577D489F13A71228C0B7BF033E0C52@ftrdmel0.rd.francetelecom.fr>, <7A2D6D1F6AC99243A77D32820D8ABBC20E95C703@xmb-sjc-235.amer.cisco.com> In-Reply-To: <7A2D6D1F6AC99243A77D32820D8ABBC20E95C703@xmb-sjc-235.amer.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.191] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [CDNi] CDNI Requirements for ABR content 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, 26 Mar 2012 15:26:15 -0000 Hi Gilles/Kent/all, It seems to me that the question we keep getting back to is whether the CDN= is aware of ABR content (and if we want to require a CDN to be aware of th= is). This question will probably also come up when discussing other interfa= ces (especially metadata and request routing). I therefore suggest that we first discuss the high-level requirements/assum= ptions regarding ABR/HAS and CDNI, come up with some guidelines for how the= CDNI interfaces should deal with ABR/HAS, and then apply these guidelines = to the various interfaces (such as in this case the logging interface). I wrote a draft for initiating such a discussion, see http://www.ietf.org/i= d/draft-brandenburg-cdni-has-00.txt. Comments are welcome. Best regards, Ray ________________________________________ From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] on behalf of Kent Leung= (kleung) [kleung@cisco.com] Sent: Monday, March 26, 2012 5:09 PM To: gilles.bertrand@orange.com; cdni@ietf.org Subject: Re: [CDNi] CDNI Requirements for ABR content Hi Gilles. The client has to be ABR-aware to obtain the ABR content. So the= question is only pertinent for the CDN. The methods for CDN to associate d= elivery of contents for the ABR session are based on cookie or URI tag (BTW= , client just passes this info back to the CDN). Also, CDN needs to underst= and the manifest file (for HLS/HDS/HSS) to determine the abr-protocol, repr= esentation, manifest-uri, and content-id. Both Event-Based Logging and Session-Based Logging require CDN to understan= d the ABR content type. So the implications or impact to the CDN is basical= ly the same for either logging mode. For file-based logging, the CDN treats= each content delivery as a file and unaware that it is really a segment/ch= unk/fragment of the whole content. There's no knowledge that there is a man= ifest file or different representations or when representation changed. I believe the reason for Event-Based Logging as [HIGH] and Session-Based Lo= gging as [MED] is the expectation that most of the content for the ABR sess= ion will be delivered at a steady rate after the initial buffering. Does that answer your questions? Kent -----Original Message----- From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com] Sent: Monday, March 26, 2012 1:24 AM To: Kent Leung (kleung); cdni@ietf.org Subject: RE: [CDNi] CDNI Requirements for ABR content Hi Kent, About the tagging as "High" of Event-Based Logging support, I would like to= understand what it implies - for the CDN and - for the client. I see the following differences between Event-Based Logging and "file-based= logging": - Session: I am not an expert of all adaptive streaming flavors; do existin= g clients provide a usable session id to the server? - other service level information: # Manifest-uri: could the CDN derive it from the session data? # Content-id: How could the CDN derive this information: From the con= tent URL? From the session data? Other? # Representation: How could the CDN derive this information: From the= content URL? From the session data? About the tagging as "Med" of segment based logging, I would also like to u= nderstand the impact on the CDN/client: - the CDN sees the chunk requests (except the ones served by a caching-prox= y or the browser cache). So I think this logging format is not more complex= than event based logging for the client (it does not have to send specific= information). For the CDN, the support of this format only requires the ad= ditional ability to: - understand the URL formats to detect the representation changes - detect session ends? Best regards, Gilles -----Message d'origine----- De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de Ken= t Leung (kleung) Envoy=E9 : jeudi 22 mars 2012 17:00 =C0 : cdni@ietf.org Objet : [CDNi] CDNI Requirements for ABR content Tracking requirements from CDNI Interface drafts. Based on the discussion f= or draft-lefaucheur-cdni-logging-delivery, we need some inputs from the WG = on the CDNI Logging requirements. Options for logging requirements for ABR content: 1) Event-Based Logging shall be supported [HIGH], Segment-Based Log= ging should be supported [MED], and Summary-Based Logging may be supported = [LOW]. Reason: The dCDN needs to be aware of ABR content and should log de= livery with the ABR-related fields. ABR is expected to be a very common del= ivery format and requires some form of log compression over very voluminous= per-segment logging. ABR content needs to be supported by CDNs. Related re= quirement is "GEN-14 [HIGH] The CDNI solution shall support HTTP Adaptive = Bit Rate (ABR) content." OR 2) Event-Based Logging, Segment-Based Logging, and Summary-Based Lo= gging may be supported [LOW]. Reason: Eliminate the need for dCDN to be aware of ABR content. For= example, dCDN is acting in a pure HTTP reverse proxy mode and may not be a= ware of that level of information and/or because the control of how to iden= tify those fields is owned by the CSP and none of CDNs may have visibility = of that mapping information. Such a requirement to force CDNs and CDNI in g= eneral to require such mappings seems to be overkill. Thoughts? Kent -----Original Message----- From: Francois Le Faucheur (flefauch) Sent: Tuesday, March 13, 2012 11:39 AM To: Kent Leung (kleung); Niven-Jenkins Ben Cc: Francois Le Faucheur (flefauch); cdni@ietf.org; Mahesh Viveganandhan (m= vittal) Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 Ben, Kent, Trying to extract the key points from the thread: 1) level of requirement for support of HTTP Adaptive Streaming Logging Sess= ion (ie ABR-aware logs): This is a valid question. The I-D proposes that some form of ABR-aware logging be mandatory. The rati= onale is that ABR is expected to be a very common delivery format and requi= res some form of log compression over very voluminous per-segment logging. = (BTW the I-D currently proposes that both Segment-Based Logging format and = Event-Based Logging format be mandatory. But come to think of it, having on= ly Event-Based Logging format mandatory would be sufficient from my viewpoi= nt). Ben argues that ABR-aware logging should not be mandatory as it requires ex= tra awareness. To get more input, I'd propose we move that requirement level discussion to= the cdni-requirements document, and have the logging I-D only talks about = what such logs would look like. _______________________________________________ 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 This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From Jan.Seedorf@neclab.eu Mon Mar 26 10:33: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 56C9E21F85AE for ; Mon, 26 Mar 2012 10:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 atJpAmxwa64b for ; Mon, 26 Mar 2012 10:33:08 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA9721F8569 for ; Mon, 26 Mar 2012 10:32:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 08EF1100A84; Mon, 26 Mar 2012 19:33:15 +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 3hzvlvdUK18r; Mon, 26 Mar 2012 19:33:14 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id D8E3D100A83; Mon, 26 Mar 2012 19:33:04 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.36]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 26 Mar 2012 19:32:17 +0200 From: Jan Seedorf To: Francois Le Faucheur , Jan Seedorf Thread-Topic: [CDNi] Few high level comments re draft-spp-cdni-rr-foot-cap-semantics-00.txt Thread-Index: AQHNCGJhH2he4TBB8U6/kTo1JhHN0pZ82aTQ Date: Mon, 26 Mar 2012 17:32:16 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24F51253@Polydeuces.office.hd> References: <20120305160316.5234.87849.idtracker@ietfa.amsl.com> <73AF50D3-F8ED-41E7-B7F1-F5F590D31B5B@cisco.com> <2779C9F0771F974CAD742BAE6D9904FE24F4E47D@Polydeuces.office.hd> <2A1DB62E-0EC6-4667-A7F5-386A6FF86AD7@cisco.com> In-Reply-To: <2A1DB62E-0EC6-4667-A7F5-386A6FF86AD7@cisco.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.196] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Few high level comments re draft-spp-cdni-rr-foot-cap-semantics-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, 26 Mar 2012 17:33:09 -0000 Hi Francois, Let me answer inline, but I think we are mostly in agreement: > I believe the "advertisement" part also needs to convey the cascaded > information (but flowing in the opposite direction to request redirection= of > course). > Let's say we have a cascaded CDN scenario where CDN1 may use CDN2 as a > dCDN, and where CDN2 may use CDN3 as a dCDN. > Then CDN3 would advertise its footprint to CDN2, and CDN2 would advertise > to CDN1 a footprint that covers CDN2/s footprint and CDN3's footprint. Th= is is > necessary so that CDN1 can select CDN2 for a request that is within CDN3'= s > footprint. I do not necessarily see why. In your example, if CDN2 implicitly includes = CDN3's footprint in its footprint it advertises to uCDN, everything should = work fine: uCDN is aware that dCDN can serve that footprint, but how exactl= y is none of uCDNs business, is it? :) Actually, I think therequirements do= c says that the dCDN should not have to disclose internals like surrogate l= ocation etc. Why should it be forced to disclose its own business agreement= s with other dCDNs as long as advertises the correct overall information to= the uCDN? > So the CDNI footprint advertisement problem comprises: > * an interface between two CDNs to exchange footprint information > * a logic to process incoming footprint information form a dCDN and decid= e > if/how it is to be re-advertised/aggregated when advertising footprint to > another CDN. > I recommend you discuss that aspect. Discussing this aspect in more detail in the draft and documenting the desi= gn choices here is a good recommendation. We will try to make this aspect m= ore clear in the next version, so that the reader can better understand wha= t is the issue here (for me, as said below, the issue is IMPLICIT vs. EXPLI= CIT advertisement of transitive dCDN relationships). > Not sure. In my view, the dCDN could in principle express load not for > individual caches but for caches in a certain region without disclosing d= etails > about its caches. >=20 >=20 >=20 > Fair enough. Some aggregated information may be reasonable. I suggest you > change text which can currently be understood to mean per-cache > information, into something explaining that aggregate info may be an > interesting trade-off between not "disclosing too much" and being helpful > for CDN selection by uCDN. >=20 > In fact, the binary/busy signal already mentioned in REQ-1 can be seen as= a > very aggregated "excessive load" signal. Ok, seems we agree here. > Ok, we can add a reference to this current consensus. Still, we are > trying to explain the extreme cases of advertisement details, >=20 > that's why I would like to have the extreme case example with direct > redirection to caches in the dCDN still in the document. >=20 >=20 >=20 > Personally, I'm more interested in documenting the consensus on what we > want to do, than extreme cases we don't really want to do, but I am fine = if > you want to bring them up as long as you identify them as such (ie extrem= e > cases we can think of but know we don't want to do). Understood and agree. We can clearly state that current WG consensus is not= to have a direct redirection to dCDN surrogates.=20 - Jan > -----Original Message----- > From: Francois Le Faucheur [mailto:flefauch@cisco.com] > Sent: Thursday, March 22, 2012 8:28 PM > To: Jan Seedorf > Cc: Francois Le Faucheur; cdni@ietf.org > Subject: Re: [CDNi] Few high level comments re draft-spp-cdni-rr-foot-cap= - > semantics-00.txt >=20 > Hello Jan, >=20 > Looks like we've converged on most points. On the remaining ones: >=20 > On 22 Mar 2012, at 14:37, Jan Seedorf wrote: >=20 >=20 >=20 >=20 >=20 > * the requirement related to support of cascaded CDNs must > be >=20 >=20 > included as it impacts the overall solution: >=20 >=20 > " REQ-3 [MED] In the case of cascaded redirection, the=20 >=20 > CDNI Request- >=20 >=20 > Routing interface shall allow the Downstream CDN to > also > > include in the information communicated to the > Upstream CDN, >=20 >=20 > information on the capabilities, resources and affinities > of >=20 >=20 > CDNs to which the Downstream CDN may (in turn) > redirect >=20 >=20 > requests received by the Upstream CDN. In that case, > the >=20 >=20 > CDNI Request-Routing interface shall prevent looping of > such >=20 >=20 > information exchange. >=20 >=20 > " >=20 >=20 > Not sure about this one. I read the requirement that the overall CDNI > request routing needs to support cascaded CDNs, and that information > exchanged needs to include cascaded dCDNs. The question at hand is if the > "advertisement" part also needs to signal such cascading information > EXPLICITLY, or if cascading CDNs merely need to be supported by the > redirection part of the request routing interface, >=20 >=20 > I believe the "advertisement" part also needs to convey the cascaded > information (but flowing in the opposite direction to request redirection= of > course). > Let's say we have a cascaded CDN scenario where CDN1 may use CDN2 as a > dCDN, and where CDN2 may use CDN3 as a dCDN. > Then CDN3 would advertise its footprint to CDN2, and CDN2 would advertise > to CDN1 a footprint that covers CDN2/s footprint and CDN3's footprint. Th= is is > necessary so that CDN1 can select CDN2 for a request that is within CDN3'= s > footprint. > So the CDNI footprint advertisement problem comprises: > * an interface between two CDNs to exchange footprint information > * a logic to process incoming footprint information form a dCDN and decid= e > if/how it is to be re-advertised/aggregated when advertising footprint to > another CDN. > I recommend you discuss that aspect. >=20 >=20 > i.e. the cascading information is IMPLICITLY included in the > advertisement information. This is to me the open question, which we try = to > raise in the draft. But it is probably a good idea to clarify that a bit = more in the > draft and to cite the requirement above. >=20 >=20 >=20 >=20 >=20 > In line with GEN-4, I believe some of the candidate > "capabilities" listed in >=20 >=20 > section 5 (ie individual "Cache Capabilities are: o load, or > "excessive load", >=20 >=20 > o available resources, storage resources, o failure > conditions) can be >=20 >=20 > excluded (at least for initial CDNI WG work). >=20 >=20 > Not sure. In my view, the dCDN could in principle express load not for > individual caches but for caches in a certain region without disclosing d= etails > about its caches. >=20 >=20 >=20 > Fair enough. Some aggregated information may be reasonable. I suggest you > change text which can currently be understood to mean per-cache > information, into something explaining that aggregate info may be an > interesting trade-off between not "disclosing too much" and being helpful > for CDN selection by uCDN. >=20 > In fact, the binary/busy signal already mentioned in REQ-1 can be seen as= a > very aggregated "excessive load" signal. >=20 >=20 >=20 > As per the recent email thread, I believe there is consensus that the > CDNI >=20 >=20 > footprint & capabilities advertisement interface is all about > helping the uCDN >=20 >=20 > select a dCDN, and not about helping the uCDN to select a > specific cache in >=20 >=20 > the dCDN (at least for the initial CDNI WG work). While this is > already >=20 >=20 > implicitly reflected in the wording of requirements and > description, I would >=20 >=20 > recommend stating this explicitly to avoid confusion. >=20 >=20 > Ok, we can add a reference to this current consensus. Still, we are > trying to explain the extreme cases of advertisement details, >=20 > that's why I would like to have the extreme case example with direct > redirection to caches in the dCDN still in the document. >=20 >=20 >=20 > Personally, I'm more interested in documenting the consensus on what we > want to do, than extreme cases we don't really want to do, but I am fine = if > you want to bring them up as long as you identify them as such (ie extrem= e > cases we can think of but know we don't want to do). >=20 > Cheers. >=20 > Francois From mcaulfie@cisco.com Mon Mar 26 11:29: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 4D71B21F85B8 for ; Mon, 26 Mar 2012 11:29:18 -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 5EDAhfX5YKQU for ; Mon, 26 Mar 2012 11:29:14 -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 79AFA21F85B6 for ; Mon, 26 Mar 2012 11:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcaulfie@cisco.com; l=3982; q=dns/txt; s=iport; t=1332786554; x=1333996154; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=IMPT+f3YidLcHHR7NCDonngqs6eKGPeFX/8VXKW080M=; b=ATRmT2fBwlRJApBHW74GYK0hdEXcX37GeboHfFNwtqVgwUCZg0YwC156 uMPkeu/zloYJuqzf5X/g8XzQz2TIinowf83r6QP8fzHhU5CUf5yHyPf8V U8yy3f64MXCRrSqWv7rluJB6BMka2kpdvm0ADKMAjK5uLQKKRU8C2rpX2 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKq0cE+tJXG8/2dsb2JhbAA6Crg0gQeCCQEBAQQBAQEPAR0KMwELDAQCAQgRBAEBCwYXAQYBJh8JCAEBBBMIEweHaAuaOp5yil6FZ2MEiFeOGoojgxGBaIMFgTgGEQ X-IronPort-AV: E=Sophos;i="4.73,652,1325462400"; d="scan'208";a="69523830" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 26 Mar 2012 18:29:14 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2QITD6I015706; Mon, 26 Mar 2012 18:29:13 GMT Received: from xmb-rcd-209.cisco.com ([72.163.62.216]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Mar 2012 13:29:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Mar 2012 13:29:12 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] CDNI Triggers interface Thread-Index: Acz3Mqt/m79xvXgfQha5EvvkZ1oA5wUP07NA References: From: "Matt Caulfield (mcaulfie)" To: "Rob Murray" X-OriginalArrivalTime: 26 Mar 2012 18:29:13.0963 (UTC) FILETIME=[585913B0:01CD0B7E] Cc: cdni@ietf.org Subject: Re: [CDNi] CDNI Triggers interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 18:29:18 -0000 Rob, Great document, nice clarity. A few comments / questions: 1. A single trigger can apply to multiple URLs but only a single "status" indicator is provided when then the trigger is polled. What happens when prepositioning one URL succeeds and another one fails?=20 2. For the cascading CDNs case, another question on status granularity. When does a trigger complete? After the immediately downstream CDN finishes the task? Or after the downstream CDN and its own downstream CDNs finish the task? If one dCDN fails to preposition content while another succeeds, is the trigger status Complete or Failed? 3. Can triggers be processed out of order? I believe Kent had a similar comment in his email, but I'm not sure about the proposed solution. Would basing decisions on time open us up to race conditions? 4. In the trigger request, content urls are separate from metadata urls. How is metadata identified? Is the metadata URL in the trigger request the url of the content for which the metatdata should be purged/prepositioned? Or is the metadata URL that of the metadata resource itself? If the latter, I see no reason to distinguish between metadata and content urls.=20 5. In the HTTP redirection case, each CDN uses a different URL to identify content. For example, an upstream CDN may use http://ucdn.com/content1 while a downstream CDN uses http://dcdn.com/ucdn/content1. Is it a correct assumption that each CDN in a cascade of CDNs must rewrite the trigger URLs to match what the downstream CDN would expect? 6. From a security considerations standpoint, the Triggers interface requires client authentication. I believe that's what you're hinting at in the Security Considerations section but it could be more explicit. I don't think this requirement is true for all CDNI interfaces (most need server authentication, but maybe not all need client authentication). 7. Is polling the only option for learning about status changes? Would registering a callback be more scalable? 8. Is there an implicit assumption that for any given piece of content, there will only be a single source of triggers? What if a CDN receives the same trigger from two upstream CDNs? Thanks, Matt -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Rob Murray Sent: Wednesday, February 29, 2012 5:34 PM To: cdni@ietf.org Subject: [CDNi] CDNI Triggers interface Hi all, I've just uploaded a new draft that proposes a CDNI Triggers interface ... http://tools.ietf.org/html/draft-murray-cdni-triggers-00 There was some discussion at the last WG meeting about whether triggers fit best as part of the control or metadata interface - the suggestion was that concrete proposals for the interface might help us spot commonality with one or the other, so let's see! Please take a look, your comments are welcome. Best regards, Rob. On 29/02/2012 19:37, "internet-drafts@ietf.org" wrote: >A new version of I-D, draft-murray-cdni-triggers-00.txt has been >successfully submitted by Rob Murray and posted to the IETF repository. > >Filename: draft-murray-cdni-triggers >Revision: 00 >Title: CDN Interconnect Triggers >Creation date: 2012-02-29 >WG ID: Individual Submission >Number of pages: 33 > >Abstract: > This document proposes a mechanism for a CDN to trigger activity in > an interconnected CDN that is configured to deliver content on its > behalf. The upstream CDN can use this mechanism to request that the > downstream CDN pre-positions metadata or content, or that it re- > validate or purge metadata or content. The upstream CDN can monitor > the status of activity that it has triggered in the downstream CDN. > > > > > > >The IETF Secretariat _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From stef@jet-stream.com Mon Mar 26 12:17: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 BE1AA21E804B for ; Mon, 26 Mar 2012 12:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[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 rW7JyGC+2V6o for ; Mon, 26 Mar 2012 12:17:09 -0700 (PDT) Received: from monitor1.jet-stream.nl (smtp.jet-stream.nl [91.196.106.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6046521E8013 for ; Mon, 26 Mar 2012 12:17:07 -0700 (PDT) Received: from [192.168.1.10] (5ED5ABD7.cm-7-6c.dynamic.ziggo.nl [94.213.171.215]) (authenticated bits=0) by monitor1.jet-stream.nl (8.13.7/8.13.7) with ESMTP id q2QJH4T3002784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 26 Mar 2012 21:17:05 +0200 From: Stef van der Ziel Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_C2A6BF96-A353-4264-9BED-9C8357FA1878" Date: Mon, 26 Mar 2012 21:17:06 +0200 In-Reply-To: To: cdni@ietf.org References: Message-Id: <082CA012-D7F8-4CEC-A08A-2E86F11333B4@jet-stream.com> X-Mailer: Apple Mail (2.1257) Subject: [CDNi] CDNi metadata questions 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, 26 Mar 2012 19:17:09 -0000 --Apple-Mail=_C2A6BF96-A353-4264-9BED-9C8357FA1878 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I would like some clarification about CDNi metadata. It seems like it is being proposed that metadata about content is = distributed alongside with the content in XML format. However, metadata is such a vague term. What specific metadata is meant = here. I can think of these metadata types: 1 - Technical content metadata (such as bit rates, screen width, codecs, = length, size, ingest date, part of logical asset) 2 - Instructional metadata (such as delete, flush, TTL, prefill, = distribute, lock, geo-block) 3 - Status metadata (such as popularity, integrity checksums, = distribution status) 4 - Enrichment metadata (such as separate subtitles, poster frames) 5 - Description content metadata (such as name, contents, keywords, = author) These types of metadata should be treated in different ways: 1 - Technical metadata can be sent via XML files but it is up to the CDN = to pass it through or parse and use it. I would prefer to exchange this = data via REST or SOAP APIs if CDNs need to use the data. 2 - Instructional metadata should better not be distributed via files. = Instructions should be exchanged via REST or SOAP APIs. 3 - Status metadata should better not be distributed via files. Status = can be exchanged via RSS feeds or REST or SOAP APIs. 4 - Enrichment metadata should be treated as regular content, not as = specific metadata. 5 - Description metadata is useful for content management systems but = are less useful for CDNs Of course a CDN can simply pass it through but then it should be treated = as regular content, not as specific metadata. I would treat logs as separate data, not as metadata. Kind regards, Stef van der Ziel --=20 Owner Jet Stream BV | StreamZilla www.jet-stream.com | www.streamzillacdn.com --Apple-Mail=_C2A6BF96-A353-4264-9BED-9C8357FA1878 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = all,

I would like some clarification about CDNi = metadata.
It seems like it is being proposed that metadata = about content is distributed alongside with the content in XML = format.
However, metadata is such a vague term. What specific = metadata is meant here. I can think of these metadata = types:

1 - Technical content metadata (such as = bit rates, screen width, codecs, length, size, ingest date, part of = logical asset)
2 - Instructional metadata (such as delete, = flush, TTL, prefill, distribute, lock, geo-block)
3 - Status = metadata (such as popularity, integrity checksums, distribution = status)
4 - Enrichment metadata (such as separate subtitles, = poster frames)
5 - Description content metadata (such as = name, contents, keywords, = author)


These types of = metadata should be treated in different ways:

1 = - Technical metadata can be sent via XML files but it is up to the CDN = to pass it through or parse and use it. I would prefer to exchange this = data via REST or SOAP APIs if CDNs need to use the = data.

2 - Instructional metadata should better = not be distributed via files. Instructions should be exchanged via REST = or SOAP APIs.

3 - Status metadata should = better not be distributed via files. Status can be exchanged via = RSS feeds or REST or SOAP APIs.

4 - Enrichment = metadata should be treated as regular content, not as specific = metadata.

5 - Description metadata is useful = for content management systems but are less useful for CDNs
Of = course a CDN can simply pass it through but then it should be treated as = regular content, not as specific = metadata.


I would treat logs as = separate data, not as = metadata.


Kind = regards,

Stef van der = Ziel

-- 
Owner= Jet Stream BV | = StreamZilla
<= /span>
= --Apple-Mail=_C2A6BF96-A353-4264-9BED-9C8357FA1878-- From kleung@cisco.com Mon Mar 26 20:18: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 1E0BE21E8028 for ; Mon, 26 Mar 2012 20:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10 X-Spam-Level: X-Spam-Status: No, score=-10 tagged_above=-999 required=5 tests=[AWL=0.599, 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 bi9e+T-exGZC for ; Mon, 26 Mar 2012 20:18:31 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id D9A8E21E8019 for ; Mon, 26 Mar 2012 20:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=7709; q=dns/txt; s=iport; t=1332818310; x=1334027910; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=8RqRJs7YnKjh55KbX5wN9ZQqWErVfP4mi5jh6hG4fbw=; b=j74nWQPSJtKhGK7FfryOH+X/BEkkTASbQnW3lCXO64b2Ka9vKT2fQ5Eh dmVBX1oRfvTJdKfsMsabjpPvFeEDLmmCpw4gk6XDMDrE8UyKneceSwxAw rsWDtn2dlbd+KmdVBny5bxP2b6ljtuK/SNeZg8zOpTR1eA3sZj3PC/01v U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJ8wcU+rRDoJ/2dsb2JhbAA6CrhDgQeCCQEBAQQBAQEPAR07AxcEAgEIEQQBAQsGFwEGASYfCQgCBAESCAESB4dnAQuaOJ8Kil4JhUVjBIglM5tOgWiDB4E0BwE X-IronPort-AV: E=Sophos;i="4.73,655,1325462400"; d="scan'208";a="34676886" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 27 Mar 2012 03:18:30 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2R3IU8j030190; Tue, 27 Mar 2012 03:18:30 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Mar 2012 20:18:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Mar 2012 20:18:26 -0700 Message-ID: <7A2D6D1F6AC99243A77D32820D8ABBC20E95CB77@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [CDNi] CDNI Requirements for ABR content Thread-Index: AQHNCETi17ClXLSrq0e902XpETmVi5Z8IWcAgABxUYCAACPkYIAAx4BQ References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com><7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com><7A2D6D1F6AC99243A77D32820D8ABBC20E8D1DD4@xmb-sjc-235.amer.cisco.com><8E09C72DBC577D489F13A71228C0B7BF033E0C52@ftrdmel0.rd.francetelecom.fr>, <7A2D6D1F6AC99243A77D32820D8ABBC20E95C703@xmb-sjc-235.amer.cisco.com> From: "Kent Leung (kleung)" To: "Brandenburg, R. (Ray) van" , , X-OriginalArrivalTime: 27 Mar 2012 03:18:30.0330 (UTC) FILETIME=[489E21A0:01CD0BC8] Subject: Re: [CDNi] CDNI Requirements for ABR content 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, 27 Mar 2012 03:18:32 -0000 Hi Ray. Yes, that is the crux of the matter. Your writeup captured many = points to consider. I appreciate the terminology section so we can use = the same language in the discussions. Do you have a specific position on this? We can await your presentation = and gather some general consensus in the CDNI session this week. Kent -----Original Message----- From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl]=20 Sent: Monday, March 26, 2012 8:26 AM To: Kent Leung (kleung); gilles.bertrand@orange.com; cdni@ietf.org Subject: RE: [CDNi] CDNI Requirements for ABR content Hi Gilles/Kent/all, It seems to me that the question we keep getting back to is whether the = CDN is aware of ABR content (and if we want to require a CDN to be aware = of this). This question will probably also come up when discussing other = interfaces (especially metadata and request routing). I therefore suggest that we first discuss the high-level = requirements/assumptions regarding ABR/HAS and CDNI, come up with some = guidelines for how the CDNI interfaces should deal with ABR/HAS, and = then apply these guidelines to the various interfaces (such as in this = case the logging interface). I wrote a draft for initiating such a discussion, see = http://www.ietf.org/id/draft-brandenburg-cdni-has-00.txt. Comments are = welcome. Best regards, Ray ________________________________________ From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] on behalf of Kent = Leung (kleung) [kleung@cisco.com] Sent: Monday, March 26, 2012 5:09 PM To: gilles.bertrand@orange.com; cdni@ietf.org Subject: Re: [CDNi] CDNI Requirements for ABR content Hi Gilles. The client has to be ABR-aware to obtain the ABR content. So = the question is only pertinent for the CDN. The methods for CDN to = associate delivery of contents for the ABR session are based on cookie = or URI tag (BTW, client just passes this info back to the CDN). Also, = CDN needs to understand the manifest file (for HLS/HDS/HSS) to determine = the abr-protocol, representation, manifest-uri, and content-id. Both Event-Based Logging and Session-Based Logging require CDN to = understand the ABR content type. So the implications or impact to the = CDN is basically the same for either logging mode. For file-based = logging, the CDN treats each content delivery as a file and unaware that = it is really a segment/chunk/fragment of the whole content. There's no = knowledge that there is a manifest file or different representations or = when representation changed. I believe the reason for Event-Based Logging as [HIGH] and Session-Based = Logging as [MED] is the expectation that most of the content for the ABR = session will be delivered at a steady rate after the initial buffering. Does that answer your questions? Kent -----Original Message----- From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com] Sent: Monday, March 26, 2012 1:24 AM To: Kent Leung (kleung); cdni@ietf.org Subject: RE: [CDNi] CDNI Requirements for ABR content Hi Kent, About the tagging as "High" of Event-Based Logging support, I would like = to understand what it implies - for the CDN and - for the client. I see the following differences between Event-Based Logging and = "file-based logging": - Session: I am not an expert of all adaptive streaming flavors; do = existing clients provide a usable session id to the server? - other service level information: # Manifest-uri: could the CDN derive it from the session data? # Content-id: How could the CDN derive this information: From the = content URL? From the session data? Other? # Representation: How could the CDN derive this information: From = the content URL? From the session data? About the tagging as "Med" of segment based logging, I would also like = to understand the impact on the CDN/client: - the CDN sees the chunk requests (except the ones served by a = caching-proxy or the browser cache). So I think this logging format is = not more complex than event based logging for the client (it does not = have to send specific information). For the CDN, the support of this = format only requires the additional ability to: - understand the URL formats to detect the representation = changes - detect session ends? Best regards, Gilles -----Message d'origine----- De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de = Kent Leung (kleung) Envoy=E9 : jeudi 22 mars 2012 17:00 =C0 : cdni@ietf.org Objet : [CDNi] CDNI Requirements for ABR content Tracking requirements from CDNI Interface drafts. Based on the = discussion for draft-lefaucheur-cdni-logging-delivery, we need some = inputs from the WG on the CDNI Logging requirements. Options for logging requirements for ABR content: 1) Event-Based Logging shall be supported [HIGH], Segment-Based = Logging should be supported [MED], and Summary-Based Logging may be = supported [LOW]. Reason: The dCDN needs to be aware of ABR content and should log = delivery with the ABR-related fields. ABR is expected to be a very = common delivery format and requires some form of log compression over = very voluminous per-segment logging. ABR content needs to be supported = by CDNs. Related requirement is "GEN-14 [HIGH] The CDNI solution shall = support HTTP Adaptive Bit Rate (ABR) content." OR 2) Event-Based Logging, Segment-Based Logging, and Summary-Based = Logging may be supported [LOW]. Reason: Eliminate the need for dCDN to be aware of ABR content. = For example, dCDN is acting in a pure HTTP reverse proxy mode and may = not be aware of that level of information and/or because the control of = how to identify those fields is owned by the CSP and none of CDNs may = have visibility of that mapping information. Such a requirement to force = CDNs and CDNI in general to require such mappings seems to be overkill. Thoughts? Kent -----Original Message----- From: Francois Le Faucheur (flefauch) Sent: Tuesday, March 13, 2012 11:39 AM To: Kent Leung (kleung); Niven-Jenkins Ben Cc: Francois Le Faucheur (flefauch); cdni@ietf.org; Mahesh Viveganandhan = (mvittal) Subject: Re: [CDNi] Comments on = draft-lefaucheur-cdni-logging-delivery-00 Ben, Kent, Trying to extract the key points from the thread: 1) level of requirement for support of HTTP Adaptive Streaming Logging = Session (ie ABR-aware logs): This is a valid question. The I-D proposes that some form of ABR-aware logging be mandatory. The = rationale is that ABR is expected to be a very common delivery format = and requires some form of log compression over very voluminous = per-segment logging. (BTW the I-D currently proposes that both = Segment-Based Logging format and Event-Based Logging format be = mandatory. But come to think of it, having only Event-Based Logging = format mandatory would be sufficient from my viewpoint). Ben argues that ABR-aware logging should not be mandatory as it requires = extra awareness. To get more input, I'd propose we move that requirement level discussion = to the cdni-requirements document, and have the logging I-D only talks = about what such logs would look like. _______________________________________________ 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 This e-mail and its contents are subject to the DISCLAIMER at = http://www.tno.nl/emaildisclaimer From flefauch@cisco.com Mon Mar 26 23:10: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 2512321F875E for ; Mon, 26 Mar 2012 23:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.236 X-Spam-Level: X-Spam-Status: No, score=-10.236 tagged_above=-999 required=5 tests=[AWL=0.363, 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 vaTDulY2rJVA for ; Mon, 26 Mar 2012 23:10:42 -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 3C8BC21F86DC for ; Mon, 26 Mar 2012 23:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=9158; q=dns/txt; s=iport; t=1332828642; x=1334038242; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=wHLKn+h2XJVyc+BZuqTTd0SMJsvGV1M2virKgtg5D3E=; b=TtuWPg9ZVZlLmsqtg5QUbIyxuuUNKh3qA2l6hQ73QcGt9/zDmR7ScTIu ZBRVjTR69XiwIyC8Mgx8U/uKz5Tqy0SDFq7U83BATHF8Q71puJRvDZqOQ 1HuyMalA4ZMgkPlzFCmtCLYgiU6lGaXx3NX22X0BtVlt+M5Y32bNIUa9X w=; X-IronPort-AV: E=Sophos;i="4.73,655,1325462400"; d="scan'208";a="133432403" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 27 Mar 2012 06:10:41 +0000 Received: from ams-flefauch-8711.cisco.com (ams-flefauch-8711.cisco.com [10.55.161.194]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2R6Ae8p020063; Tue, 27 Mar 2012 06:10:40 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Francois Le Faucheur In-Reply-To: <7A2D6D1F6AC99243A77D32820D8ABBC20E95CB77@xmb-sjc-235.amer.cisco.com> Date: Tue, 27 Mar 2012 08:10:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4853B5B2-EDB2-46EB-B599-8559F010758D@cisco.com> References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com><7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com><7A2D6D1F6AC99243A77D32820D8ABBC20E8D1DD4@xmb-sjc-235.amer.cisco.com><8E09C72DBC577D489F13A71228C0B7BF033E0C52@ftrdmel0.rd.francetelecom.fr>, <7A2D6D1F6AC99243A77D32820D8ABBC20E95C703@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E95CB77@xmb-sjc-235.amer.cisco.com> To: Larry Peterson , "Brandenburg, R. (Ray) van" , "Kent Leung (kleung)" X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org Subject: Re: [CDNi] CDNI Requirements for ABR content 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, 27 Mar 2012 06:10:44 -0000 Ray, Larry, Kent, On 27 Mar 2012, at 05:18, Kent Leung (kleung) wrote: > Hi Ray. Yes, that is the crux of the matter. Your writeup captured = many points to consider. I appreciate the terminology section so we can = use the same language in the discussions. >=20 > Do you have a specific position on this? We can await your = presentation and gather some general consensus in the CDNI session this = week. I also believe there is useful definitions/terminology/discussion in = draft-brandenburg-cdni-has-00.txt that can be leveraged in the framework = document. To help reach consensus on how to do that, the Thursday session agenda = includes a 10 mins slot dedicated to this exact discussion right after = the presentation of draft-brandenburg-cdni-has:=20 " =95 Framework (discussion on design trade-offs), = draft-davie-cdni-framework-01: Larry Peterson (20 mins) =95 Models for adaptive-streaming-aware CDN Interconnection, = draft-brandenburg-cdni-has-00: Ray Brandenburg (10 mins) =95 Framework (discussion on reflecting adaptive streaming = design trade-offs in framework): led by Larry Peterson (10 mins) " But, if possible, I suggest that you guys get together and start = discussing this beforehand so you can come with proposals Thanks Francois >=20 > Kent >=20 > -----Original Message----- > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl]=20 > Sent: Monday, March 26, 2012 8:26 AM > To: Kent Leung (kleung); gilles.bertrand@orange.com; cdni@ietf.org > Subject: RE: [CDNi] CDNI Requirements for ABR content >=20 > Hi Gilles/Kent/all, >=20 > It seems to me that the question we keep getting back to is whether = the CDN is aware of ABR content (and if we want to require a CDN to be = aware of this). This question will probably also come up when discussing = other interfaces (especially metadata and request routing). >=20 > I therefore suggest that we first discuss the high-level = requirements/assumptions regarding ABR/HAS and CDNI, come up with some = guidelines for how the CDNI interfaces should deal with ABR/HAS, and = then apply these guidelines to the various interfaces (such as in this = case the logging interface). >=20 > I wrote a draft for initiating such a discussion, see = http://www.ietf.org/id/draft-brandenburg-cdni-has-00.txt. Comments are = welcome. >=20 > Best regards, >=20 > Ray >=20 >=20 >=20 >=20 >=20 >=20 > ________________________________________ > From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] on behalf of Kent = Leung (kleung) [kleung@cisco.com] > Sent: Monday, March 26, 2012 5:09 PM > To: gilles.bertrand@orange.com; cdni@ietf.org > Subject: Re: [CDNi] CDNI Requirements for ABR content >=20 > Hi Gilles. The client has to be ABR-aware to obtain the ABR content. = So the question is only pertinent for the CDN. The methods for CDN to = associate delivery of contents for the ABR session are based on cookie = or URI tag (BTW, client just passes this info back to the CDN). Also, = CDN needs to understand the manifest file (for HLS/HDS/HSS) to determine = the abr-protocol, representation, manifest-uri, and content-id. >=20 > Both Event-Based Logging and Session-Based Logging require CDN to = understand the ABR content type. So the implications or impact to the = CDN is basically the same for either logging mode. For file-based = logging, the CDN treats each content delivery as a file and unaware that = it is really a segment/chunk/fragment of the whole content. There's no = knowledge that there is a manifest file or different representations or = when representation changed. >=20 > I believe the reason for Event-Based Logging as [HIGH] and = Session-Based Logging as [MED] is the expectation that most of the = content for the ABR session will be delivered at a steady rate after the = initial buffering. >=20 > Does that answer your questions? >=20 > Kent >=20 > -----Original Message----- > From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com] > Sent: Monday, March 26, 2012 1:24 AM > To: Kent Leung (kleung); cdni@ietf.org > Subject: RE: [CDNi] CDNI Requirements for ABR content >=20 > Hi Kent, >=20 > About the tagging as "High" of Event-Based Logging support, I would = like to understand what it implies > - for the CDN and > - for the client. >=20 > I see the following differences between Event-Based Logging and = "file-based logging": >=20 > - Session: I am not an expert of all adaptive streaming flavors; do = existing clients provide a usable session id to the server? > - other service level information: > # Manifest-uri: could the CDN derive it from the session data? > # Content-id: How could the CDN derive this information: =46rom = the content URL? =46rom the session data? Other? > # Representation: How could the CDN derive this information: =46rom= the content URL? =46rom the session data? >=20 > About the tagging as "Med" of segment based logging, I would also like = to understand the impact on the CDN/client: > - the CDN sees the chunk requests (except the ones served by a = caching-proxy or the browser cache). So I think this logging format is = not more complex than event based logging for the client (it does not = have to send specific information). For the CDN, the support of this = format only requires the additional ability to: > - understand the URL formats to detect the representation = changes > - detect session ends? >=20 > Best regards, >=20 > Gilles >=20 > -----Message d'origine----- > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part = de Kent Leung (kleung) > Envoy=E9 : jeudi 22 mars 2012 17:00 > =C0 : cdni@ietf.org > Objet : [CDNi] CDNI Requirements for ABR content >=20 > Tracking requirements from CDNI Interface drafts. Based on the = discussion for draft-lefaucheur-cdni-logging-delivery, we need some = inputs from the WG on the CDNI Logging requirements. >=20 > Options for logging requirements for ABR content: >=20 > 1) Event-Based Logging shall be supported [HIGH], Segment-Based = Logging should be supported [MED], and Summary-Based Logging may be = supported [LOW]. >=20 > Reason: The dCDN needs to be aware of ABR content and should = log delivery with the ABR-related fields. ABR is expected to be a very = common delivery format and requires some form of log compression over = very voluminous per-segment logging. ABR content needs to be supported = by CDNs. Related requirement is "GEN-14 [HIGH] The CDNI solution shall = support HTTP Adaptive Bit Rate (ABR) content." >=20 > OR >=20 > 2) Event-Based Logging, Segment-Based Logging, and = Summary-Based Logging may be supported [LOW]. >=20 > Reason: Eliminate the need for dCDN to be aware of ABR content. = For example, dCDN is acting in a pure HTTP reverse proxy mode and may = not be aware of that level of information and/or because the control of = how to identify those fields is owned by the CSP and none of CDNs may = have visibility of that mapping information. Such a requirement to force = CDNs and CDNI in general to require such mappings seems to be overkill. >=20 >=20 > Thoughts? >=20 > Kent >=20 >=20 > -----Original Message----- > From: Francois Le Faucheur (flefauch) > Sent: Tuesday, March 13, 2012 11:39 AM > To: Kent Leung (kleung); Niven-Jenkins Ben > Cc: Francois Le Faucheur (flefauch); cdni@ietf.org; Mahesh = Viveganandhan (mvittal) > Subject: Re: [CDNi] Comments on = draft-lefaucheur-cdni-logging-delivery-00 >=20 > Ben, Kent, >=20 > Trying to extract the key points from the thread: >=20 > 1) level of requirement for support of HTTP Adaptive Streaming Logging = Session (ie ABR-aware logs): > This is a valid question. > The I-D proposes that some form of ABR-aware logging be mandatory. The = rationale is that ABR is expected to be a very common delivery format = and requires some form of log compression over very voluminous = per-segment logging. (BTW the I-D currently proposes that both = Segment-Based Logging format and Event-Based Logging format be = mandatory. But come to think of it, having only Event-Based Logging = format mandatory would be sufficient from my viewpoint). > Ben argues that ABR-aware logging should not be mandatory as it = requires extra awareness. > To get more input, I'd propose we move that requirement level = discussion to the cdni-requirements document, and have the logging I-D = only talks about what such logs would look like. > >=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 > This e-mail and its contents are subject to the DISCLAIMER at = http://www.tno.nl/emaildisclaimer >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Mon Mar 26 23:31: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 1519121E8088 for ; Mon, 26 Mar 2012 23:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.245 X-Spam-Level: X-Spam-Status: No, score=-10.245 tagged_above=-999 required=5 tests=[AWL=0.354, 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 xwi-fq86xLPG for ; Mon, 26 Mar 2012 23:31:06 -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 5E10721E8086 for ; Mon, 26 Mar 2012 23:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=9833; q=dns/txt; s=iport; t=1332829865; x=1334039465; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=dzFBZO1yVVGJBMTkwAaPDqpx/nZGDyl4gk2QazIUpa4=; b=i5GAoy6GZRrKZCiA2uqQ36HGfh/b/JEiLrn7EIKeHH92XgA+y+Dt0pF/ Hn/2SgglFEAsEivelw97Lp0wpuXuodO4p0mmN2eWs98uh9m0/VJ2rJuPq YH8oqNPM2PPrivtuSdW+4w23nHhNAUA93ODnvFEPE3YBvboetX8SmlLEB I=; X-IronPort-AV: E=Sophos;i="4.73,655,1325462400"; d="scan'208";a="133433639" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 27 Mar 2012 06:31:04 +0000 Received: from ams-flefauch-8711.cisco.com (ams-flefauch-8711.cisco.com [10.55.161.194]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2R6V34e025877; Tue, 27 Mar 2012 06:31:03 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Francois Le Faucheur In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE24F51253@Polydeuces.office.hd> Date: Tue, 27 Mar 2012 08:31:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120305160316.5234.87849.idtracker@ietfa.amsl.com> <73AF50D3-F8ED-41E7-B7F1-F5F590D31B5B@cisco.com> <2779C9F0771F974CAD742BAE6D9904FE24F4E47D@Polydeuces.office.hd> <2A1DB62E-0EC6-4667-A7F5-386A6FF86AD7@cisco.com> <2779C9F0771F974CAD742BAE6D9904FE24F51253@Polydeuces.office.hd> To: Jan Seedorf X-Mailer: Apple Mail (2.1084) Cc: "cdni@ietf.org" Subject: Re: [CDNi] Few high level comments re draft-spp-cdni-rr-foot-cap-semantics-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, 27 Mar 2012 06:31:07 -0000 On 26 Mar 2012, at 19:32, Jan Seedorf wrote: > Hi Francois, >=20 > Let me answer inline, but I think we are mostly in agreement: I think we have actually converged. See below: >=20 >> I believe the "advertisement" part also needs to convey the cascaded >> information (but flowing in the opposite direction to request = redirection of >> course). >> Let's say we have a cascaded CDN scenario where CDN1 may use CDN2 as = a >> dCDN, and where CDN2 may use CDN3 as a dCDN. >> Then CDN3 would advertise its footprint to CDN2, and CDN2 would = advertise >> to CDN1 a footprint that covers CDN2/s footprint and CDN3's = footprint. This is >> necessary so that CDN1 can select CDN2 for a request that is within = CDN3's >> footprint. > I do not necessarily see why. In your example, if CDN2 implicitly = includes CDN3's footprint in its footprint it advertises to uCDN, = everything should work fine: We are actually saying the same thing ie that the footprint = advertisement that CDN2 exchanges with CDN1 need to comprise the = footprint coverage of CDN2 and of CDN3. I am not saying that the = footprint coverage of CDN3 has to appear as CDN3, it can (and in fact I = believe it should) appear as part of CDN2 footprint. > uCDN is aware that dCDN can serve that footprint, but how exactly is = none of uCDNs business, is it? :) I agree. > Actually, I think therequirements doc says that the dCDN should not = have to disclose internals like surrogate location etc. Why should it be = forced to disclose its own business agreements with other dCDNs as long = as advertises the correct overall information to the uCDN? I agree it shoudl not. >=20 >> So the CDNI footprint advertisement problem comprises: >> * an interface between two CDNs to exchange footprint information >> * a logic to process incoming footprint information form a dCDN and = decide >> if/how it is to be re-advertised/aggregated when advertising = footprint to >> another CDN. >> I recommend you discuss that aspect. > Discussing this aspect in more detail in the draft and documenting the = design choices here is a good recommendation. We will try to make this = aspect more clear in the next version, so that the reader can better = understand what is the issue here (for me, as said below, the issue is = IMPLICIT vs. EXPLICIT advertisement of transitive dCDN relationships). Good. Again, I believe this is important because the solution needs to not = only facilitate exchange of footprint information between 2 neighbor = CDNs, but also facilitate exchange of footprint information among an = arbitrary mesh of CDNs, which brings a complete set of additional = dimensions to the problem (re-advertising, aggregation, filtering, = policy control, loop-prevention,...) and this is an important aspect of = the problem definition and solution assessment. Cheers Francois >=20 >=20 >> Not sure. In my view, the dCDN could in principle express load = not for >> individual caches but for caches in a certain region without = disclosing details >> about its caches. >>=20 >>=20 >>=20 >> Fair enough. Some aggregated information may be reasonable. I suggest = you >> change text which can currently be understood to mean per-cache >> information, into something explaining that aggregate info may be an >> interesting trade-off between not "disclosing too much" and being = helpful >> for CDN selection by uCDN. >>=20 >> In fact, the binary/busy signal already mentioned in REQ-1 can be = seen as a >> very aggregated "excessive load" signal. > Ok, seems we agree here. >=20 >=20 >> Ok, we can add a reference to this current consensus. Still, we = are >> trying to explain the extreme cases of advertisement details, >>=20 >> that's why I would like to have the extreme case example with = direct >> redirection to caches in the dCDN still in the document. >>=20 >>=20 >>=20 >> Personally, I'm more interested in documenting the consensus on what = we >> want to do, than extreme cases we don't really want to do, but I am = fine if >> you want to bring them up as long as you identify them as such (ie = extreme >> cases we can think of but know we don't want to do). > Understood and agree. We can clearly state that current WG consensus = is not to have a direct redirection to dCDN surrogates.=20 >=20 > - Jan >=20 >=20 >=20 >> -----Original Message----- >> From: Francois Le Faucheur [mailto:flefauch@cisco.com] >> Sent: Thursday, March 22, 2012 8:28 PM >> To: Jan Seedorf >> Cc: Francois Le Faucheur; cdni@ietf.org >> Subject: Re: [CDNi] Few high level comments re = draft-spp-cdni-rr-foot-cap- >> semantics-00.txt >>=20 >> Hello Jan, >>=20 >> Looks like we've converged on most points. On the remaining ones: >>=20 >> On 22 Mar 2012, at 14:37, Jan Seedorf wrote: >>=20 >>=20 >>=20 >>=20 >>=20 >> * the requirement related to support of cascaded CDNs = must >> be >>=20 >>=20 >> included as it impacts the overall solution: >>=20 >>=20 >> " REQ-3 [MED] In the case of cascaded redirection, = the=20 >>=20 >> CDNI Request- >>=20 >>=20 >> Routing interface shall allow the Downstream = CDN to >> also >>=20 >> include in the information communicated to the >> Upstream CDN, >>=20 >>=20 >> information on the capabilities, resources and = affinities >> of >>=20 >>=20 >> CDNs to which the Downstream CDN may (in turn) >> redirect >>=20 >>=20 >> requests received by the Upstream CDN. In = that case, >> the >>=20 >>=20 >> CDNI Request-Routing interface shall prevent = looping of >> such >>=20 >>=20 >> information exchange. >>=20 >>=20 >> " >>=20 >>=20 >> Not sure about this one. I read the requirement that the overall = CDNI >> request routing needs to support cascaded CDNs, and that information >> exchanged needs to include cascaded dCDNs. The question at hand is if = the >> "advertisement" part also needs to signal such cascading information >> EXPLICITLY, or if cascading CDNs merely need to be supported by the >> redirection part of the request routing interface, >>=20 >>=20 >> I believe the "advertisement" part also needs to convey the cascaded >> information (but flowing in the opposite direction to request = redirection of >> course). >> Let's say we have a cascaded CDN scenario where CDN1 may use CDN2 as = a >> dCDN, and where CDN2 may use CDN3 as a dCDN. >> Then CDN3 would advertise its footprint to CDN2, and CDN2 would = advertise >> to CDN1 a footprint that covers CDN2/s footprint and CDN3's = footprint. This is >> necessary so that CDN1 can select CDN2 for a request that is within = CDN3's >> footprint. >> So the CDNI footprint advertisement problem comprises: >> * an interface between two CDNs to exchange footprint information >> * a logic to process incoming footprint information form a dCDN and = decide >> if/how it is to be re-advertised/aggregated when advertising = footprint to >> another CDN. >> I recommend you discuss that aspect. >>=20 >>=20 >> i.e. the cascading information is IMPLICITLY included in the >> advertisement information. This is to me the open question, which we = try to >> raise in the draft. But it is probably a good idea to clarify that a = bit more in the >> draft and to cite the requirement above. >>=20 >>=20 >>=20 >>=20 >>=20 >> In line with GEN-4, I believe some of the candidate >> "capabilities" listed in >>=20 >>=20 >> section 5 (ie individual "Cache Capabilities are: o = load, or >> "excessive load", >>=20 >>=20 >> o available resources, storage resources, o failure >> conditions) can be >>=20 >>=20 >> excluded (at least for initial CDNI WG work). >>=20 >>=20 >> Not sure. In my view, the dCDN could in principle express load = not for >> individual caches but for caches in a certain region without = disclosing details >> about its caches. >>=20 >>=20 >>=20 >> Fair enough. Some aggregated information may be reasonable. I suggest = you >> change text which can currently be understood to mean per-cache >> information, into something explaining that aggregate info may be an >> interesting trade-off between not "disclosing too much" and being = helpful >> for CDN selection by uCDN. >>=20 >> In fact, the binary/busy signal already mentioned in REQ-1 can be = seen as a >> very aggregated "excessive load" signal. >>=20 >>=20 >>=20 >> As per the recent email thread, I believe there is consensus = that the >> CDNI >>=20 >>=20 >> footprint & capabilities advertisement interface is all = about >> helping the uCDN >>=20 >>=20 >> select a dCDN, and not about helping the uCDN to select = a >> specific cache in >>=20 >>=20 >> the dCDN (at least for the initial CDNI WG work). While = this is >> already >>=20 >>=20 >> implicitly reflected in the wording of requirements and >> description, I would >>=20 >>=20 >> recommend stating this explicitly to avoid confusion. >>=20 >>=20 >> Ok, we can add a reference to this current consensus. Still, we = are >> trying to explain the extreme cases of advertisement details, >>=20 >> that's why I would like to have the extreme case example with = direct >> redirection to caches in the dCDN still in the document. >>=20 >>=20 >>=20 >> Personally, I'm more interested in documenting the consensus on what = we >> want to do, than extreme cases we don't really want to do, but I am = fine if >> you want to bring them up as long as you identify them as such (ie = extreme >> cases we can think of but know we don't want to do). >>=20 >> Cheers. >>=20 >> Francois >=20 From christian.timmerer@itec.uni-klu.ac.at Mon Mar 26 23:42: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 AD0CE21E808F for ; Mon, 26 Mar 2012 23:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 SIq8xU1vWewK for ; Mon, 26 Mar 2012 23:42:00 -0700 (PDT) Received: from mailsrv.uni-klu.ac.at (mailsrv3.uni-klu.ac.at [143.205.180.48]) by ietfa.amsl.com (Postfix) with ESMTP id 539F121E808D for ; Mon, 26 Mar 2012 23:41:59 -0700 (PDT) Received: from mailsrv.uni-klu.ac.at (localhost [127.0.0.1]) by mailsrv.uni-klu.ac.at (Postfix) with ESMTP id 6EE0BBFF6B; Tue, 27 Mar 2012 08:41:57 +0200 (CEST) Received: from mailsrv.itec.uni-klu.ac.at (mailsrv-itec.uni-klu.ac.at [143.205.176.139]) by mailsrv.uni-klu.ac.at (Postfix) with ESMTP id 41245BFF65; Tue, 27 Mar 2012 08:41:57 +0200 (CEST) Received: from mailsrv.itec.uni-klu.ac.at (localhost [127.0.0.1]) by mailsrv.itec.uni-klu.ac.at (Postfix) with ESMTP id 3C2821380333; Tue, 27 Mar 2012 08:41:58 +0200 (CEST) Received: from nbmac2.itec.uni-klu.ac.at (nbmac2.itec.uni-klu.ac.at [143.205.122.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailsrv.itec.uni-klu.ac.at (Postfix) with ESMTPSA id 16EF7138004C; Tue, 27 Mar 2012 08:41:58 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: "Christian Timmerer (ITEC)" In-Reply-To: Date: Tue, 27 Mar 2012 08:41:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com><7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1DD4@xmb-sjc-235.amer.cisco.com> <8E09C72DBC577D489F13A71228C0B7BF033E0C52@ftrdmel0.rd.francetelecom.fr>, <7A2D6D1F6AC99243A77D32820D8ABBC20E95C703@xmb-sjc-235.amer.cisco.com> To: "Brandenburg, R. (Ray) van" X-Mailer: Apple Mail (2.1257) X-AV-Checked: ClamAV at mailsrv.itec.uni-klu.ac.at X-Virus-Scanned: ClamAV using ClamSMTP Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Requirements for ABR content 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, 27 Mar 2012 06:42:03 -0000 Dear Ray, regarding terminology of segments and fragments, 3GPP- and MPEG-DASH = uses segment and subsegment independent of the container format = (ISOBMFF, M2TS). The former is equivalent to what you're referring to as = segments and the latter is equivalent to the fragments in your draft. = Furthermore, subsegments are indexed by a segment index providing the = time range to byte range mapping.=20 Best regards, -Christian :-- :- Dr. Christian Timmerer :- Ass.-Prof., Multimedia Communication, Alpen-Adria-Universit=E4t = Klagenfurt :- research.timmerer.com | selab.itec.aau.at | dash.itec.aau.at = --------------------------------------------------------------------------= ---------------------------- Q: Why is this email three sentences or less? A: http://three.sentenc.es On Mar 26, 2012, at 5:25 PM, Brandenburg, R. (Ray) van wrote: > Hi Gilles/Kent/all, >=20 > It seems to me that the question we keep getting back to is whether = the CDN is aware of ABR content (and if we want to require a CDN to be = aware of this). This question will probably also come up when discussing = other interfaces (especially metadata and request routing). >=20 > I therefore suggest that we first discuss the high-level = requirements/assumptions regarding ABR/HAS and CDNI, come up with some = guidelines for how the CDNI interfaces should deal with ABR/HAS, and = then apply these guidelines to the various interfaces (such as in this = case the logging interface). >=20 > I wrote a draft for initiating such a discussion, see = http://www.ietf.org/id/draft-brandenburg-cdni-has-00.txt. Comments are = welcome. >=20 > Best regards, >=20 > Ray >=20 >=20 >=20 >=20 >=20 >=20 > ________________________________________ > From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] on behalf of Kent = Leung (kleung) [kleung@cisco.com] > Sent: Monday, March 26, 2012 5:09 PM > To: gilles.bertrand@orange.com; cdni@ietf.org > Subject: Re: [CDNi] CDNI Requirements for ABR content >=20 > Hi Gilles. The client has to be ABR-aware to obtain the ABR content. = So the question is only pertinent for the CDN. The methods for CDN to = associate delivery of contents for the ABR session are based on cookie = or URI tag (BTW, client just passes this info back to the CDN). Also, = CDN needs to understand the manifest file (for HLS/HDS/HSS) to determine = the abr-protocol, representation, manifest-uri, and content-id. >=20 > Both Event-Based Logging and Session-Based Logging require CDN to = understand the ABR content type. So the implications or impact to the = CDN is basically the same for either logging mode. For file-based = logging, the CDN treats each content delivery as a file and unaware that = it is really a segment/chunk/fragment of the whole content. There's no = knowledge that there is a manifest file or different representations or = when representation changed. >=20 > I believe the reason for Event-Based Logging as [HIGH] and = Session-Based Logging as [MED] is the expectation that most of the = content for the ABR session will be delivered at a steady rate after the = initial buffering. >=20 > Does that answer your questions? >=20 > Kent >=20 > -----Original Message----- > From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com] > Sent: Monday, March 26, 2012 1:24 AM > To: Kent Leung (kleung); cdni@ietf.org > Subject: RE: [CDNi] CDNI Requirements for ABR content >=20 > Hi Kent, >=20 > About the tagging as "High" of Event-Based Logging support, I would = like to understand what it implies > - for the CDN and > - for the client. >=20 > I see the following differences between Event-Based Logging and = "file-based logging": >=20 > - Session: I am not an expert of all adaptive streaming flavors; do = existing clients provide a usable session id to the server? > - other service level information: > # Manifest-uri: could the CDN derive it from the session data? > # Content-id: How could the CDN derive this information: =46rom = the content URL? =46rom the session data? Other? > # Representation: How could the CDN derive this information: =46rom= the content URL? =46rom the session data? >=20 > About the tagging as "Med" of segment based logging, I would also like = to understand the impact on the CDN/client: > - the CDN sees the chunk requests (except the ones served by a = caching-proxy or the browser cache). So I think this logging format is = not more complex than event based logging for the client (it does not = have to send specific information). For the CDN, the support of this = format only requires the additional ability to: > - understand the URL formats to detect the representation = changes > - detect session ends? >=20 > Best regards, >=20 > Gilles >=20 > -----Message d'origine----- > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part = de Kent Leung (kleung) > Envoy=E9 : jeudi 22 mars 2012 17:00 > =C0 : cdni@ietf.org > Objet : [CDNi] CDNI Requirements for ABR content >=20 > Tracking requirements from CDNI Interface drafts. Based on the = discussion for draft-lefaucheur-cdni-logging-delivery, we need some = inputs from the WG on the CDNI Logging requirements. >=20 > Options for logging requirements for ABR content: >=20 > 1) Event-Based Logging shall be supported [HIGH], Segment-Based = Logging should be supported [MED], and Summary-Based Logging may be = supported [LOW]. >=20 > Reason: The dCDN needs to be aware of ABR content and should = log delivery with the ABR-related fields. ABR is expected to be a very = common delivery format and requires some form of log compression over = very voluminous per-segment logging. ABR content needs to be supported = by CDNs. Related requirement is "GEN-14 [HIGH] The CDNI solution shall = support HTTP Adaptive Bit Rate (ABR) content." >=20 > OR >=20 > 2) Event-Based Logging, Segment-Based Logging, and = Summary-Based Logging may be supported [LOW]. >=20 > Reason: Eliminate the need for dCDN to be aware of ABR content. = For example, dCDN is acting in a pure HTTP reverse proxy mode and may = not be aware of that level of information and/or because the control of = how to identify those fields is owned by the CSP and none of CDNs may = have visibility of that mapping information. Such a requirement to force = CDNs and CDNI in general to require such mappings seems to be overkill. >=20 >=20 > Thoughts? >=20 > Kent >=20 >=20 > -----Original Message----- > From: Francois Le Faucheur (flefauch) > Sent: Tuesday, March 13, 2012 11:39 AM > To: Kent Leung (kleung); Niven-Jenkins Ben > Cc: Francois Le Faucheur (flefauch); cdni@ietf.org; Mahesh = Viveganandhan (mvittal) > Subject: Re: [CDNi] Comments on = draft-lefaucheur-cdni-logging-delivery-00 >=20 > Ben, Kent, >=20 > Trying to extract the key points from the thread: >=20 > 1) level of requirement for support of HTTP Adaptive Streaming Logging = Session (ie ABR-aware logs): > This is a valid question. > The I-D proposes that some form of ABR-aware logging be mandatory. The = rationale is that ABR is expected to be a very common delivery format = and requires some form of log compression over very voluminous = per-segment logging. (BTW the I-D currently proposes that both = Segment-Based Logging format and Event-Based Logging format be = mandatory. But come to think of it, having only Event-Based Logging = format mandatory would be sufficient from my viewpoint). > Ben argues that ABR-aware logging should not be mandatory as it = requires extra awareness. > To get more input, I'd propose we move that requirement level = discussion to the cdni-requirements document, and have the logging I-D = only talks about what such logs would look like. > >=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 > This e-mail and its contents are subject to the DISCLAIMER at = http://www.tno.nl/emaildisclaimer >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 From ben@niven-jenkins.co.uk Tue Mar 27 03:36: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 9A8D521E8143 for ; Tue, 27 Mar 2012 03:36:21 -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_51=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 t3UTdbwQWd8I for ; Tue, 27 Mar 2012 03:36:20 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 873D921E8101 for ; Tue, 27 Mar 2012 03:36:20 -0700 (PDT) Received: from access-50.80.rev.fr.colt.net ([213.41.80.50] helo=[10.59.90.211]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SCTl5-0005kw-GG; Tue, 27 Mar 2012 11:36:19 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <082CA012-D7F8-4CEC-A08A-2E86F11333B4@jet-stream.com> Date: Tue, 27 Mar 2012 11:36:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <082CA012-D7F8-4CEC-A08A-2E86F11333B4@jet-stream.com> To: Stef van der Ziel X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org Subject: Re: [CDNi] CDNi metadata questions 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, 27 Mar 2012 10:36:21 -0000 Stef, The terminology section of draft-ietf-cdni-problem-statement-04 tries to = provide some clarification. In general I tend to think of CDNI Metadata (as exchanged over the CDNI = Metadata interface) to be configuration data so includes things like: - What/How to contact the origin server for content - How to deliver the content (throttle etc.) - What geo-blocking rules apply to the content - what authorisation (tokens etc.) is required - etc. more inline On 26 Mar 2012, at 20:17, Stef van der Ziel wrote: > Hi all, >=20 > I would like some clarification about CDNi metadata. > It seems like it is being proposed that metadata about content is = distributed alongside with the content in XML format. > However, metadata is such a vague term. What specific metadata is = meant here. I can think of these metadata types: >=20 > 1 - Technical content metadata (such as bit rates, screen width, = codecs, length, size, ingest date, part of logical asset) I think this is largely out of scope for CDNI. It is information the = content provider might have but that information is not typically shared = with CDNs. > 2 - Instructional metadata (such as delete, flush, TTL, prefill, = distribute, lock, geo-block) Things like delete/flush/prefill/etc should be covered by = draft-murray-cdni-triggers-00 TTL of metadata on the CDNI Metadata interface is determine by = Cache-Control headers in the responses. Geo-blocking would be explicit = in the CDNI Metadata exchanged over the CDNI Metadata interface (see = above). > 3 - Status metadata (such as popularity, integrity checksums, = distribution status) IMO this is largely internal to a CDN. upstream CDN could track = popularity using log data sent back from downstream CDNs. > 4 - Enrichment metadata (such as separate subtitles, poster frames) This is relevant to the content provider & client but a CDN doesn;t need = explicit knowledge of this IMO. > 5 - Description content metadata (such as name, contents, keywords, = author) Same as (4). > These types of metadata should be treated in different ways: >=20 > 1 - Technical metadata can be sent via XML files but it is up to the = CDN to pass it through or parse and use it. I would prefer to exchange = this data via REST or SOAP APIs if CDNs need to use the data. Could be XML or could be JSON (how we serialise the metadata onto the = wire is less critical at this stage IMO than making sure we're carrying = the right metadata). Agree on REST based APIs. I'd strongly like to avoid SOAP. > 2 - Instructional metadata should better not be distributed via files. = Instructions should be exchanged via REST or SOAP APIs. See draft-murray-cdni-triggers-00 where we propose a REST interface for = this & an RSS-inspired interface for retrieving status of the triggers. >=20 > 3 - Status metadata should better not be distributed via files. Status = can be exchanged via RSS feeds or REST or SOAP APIs. >=20 > 4 - Enrichment metadata should be treated as regular content, not as = specific metadata. Agreed. > 5 - Description metadata is useful for content management systems but = are less useful for CDNs > Of course a CDN can simply pass it through but then it should be = treated as regular content, not as specific metadata. Agreed. > I would treat logs as separate data, not as metadata. Agreed. HTH Ben >=20 >=20 > Kind regards, >=20 > Stef van der Ziel >=20 > --=20 > Owner Jet Stream BV | StreamZilla > www.jet-stream.com | www.streamzillacdn.com >=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From Jan.Seedorf@neclab.eu Tue Mar 27 04:43: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 711A721E819B for ; Tue, 27 Mar 2012 04:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 ETu9NJ+p4Iyq for ; Tue, 27 Mar 2012 04:43:04 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 90E3421E8192 for ; Tue, 27 Mar 2012 04:43:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id D8A60100A96; Tue, 27 Mar 2012 13:43:36 +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 G4WIFh+nv4US; Tue, 27 Mar 2012 13:43:36 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id BB0F7100A19; Tue, 27 Mar 2012 13:43:26 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.36]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 27 Mar 2012 13:42:52 +0200 From: Jan Seedorf To: Francois Le Faucheur Thread-Topic: [CDNi] Few high level comments re draft-spp-cdni-rr-foot-cap-semantics-00.txt Thread-Index: AQHNCGJhH2he4TBB8U6/kTo1JhHN0pZ82aTQgAC6fYCAAHZ1cA== Date: Tue, 27 Mar 2012 11:42:51 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24F518B3@Polydeuces.office.hd> References: <20120305160316.5234.87849.idtracker@ietfa.amsl.com> <73AF50D3-F8ED-41E7-B7F1-F5F590D31B5B@cisco.com> <2779C9F0771F974CAD742BAE6D9904FE24F4E47D@Polydeuces.office.hd> <2A1DB62E-0EC6-4667-A7F5-386A6FF86AD7@cisco.com> <2779C9F0771F974CAD742BAE6D9904FE24F51253@Polydeuces.office.hd> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Few high level comments re draft-spp-cdni-rr-foot-cap-semantics-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, 27 Mar 2012 11:43:05 -0000 Hi Francois, > I think we have actually converged. I think so, too, good. Thanks for your comments, we will address them in th= e next version of the semantics draft to capture the discussion and to docu= ment key points / WG consensus / design decisions. - Jan > -----Original Message----- > From: Francois Le Faucheur [mailto:flefauch@cisco.com] > Sent: Tuesday, March 27, 2012 8:31 AM > To: Jan Seedorf > Cc: Francois Le Faucheur; cdni@ietf.org > Subject: Re: [CDNi] Few high level comments re draft-spp-cdni-rr-foot-cap= - > semantics-00.txt >=20 >=20 > On 26 Mar 2012, at 19:32, Jan Seedorf wrote: >=20 > > Hi Francois, > > > > Let me answer inline, but I think we are mostly in agreement: >=20 > I think we have actually converged. See below: >=20 > > > >> I believe the "advertisement" part also needs to convey the cascaded > >> information (but flowing in the opposite direction to request redirect= ion > of > >> course). > >> Let's say we have a cascaded CDN scenario where CDN1 may use CDN2 as > a > >> dCDN, and where CDN2 may use CDN3 as a dCDN. > >> Then CDN3 would advertise its footprint to CDN2, and CDN2 would > advertise > >> to CDN1 a footprint that covers CDN2/s footprint and CDN3's footprint. > This is > >> necessary so that CDN1 can select CDN2 for a request that is within > CDN3's > >> footprint. > > I do not necessarily see why. In your example, if CDN2 implicitly inclu= des > CDN3's footprint in its footprint it advertises to uCDN, everything shoul= d > work fine: >=20 > We are actually saying the same thing ie that the footprint advertisement > that CDN2 exchanges with CDN1 need to comprise the footprint coverage of > CDN2 and of CDN3. I am not saying that the footprint coverage of CDN3 has > to appear as CDN3, it can (and in fact I believe it should) appear as par= t of > CDN2 footprint. >=20 >=20 > > uCDN is aware that dCDN can serve that footprint, but how exactly is no= ne > of uCDNs business, is it? :) >=20 > I agree. >=20 > > Actually, I think therequirements doc says that the dCDN should not hav= e > to disclose internals like surrogate location etc. Why should it be force= d to > disclose its own business agreements with other dCDNs as long as advertis= es > the correct overall information to the uCDN? >=20 > I agree it shoudl not. >=20 > > > >> So the CDNI footprint advertisement problem comprises: > >> * an interface between two CDNs to exchange footprint information > >> * a logic to process incoming footprint information form a dCDN and > decide > >> if/how it is to be re-advertised/aggregated when advertising footprint= to > >> another CDN. > >> I recommend you discuss that aspect. > > Discussing this aspect in more detail in the draft and documenting the > design choices here is a good recommendation. We will try to make this > aspect more clear in the next version, so that the reader can better > understand what is the issue here (for me, as said below, the issue is > IMPLICIT vs. EXPLICIT advertisement of transitive dCDN relationships). >=20 > Good. > Again, I believe this is important because the solution needs to not only > facilitate exchange of footprint information between 2 neighbor CDNs, but > also facilitate exchange of footprint information among an arbitrary mesh= of > CDNs, which brings a complete set of additional dimensions to the problem > (re-advertising, aggregation, filtering, policy control, loop-prevention,= ...) and > this is an important aspect of the problem definition and solution > assessment. >=20 > Cheers >=20 > Francois >=20 > > > > > >> Not sure. In my view, the dCDN could in principle express load not fo= r > >> individual caches but for caches in a certain region without disclosin= g > details > >> about its caches. > >> > >> > >> > >> Fair enough. Some aggregated information may be reasonable. I suggest > you > >> change text which can currently be understood to mean per-cache > >> information, into something explaining that aggregate info may be an > >> interesting trade-off between not "disclosing too much" and being help= ful > >> for CDN selection by uCDN. > >> > >> In fact, the binary/busy signal already mentioned in REQ-1 can be seen= as > a > >> very aggregated "excessive load" signal. > > Ok, seems we agree here. > > > > > >> Ok, we can add a reference to this current consensus. Still, we are > >> trying to explain the extreme cases of advertisement details, > >> > >> that's why I would like to have the extreme case example with direct > >> redirection to caches in the dCDN still in the document. > >> > >> > >> > >> Personally, I'm more interested in documenting the consensus on what > we > >> want to do, than extreme cases we don't really want to do, but I am fi= ne if > >> you want to bring them up as long as you identify them as such (ie > extreme > >> cases we can think of but know we don't want to do). > > Understood and agree. We can clearly state that current WG consensus is > not to have a direct redirection to dCDN surrogates. > > > > - Jan > > > > > > > >> -----Original Message----- > >> From: Francois Le Faucheur [mailto:flefauch@cisco.com] > >> Sent: Thursday, March 22, 2012 8:28 PM > >> To: Jan Seedorf > >> Cc: Francois Le Faucheur; cdni@ietf.org > >> Subject: Re: [CDNi] Few high level comments re draft-spp-cdni-rr-foot- > cap- > >> semantics-00.txt > >> > >> Hello Jan, > >> > >> Looks like we've converged on most points. On the remaining ones: > >> > >> On 22 Mar 2012, at 14:37, Jan Seedorf wrote: > >> > >> > >> > >> > >> > >> * the requirement related to support of cascaded CDNs must > >> be > >> > >> > >> included as it impacts the overall solution: > >> > >> > >> " REQ-3 [MED] In the case of cascaded redirection, the > >> > >> CDNI Request- > >> > >> > >> Routing interface shall allow the Downstream CDN to > >> also > >> > >> include in the information communicated to the > >> Upstream CDN, > >> > >> > >> information on the capabilities, resources and affinities > >> of > >> > >> > >> CDNs to which the Downstream CDN may (in turn) > >> redirect > >> > >> > >> requests received by the Upstream CDN. In that case, > >> the > >> > >> > >> CDNI Request-Routing interface shall prevent looping of > >> such > >> > >> > >> information exchange. > >> > >> > >> " > >> > >> > >> Not sure about this one. I read the requirement that the overall CDNI > >> request routing needs to support cascaded CDNs, and that information > >> exchanged needs to include cascaded dCDNs. The question at hand is if > the > >> "advertisement" part also needs to signal such cascading information > >> EXPLICITLY, or if cascading CDNs merely need to be supported by the > >> redirection part of the request routing interface, > >> > >> > >> I believe the "advertisement" part also needs to convey the cascaded > >> information (but flowing in the opposite direction to request redirect= ion > of > >> course). > >> Let's say we have a cascaded CDN scenario where CDN1 may use CDN2 as > a > >> dCDN, and where CDN2 may use CDN3 as a dCDN. > >> Then CDN3 would advertise its footprint to CDN2, and CDN2 would > advertise > >> to CDN1 a footprint that covers CDN2/s footprint and CDN3's footprint. > This is > >> necessary so that CDN1 can select CDN2 for a request that is within > CDN3's > >> footprint. > >> So the CDNI footprint advertisement problem comprises: > >> * an interface between two CDNs to exchange footprint information > >> * a logic to process incoming footprint information form a dCDN and > decide > >> if/how it is to be re-advertised/aggregated when advertising footprint= to > >> another CDN. > >> I recommend you discuss that aspect. > >> > >> > >> i.e. the cascading information is IMPLICITLY included in the > >> advertisement information. This is to me the open question, which we t= ry > to > >> raise in the draft. But it is probably a good idea to clarify that a b= it more in > the > >> draft and to cite the requirement above. > >> > >> > >> > >> > >> > >> In line with GEN-4, I believe some of the candidate > >> "capabilities" listed in > >> > >> > >> section 5 (ie individual "Cache Capabilities are: o load, or > >> "excessive load", > >> > >> > >> o available resources, storage resources, o failure > >> conditions) can be > >> > >> > >> excluded (at least for initial CDNI WG work). > >> > >> > >> Not sure. In my view, the dCDN could in principle express load not fo= r > >> individual caches but for caches in a certain region without disclosin= g > details > >> about its caches. > >> > >> > >> > >> Fair enough. Some aggregated information may be reasonable. I suggest > you > >> change text which can currently be understood to mean per-cache > >> information, into something explaining that aggregate info may be an > >> interesting trade-off between not "disclosing too much" and being help= ful > >> for CDN selection by uCDN. > >> > >> In fact, the binary/busy signal already mentioned in REQ-1 can be seen= as > a > >> very aggregated "excessive load" signal. > >> > >> > >> > >> As per the recent email thread, I believe there is consensus that the > >> CDNI > >> > >> > >> footprint & capabilities advertisement interface is all about > >> helping the uCDN > >> > >> > >> select a dCDN, and not about helping the uCDN to select a > >> specific cache in > >> > >> > >> the dCDN (at least for the initial CDNI WG work). While this is > >> already > >> > >> > >> implicitly reflected in the wording of requirements and > >> description, I would > >> > >> > >> recommend stating this explicitly to avoid confusion. > >> > >> > >> Ok, we can add a reference to this current consensus. Still, we are > >> trying to explain the extreme cases of advertisement details, > >> > >> that's why I would like to have the extreme case example with direct > >> redirection to caches in the dCDN still in the document. > >> > >> > >> > >> Personally, I'm more interested in documenting the consensus on what > we > >> want to do, than extreme cases we don't really want to do, but I am fi= ne if > >> you want to bring them up as long as you identify them as such (ie > extreme > >> cases we can think of but know we don't want to do). > >> > >> Cheers. > >> > >> Francois > > From richard_woundy@cable.comcast.com Tue Mar 27 06:58: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 A77D721E81AB for ; Tue, 27 Mar 2012 06:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.069 X-Spam-Level: X-Spam-Status: No, score=-102.069 tagged_above=-999 required=5 tests=[AWL=-0.839, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 bH5gy2btespe for ; Tue, 27 Mar 2012 06:58:36 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 01BC921E818A for ; Tue, 27 Mar 2012 06:58:35 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.11034120; Tue, 27 Mar 2012 07:46:20 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.01.0355.002; Tue, 27 Mar 2012 09:58:34 -0400 From: "Woundy, Richard" To: "cdni@ietf.org" Thread-Topic: WebEx sessions for CDNI Thread-Index: AQHNDCGyc9pja6XnIEC6ProMklHiuw== Date: Tue, 27 Mar 2012 13:58:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.72] Content-Type: multipart/alternative; boundary="_000_CB97942637F5RichardWoundycablecomcastcom_" MIME-Version: 1.0 Subject: [CDNi] WebEx sessions for CDNI X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 13:58:36 -0000 --_000_CB97942637F5RichardWoundycablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, We have scheduled two WebEx sessions for remote participants of the CDNI WG= discussions on Thursday and Friday. I have copied the information below fr= om which i= s the authoritative source of WebEx session information for the IETF meetin= g. Thursday, March 29, 2012 Session Time Room WebEx Link Meeting Number Audio Channel cdni 1300-1500 252B Join WebEx Session = 644 055 899 6 Friday, March 30, 2012 Session Time Room WebEx Link Meeting Number Audio Channel cdni 0900-1100 242AB Join WebEx Session = 642 221 593 3 -- Rich --_000_CB97942637F5RichardWoundycablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Folks,

We have scheduled two WebEx sessions for remote participants of the CD= NI WG discussions on Thursday and Friday. I have copied the information bel= ow from <http://www.ietf.org/meeting/83/remote-participation.html#webex<= /a>> which is the authoritative source of WebEx session information for the IET= F meeting.

Thursday, March 29, 2012

Session Time Room WebEx Link Meeting Number Audio Channel
cdni 1300-1500 252B Join WebEx S= ession 644 055 899 6

Friday, March 30, 2012

Session Time Room WebEx Link Meeting Number Audio Channel
cdni 0900-1100 242AB Join WebEx Session 642 221 593 3<= /td>

-- Rich
--_000_CB97942637F5RichardWoundycablecomcastcom_-- From kevin.ma@azukisystems.com Tue Mar 27 17:08: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 478BB21E803D for ; Tue, 27 Mar 2012 17:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.768 X-Spam-Level: X-Spam-Status: No, score=-0.768 tagged_above=-999 required=5 tests=[AWL=1.831, 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 fGV7N+2TM3Hq for ; Tue, 27 Mar 2012 17:08:35 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 7F55C21E8025 for ; Tue, 27 Mar 2012 17:08:29 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id B160283F3A7; Tue, 27 Mar 2012 20:08:28 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB023.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 2710383F1BA; Tue, 27 Mar 2012 20:08:28 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Tue, 27 Mar 2012 20:08:27 -0400 From: Kevin J Ma To: Ben Niven-Jenkins , Francois Le Faucheur Date: Tue, 27 Mar 2012 20:08:25 -0400 Thread-Topic: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 Thread-Index: Ac0IoWw21p0KZnNnTeqrKMvb9ECZoAD0bTTQ Message-ID: <291CC3F9E50E7641901A54E85D0977C652608722A6@MAILR002.mail.lan> References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> <9871DFEE-4302-4B34-967D-91B333DF1011@niven-jenkins.co.uk> In-Reply-To: <9871DFEE-4302-4B34-967D-91B333DF1011@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: "cdni@ietf.org" , Viveganandhan Mahesh Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-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, 28 Mar 2012 00:08:37 -0000 Hi All, I had a similar concern to Ben. The loss of information in the Event-bas= ed logging seems undesirable from a content owner perspective. It would see= m that adding additional segment-based logging fields would be an easier fi= rst step. Given a piece of metadata that says the content in directory X is = ABR, then the additional fields could be added. Implementing the event criter= ia seems more cumbersome than that. It is also not clear to me what happens when the session gets delegated between different CDNs? The events seem = to be local-CDN specific? thanx. -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Ben Niven-Jenkins > Sent: Thursday, March 22, 2012 11:03 PM > To: Francois Le Faucheur > Cc: cdni@ietf.org; Viveganandhan Mahesh > Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 >=20 > Francois, >=20 > On 13 Mar 2012, at 18:39, Francois Le Faucheur wrote: >=20 > > Ben, Kent, > > > > Trying to extract the key points from the thread: > > > > 1) level of requirement for support of HTTP Adaptive Streaming Logging > Session (ie ABR-aware logs): > > This is a valid question. > > The I-D proposes that some form of ABR-aware logging be mandatory. The > rationale is that ABR is expected to be a very common delivery format and > requires some form of log compression over very voluminous per-segment > logging. >=20 > I agree that ABR produces large volumes of log entries when the dCDN > creates a log entry per HTTP delivery (HTTP response). >=20 > I agree that compressing those logs in some way before distributing to > uCDNs would be more efficient that not doing so provided the compression > does not result in the loss of information. >=20 > > (BTW the I-D currently proposes that both Segment-Based Logging format > and Event-Based Logging format be mandatory. But come to think of it, > having only Event-Based Logging format mandatory would be sufficient from > my viewpoint). >=20 > Some of the confusion from my side might be that I'm not entirely certain > what you are proposing the logging behaviour of the dCDN should be, i.e. > are you arguing that in the case where the dCDN is "ABR aware": >=20 > 1) We log every single HTTP delivery (HTTP response) individually (let's > ignore whether the format is just "plain" HTTP log fields or "plain" HTTP > log field plus your proposed Segment-Based log fields) and we produce > Event-Based Logs >=20 > 2) We just produce Event-Based Logs >=20 > > 4) summarization of Logging info for Adaptive Streaming delivery > > I believe some form of summarization is required. The Event-Based > Logging seems like a nice sweet-spot because it achieves a high > summarization gain without losing any info (ie any change in > bandwidth/quality is logged). >=20 > Except that if all the dCDN produces for ABR content is an Event-Based > Log, the proposed Event-Based Log does lose information compared to a > "plain" HTTP delivery log. For example the proposed Event-Based Log does > not contain all the URLs that were requested by the client, or the timing= s > of the individual requests/responses, or the sizes of the individual > responses or the cache disposition/Action (TCP_HIT, TCP_MISS, etc.) of th= e > individual responses. >=20 > Furthermore, the draft as written does say that, for example an Event- > Based Log entry contains a Cache Disposition/Action field but the > semantics of that field are not clear, i.e. a single event potentially > consists of a >1 HTTP delivery (HTTP response) and in the case where some > of those deliveries/responses were hits and others were misses what is th= e > correct value to log? The semantics of several other fields in the Event- > Based Log are also unclear. >=20 > > Ben, it'd be interesting to provide a brief write-up on the > summarization approach you mention so we can evaluate it (an email to the > list woudl be just fine). >=20 > I will post something to the mailing list when I get a chance. >=20 > Ben > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From kevin.ma@azukisystems.com Tue Mar 27 17:28: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 E104921E8032 for ; Tue, 27 Mar 2012 17:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[AWL=0.915, 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 fKdYG58Kc+vp for ; Tue, 27 Mar 2012 17:28:10 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id DB96221E8025 for ; Tue, 27 Mar 2012 17:28:09 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 8099A417147; Tue, 27 Mar 2012 20:28:09 -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 0178A417437; Tue, 27 Mar 2012 20:08:18 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Tue, 27 Mar 2012 20:08:14 -0400 From: Kevin J Ma To: Rob Murray , "Kent Leung (kleung)" , "cdni@ietf.org" Date: Tue, 27 Mar 2012 20:08:15 -0400 Thread-Topic: [CDNi] CDNI Triggers interface Thread-Index: AQHM9ylJjw/I9226gUqTKwJkpHCC05Z2wCQAgARJ3wCAA+KmoA== Message-ID: <291CC3F9E50E7641901A54E85D0977C652608722A5@MAILR002.mail.lan> References: <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1F16@xmb-sjc-235.amer.cisco.com> 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 Subject: Re: [CDNi] CDNI Triggers interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 00:28:11 -0000 Hi Rob, I think the doc does a good job of clearly defining the space. I had a couple of questions: - Section 4.4 mentions returning 404/410 on subsequent requests for a resource after deletion. I assume this also applies to section 4.3 and explicit deletion? Might be worth clarifying in section 4.3? - Along the lines of Matt and Kent's questions about request ordering, I was wondering about repeat requests. The current set of triggers are fairly idemopotent, so perhaps it would only be an optimization for them, but are there concerns for duplicate requests or requests with overlapping urls/patterns wrt any pending or active triggers? - For trigger creation, would it make sense to have a priority field, to allow uCDNs to influence the order in which dCDNs process triggers? thanx. -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Rob Murray > Sent: Sunday, March 25, 2012 7:43 AM > To: Kent Leung (kleung); cdni@ietf.org > Subject: Re: [CDNi] CDNI Triggers interface >=20 > Thanks Kent - replies inline ... >=20 > On 22/03/2012 18:11, "Kent Leung (kleung)" wrote: >=20 > >Hi Rob. Nice write-up. Here are some comments on the draft. > > > >1. Sect. 2: Nit for "The trigger may request action on either metadata > >or on content". Reword to "The trigger may request action on either > >metadata or content"? >=20 > Will do. >=20 > >2. Sect. 2: Any thoughts on the scalability aspect of using RESTful web > >service assuming there will be many dCDNs providing delivery service for > >a uCDN? These triggers will likely apply on all the dCDNs. >=20 > Since uCDN has the contract with the Content Owner (or with another uCDN > that does), it has ultimate responsibility for ensuring that triggers are > acted upon - I think it will need to track which dCDNs have its data and > which have completed its triggers, for auditing purposes if nothing else? > Because it's got that responsibility, uCDN will want a way to interrogate > dCDN for status of triggers so, correspondingly, dCDN will need to track > and report state of triggers. >=20 > So, I'd say per-trigger, per-interconnect state will exist at both ends > of the interface whether it's RESTful or not. Does that answer the > concern? I can add some descriptive text to the draft along those lines i= f > it does. >=20 > Do you have a feel for the numbers of interconnects a given CDN is likely > to have? I can't find an indication in the problem-statement or > requirements - but I'd imagine each CDN will have a relatively small > number > of interconnect agreements, perhaps up to low tens? Generally I'd think > CDNs will have many fewer interconnects than Delivery Surrogates, but an > exception might be a "broker" CDN that owns content but doesn't do the > actual delivery itself. In that case, I'd guess we're not talking about > thousands of interconnects but perhaps it might get into hundreds? I > don't have any actual facts or data to cloud my thinking though (!), so > I'd be interested to hear other views. >=20 > >3. Sect. 4: Typo in "For example, is anticipated that decisions on use > >of HTTPS for other CDNI interfaces will be adopted for Triggers." >=20 > Will fix. >=20 > >4. Sect. 4.1: The Trigger Request must be processed in the sequence as > >triggered by the uCDN? Is there a message sequencing method defined? For > >example, uCDN wants to purge a specific content, then preposition that > >content. What happens when the message arrives at dCDN out of order? >=20 > Good point, thanks, I've not covered that. >=20 > If we define the invalidate/purge triggers to mean "invalidate or purge > data obtained before this trigger was created" (before "ctime" of the > Trigger Status Resource), I think that solves the problem. For example, a > use-case for "invalidate" followed by "preposition" would be an emergency > fix to some metadata or content - with this change, by issuing triggers i= n > order after the data is repaired, uCDN can be sure incorrect data is > deleted. But, data acquired from the same location after the repair > (either as a result of pre-positioning or normal operation) will not need > to be re-fetched. The invalidate/purge and the preposition triggers can > run concurrently. >=20 > I makes the semantics of invalidate/purge cleaner anyway. If (repaired) > data can still obtained from affected URL, it'd be hard for uCDN to > guarantee that when a purge completes no data from affected URLs exists > in dCDN. Much easier for it to say that data acquired before a given > time has been invalidated/purged from the network. >=20 > >5. Sect. 4.2: Nit for ".. to cheaply check for change .." Maybe " .. to > >inherently check for change .."? >=20 > How about "... to check for change in status of a resource or collection > of resources without re-fetching the whole resource or collection." >=20 > > > >6. Sect 4.2: Reword " to indicate the frequency it would like uCDN to > >poll at." to " to indicate the frequency of polling by the uCDN"? >=20 > How about "The dCDN should use the cache control headers for responses to > GETs for Trigger Status Resources and Collections to indicate the > frequency at which it recommends uCDN should poll for change." >=20 > >Kent > > > >-----Original Message----- > >From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > >Rob Murray > >Sent: Wednesday, February 29, 2012 1:25 PM > >To: cdni@ietf.org > >Subject: [CDNi] CDNI Triggers interface > > > >Hi all, > > > >I've just uploaded a new draft that proposes a CDNI Triggers interface > >... > > > > http://datatracker.ietf.org/doc/draft-murray-cdni-triggers/ > > > > > >There was some discussion at the last WG meeting about whether triggers > >fit best as part of the control or metadata interface - the suggestion > >was > >that concrete proposals for the interface might help us spot commonality > >with one or the other, so let's see! > > > >Please take a look, your comments are welcome. > > > >Best regards, > >Rob. > > > > > >On 29/02/2012 19:37, "internet-drafts@ietf.org" > > > >wrote: > > > >>A new version of I-D, draft-murray-cdni-triggers-00.txt has been > >>successfully submitted by Rob Murray and posted to the IETF repository. > >> > >>Filename: draft-murray-cdni-triggers > >>Revision: 00 > >>Title: CDN Interconnect Triggers > >>Creation date: 2012-02-29 > >>WG ID: Individual Submission > >>Number of pages: 33 > >> > >>Abstract: > >> This document proposes a mechanism for a CDN to trigger activity in > >> an interconnected CDN that is configured to deliver content on its > >> behalf. The upstream CDN can use this mechanism to request that the > >> downstream CDN pre-positions metadata or content, or that it re- > >> validate or purge metadata or content. The upstream CDN can monitor > >> the status of activity that it has triggered in the downstream CDN. > >> > >> > >> > >> > >> > >> > >>The IETF Secretariat > > > >_______________________________________________ > >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 Tue Mar 27 17:28: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 D8E0321E80B2 for ; Tue, 27 Mar 2012 17:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[AWL=0.610, 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 PDv6U9CD9zCV for ; Tue, 27 Mar 2012 17:28:18 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id B42F721E809C for ; Tue, 27 Mar 2012 17:28:17 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 660124170B7; Tue, 27 Mar 2012 20:28:17 -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 F1C634177DD; Tue, 27 Mar 2012 20:08:48 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Tue, 27 Mar 2012 20:08:45 -0400 From: Kevin J Ma To: "Kent Leung (kleung)" , "gilles.bertrand@orange.com" , "cdni@ietf.org" Date: Tue, 27 Mar 2012 20:08:47 -0400 Thread-Topic: [CDNi] CDNI Requirements for ABR content Thread-Index: Ac0BSJhyMA6ZY4c+Q3uSDuyuYRmJ/QG+E8PgALkWbsAADdK2MABFw/Mg Message-ID: <291CC3F9E50E7641901A54E85D0977C652608722A7@MAILR002.mail.lan> References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com><7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1DD4@xmb-sjc-235.amer.cisco.com> <8E09C72DBC577D489F13A71228C0B7BF033E0C52@ftrdmel0.rd.francetelecom.fr> <7A2D6D1F6AC99243A77D32820D8ABBC20E95C703@xmb-sjc-235.amer.cisco.com> In-Reply-To: <7A2D6D1F6AC99243A77D32820D8ABBC20E95C703@xmb-sjc-235.amer.cisco.com> 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 Subject: Re: [CDNi] CDNI Requirements for ABR content 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, 28 Mar 2012 00:28:19 -0000 Hi Kent, It was not clear to me why the priority of segment-based logging is not higher than, or at least equal to that of event-based. Segment-based seems easier than event-based. Though event-based has the arguable benefit of log reduction, you would already get segment-based for free? I would think that ABR awareness for segment-based logging could be=20 implemented simply with metadata. Event and summary-based logging would require much more ABR awareness. I might vote for option 3: 3) Event-Based Logging shall be supported [LOW], Segment-Based Logging should be supported [MED], and Summary-Based Logging may be supported [LOW]. thanx. -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Kent Leung (kleung) > Sent: Monday, March 26, 2012 11:09 AM > To: gilles.bertrand@orange.com; cdni@ietf.org > Subject: Re: [CDNi] CDNI Requirements for ABR content >=20 > Hi Gilles. The client has to be ABR-aware to obtain the ABR content. So > the question is only pertinent for the CDN. The methods for CDN to > associate delivery of contents for the ABR session are based on cookie or > URI tag (BTW, client just passes this info back to the CDN). Also, CDN > needs to understand the manifest file (for HLS/HDS/HSS) to determine the > abr-protocol, representation, manifest-uri, and content-id. >=20 > Both Event-Based Logging and Session-Based Logging require CDN to > understand the ABR content type. So the implications or impact to the CDN > is basically the same for either logging mode. For file-based logging, th= e > CDN treats each content delivery as a file and unaware that it is really = a > segment/chunk/fragment of the whole content. There's no knowledge that > there is a manifest file or different representations or when > representation changed. >=20 > I believe the reason for Event-Based Logging as [HIGH] and Session-Based > Logging as [MED] is the expectation that most of the content for the ABR > session will be delivered at a steady rate after the initial buffering. >=20 > Does that answer your questions? >=20 > Kent >=20 > -----Original Message----- > From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com] > Sent: Monday, March 26, 2012 1:24 AM > To: Kent Leung (kleung); cdni@ietf.org > Subject: RE: [CDNi] CDNI Requirements for ABR content >=20 > Hi Kent, >=20 > About the tagging as "High" of Event-Based Logging support, I would like > to understand what it implies > - for the CDN and > - for the client. >=20 > I see the following differences between Event-Based Logging and "file- > based logging": >=20 > - Session: I am not an expert of all adaptive streaming flavors; do > existing clients provide a usable session id to the server? > - other service level information: > # Manifest-uri: could the CDN derive it from the session data? > # Content-id: How could the CDN derive this information: From the > content URL? From the session data? Other? > # Representation: How could the CDN derive this information: From > the content URL? From the session data? >=20 > About the tagging as "Med" of segment based logging, I would also like to > understand the impact on the CDN/client: > - the CDN sees the chunk requests (except the ones served by a caching- > proxy or the browser cache). So I think this logging format is not more > complex than event based logging for the client (it does not have to send > specific information). For the CDN, the support of this format only > requires the additional ability to: > - understand the URL formats to detect the representation changes > - detect session ends? >=20 > Best regards, >=20 > Gilles >=20 > -----Message d'origine----- > De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de > Kent Leung (kleung) > Envoy=E9=A0: jeudi 22 mars 2012 17:00 > =C0=A0: cdni@ietf.org > Objet=A0: [CDNi] CDNI Requirements for ABR content >=20 > Tracking requirements from CDNI Interface drafts. Based on the discussion > for draft-lefaucheur-cdni-logging-delivery, we need some inputs from the > WG on the CDNI Logging requirements. >=20 > Options for logging requirements for ABR content: >=20 > 1) Event-Based Logging shall be supported [HIGH], Segment-Based > Logging should be supported [MED], and Summary-Based Logging may be > supported [LOW]. >=20 > Reason: The dCDN needs to be aware of ABR content and should log > delivery with the ABR-related fields. ABR is expected to be a very common > delivery format and requires some form of log compression over very > voluminous per-segment logging. ABR content needs to be supported by CDNs= . > Related requirement is "GEN-14 [HIGH] The CDNI solution shall support > HTTP Adaptive Bit Rate (ABR) content." >=20 > OR >=20 > 2) Event-Based Logging, Segment-Based Logging, and Summary-Based > Logging may be supported [LOW]. >=20 > Reason: Eliminate the need for dCDN to be aware of ABR content. For > example, dCDN is acting in a pure HTTP reverse proxy mode and may not be > aware of that level of information and/or because the control of how to > identify those fields is owned by the CSP and none of CDNs may have > visibility of that mapping information. Such a requirement to force CDNs > and CDNI in general to require such mappings seems to be overkill. >=20 >=20 > Thoughts? >=20 > Kent >=20 >=20 > -----Original Message----- > From: Francois Le Faucheur (flefauch) > Sent: Tuesday, March 13, 2012 11:39 AM > To: Kent Leung (kleung); Niven-Jenkins Ben > Cc: Francois Le Faucheur (flefauch); cdni@ietf.org; Mahesh Viveganandhan > (mvittal) > Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 >=20 > Ben, Kent, >=20 > Trying to extract the key points from the thread: >=20 > 1) level of requirement for support of HTTP Adaptive Streaming Logging > Session (ie ABR-aware logs): > This is a valid question. > The I-D proposes that some form of ABR-aware logging be mandatory. The > rationale is that ABR is expected to be a very common delivery format and > requires some form of log compression over very voluminous per-segment > logging. (BTW the I-D currently proposes that both Segment-Based Logging > format and Event-Based Logging format be mandatory. But come to think of > it, having only Event-Based Logging format mandatory would be sufficient > from my viewpoint). > Ben argues that ABR-aware logging should not be mandatory as it requires > extra awareness. > To get more input, I'd propose we move that requirement level discussion > to the cdni-requirements document, and have the logging I-D only talks > about what such logs would look like. > >=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 kevin.ma@azukisystems.com Tue Mar 27 17:34: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 C910421E8047 for ; Tue, 27 Mar 2012 17:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.458, 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 JNZIVIwI8SoR for ; Tue, 27 Mar 2012 17:34:23 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id E064C21E8041 for ; Tue, 27 Mar 2012 17:34:22 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id CDD6641705F; Tue, 27 Mar 2012 20:28:24 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB023.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 0108A417416; Tue, 27 Mar 2012 20:09:15 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Tue, 27 Mar 2012 20:09:14 -0400 From: Kevin J Ma To: "Brandenburg, R. (Ray) van" , "Kent Leung (kleung)" , "gilles.bertrand@orange.com" , "cdni@ietf.org" Date: Tue, 27 Mar 2012 20:09:12 -0400 Thread-Topic: [CDNi] CDNI Requirements for ABR content Thread-Index: AQHNCETi17ClXLSrq0e902XpETmVi5Z8IWcAgABxUYCAACPkYIACFmJw Message-ID: <291CC3F9E50E7641901A54E85D0977C652608722A8@MAILR002.mail.lan> References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com><7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1DD4@xmb-sjc-235.amer.cisco.com> <8E09C72DBC577D489F13A71228C0B7BF033E0C52@ftrdmel0.rd.francetelecom.fr>, <7A2D6D1F6AC99243A77D32820D8ABBC20E95C703@xmb-sjc-235.amer.cisco.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] CDNI Requirements for ABR content 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, 28 Mar 2012 00:34:24 -0000 Hi Ray, I think the draft provides a nice description of the options. I had a couple of comments: - The chunk request routing case (section 2.2.3) seems like a degenerate case of full locator. It is a full URL that points to the CDN RR. The result is an HTTP redirect to either a surrogate or a dCDN RR? Though the format of the URL may be protocol specific, it should not be CDN specific, and so it does not have to be treated any differenly from any other full locator. Note: skipping ahead to the questions in section 3.2.1, I do not think that manifest files should be modified. At least in the current phase, I believe content adaptation is off the table? Wrt to the conclusion that full/relative locators require manifest file rewrite (in section 3.2.1), I do not see this as the case. In the worst case, it just means that delegation is not persistent, though that is dependent upon how the client handles redirects... - One of the reasons behind the metadata grouping requirements was to support Chunk Collections and Content Collections. Wrt the questions in section 3.2.1, I think that collections make sense, and that the propogation of metadata could synchronize definitions of collections across CDNs? thanx. -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Brandenburg, R. (Ray) van > Sent: Monday, March 26, 2012 11:26 AM > To: Kent Leung (kleung); gilles.bertrand@orange.com; cdni@ietf.org > Subject: Re: [CDNi] CDNI Requirements for ABR content >=20 > Hi Gilles/Kent/all, >=20 > It seems to me that the question we keep getting back to is whether the > CDN is aware of ABR content (and if we want to require a CDN to be aware > of this). This question will probably also come up when discussing other > interfaces (especially metadata and request routing). >=20 > I therefore suggest that we first discuss the high-level > requirements/assumptions regarding ABR/HAS and CDNI, come up with some > guidelines for how the CDNI interfaces should deal with ABR/HAS, and then > apply these guidelines to the various interfaces (such as in this case th= e > logging interface). >=20 > I wrote a draft for initiating such a discussion, see > http://www.ietf.org/id/draft-brandenburg-cdni-has-00.txt. Comments are > welcome. >=20 > Best regards, >=20 > Ray >=20 >=20 >=20 >=20 >=20 >=20 > ________________________________________ > From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] on behalf of Kent > Leung (kleung) [kleung@cisco.com] > Sent: Monday, March 26, 2012 5:09 PM > To: gilles.bertrand@orange.com; cdni@ietf.org > Subject: Re: [CDNi] CDNI Requirements for ABR content >=20 > Hi Gilles. The client has to be ABR-aware to obtain the ABR content. So > the question is only pertinent for the CDN. The methods for CDN to > associate delivery of contents for the ABR session are based on cookie or > URI tag (BTW, client just passes this info back to the CDN). Also, CDN > needs to understand the manifest file (for HLS/HDS/HSS) to determine the > abr-protocol, representation, manifest-uri, and content-id. >=20 > Both Event-Based Logging and Session-Based Logging require CDN to > understand the ABR content type. So the implications or impact to the CDN > is basically the same for either logging mode. For file-based logging, th= e > CDN treats each content delivery as a file and unaware that it is really = a > segment/chunk/fragment of the whole content. There's no knowledge that > there is a manifest file or different representations or when > representation changed. >=20 > I believe the reason for Event-Based Logging as [HIGH] and Session-Based > Logging as [MED] is the expectation that most of the content for the ABR > session will be delivered at a steady rate after the initial buffering. >=20 > Does that answer your questions? >=20 > Kent >=20 > -----Original Message----- > From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com] > Sent: Monday, March 26, 2012 1:24 AM > To: Kent Leung (kleung); cdni@ietf.org > Subject: RE: [CDNi] CDNI Requirements for ABR content >=20 > Hi Kent, >=20 > About the tagging as "High" of Event-Based Logging support, I would like > to understand what it implies > - for the CDN and > - for the client. >=20 > I see the following differences between Event-Based Logging and "file- > based logging": >=20 > - Session: I am not an expert of all adaptive streaming flavors; do > existing clients provide a usable session id to the server? > - other service level information: > # Manifest-uri: could the CDN derive it from the session data? > # Content-id: How could the CDN derive this information: From the > content URL? From the session data? Other? > # Representation: How could the CDN derive this information: From > the content URL? From the session data? >=20 > About the tagging as "Med" of segment based logging, I would also like to > understand the impact on the CDN/client: > - the CDN sees the chunk requests (except the ones served by a caching- > proxy or the browser cache). So I think this logging format is not more > complex than event based logging for the client (it does not have to send > specific information). For the CDN, the support of this format only > requires the additional ability to: > - understand the URL formats to detect the representation changes > - detect session ends? >=20 > Best regards, >=20 > Gilles >=20 > -----Message d'origine----- > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de > Kent Leung (kleung) > Envoy=E9 : jeudi 22 mars 2012 17:00 > =C0 : cdni@ietf.org > Objet : [CDNi] CDNI Requirements for ABR content >=20 > Tracking requirements from CDNI Interface drafts. Based on the discussion > for draft-lefaucheur-cdni-logging-delivery, we need some inputs from the > WG on the CDNI Logging requirements. >=20 > Options for logging requirements for ABR content: >=20 > 1) Event-Based Logging shall be supported [HIGH], Segment-Based > Logging should be supported [MED], and Summary-Based Logging may be > supported [LOW]. >=20 > Reason: The dCDN needs to be aware of ABR content and should log > delivery with the ABR-related fields. ABR is expected to be a very common > delivery format and requires some form of log compression over very > voluminous per-segment logging. ABR content needs to be supported by CDNs= . > Related requirement is "GEN-14 [HIGH] The CDNI solution shall support > HTTP Adaptive Bit Rate (ABR) content." >=20 > OR >=20 > 2) Event-Based Logging, Segment-Based Logging, and Summary-Based > Logging may be supported [LOW]. >=20 > Reason: Eliminate the need for dCDN to be aware of ABR content. > For example, dCDN is acting in a pure HTTP reverse proxy mode and may not > be aware of that level of information and/or because the control of how t= o > identify those fields is owned by the CSP and none of CDNs may have > visibility of that mapping information. Such a requirement to force CDNs > and CDNI in general to require such mappings seems to be overkill. >=20 >=20 > Thoughts? >=20 > Kent >=20 >=20 > -----Original Message----- > From: Francois Le Faucheur (flefauch) > Sent: Tuesday, March 13, 2012 11:39 AM > To: Kent Leung (kleung); Niven-Jenkins Ben > Cc: Francois Le Faucheur (flefauch); cdni@ietf.org; Mahesh Viveganandhan > (mvittal) > Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 >=20 > Ben, Kent, >=20 > Trying to extract the key points from the thread: >=20 > 1) level of requirement for support of HTTP Adaptive Streaming Logging > Session (ie ABR-aware logs): > This is a valid question. > The I-D proposes that some form of ABR-aware logging be mandatory. The > rationale is that ABR is expected to be a very common delivery format and > requires some form of log compression over very voluminous per-segment > logging. (BTW the I-D currently proposes that both Segment-Based Logging > format and Event-Based Logging format be mandatory. But come to think of > it, having only Event-Based Logging format mandatory would be sufficient > from my viewpoint). > Ben argues that ABR-aware logging should not be mandatory as it requires > extra awareness. > To get more input, I'd propose we move that requirement level discussion > to the cdni-requirements document, and have the logging I-D only talks > about what such logs would look like. > >=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 > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/emaildisclaimer >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Tue Mar 27 23:45:51 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 CD99E21E80F2 for ; Tue, 27 Mar 2012 23:45:51 -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 hxhnX0tto03C for ; Tue, 27 Mar 2012 23:45:50 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 39B3F21E80E7 for ; Tue, 27 Mar 2012 23:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=5124; q=dns/txt; s=iport; t=1332917150; x=1334126750; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=DHCnIzS4DNjfHixBw9wTTWQBa34ZPb5rTQb4tNlBE64=; b=NrgOeVEgzD0vQXRU2PHzUikOijCrGHRTFplYYoHmZxmoesXkH4Kmt+qm Ogh70Rl6kUrPcxhgQ0LIwjCdQl4v4VkKkT94WpeIJo2aHngPdMn/K6F2t HqHUYdGHp/B1EFicoq+Y8YZKJpEq0wdduxf9ARX+eMA7haa4BeQS3z3vA M=; X-IronPort-AV: E=Sophos;i="4.73,659,1325462400"; d="scan'208";a="69505355" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 28 Mar 2012 06:45:49 +0000 Received: from [64.103.30.103] ([64.103.30.103]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2S6jnmu009580; Wed, 28 Mar 2012 06:45:49 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Francois Le Faucheur In-Reply-To: <291CC3F9E50E7641901A54E85D0977C652608722A6@MAILR002.mail.lan> Date: Wed, 28 Mar 2012 08:46:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> <9871DFEE-4302-4B34-967D-91B333DF1011@niven-jenkins.co.uk> <291CC3F9E50E7641901A54E85D0977C652608722A6@MAILR002.mail.lan> To: Kevin J Ma X-Mailer: Apple Mail (2.1084) Cc: "cdni@ietf.org" , Viveganandhan Mahesh Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-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, 28 Mar 2012 06:45:51 -0000 Hello Kevin, On 28 Mar 2012, at 02:08, Kevin J Ma wrote: > Hi All, >=20 > I had a similar concern to Ben. The loss of information in the = Event-based > logging seems undesirable from a content owner perspective. With event-based, the gist of it is that if the client successfully = pulls 100 consecutive segments at the same bandwidth/resolution, you = generate one log-line that means exactly that ie here's teh base URI and = here is the number of bytes that have been successfully delivered from = there on. So you lose a tiny bit of information (eg which is at what = time exactly was the 27th segment requested and completed its individual = delivery) but you retain the significant information. Which specific info are you concerned about that would get lost? Thanks Francois > It would seem > that adding additional segment-based logging fields would be an = easier first > step. Given a piece of metadata that says the content in directory X = is ABR, > then the additional fields could be added. Implementing the event = criteria > seems more cumbersome than that. It is also not clear to me what = happens > when the session gets delegated between different CDNs? The events = seem to > be local-CDN specific? >=20 > thanx. >=20 > -- Kevin J. Ma >=20 >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of >> Ben Niven-Jenkins >> Sent: Thursday, March 22, 2012 11:03 PM >> To: Francois Le Faucheur >> Cc: cdni@ietf.org; Viveganandhan Mahesh >> Subject: Re: [CDNi] Comments on = draft-lefaucheur-cdni-logging-delivery-00 >>=20 >> Francois, >>=20 >> On 13 Mar 2012, at 18:39, Francois Le Faucheur wrote: >>=20 >>> Ben, Kent, >>>=20 >>> Trying to extract the key points from the thread: >>>=20 >>> 1) level of requirement for support of HTTP Adaptive Streaming = Logging >> Session (ie ABR-aware logs): >>> This is a valid question. >>> The I-D proposes that some form of ABR-aware logging be mandatory. = The >> rationale is that ABR is expected to be a very common delivery format = and >> requires some form of log compression over very voluminous = per-segment >> logging. >>=20 >> I agree that ABR produces large volumes of log entries when the dCDN >> creates a log entry per HTTP delivery (HTTP response). >>=20 >> I agree that compressing those logs in some way before distributing = to >> uCDNs would be more efficient that not doing so provided the = compression >> does not result in the loss of information. >>=20 >>> (BTW the I-D currently proposes that both Segment-Based Logging = format >> and Event-Based Logging format be mandatory. But come to think of it, >> having only Event-Based Logging format mandatory would be sufficient = from >> my viewpoint). >>=20 >> Some of the confusion from my side might be that I'm not entirely = certain >> what you are proposing the logging behaviour of the dCDN should be, = i.e. >> are you arguing that in the case where the dCDN is "ABR aware": >>=20 >> 1) We log every single HTTP delivery (HTTP response) individually = (let's >> ignore whether the format is just "plain" HTTP log fields or "plain" = HTTP >> log field plus your proposed Segment-Based log fields) and we produce >> Event-Based Logs >>=20 >> 2) We just produce Event-Based Logs >>=20 >>> 4) summarization of Logging info for Adaptive Streaming delivery >>> I believe some form of summarization is required. The Event-Based >> Logging seems like a nice sweet-spot because it achieves a high >> summarization gain without losing any info (ie any change in >> bandwidth/quality is logged). >>=20 >> Except that if all the dCDN produces for ABR content is an = Event-Based >> Log, the proposed Event-Based Log does lose information compared to a >> "plain" HTTP delivery log. For example the proposed Event-Based Log = does >> not contain all the URLs that were requested by the client, or the = timings >> of the individual requests/responses, or the sizes of the individual >> responses or the cache disposition/Action (TCP_HIT, TCP_MISS, etc.) = of the >> individual responses. >>=20 >> Furthermore, the draft as written does say that, for example an = Event- >> Based Log entry contains a Cache Disposition/Action field but the >> semantics of that field are not clear, i.e. a single event = potentially >> consists of a >1 HTTP delivery (HTTP response) and in the case where = some >> of those deliveries/responses were hits and others were misses what = is the >> correct value to log? The semantics of several other fields in the = Event- >> Based Log are also unclear. >>=20 >>> Ben, it'd be interesting to provide a brief write-up on the >> summarization approach you mention so we can evaluate it (an email to = the >> list woudl be just fine). >>=20 >> I will post something to the mailing list when I get a chance. >>=20 >> Ben >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni From ray.vanbrandenburg@tno.nl Wed Mar 28 00:50: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 8D64D21F88D4 for ; Wed, 28 Mar 2012 00:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.078 X-Spam-Level: X-Spam-Status: No, score=0.078 tagged_above=-999 required=5 tests=[AWL=0.582, 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 EM8HyeWw-pKR for ; Wed, 28 Mar 2012 00:50:00 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 8D26921F88A2 for ; Wed, 28 Mar 2012 00:49:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,661,1325458800"; d="scan'208";a="14898800" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 28 Mar 2012 09:49:44 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.232]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.02.0283.003; Wed, 28 Mar 2012 09:49:44 +0200 From: "Brandenburg, R. (Ray) van" To: Kevin J Ma , "Kent Leung (kleung)" , "gilles.bertrand@orange.com" , "cdni@ietf.org" Thread-Topic: [CDNi] CDNI Requirements for ABR content Thread-Index: AQHNCETi17ClXLSrq0e902XpETmVi5Z8IWcAgABxUYCAACPkYIACFmJwgACISpA= Date: Wed, 28 Mar 2012 07:49:44 +0000 Message-ID: References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com><7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1DD4@xmb-sjc-235.amer.cisco.com> <8E09C72DBC577D489F13A71228C0B7BF033E0C52@ftrdmel0.rd.francetelecom.fr>, <7A2D6D1F6AC99243A77D32820D8ABBC20E95C703@xmb-sjc-235.amer.cisco.com> , <291CC3F9E50E7641901A54E85D0977C652608722A8@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C652608722A8@MAILR002.mail.lan> 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 Subject: Re: [CDNi] CDNI Requirements for ABR content 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, 28 Mar 2012 07:50:01 -0000 Hi Kevin,=0A= =0A= Thanks for your comments.=0A= =0A= Wrt to your comment that Chunk Request Routing is a degenerate version of a= Full Locator: While from a Client point of view the two options are certai= nly similar, I think they are actually quite different from a CDN functiona= l perspective. The Full Locator as I defined it points to a specific file o= n a specific Delivery Node, which means that the client will not be redirec= ted. The Chunk Request Routing option (we might need to choose a better nam= e) on the other hand points to a request routing function, which means that= there will definitely be a redirect. The RR function may either redirect t= he client to a specific delivery node in the same CDN or to another RR func= tion in another CDN. For better understanding of some of the problems that = are described later in the document, I think it is better to distinguish be= tween these two methods. =0A= =0A= As for your comment that full locators and chunk request routing do not req= uire manifest rewriting, I don't understand this. Assuming that delivery no= des are 'dumb' and don't know anything about inter-CDN request routing, and= that full locators point to a specific delivery node (let's say on a uCDN)= , how can the Full Locator in the manifest line not be rewritten when the c= ontent is now supposed to be delivered by another CDN?=0A= =0A= Although I agree that it is technically feasible to not rewrite Chunk Reque= st Routing urls in the manifest, this would mean that for every chunk reque= sted by the client, the uCDN needs to be involved (since it has to redirect= the client to the dCDN). =0A= =0A= Finally, my personal opinion is that we shouldn't classify manifest file re= writing as content adaption in the sense that the CDNI WG shouldn't work on= it. In other to provide a scalable solution for allowing the CDNI interfac= es to deliver content using the various HAS protocols, we basically have tw= o options: 1) we impose the use of Relative Locators for all content, and t= herefore limit the flexibility for both CDNs and Content Providers, or 2) w= e allow manifest file rewriting in some cases. While I agree that some cont= ent providers might consider the manifest as 'content' and therefore don't = want it to be modified, this can be handled on an individual case by using = relative locators in those cases.=0A= =0A= Best regards,=0A= =0A= Ray=0A= =0A= =0A= =0A= ________________________________________=0A= From: Kevin J Ma [kevin.ma@azukisystems.com]=0A= Sent: Wednesday, March 28, 2012 2:09 AM=0A= To: Brandenburg, R. (Ray) van; Kent Leung (kleung); gilles.bertrand@orange.= com; cdni@ietf.org=0A= Subject: RE: [CDNi] CDNI Requirements for ABR content=0A= =0A= Hi Ray,=0A= =0A= I think the draft provides a nice description of the options.=0A= I had a couple of comments:=0A= =0A= - The chunk request routing case (section 2.2.3) seems like a degenerate= =0A= case of full locator. It is a full URL that points to the CDN RR. The= =0A= result is an HTTP redirect to either a surrogate or a dCDN RR? Though= =0A= the format of the URL may be protocol specific, it should not be CDN=0A= specific, and so it does not have to be treated any differenly from any= =0A= other full locator. Note: skipping ahead to the questions in section= =0A= 3.2.1, I do not think that manifest files should be modified. At least= =0A= in the current phase, I believe content adaptation is off the table?=0A= =0A= Wrt to the conclusion that full/relative locators require manifest=0A= file rewrite (in section 3.2.1), I do not see this as the case. In=0A= the worst case, it just means that delegation is not persistent,=0A= though that is dependent upon how the client handles redirects...=0A= =0A= - One of the reasons behind the metadata grouping requirements was to=0A= support Chunk Collections and Content Collections. Wrt the questions= =0A= in section 3.2.1, I think that collections make sense, and that the=0A= propogation of metadata could synchronize definitions of collections=0A= across CDNs?=0A= =0A= thanx.=0A= =0A= -- Kevin J. Ma=0A= =0A= > -----Original Message-----=0A= > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of= =0A= > Brandenburg, R. (Ray) van=0A= > Sent: Monday, March 26, 2012 11:26 AM=0A= > To: Kent Leung (kleung); gilles.bertrand@orange.com; cdni@ietf.org=0A= > Subject: Re: [CDNi] CDNI Requirements for ABR content=0A= >=0A= > Hi Gilles/Kent/all,=0A= >=0A= > It seems to me that the question we keep getting back to is whether the= =0A= > CDN is aware of ABR content (and if we want to require a CDN to be aware= =0A= > of this). This question will probably also come up when discussing other= =0A= > interfaces (especially metadata and request routing).=0A= >=0A= > I therefore suggest that we first discuss the high-level=0A= > requirements/assumptions regarding ABR/HAS and CDNI, come up with some=0A= > guidelines for how the CDNI interfaces should deal with ABR/HAS, and then= =0A= > apply these guidelines to the various interfaces (such as in this case th= e=0A= > logging interface).=0A= >=0A= > I wrote a draft for initiating such a discussion, see=0A= > http://www.ietf.org/id/draft-brandenburg-cdni-has-00.txt. Comments are=0A= > welcome.=0A= >=0A= > Best regards,=0A= >=0A= > Ray=0A= >=0A= >=0A= >=0A= >=0A= >=0A= >=0A= > ________________________________________=0A= > From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] on behalf of Kent=0A= > Leung (kleung) [kleung@cisco.com]=0A= > Sent: Monday, March 26, 2012 5:09 PM=0A= > To: gilles.bertrand@orange.com; cdni@ietf.org=0A= > Subject: Re: [CDNi] CDNI Requirements for ABR content=0A= >=0A= > Hi Gilles. The client has to be ABR-aware to obtain the ABR content. So= =0A= > the question is only pertinent for the CDN. The methods for CDN to=0A= > associate delivery of contents for the ABR session are based on cookie or= =0A= > URI tag (BTW, client just passes this info back to the CDN). Also, CDN=0A= > needs to understand the manifest file (for HLS/HDS/HSS) to determine the= =0A= > abr-protocol, representation, manifest-uri, and content-id.=0A= >=0A= > Both Event-Based Logging and Session-Based Logging require CDN to=0A= > understand the ABR content type. So the implications or impact to the CDN= =0A= > is basically the same for either logging mode. For file-based logging, th= e=0A= > CDN treats each content delivery as a file and unaware that it is really = a=0A= > segment/chunk/fragment of the whole content. There's no knowledge that=0A= > there is a manifest file or different representations or when=0A= > representation changed.=0A= >=0A= > I believe the reason for Event-Based Logging as [HIGH] and Session-Based= =0A= > Logging as [MED] is the expectation that most of the content for the ABR= =0A= > session will be delivered at a steady rate after the initial buffering.= =0A= >=0A= > Does that answer your questions?=0A= >=0A= > Kent=0A= >=0A= > -----Original Message-----=0A= > From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com]=0A= > Sent: Monday, March 26, 2012 1:24 AM=0A= > To: Kent Leung (kleung); cdni@ietf.org=0A= > Subject: RE: [CDNi] CDNI Requirements for ABR content=0A= >=0A= > Hi Kent,=0A= >=0A= > About the tagging as "High" of Event-Based Logging support, I would like= =0A= > to understand what it implies=0A= > - for the CDN and=0A= > - for the client.=0A= >=0A= > I see the following differences between Event-Based Logging and "file-=0A= > based logging":=0A= >=0A= > - Session: I am not an expert of all adaptive streaming flavors; do=0A= > existing clients provide a usable session id to the server?=0A= > - other service level information:=0A= > # Manifest-uri: could the CDN derive it from the session data?=0A= > # Content-id: How could the CDN derive this information: From the= =0A= > content URL? From the session data? Other?=0A= > # Representation: How could the CDN derive this information: From= =0A= > the content URL? From the session data?=0A= >=0A= > About the tagging as "Med" of segment based logging, I would also like to= =0A= > understand the impact on the CDN/client:=0A= > - the CDN sees the chunk requests (except the ones served by a caching-= =0A= > proxy or the browser cache). So I think this logging format is not more= =0A= > complex than event based logging for the client (it does not have to send= =0A= > specific information). For the CDN, the support of this format only=0A= > requires the additional ability to:=0A= > - understand the URL formats to detect the representation changes= =0A= > - detect session ends?=0A= >=0A= > Best regards,=0A= >=0A= > Gilles=0A= >=0A= > -----Message d'origine-----=0A= > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de= =0A= > Kent Leung (kleung)=0A= > Envoy=E9 : jeudi 22 mars 2012 17:00=0A= > =C0 : cdni@ietf.org=0A= > Objet : [CDNi] CDNI Requirements for ABR content=0A= >=0A= > Tracking requirements from CDNI Interface drafts. Based on the discussion= =0A= > for draft-lefaucheur-cdni-logging-delivery, we need some inputs from the= =0A= > WG on the CDNI Logging requirements.=0A= >=0A= > Options for logging requirements for ABR content:=0A= >=0A= > 1) Event-Based Logging shall be supported [HIGH], Segment-Based= =0A= > Logging should be supported [MED], and Summary-Based Logging may be=0A= > supported [LOW].=0A= >=0A= > Reason: The dCDN needs to be aware of ABR content and should log= =0A= > delivery with the ABR-related fields. ABR is expected to be a very common= =0A= > delivery format and requires some form of log compression over very=0A= > voluminous per-segment logging. ABR content needs to be supported by CDNs= .=0A= > Related requirement is "GEN-14 [HIGH] The CDNI solution shall support=0A= > HTTP Adaptive Bit Rate (ABR) content."=0A= >=0A= > OR=0A= >=0A= > 2) Event-Based Logging, Segment-Based Logging, and Summary-Based= =0A= > Logging may be supported [LOW].=0A= >=0A= > Reason: Eliminate the need for dCDN to be aware of ABR content.= =0A= > For example, dCDN is acting in a pure HTTP reverse proxy mode and may not= =0A= > be aware of that level of information and/or because the control of how t= o=0A= > identify those fields is owned by the CSP and none of CDNs may have=0A= > visibility of that mapping information. Such a requirement to force CDNs= =0A= > and CDNI in general to require such mappings seems to be overkill.=0A= >=0A= >=0A= > Thoughts?=0A= >=0A= > Kent=0A= >=0A= >=0A= > -----Original Message-----=0A= > From: Francois Le Faucheur (flefauch)=0A= > Sent: Tuesday, March 13, 2012 11:39 AM=0A= > To: Kent Leung (kleung); Niven-Jenkins Ben=0A= > Cc: Francois Le Faucheur (flefauch); cdni@ietf.org; Mahesh Viveganandhan= =0A= > (mvittal)=0A= > Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00= =0A= >=0A= > Ben, Kent,=0A= >=0A= > Trying to extract the key points from the thread:=0A= >=0A= > 1) level of requirement for support of HTTP Adaptive Streaming Logging=0A= > Session (ie ABR-aware logs):=0A= > This is a valid question.=0A= > The I-D proposes that some form of ABR-aware logging be mandatory. The=0A= > rationale is that ABR is expected to be a very common delivery format and= =0A= > requires some form of log compression over very voluminous per-segment=0A= > logging. (BTW the I-D currently proposes that both Segment-Based Logging= =0A= > format and Event-Based Logging format be mandatory. But come to think of= =0A= > it, having only Event-Based Logging format mandatory would be sufficient= =0A= > from my viewpoint).=0A= > Ben argues that ABR-aware logging should not be mandatory as it requires= =0A= > extra awareness.=0A= > To get more input, I'd propose we move that requirement level discussion= =0A= > to the cdni-requirements document, and have the logging I-D only talks=0A= > about what such logs would look like.=0A= > =0A= >=0A= > _______________________________________________=0A= > CDNi mailing list=0A= > CDNi@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/cdni=0A= > _______________________________________________=0A= > CDNi mailing list=0A= > CDNi@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/cdni=0A= > This e-mail and its contents are subject to the DISCLAIMER at=0A= > http://www.tno.nl/emaildisclaimer=0A= >=0A= > _______________________________________________=0A= > CDNi mailing list=0A= > CDNi@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/cdni=0A= From RMurray@velocix.com Wed Mar 28 02:56: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 B8D7B21F89D6 for ; Wed, 28 Mar 2012 02:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 DBtcIDS2YKGs for ; Wed, 28 Mar 2012 02:56:43 -0700 (PDT) Received: from owa.velocix.com (host1.cachelogic.com [212.44.43.80]) by ietfa.amsl.com (Postfix) with ESMTP id 314F021F89D1 for ; Wed, 28 Mar 2012 02:56:43 -0700 (PDT) Received: from EXB04CAM.corp.velocix.com ([169.254.1.160]) by exc02cam.corp.velocix.com ([172.16.16.133]) with mapi id 14.02.0247.003; Wed, 28 Mar 2012 10:56:41 +0100 From: Rob Murray To: "Matt Caulfield (mcaulfie)" , "cdni@ietf.org" Thread-Topic: [CDNi] CDNI Triggers interface Thread-Index: AQHM9zKuoZRS46pH5ku7qFaJlJ0Mm5Z8/YUAgAK2/IA= Date: Wed, 28 Mar 2012 09:56:41 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.16.16.169] Content-Type: text/plain; charset="us-ascii" Content-ID: <89E7F97C85DCCA4E98598E448E99F184@velocix.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] CDNI Triggers interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 09:56:47 -0000 Hi Matt, many thanks for the input - responses inline... On 26/03/2012 19:29, "Matt Caulfield (mcaulfie)" wrote: >Rob, > >Great document, nice clarity. A few comments / questions: > >1. A single trigger can apply to multiple URLs but only a single >"status" indicator is provided when then the trigger is polled. What >happens when prepositioning one URL succeeds and another one fails? I think failure of any part of the trigger should mean the overall result is Failed. For prepositioning, as you suggest, it'd be useful to have an indication of which URLs caused the problem - I think that could be added to the "error" property (which is undefined at the moment). Error types that include a failure reason and sets of URLs would make sense. We need to do some more analysis of likely causes of failure, and what information uCDN will find useful. Input on that would be welcome. >2. For the cascading CDNs case, another question on status granularity. >When does a trigger complete? After the immediately downstream CDN >finishes the task? Or after the downstream CDN and its own downstream >CDNs finish the task? If one dCDN fails to preposition content while >another succeeds, is the trigger status Complete or Failed? Because uCDN can have no direct influence on further-downstream CDNs, I think it has to be each CDNs responsibility to make sure all of its dCDNs complete triggers before reporting upwards. In the case of prepositioning, the net result of failure in one dCDN would be that the footprint or capabilities advertised by the intermediate CDN would be incorrect for that content - so the overall result of the trigger has to be Failed. I'm not sure whether it'd useful (or even possible/allowable) to state which dCDNs failed in the intermediate CDN's trigger status report. There's not much uCDN could do with that information other than report it back to the intermediate CDN, and there might not be a way to refer to the failed dCDN anyway - if each uCDN sees one downstream footprint it may not know or care that it's actually composed of a cascade of other networks (and the intermediate CDN may not want to expose that detail). >3. Can triggers be processed out of order? I believe Kent had a similar >comment in his email, but I'm not sure about the proposed solution. >Would basing decisions on time open us up to race conditions? I don't think there's a race condition - the only potentially-bad interaction would be a purge/invalidate running behind a preposition trigger (so data that's just been carefully acquired and prepositioned gets immediately deleted). By creating triggers in-order, if invalidate/purge only act on data acquired before the trigger was created, uCDN can make sure only the old data is removed. Thinking about other ways of achieving the ordering - I don't think we've any requirements for clock-sync between CDNs, so it'd be nice to avoid putting times in trigger requests. Another option might be to invent a way of describing sequencing within a trigger request (delete first, then preposition), but that's starting to get messy and still doesn't deal with interaction between triggers. I think this is a simple solution that leaves uCDN in control of the sequencing. >4. In the trigger request, content urls are separate from metadata urls. >How is metadata identified? Is the metadata URL in the trigger request >the url of the content for which the metatdata should be >purged/prepositioned? Or is the metadata URL that of the metadata >resource itself? If the latter, I see no reason to distinguish between >metadata and content urls. Yes, we talked about this when coming up with the draft and decided than making the distinction was probably useful and at-worst harmless. Exactly how to refer to metadata is an open issue that needs more thought. I tried to outline some options in section 5.1.1 of the draft. As the metadata interface evolves the answers might become clearer, but ideas are welcome. But, whichever option we pick - metadata and content are quite distinct and while separating them in the trigger request comes at no real cost, it might make processing on dCDN easier. Operations on metadata may be quite a different to operations on content in its control plane. If it is possible to tell from the URL whether it's a metadata or content reference, having the separation might at least be a useful sanity check on the request. >5. In the HTTP redirection case, each CDN uses a different URL to >identify content. For example, an upstream CDN may use >http://ucdn.com/content1 while a downstream CDN uses >http://dcdn.com/ucdn/content1. Is it a correct assumption that each CDN >in a cascade of CDNs must rewrite the trigger URLs to match what the >downstream CDN would expect? Yes, I think that's the case - but, as above, the form of a metadata reference is an open question. One option (not necessarily a good option!) would be a canonical URL, in which case it wouldn't need rewriting. I think we need to wait for the metadata interface to take more shape before we have a final answer here. >6. From a security considerations standpoint, the Triggers interface >requires client authentication. I believe that's what you're hinting at >in the Security Considerations section but it could be more explicit. I >don't think this requirement is true for all CDNI interfaces (most need >server authentication, but maybe not all need client authentication). Yes, that was what I was trying to get at - I can expand on it in the draft and as the other interfaces take shape it should start to become clearer what can be shared. If we end up with RESTful interfaces though (as I hope we do), there might be quite a bit of commonality. >7. Is polling the only option for learning about status changes? Would >registering a callback be more scalable? Exact completion time of these operations isn't likely to be critical, particularly for prepositioning but also invalidate/purge which (depending on the request and the implementation) may involve slow trawls through large volumes of cached data. The polling mechanism would still be required to allow uCDN to get intermediate status updates, and to check that a callback hadn't gone missing - so adding a callback mechanism would add complexity and imply more responsiveness that is perhaps necessary. =20 With uCDN polling for status, dCDN can choose to only calculate the status when asked - or less frequently if it wants to return a cached result. When compared with what the rest of the CDN is doing (and is good-at), dealing with conditional HTTP requests for trigger status probably isn't be a huge burden. >8. Is there an implicit assumption that for any given piece of content, >there will only be a single source of triggers? What if a CDN receives >the same trigger from two upstream CDNs? There has to be access control - each uCDN must only be able to create triggers that affect its own data (one uCDN shouldn't be allowed to flush another's content). Where there are multiple routes from an origin to a dCDN for one set of content (through different uCDNs to a final dCDN), it may not always be clear which uCDN owns that content. Using metadata URLs to refer to content as you mentioned above might help - but I think it has to be dCDN's responsibility to resolve the conflict... perhaps that configuration will be disallowed, or we may need a non-technical solution in interconnect agreements. >Thanks, >Matt > >-----Original Message----- >From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of >Rob Murray >Sent: Wednesday, February 29, 2012 5:34 PM >To: cdni@ietf.org >Subject: [CDNi] CDNI Triggers interface > >Hi all, > >I've just uploaded a new draft that proposes a CDNI Triggers interface >... > > http://tools.ietf.org/html/draft-murray-cdni-triggers-00 > >There was some discussion at the last WG meeting about whether triggers >fit best as part of the control or metadata interface - the suggestion >was >that concrete proposals for the interface might help us spot commonality >with one or the other, so let's see! > >Please take a look, your comments are welcome. > >Best regards, >Rob. > > >On 29/02/2012 19:37, "internet-drafts@ietf.org" > >wrote: > >>A new version of I-D, draft-murray-cdni-triggers-00.txt has been >>successfully submitted by Rob Murray and posted to the IETF repository. >> >>Filename: draft-murray-cdni-triggers >>Revision: 00 >>Title: CDN Interconnect Triggers >>Creation date: 2012-02-29 >>WG ID: Individual Submission >>Number of pages: 33 >> >>Abstract: >> This document proposes a mechanism for a CDN to trigger activity in >> an interconnected CDN that is configured to deliver content on its >> behalf. The upstream CDN can use this mechanism to request that the >> downstream CDN pre-positions metadata or content, or that it re- >> validate or purge metadata or content. The upstream CDN can monitor >> the status of activity that it has triggered in the downstream CDN. >> >> >> >> >> >> >>The IETF Secretariat >_______________________________________________ >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 RMurray@velocix.com Wed Mar 28 03:25: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 786C521F891C for ; Wed, 28 Mar 2012 03:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 8SQuhuZ7FVFy for ; Wed, 28 Mar 2012 03:25:20 -0700 (PDT) Received: from owa.velocix.com (host1.cachelogic.com [212.44.43.80]) by ietfa.amsl.com (Postfix) with ESMTP id A865421F8A31 for ; Wed, 28 Mar 2012 03:25:19 -0700 (PDT) Received: from EXB04CAM.corp.velocix.com ([169.254.1.160]) by exc02cam.corp.velocix.com ([172.16.16.133]) with mapi id 14.02.0247.003; Wed, 28 Mar 2012 11:25:18 +0100 From: Rob Murray To: Kevin J Ma , "Kent Leung (kleung)" , "cdni@ietf.org" Thread-Topic: [CDNi] CDNI Triggers interface Thread-Index: AQHM9ylJjw/I9226gUqTKwJkpHCC05Z2wCQAgARJ3wCAA+KmoIAAz+mA Date: Wed, 28 Mar 2012 10:25:18 +0000 Message-ID: In-Reply-To: <291CC3F9E50E7641901A54E85D0977C652608722A5@MAILR002.mail.lan> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.16.16.169] Content-Type: text/plain; charset="us-ascii" Content-ID: <052E21A23FE9F84583B16E8C505E91D2@velocix.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] CDNI Triggers interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 10:25:21 -0000 Hi Kevin, and thanks - responses inline... On 28/03/2012 02:08, "Kevin J Ma" wrote: >Hi Rob, > > I think the doc does a good job of clearly defining the space. > I had a couple of questions: > > - Section 4.4 mentions returning 404/410 on subsequent requests for a > resource after deletion. I assume this also applies to section 4.3 > and explicit deletion? Might be worth clarifying in section 4.3? Yes, will do. > - Along the lines of Matt and Kent's questions about request ordering, > I was wondering about repeat requests. The current set of triggers > are fairly idemopotent, so perhaps it would only be an optimization > for them, but are there concerns for duplicate requests or requests > with overlapping urls/patterns wrt any pending or active triggers? I think the interaction we want to avoid is between invalidate/purge and preposition, I hope my suggestion for using trigger "ctime" to indicate which data should be invalidated/purged addresses that? And, as you say, the current operations are fairly idempotent. Each uCDN can only affect its own data, so it should be in full control of any interactions. If it asks dCDN to do something silly with overlapping URLs/paterns, I don't think dCDN should try to second-guess it. > - For trigger creation, would it make sense to have a priority field, > to allow uCDNs to influence the order in which dCDNs process triggers? Whether it's possible to influence the order of processing will depend a lot on the implementation in dCDN. It may or may not be possible to stop/pause/pace triggered activity on any given cache, or across the network. Allowing the uCDN to set a priority might give an illusion of control that it doesn't have. Do you have a particular use-case in mind? One that springs to mind would be that uCDN has made a time-consuming request, then wants to inject something more urgent. In this case it has the option of deleting the original trigger (dCDN may or may not stop work on it) and re-creating it later, the idempotence of the operations helps us again there. Overall, I think it's probably best to keep things simple and leave scheduling/ordering of triggers under uCDN control by expecting it to make requests and wait for completions in an order it likes. >thanx. > >-- Kevin J. Ma > >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of >> Rob Murray >> Sent: Sunday, March 25, 2012 7:43 AM >> To: Kent Leung (kleung); cdni@ietf.org >> Subject: Re: [CDNi] CDNI Triggers interface >>=20 >> Thanks Kent - replies inline ... >>=20 >> On 22/03/2012 18:11, "Kent Leung (kleung)" wrote: >>=20 >> >Hi Rob. Nice write-up. Here are some comments on the draft. >> > >> >1. Sect. 2: Nit for "The trigger may request action on either metadata >> >or on content". Reword to "The trigger may request action on either >> >metadata or content"? >>=20 >> Will do. >>=20 >> >2. Sect. 2: Any thoughts on the scalability aspect of using RESTful web >> >service assuming there will be many dCDNs providing delivery service >>for >> >a uCDN? These triggers will likely apply on all the dCDNs. >>=20 >> Since uCDN has the contract with the Content Owner (or with another uCDN >> that does), it has ultimate responsibility for ensuring that triggers >>are >> acted upon - I think it will need to track which dCDNs have its data and >> which have completed its triggers, for auditing purposes if nothing >>else? >> Because it's got that responsibility, uCDN will want a way to >>interrogate >> dCDN for status of triggers so, correspondingly, dCDN will need to track >> and report state of triggers. >>=20 >> So, I'd say per-trigger, per-interconnect state will exist at both ends >> of the interface whether it's RESTful or not. Does that answer the >> concern? I can add some descriptive text to the draft along those lines >>if >> it does. >>=20 >> Do you have a feel for the numbers of interconnects a given CDN is >>likely >> to have? I can't find an indication in the problem-statement or >> requirements - but I'd imagine each CDN will have a relatively small >> number >> of interconnect agreements, perhaps up to low tens? Generally I'd think >> CDNs will have many fewer interconnects than Delivery Surrogates, but an >> exception might be a "broker" CDN that owns content but doesn't do the >> actual delivery itself. In that case, I'd guess we're not talking about >> thousands of interconnects but perhaps it might get into hundreds? I >> don't have any actual facts or data to cloud my thinking though (!), so >> I'd be interested to hear other views. >>=20 >> >3. Sect. 4: Typo in "For example, is anticipated that decisions on use >> >of HTTPS for other CDNI interfaces will be adopted for Triggers." >>=20 >> Will fix. >>=20 >> >4. Sect. 4.1: The Trigger Request must be processed in the sequence as >> >triggered by the uCDN? Is there a message sequencing method defined? >>For >> >example, uCDN wants to purge a specific content, then preposition that >> >content. What happens when the message arrives at dCDN out of order? >>=20 >> Good point, thanks, I've not covered that. >>=20 >> If we define the invalidate/purge triggers to mean "invalidate or purge >> data obtained before this trigger was created" (before "ctime" of the >> Trigger Status Resource), I think that solves the problem. For example, >>a >> use-case for "invalidate" followed by "preposition" would be an >>emergency >> fix to some metadata or content - with this change, by issuing triggers >>in >> order after the data is repaired, uCDN can be sure incorrect data is >> deleted. But, data acquired from the same location after the repair >> (either as a result of pre-positioning or normal operation) will not >>need >> to be re-fetched. The invalidate/purge and the preposition triggers can >> run concurrently. >>=20 >> I makes the semantics of invalidate/purge cleaner anyway. If (repaired) >> data can still obtained from affected URL, it'd be hard for uCDN to >> guarantee that when a purge completes no data from affected URLs exists >> in dCDN. Much easier for it to say that data acquired before a given >> time has been invalidated/purged from the network. >>=20 >> >5. Sect. 4.2: Nit for ".. to cheaply check for change .." Maybe " .. to >> >inherently check for change .."? >>=20 >> How about "... to check for change in status of a resource or collection >> of resources without re-fetching the whole resource or collection." >>=20 >> > >> >6. Sect 4.2: Reword " to indicate the frequency it would like uCDN to >> >poll at." to " to indicate the frequency of polling by the uCDN"? >>=20 >> How about "The dCDN should use the cache control headers for responses >>to >> GETs for Trigger Status Resources and Collections to indicate the >> frequency at which it recommends uCDN should poll for change." >>=20 >> >Kent >> > >> >-----Original Message----- >> >From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of >> >Rob Murray >> >Sent: Wednesday, February 29, 2012 1:25 PM >> >To: cdni@ietf.org >> >Subject: [CDNi] CDNI Triggers interface >> > >> >Hi all, >> > >> >I've just uploaded a new draft that proposes a CDNI Triggers interface >> >... >> > >> > http://datatracker.ietf.org/doc/draft-murray-cdni-triggers/ >> > >> > >> >There was some discussion at the last WG meeting about whether triggers >> >fit best as part of the control or metadata interface - the suggestion >> >was >> >that concrete proposals for the interface might help us spot >>commonality >> >with one or the other, so let's see! >> > >> >Please take a look, your comments are welcome. >> > >> >Best regards, >> >Rob. >> > >> > >> >On 29/02/2012 19:37, "internet-drafts@ietf.org" >> > >> >wrote: >> > >> >>A new version of I-D, draft-murray-cdni-triggers-00.txt has been >> >>successfully submitted by Rob Murray and posted to the IETF >>repository. >> >> >> >>Filename: draft-murray-cdni-triggers >> >>Revision: 00 >> >>Title: CDN Interconnect Triggers >> >>Creation date: 2012-02-29 >> >>WG ID: Individual Submission >> >>Number of pages: 33 >> >> >> >>Abstract: >> >> This document proposes a mechanism for a CDN to trigger activity in >> >> an interconnected CDN that is configured to deliver content on its >> >> behalf. The upstream CDN can use this mechanism to request that >>the >> >> downstream CDN pre-positions metadata or content, or that it re- >> >> validate or purge metadata or content. The upstream CDN can >>monitor >> >> the status of activity that it has triggered in the downstream CDN. >> >> >> >> >> >> >> >> >> >> >> >> >> >>The IETF Secretariat >> > >> >_______________________________________________ >> >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 gilles.bertrand@orange.com Wed Mar 28 04:56: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 2CA3621E811C for ; Wed, 28 Mar 2012 04:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.006 X-Spam-Level: X-Spam-Status: No, score=-6.006 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 i5J1Zw3ern6I for ; Wed, 28 Mar 2012 04:56:17 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 468B821E813C for ; Wed, 28 Mar 2012 04:56:15 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B8916FC4021; Wed, 28 Mar 2012 13:56:12 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id AE50EFC4008; Wed, 28 Mar 2012 13:56:12 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 13:56:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0CD9.C53954F4" Date: Wed, 28 Mar 2012 13:55:50 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF034265BB@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <7A2D6D1F6AC99243A77D32820D8ABBC20E95C618@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] TR: I-D Action: draft-bertrand-cdni-logging-00.txt Thread-Index: AczqV04P2kj58bv3Su2UKn4mvvPeCwAAGnzQCAWYkVAAmiXBgA== References: <8E09C72DBC577D489F13A71228C0B7BF03231555@ftrdmel0.rd.francetelecom.fr> <7A2D6D1F6AC99243A77D32820D8ABBC20E95C618@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 28 Mar 2012 11:56:12.0832 (UTC) FILETIME=[C5B98A00:01CD0CD9] Subject: Re: [CDNi] TR: I-D Action: draft-bertrand-cdni-logging-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 11:56:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0CD9.C53954F4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Kent, =20 Thanks for the useful comments. My answers are below. =20 Best regards, =20 Gilles =20 -----Message d'origine----- De : Kent Leung (kleung) [mailto:kleung@cisco.com]=20 Envoy=E9 : dimanche 25 mars 2012 12:31 =C0 : BERTRAND Gilles RD-CORE-ISS; cdni@ietf.org Objet : RE: [CDNi] TR: I-D Action: draft-bertrand-cdni-logging-00.txt =20 Hi Gilles and Stephan. A few comments on your draft. =20 1. Sect. 3: Should the Logging Architecture include on-demand access to = logging information (see LOG-9 requirement)? So it's not only CoDR = Selection from uCDN to dCDN, but also CoDR Request. =20 GB: Agreed =20 2. Sect. 6.2: Not clear how Cascaded CDNs are supported in the = Information Elements in the logging records? The CDNI Logging interface = is between uCDN and dCDN. Some clarification on how cascaded CDNs are = handled would be helpful (see LOG-3 requirement). =20 GB: I agree it's an important point. The approach in this draft is first = to agree on the core information elements that a dCDN needs to provide = to the uCDN. We will extend this list in next version of the draft and = we will get more into the details of the information elements provided = in the Content Delivery Records.=20 =20 =20 3. Sect. 7: Should there be logging for Metadata acquisition and = purging? Also, logging for Triggers (Control Interface) for = content/metadata acquisition and purging? =20 GB: Logging has various uses, in particular debugging. CDNs may keep a = log of Metadata related operations and of Triggers. This information = might be interesting for the uCDN for debugging purposes.=20 =20 4. Not sure if support for batch/offline exchange of logging records was = mentioned (LOG-5 requirement)? =20 GB: We will describe these aspects in section 9. =20 5. Not sure if resource consumption reporting is covered (LOG-12 = requirement)? =20 GB: We can consider such data as a KPI (rather than a "usual" raw = Content Delivery Record) reported by the dCDN to the uCDN. We will = describe how dCDNs should report such specific KPIs to the uCDN in next = versions of the draft.=20 =20 6. Sect. 8.1.1: Just a note that draft-lefaucheur-cdni-logging-delivery = has more details for ABR. =20 GB: right. draft-lefaucheur-cdni-logging-delivery details more the = Logging for ABR content.=20 =20 =20 =20 Kent =20 -----Original Message----- From: cdni-bounces@ietf.org = [mailto:cdni-bounces@ietf.org ] On Behalf = Of gilles.bertrand@orange.com =20 Sent: Monday, February 13, 2012 6:04 AM To: cdni@ietf.org =20 Subject: [CDNi] TR: I-D Action: draft-bertrand-cdni-logging-00.txt =20 Hi everyone, =20 We have submitted a new draft on the Logging interface: http://tools.ietf.org/html/draft-bertrand-cdni-logging-00 = =20 =20 "This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN). It introduces a framework, an = architecture design and a set of new requirements. Then it drafts an = information model." =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 13 f=E9vrier 2012 14:56 =C0 : i-d-announce@ietf.org = Objet : I-D Action: = draft-bertrand-cdni-logging-00.txt =20 =20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. =20 Title : CDNI Logging Interface Author(s) : Gilles Bertrand Stephan Emile Filename : draft-bertrand-cdni-logging-00.txt Pages : 26 Date : 2012-02-13 =20 This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN). It introduces a framework, an architecture design and a set of new requirements. Then it drafts an information model. =20 =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bertrand-cdni-logging-00.txt = = =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ = =20 =20 This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-bertrand-cdni-logging-00.txt = =20 =20 _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org =20 https://www.ietf.org/mailman/listinfo/i-d-announce = =20 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 =20 https://www.ietf.org/mailman/listinfo/cdni = =20 ------_=_NextPart_001_01CD0CD9.C53954F4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Kent,

 

Thanks for the useful comments. My answers are = below.

 

Best regards,

 

Gilles

 

-----Message d'origine-----
De : = Kent Leung (kleung) [mailto:kleung@cisco.com]
Envoy=E9 : = dimanche 25 mars 2012 12:31
=C0 : BERTRAND Gilles RD-CORE-ISS; = cdni@ietf.org
Objet : RE: [CDNi] TR: I-D Action: = draft-bertrand-cdni-logging-00.txt

 

Hi Gilles and Stephan. = A few comments on your draft.

 

1. Sect. 3: Should the = Logging Architecture include on-demand access to logging information = (see LOG-9 requirement)? So it's not only CoDR Selection from uCDN to = dCDN, but also CoDR Request.

 

GB: = Agreed

 

2. Sect. 6.2: Not = clear how Cascaded CDNs are supported in the Information Elements in the = logging records? The CDNI Logging interface is between uCDN and dCDN. = Some clarification on how cascaded CDNs are handled would be helpful = (see LOG-3 requirement).

 

GB: I agree it's an important point. The approach = in this draft is first to agree on the core information elements that a = dCDN needs to provide to the uCDN. We will extend this list in next = version of the draft and we will get more into the details of the = information elements provided in the Content Delivery Records. =

 

 

3. Sect. 7: Should = there be logging for Metadata acquisition and purging?=A0 Also, logging = for Triggers (Control Interface) for content/metadata acquisition and = purging?

 

GB: Logging has various = uses, in particular debugging. CDNs may keep a log of Metadata related = operations and of Triggers. This information might be interesting for = the uCDN for debugging purposes.

 

4. Not sure if support = for batch/offline exchange of logging records was mentioned (LOG-5 = requirement)?

 

GB: We = will describe these aspects in section 9.

 

5. Not sure if = resource consumption reporting is covered (LOG-12 = requirement)?

 

GB: We can consider such data as a KPI (rather = than a "usual" raw Content Delivery Record) reported by the = dCDN to the uCDN. We will describe how dCDNs should report such specific = KPIs to the uCDN in next versions of the draft.

 

6. Sect. 8.1.1: Just a = note that draft-lefaucheur-cdni-logging-delivery has more details for = ABR.

 

GB: right. = draft-lefaucheur-cdni-logging-delivery details more the Logging for ABR = content.

 

 

 

Kent

 

-----Original Message-----

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.= org] On Behalf Of gilles.bertrand@orange.co= m

Sent: Monday, = February 13, 2012 6:04 AM

To: cdni@ietf.org<= o:p>

Subject: [CDNi] TR: I-D Action: = draft-bertrand-cdni-logging-00.txt

 

Hi = everyone,

 

We have submitted a new draft on the Logging = interface:

http://tools.ietf.org/htm= l/draft-bertrand-cdni-logging-00

 

"This memo specifies the Logging interface = between a downstream CDN

(dCDN) = and an upstream CDN (uCDN). It introduces a framework, an architecture = design and a set of new requirements. Then it drafts an information = model."

 

Best = regards,

 

Gilles

 

 

-----Message d'origine-----

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

 

 

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

 

=A0=A0=A0=A0=A0 Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = : CDNI Logging Interface

=A0=A0=A0=A0=A0 Author(s)=A0=A0=A0=A0=A0=A0 : = Gilles Bertrand

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 Stephan Emile

=A0=A0=A0=A0=A0 Filename=A0=A0=A0=A0=A0=A0=A0 : = draft-bertrand-cdni-logging-00.txt

=A0=A0=A0=A0=A0 Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = : 26

=A0=A0=A0=A0=A0 = Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2012-02-13

 

=A0=A0 = This memo specifies the Logging interface between a downstream = CDN

=A0=A0 (dCDN) and an upstream = CDN (uCDN).=A0 It introduces a framework, an

=A0=A0 architecture design and a set of new = requirements.=A0 Then it drafts an

=A0=A0 information model.

 

 

A URL = for this Internet-Draft is:

http://www.ietf.org/inter= net-drafts/draft-bertrand-cdni-logging-00.txt

 

Internet-Drafts are also available by anonymous FTP = at:

ftp://ftp.ietf.org/intern= et-drafts/

 

This = Internet-Draft can be retrieved at:

ftp://ftp.ietf.org/intern= et-drafts/draft-bertrand-cdni-logging-00.txt

 

_______________________________________________=

I-D-Announce mailing = list

I-D-Announce@ietf.org

https://www.ietf.org/mail= man/listinfo/i-d-announce

Internet-Draft directories: http://www.ietf.org/shado= w.html or ftp://ftp.ietf.org/ietf/1= shadow-sites.txt

_______________________________________________=

CDNi mailing list

CDNi@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/cdni

------_=_NextPart_001_01CD0CD9.C53954F4-- From kevin.ma@azukisystems.com Wed Mar 28 06:40: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 2853B21E8158 for ; Wed, 28 Mar 2012 06:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.366, 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 YA9zFBbkBKO4 for ; Wed, 28 Mar 2012 06:40:42 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF9121E80CB for ; Wed, 28 Mar 2012 06:40:42 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 6DF2F8BED29; Wed, 28 Mar 2012 09:40:41 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.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 4A3098BEC5E; Wed, 28 Mar 2012 09:40:40 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Wed, 28 Mar 2012 09:40:32 -0400 From: Kevin J Ma To: Rob Murray , "Kent Leung (kleung)" , "cdni@ietf.org" Date: Wed, 28 Mar 2012 09:40:37 -0400 Thread-Topic: [CDNi] CDNI Triggers interface Thread-Index: AQHM9ylJjw/I9226gUqTKwJkpHCC05Z2wCQAgARJ3wCAA+KmoIAAz+mAgAAcY3A= Message-ID: <291CC3F9E50E7641901A54E85D0977C6526087235B@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C652608722A5@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 Subject: Re: [CDNi] CDNI Triggers interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 13:40:44 -0000 Hi Rob, Wrt priorities, I was thinking about a case where there are a large numbe= r of trigger requests, possibly initiated by end customers, e.g., the uCDN provides a web portal to allow customers to purge/invalidate content. No= t all customers/administrators are created equal, and not wanting to delete= , remember, and repost every trigger, it might be useful to have priorities= . I agree that we may not want triggers to be pre-emptive, and the dCDN may have its own priorities, but if a uCDN and dCDN negotiate some understand= ing, outside the scope of CDNI, would a priority field be useful? thanx. -- Kevin J. Ma > -----Original Message----- > From: Rob Murray [mailto:RMurray@velocix.com] > Sent: Wednesday, March 28, 2012 6:25 AM > To: Kevin J Ma; Kent Leung (kleung); cdni@ietf.org > Subject: Re: [CDNi] CDNI Triggers interface >=20 > Hi Kevin, and thanks - responses inline... >=20 > On 28/03/2012 02:08, "Kevin J Ma" wrote: >=20 > >Hi Rob, > > > > I think the doc does a good job of clearly defining the space. > > I had a couple of questions: > > > > - Section 4.4 mentions returning 404/410 on subsequent requests for a > > resource after deletion. I assume this also applies to section 4.3 > > and explicit deletion? Might be worth clarifying in section 4.3? >=20 > Yes, will do. >=20 > > - Along the lines of Matt and Kent's questions about request ordering, > > I was wondering about repeat requests. The current set of triggers > > are fairly idemopotent, so perhaps it would only be an optimization > > for them, but are there concerns for duplicate requests or requests > > with overlapping urls/patterns wrt any pending or active triggers? >=20 > I think the interaction we want to avoid is between invalidate/purge and > preposition, I hope my suggestion for using trigger "ctime" to indicate > which data should be invalidated/purged addresses that? And, as you say, > the current operations are fairly idempotent. >=20 > Each uCDN can only affect its own data, so it should be in full control o= f > any interactions. If it asks dCDN to do something silly with overlapping > URLs/paterns, I don't think dCDN should try to second-guess it. >=20 > > - For trigger creation, would it make sense to have a priority field, > > to allow uCDNs to influence the order in which dCDNs process > triggers? >=20 > Whether it's possible to influence the order of processing will depend a > lot on the implementation in dCDN. It may or may not be possible to > stop/pause/pace triggered activity on any given cache, or across the > network. Allowing the uCDN to set a priority might give an illusion of > control that it doesn't have. >=20 > Do you have a particular use-case in mind? One that springs to mind would > be that uCDN has made a time-consuming request, then wants to inject > something more urgent. In this case it has the option of deleting the > original trigger (dCDN may or may not stop work on it) and re-creating it > later, the idempotence of the operations helps us again there. >=20 > Overall, I think it's probably best to keep things simple and leave > scheduling/ordering of triggers under uCDN control by expecting it to mak= e > requests and wait for completions in an order it likes. >=20 >=20 > >thanx. > > > >-- Kevin J. Ma > > > >> -----Original Message----- > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf O= f > >> Rob Murray > >> Sent: Sunday, March 25, 2012 7:43 AM > >> To: Kent Leung (kleung); cdni@ietf.org > >> Subject: Re: [CDNi] CDNI Triggers interface > >> > >> Thanks Kent - replies inline ... > >> > >> On 22/03/2012 18:11, "Kent Leung (kleung)" wrote: > >> > >> >Hi Rob. Nice write-up. Here are some comments on the draft. > >> > > >> >1. Sect. 2: Nit for "The trigger may request action on either metadat= a > >> >or on content". Reword to "The trigger may request action on either > >> >metadata or content"? > >> > >> Will do. > >> > >> >2. Sect. 2: Any thoughts on the scalability aspect of using RESTful > web > >> >service assuming there will be many dCDNs providing delivery service > >>for > >> >a uCDN? These triggers will likely apply on all the dCDNs. > >> > >> Since uCDN has the contract with the Content Owner (or with another > uCDN > >> that does), it has ultimate responsibility for ensuring that triggers > >>are > >> acted upon - I think it will need to track which dCDNs have its data > and > >> which have completed its triggers, for auditing purposes if nothing > >>else? > >> Because it's got that responsibility, uCDN will want a way to > >>interrogate > >> dCDN for status of triggers so, correspondingly, dCDN will need to > track > >> and report state of triggers. > >> > >> So, I'd say per-trigger, per-interconnect state will exist at both end= s > >> of the interface whether it's RESTful or not. Does that answer the > >> concern? I can add some descriptive text to the draft along those line= s > >>if > >> it does. > >> > >> Do you have a feel for the numbers of interconnects a given CDN is > >>likely > >> to have? I can't find an indication in the problem-statement or > >> requirements - but I'd imagine each CDN will have a relatively small > >> number > >> of interconnect agreements, perhaps up to low tens? Generally I'd thin= k > >> CDNs will have many fewer interconnects than Delivery Surrogates, but > an > >> exception might be a "broker" CDN that owns content but doesn't do the > >> actual delivery itself. In that case, I'd guess we're not talking abou= t > >> thousands of interconnects but perhaps it might get into hundreds? I > >> don't have any actual facts or data to cloud my thinking though (!), s= o > >> I'd be interested to hear other views. > >> > >> >3. Sect. 4: Typo in "For example, is anticipated that decisions on us= e > >> >of HTTPS for other CDNI interfaces will be adopted for Triggers." > >> > >> Will fix. > >> > >> >4. Sect. 4.1: The Trigger Request must be processed in the sequence a= s > >> >triggered by the uCDN? Is there a message sequencing method defined? > >>For > >> >example, uCDN wants to purge a specific content, then preposition tha= t > >> >content. What happens when the message arrives at dCDN out of order? > >> > >> Good point, thanks, I've not covered that. > >> > >> If we define the invalidate/purge triggers to mean "invalidate or purg= e > >> data obtained before this trigger was created" (before "ctime" of the > >> Trigger Status Resource), I think that solves the problem. For example= , > >>a > >> use-case for "invalidate" followed by "preposition" would be an > >>emergency > >> fix to some metadata or content - with this change, by issuing trigger= s > >>in > >> order after the data is repaired, uCDN can be sure incorrect data is > >> deleted. But, data acquired from the same location after the repair > >> (either as a result of pre-positioning or normal operation) will not > >>need > >> to be re-fetched. The invalidate/purge and the preposition triggers ca= n > >> run concurrently. > >> > >> I makes the semantics of invalidate/purge cleaner anyway. If (repaired= ) > >> data can still obtained from affected URL, it'd be hard for uCDN to > >> guarantee that when a purge completes no data from affected URLs exist= s > >> in dCDN. Much easier for it to say that data acquired before a given > >> time has been invalidated/purged from the network. > >> > >> >5. Sect. 4.2: Nit for ".. to cheaply check for change .." Maybe " .. > to > >> >inherently check for change .."? > >> > >> How about "... to check for change in status of a resource or > collection > >> of resources without re-fetching the whole resource or collection." > >> > >> > > >> >6. Sect 4.2: Reword " to indicate the frequency it would like uCDN to > >> >poll at." to " to indicate the frequency of polling by the uCDN"? > >> > >> How about "The dCDN should use the cache control headers for responses > >>to > >> GETs for Trigger Status Resources and Collections to indicate the > >> frequency at which it recommends uCDN should poll for change." > >> > >> >Kent > >> > > >> >-----Original Message----- > >> >From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > Of > >> >Rob Murray > >> >Sent: Wednesday, February 29, 2012 1:25 PM > >> >To: cdni@ietf.org > >> >Subject: [CDNi] CDNI Triggers interface > >> > > >> >Hi all, > >> > > >> >I've just uploaded a new draft that proposes a CDNI Triggers interfac= e > >> >... > >> > > >> > http://datatracker.ietf.org/doc/draft-murray-cdni-triggers/ > >> > > >> > > >> >There was some discussion at the last WG meeting about whether > triggers > >> >fit best as part of the control or metadata interface - the suggestio= n > >> >was > >> >that concrete proposals for the interface might help us spot > >>commonality > >> >with one or the other, so let's see! > >> > > >> >Please take a look, your comments are welcome. > >> > > >> >Best regards, > >> >Rob. > >> > > >> > > >> >On 29/02/2012 19:37, "internet-drafts@ietf.org" > >> > > >> >wrote: > >> > > >> >>A new version of I-D, draft-murray-cdni-triggers-00.txt has been > >> >>successfully submitted by Rob Murray and posted to the IETF > >>repository. > >> >> > >> >>Filename: draft-murray-cdni-triggers > >> >>Revision: 00 > >> >>Title: CDN Interconnect Triggers > >> >>Creation date: 2012-02-29 > >> >>WG ID: Individual Submission > >> >>Number of pages: 33 > >> >> > >> >>Abstract: > >> >> This document proposes a mechanism for a CDN to trigger activity > in > >> >> an interconnected CDN that is configured to deliver content on it= s > >> >> behalf. The upstream CDN can use this mechanism to request that > >>the > >> >> downstream CDN pre-positions metadata or content, or that it re- > >> >> validate or purge metadata or content. The upstream CDN can > >>monitor > >> >> the status of activity that it has triggered in the downstream > CDN. > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >>The IETF Secretariat > >> > > >> >_______________________________________________ > >> >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 kevin.ma@azukisystems.com Wed Mar 28 06:53: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 92FA421F8967 for ; Wed, 28 Mar 2012 06:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.305, 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 yiRhHMtGIxVL for ; Wed, 28 Mar 2012 06:53:16 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id D369321F8819 for ; Wed, 28 Mar 2012 06:53:15 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 8672E83F699; Wed, 28 Mar 2012 09:53:15 -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 66BA883F560; Wed, 28 Mar 2012 09:53:14 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Wed, 28 Mar 2012 09:53:14 -0400 From: Kevin J Ma To: "Brandenburg, R. (Ray) van" , "Kent Leung (kleung)" , "gilles.bertrand@orange.com" , "cdni@ietf.org" Date: Wed, 28 Mar 2012 09:53:11 -0400 Thread-Topic: [CDNi] CDNI Requirements for ABR content Thread-Index: AQHNCETi17ClXLSrq0e902XpETmVi5Z8IWcAgABxUYCAACPkYIACFmJwgACISpCAAGWxEA== Message-ID: <291CC3F9E50E7641901A54E85D0977C65260872386@MAILR002.mail.lan> References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com><7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1DD4@xmb-sjc-235.amer.cisco.com> <8E09C72DBC577D489F13A71228C0B7BF033E0C52@ftrdmel0.rd.francetelecom.fr>, <7A2D6D1F6AC99243A77D32820D8ABBC20E95C703@xmb-sjc-235.amer.cisco.com> , <291CC3F9E50E7641901A54E85D0977C652608722A8@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] CDNI Requirements for ABR content 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, 28 Mar 2012 13:53:18 -0000 Hi Ray, comment inline: > -----Original Message----- > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > Sent: Wednesday, March 28, 2012 3:50 AM > To: Kevin J Ma; Kent Leung (kleung); gilles.bertrand@orange.com; > cdni@ietf.org > Subject: RE: [CDNi] CDNI Requirements for ABR content >=20 > Hi Kevin, >=20 > Thanks for your comments. >=20 > Wrt to your comment that Chunk Request Routing is a degenerate version of > a Full Locator: While from a Client point of view the two options are > certainly similar, I think they are actually quite different from a CDN > functional perspective. The Full Locator as I defined it points to a > specific file on a specific Delivery Node, which means that the client > will not be redirected.=20 I see. That specific aspect did not register on first read. So, delivery = node in this example refers to a surrogate? In that case, it is not clear to me= why the manifest would have a URL pointing at a specific delivery node (without= the assumption that the CDN has already modified the manifest)? A content prov= ider who does not run their own CDN is unlikely to know about surrogates. The U= RL is more likely to be the content providers registered DNS address thats CNA= MEd to the uCDN which follows the normal request routing flow? In the branding= use case, it is unlikely that the content provider would want URL rewrites? thanx. -- Kevin J. Ma > The Chunk Request Routing option (we might need to > choose a better name) on the other hand points to a request routing > function, which means that there will definitely be a redirect. The RR > function may either redirect the client to a specific delivery node in th= e > same CDN or to another RR function in another CDN. For better > understanding of some of the problems that are described later in the > document, I think it is better to distinguish between these two methods. >=20 > As for your comment that full locators and chunk request routing do not > require manifest rewriting, I don't understand this. Assuming that > delivery nodes are 'dumb' and don't know anything about inter-CDN request > routing, and that full locators point to a specific delivery node (let's > say on a uCDN), how can the Full Locator in the manifest line not be > rewritten when the content is now supposed to be delivered by another CDN= ? >=20 > Although I agree that it is technically feasible to not rewrite Chunk > Request Routing urls in the manifest, this would mean that for every chun= k > requested by the client, the uCDN needs to be involved (since it has to > redirect the client to the dCDN). > > Finally, my personal opinion is that we shouldn't classify manifest file > rewriting as content adaption in the sense that the CDNI WG shouldn't wor= k > on it. In other to provide a scalable solution for allowing the CDNI > interfaces to deliver content using the various HAS protocols, we > basically have two options: 1) we impose the use of Relative Locators for > all content, and therefore limit the flexibility for both CDNs and Conten= t > Providers, or 2) we allow manifest file rewriting in some cases. While I > agree that some content providers might consider the manifest as 'content= ' > and therefore don't want it to be modified, this can be handled on an > individual case by using relative locators in those cases. > > Best regards, >=20 > Ray >=20 >=20 >=20 > ________________________________________ > From: Kevin J Ma [kevin.ma@azukisystems.com] > Sent: Wednesday, March 28, 2012 2:09 AM > To: Brandenburg, R. (Ray) van; Kent Leung (kleung); > gilles.bertrand@orange.com; cdni@ietf.org > Subject: RE: [CDNi] CDNI Requirements for ABR content >=20 > Hi Ray, >=20 > I think the draft provides a nice description of the options. > I had a couple of comments: >=20 > - The chunk request routing case (section 2.2.3) seems like a degenerat= e > case of full locator. It is a full URL that points to the CDN RR. > The > result is an HTTP redirect to either a surrogate or a dCDN RR? Thoug= h > the format of the URL may be protocol specific, it should not be CDN > specific, and so it does not have to be treated any differenly from > any > other full locator. Note: skipping ahead to the questions in section > 3.2.1, I do not think that manifest files should be modified. At > least > in the current phase, I believe content adaptation is off the table? >=20 > Wrt to the conclusion that full/relative locators require manifest > file rewrite (in section 3.2.1), I do not see this as the case. In > the worst case, it just means that delegation is not persistent, > though that is dependent upon how the client handles redirects... >=20 > - One of the reasons behind the metadata grouping requirements was to > support Chunk Collections and Content Collections. Wrt the questions > in section 3.2.1, I think that collections make sense, and that the > propogation of metadata could synchronize definitions of collections > across CDNs? >=20 > thanx. >=20 > -- Kevin J. Ma >=20 > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > > Brandenburg, R. (Ray) van > > Sent: Monday, March 26, 2012 11:26 AM > > To: Kent Leung (kleung); gilles.bertrand@orange.com; cdni@ietf.org > > Subject: Re: [CDNi] CDNI Requirements for ABR content > > > > Hi Gilles/Kent/all, > > > > It seems to me that the question we keep getting back to is whether the > > CDN is aware of ABR content (and if we want to require a CDN to be awar= e > > of this). This question will probably also come up when discussing othe= r > > interfaces (especially metadata and request routing). > > > > I therefore suggest that we first discuss the high-level > > requirements/assumptions regarding ABR/HAS and CDNI, come up with some > > guidelines for how the CDNI interfaces should deal with ABR/HAS, and > then > > apply these guidelines to the various interfaces (such as in this case > the > > logging interface). > > > > I wrote a draft for initiating such a discussion, see > > http://www.ietf.org/id/draft-brandenburg-cdni-has-00.txt. Comments are > > welcome. > > > > Best regards, > > > > Ray > > > > > > > > > > > > > > ________________________________________ > > From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] on behalf of Kent > > Leung (kleung) [kleung@cisco.com] > > Sent: Monday, March 26, 2012 5:09 PM > > To: gilles.bertrand@orange.com; cdni@ietf.org > > Subject: Re: [CDNi] CDNI Requirements for ABR content > > > > Hi Gilles. The client has to be ABR-aware to obtain the ABR content. So > > the question is only pertinent for the CDN. The methods for CDN to > > associate delivery of contents for the ABR session are based on cookie > or > > URI tag (BTW, client just passes this info back to the CDN). Also, CDN > > needs to understand the manifest file (for HLS/HDS/HSS) to determine th= e > > abr-protocol, representation, manifest-uri, and content-id. > > > > Both Event-Based Logging and Session-Based Logging require CDN to > > understand the ABR content type. So the implications or impact to the > CDN > > is basically the same for either logging mode. For file-based logging, > the > > CDN treats each content delivery as a file and unaware that it is reall= y > a > > segment/chunk/fragment of the whole content. There's no knowledge that > > there is a manifest file or different representations or when > > representation changed. > > > > I believe the reason for Event-Based Logging as [HIGH] and Session-Base= d > > Logging as [MED] is the expectation that most of the content for the AB= R > > session will be delivered at a steady rate after the initial buffering. > > > > Does that answer your questions? > > > > Kent > > > > -----Original Message----- > > From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com] > > Sent: Monday, March 26, 2012 1:24 AM > > To: Kent Leung (kleung); cdni@ietf.org > > Subject: RE: [CDNi] CDNI Requirements for ABR content > > > > Hi Kent, > > > > About the tagging as "High" of Event-Based Logging support, I would lik= e > > to understand what it implies > > - for the CDN and > > - for the client. > > > > I see the following differences between Event-Based Logging and "file- > > based logging": > > > > - Session: I am not an expert of all adaptive streaming flavors; do > > existing clients provide a usable session id to the server? > > - other service level information: > > # Manifest-uri: could the CDN derive it from the session data? > > # Content-id: How could the CDN derive this information: From the > > content URL? From the session data? Other? > > # Representation: How could the CDN derive this information: From > > the content URL? From the session data? > > > > About the tagging as "Med" of segment based logging, I would also like > to > > understand the impact on the CDN/client: > > - the CDN sees the chunk requests (except the ones served by a caching- > > proxy or the browser cache). So I think this logging format is not more > > complex than event based logging for the client (it does not have to > send > > specific information). For the CDN, the support of this format only > > requires the additional ability to: > > - understand the URL formats to detect the representation > changes > > - detect session ends? > > > > Best regards, > > > > Gilles > > > > -----Message d'origine----- > > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de > > Kent Leung (kleung) > > Envoy=E9 : jeudi 22 mars 2012 17:00 > > =C0 : cdni@ietf.org > > Objet : [CDNi] CDNI Requirements for ABR content > > > > Tracking requirements from CDNI Interface drafts. Based on the > discussion > > for draft-lefaucheur-cdni-logging-delivery, we need some inputs from th= e > > WG on the CDNI Logging requirements. > > > > Options for logging requirements for ABR content: > > > > 1) Event-Based Logging shall be supported [HIGH], Segment-Based > > Logging should be supported [MED], and Summary-Based Logging may be > > supported [LOW]. > > > > Reason: The dCDN needs to be aware of ABR content and should lo= g > > delivery with the ABR-related fields. ABR is expected to be a very > common > > delivery format and requires some form of log compression over very > > voluminous per-segment logging. ABR content needs to be supported by > CDNs. > > Related requirement is "GEN-14 [HIGH] The CDNI solution shall support > > HTTP Adaptive Bit Rate (ABR) content." > > > > OR > > > > 2) Event-Based Logging, Segment-Based Logging, and Summary-Base= d > > Logging may be supported [LOW]. > > > > Reason: Eliminate the need for dCDN to be aware of ABR content. > > For example, dCDN is acting in a pure HTTP reverse proxy mode and may > not > > be aware of that level of information and/or because the control of how > to > > identify those fields is owned by the CSP and none of CDNs may have > > visibility of that mapping information. Such a requirement to force CDN= s > > and CDNI in general to require such mappings seems to be overkill. > > > > > > Thoughts? > > > > Kent > > > > > > -----Original Message----- > > From: Francois Le Faucheur (flefauch) > > Sent: Tuesday, March 13, 2012 11:39 AM > > To: Kent Leung (kleung); Niven-Jenkins Ben > > Cc: Francois Le Faucheur (flefauch); cdni@ietf.org; Mahesh Viveganandha= n > > (mvittal) > > Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery- > 00 > > > > Ben, Kent, > > > > Trying to extract the key points from the thread: > > > > 1) level of requirement for support of HTTP Adaptive Streaming Logging > > Session (ie ABR-aware logs): > > This is a valid question. > > The I-D proposes that some form of ABR-aware logging be mandatory. The > > rationale is that ABR is expected to be a very common delivery format > and > > requires some form of log compression over very voluminous per-segment > > logging. (BTW the I-D currently proposes that both Segment-Based Loggin= g > > format and Event-Based Logging format be mandatory. But come to think o= f > > it, having only Event-Based Logging format mandatory would be sufficien= t > > from my viewpoint). > > Ben argues that ABR-aware logging should not be mandatory as it require= s > > extra awareness. > > To get more input, I'd propose we move that requirement level discussio= n > > to the cdni-requirements document, and have the logging I-D only talks > > about what such logs would look like. > > > > > > _______________________________________________ > > 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 > > 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 kevin.ma@azukisystems.com Wed Mar 28 07:04: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 F32AA21E819B for ; Wed, 28 Mar 2012 07:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.262, 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 UCB-eVSrZ-G5 for ; Wed, 28 Mar 2012 07:04:23 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDDF21F8A58 for ; Wed, 28 Mar 2012 07:04:23 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 5588A554B5F; Wed, 28 Mar 2012 10:04:18 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB024.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 7D7A3553C3D; Wed, 28 Mar 2012 10:03:41 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Wed, 28 Mar 2012 10:03:21 -0400 From: Kevin J Ma To: Francois Le Faucheur Date: Wed, 28 Mar 2012 10:03:34 -0400 Thread-Topic: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 Thread-Index: Ac0Mrmvys+5ZdWq2T2uLbXg3TH/ksQAPD9OQ Message-ID: <291CC3F9E50E7641901A54E85D0977C652608723A3@MAILR002.mail.lan> References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> <9871DFEE-4302-4B34-967D-91B333DF1011@niven-jenkins.co.uk> <291CC3F9E50E7641901A54E85D0977C652608722A6@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: "cdni@ietf.org" , Viveganandhan Mahesh Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-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, 28 Mar 2012 14:04:25 -0000 Hi Francois, Ignoring possible timeliness, the individual logs include Time-to-Serve, and Current-Time, which are useful for assessing delivery performance. It is also not clear how errors are handled? If the client gets handed a bunch of 403s and 404s, but still gets the content eventually, without triggering an event, are those still logged? For Bytes-Transferred, if there were aborted requests, do those get counted as well? Not all clien= t behavior can be correlated with the simplified log. thanx. -- Kevin J. Ma > -----Original Message----- > From: Francois Le Faucheur [mailto:flefauch@cisco.com] > Sent: Wednesday, March 28, 2012 2:46 AM > To: Kevin J Ma > Cc: Francois Le Faucheur; Ben Niven-Jenkins; cdni@ietf.org; Viveganandhan > Mahesh > Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 >=20 > Hello Kevin, >=20 > On 28 Mar 2012, at 02:08, Kevin J Ma wrote: >=20 > > Hi All, > > > > I had a similar concern to Ben. The loss of information in the Event- > based > > logging seems undesirable from a content owner perspective. >=20 > With event-based, the gist of it is that if the client successfully pulls > 100 consecutive segments at the same bandwidth/resolution, you generate > one log-line that means exactly that ie here's teh base URI and here is > the number of bytes that have been successfully delivered from there on. > So you lose a tiny bit of information (eg which is at what time exactly > was the 27th segment requested and completed its individual delivery) but > you retain the significant information. > Which specific info are you concerned about that would get lost? >=20 > Thanks >=20 > Francois >=20 >=20 > > It would seem > > that adding additional segment-based logging fields would be an easier > first > > step. Given a piece of metadata that says the content in directory X > is ABR, > > then the additional fields could be added. Implementing the event > criteria > > seems more cumbersome than that. It is also not clear to me what > happens > > when the session gets delegated between different CDNs? The events > seem to > > be local-CDN specific? > > > > thanx. > > > > -- Kevin J. Ma > > > >> -----Original Message----- > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf O= f > >> Ben Niven-Jenkins > >> Sent: Thursday, March 22, 2012 11:03 PM > >> To: Francois Le Faucheur > >> Cc: cdni@ietf.org; Viveganandhan Mahesh > >> Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery= - > 00 > >> > >> Francois, > >> > >> On 13 Mar 2012, at 18:39, Francois Le Faucheur wrote: > >> > >>> Ben, Kent, > >>> > >>> Trying to extract the key points from the thread: > >>> > >>> 1) level of requirement for support of HTTP Adaptive Streaming Loggin= g > >> Session (ie ABR-aware logs): > >>> This is a valid question. > >>> The I-D proposes that some form of ABR-aware logging be mandatory. Th= e > >> rationale is that ABR is expected to be a very common delivery format > and > >> requires some form of log compression over very voluminous per-segment > >> logging. > >> > >> I agree that ABR produces large volumes of log entries when the dCDN > >> creates a log entry per HTTP delivery (HTTP response). > >> > >> I agree that compressing those logs in some way before distributing to > >> uCDNs would be more efficient that not doing so provided the > compression > >> does not result in the loss of information. > >> > >>> (BTW the I-D currently proposes that both Segment-Based Logging forma= t > >> and Event-Based Logging format be mandatory. But come to think of it, > >> having only Event-Based Logging format mandatory would be sufficient > from > >> my viewpoint). > >> > >> Some of the confusion from my side might be that I'm not entirely > certain > >> what you are proposing the logging behaviour of the dCDN should be, > i.e. > >> are you arguing that in the case where the dCDN is "ABR aware": > >> > >> 1) We log every single HTTP delivery (HTTP response) individually > (let's > >> ignore whether the format is just "plain" HTTP log fields or "plain" > HTTP > >> log field plus your proposed Segment-Based log fields) and we produce > >> Event-Based Logs > >> > >> 2) We just produce Event-Based Logs > >> > >>> 4) summarization of Logging info for Adaptive Streaming delivery > >>> I believe some form of summarization is required. The Event-Based > >> Logging seems like a nice sweet-spot because it achieves a high > >> summarization gain without losing any info (ie any change in > >> bandwidth/quality is logged). > >> > >> Except that if all the dCDN produces for ABR content is an Event-Based > >> Log, the proposed Event-Based Log does lose information compared to a > >> "plain" HTTP delivery log. For example the proposed Event-Based Log > does > >> not contain all the URLs that were requested by the client, or the > timings > >> of the individual requests/responses, or the sizes of the individual > >> responses or the cache disposition/Action (TCP_HIT, TCP_MISS, etc.) of > the > >> individual responses. > >> > >> Furthermore, the draft as written does say that, for example an Event- > >> Based Log entry contains a Cache Disposition/Action field but the > >> semantics of that field are not clear, i.e. a single event potentially > >> consists of a >1 HTTP delivery (HTTP response) and in the case where > some > >> of those deliveries/responses were hits and others were misses what is > the > >> correct value to log? The semantics of several other fields in the > Event- > >> Based Log are also unclear. > >> > >>> Ben, it'd be interesting to provide a brief write-up on the > >> summarization approach you mention so we can evaluate it (an email to > the > >> list woudl be just fine). > >> > >> I will post something to the mailing list when I get a chance. > >> > >> Ben > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni From ray.vanbrandenburg@tno.nl Wed Mar 28 08:15: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 C4A3D21E82AE for ; Wed, 28 Mar 2012 08:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.025 X-Spam-Level: X-Spam-Status: No, score=0.025 tagged_above=-999 required=5 tests=[AWL=0.529, 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 G3T1IruhieTR for ; Wed, 28 Mar 2012 08:14:59 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 8808721E81AD for ; Wed, 28 Mar 2012 08:14:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,661,1325458800"; d="scan'208";a="14906815" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1b.tno.nl with ESMTP; 28 Mar 2012 17:14:56 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.232]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0283.003; Wed, 28 Mar 2012 17:14:55 +0200 From: "Brandenburg, R. (Ray) van" To: Kevin J Ma , "Kent Leung (kleung)" , "gilles.bertrand@orange.com" , "cdni@ietf.org" Thread-Topic: [CDNi] CDNI Requirements for ABR content Thread-Index: AQHNCETi17ClXLSrq0e902XpETmVi5Z8IWcAgABxUYCAACPkYIACFmJwgACISpCAAGWxEIAAHdnM Date: Wed, 28 Mar 2012 15:14:54 +0000 Message-ID: References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com><7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1DD4@xmb-sjc-235.amer.cisco.com> <8E09C72DBC577D489F13A71228C0B7BF033E0C52@ftrdmel0.rd.francetelecom.fr>, <7A2D6D1F6AC99243A77D32820D8ABBC20E95C703@xmb-sjc-235.amer.cisco.com> , <291CC3F9E50E7641901A54E85D0977C652608722A8@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C65260872386@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C65260872386@MAILR002.mail.lan> 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-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] CDNI Requirements for ABR content 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, 28 Mar 2012 15:15:01 -0000 Hi Kevin, comment inline.=0A= =0A= Ray=0A= ________________________________________=0A= From: Kevin J Ma [kevin.ma@azukisystems.com]=0A= Sent: Wednesday, March 28, 2012 3:53 PM=0A= To: Brandenburg, R. (Ray) van; Kent Leung (kleung); gilles.bertrand@orange.= com; cdni@ietf.org=0A= Subject: RE: [CDNi] CDNI Requirements for ABR content=0A= =0A= Hi Ray,=0A= =0A= comment inline:=0A= =0A= > -----Original Message-----=0A= > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl]=0A= > Sent: Wednesday, March 28, 2012 3:50 AM=0A= > To: Kevin J Ma; Kent Leung (kleung); gilles.bertrand@orange.com;=0A= > cdni@ietf.org=0A= > Subject: RE: [CDNi] CDNI Requirements for ABR content=0A= >=0A= > Hi Kevin,=0A= >=0A= > Thanks for your comments.=0A= >=0A= > Wrt to your comment that Chunk Request Routing is a degenerate version of= =0A= > a Full Locator: While from a Client point of view the two options are=0A= > certainly similar, I think they are actually quite different from a CDN= =0A= > functional perspective. The Full Locator as I defined it points to a=0A= > specific file on a specific Delivery Node, which means that the client=0A= > will not be redirected.=0A= =0A= I see. That specific aspect did not register on first read. So, delivery = node=0A= in this example refers to a surrogate? In that case, it is not clear to me= why=0A= the manifest would have a URL pointing at a specific delivery node (without= the=0A= assumption that the CDN has already modified the manifest)? A content prov= ider=0A= who does not run their own CDN is unlikely to know about surrogates. The U= RL=0A= is more likely to be the content providers registered DNS address thats CNA= MEd=0A= to the uCDN which follows the normal request routing flow? In the branding= use=0A= case, it is unlikely that the content provider would want URL rewrites?=0A= =0A= [RAY]: One situation where Full Locators are used is in cases where a parti= cular CDN wants to divide segments across different delivery nodes (or surr= ogates using your terminology). For example, for efficiency reasons a CDN m= ight want to place a certain subset of the segments on more nodes (or diffe= rent nodes) than all of the other segments. In that case, having Full Locat= ors doesn't require per-chunk request routing, while it is still possible t= o have this added flexibility. I agree that this does mean that the CDN (in= this case the uCDN) has rewritten the manifest it received from the conten= t provider, but that can be a bilateral agreement where the content provide= r does not have any problems with rewriting the manifest.=0A= =0A= thanx.=0A= =0A= -- Kevin J. Ma=0A= =0A= > The Chunk Request Routing option (we might need to=0A= > choose a better name) on the other hand points to a request routing=0A= > function, which means that there will definitely be a redirect. The RR=0A= > function may either redirect the client to a specific delivery node in th= e=0A= > same CDN or to another RR function in another CDN. For better=0A= > understanding of some of the problems that are described later in the=0A= > document, I think it is better to distinguish between these two methods.= =0A= >=0A= > As for your comment that full locators and chunk request routing do not= =0A= > require manifest rewriting, I don't understand this. Assuming that=0A= > delivery nodes are 'dumb' and don't know anything about inter-CDN request= =0A= > routing, and that full locators point to a specific delivery node (let's= =0A= > say on a uCDN), how can the Full Locator in the manifest line not be=0A= > rewritten when the content is now supposed to be delivered by another CDN= ?=0A= >=0A= > Although I agree that it is technically feasible to not rewrite Chunk=0A= > Request Routing urls in the manifest, this would mean that for every chun= k=0A= > requested by the client, the uCDN needs to be involved (since it has to= =0A= > redirect the client to the dCDN).=0A= >=0A= > Finally, my personal opinion is that we shouldn't classify manifest file= =0A= > rewriting as content adaption in the sense that the CDNI WG shouldn't wor= k=0A= > on it. In other to provide a scalable solution for allowing the CDNI=0A= > interfaces to deliver content using the various HAS protocols, we=0A= > basically have two options: 1) we impose the use of Relative Locators for= =0A= > all content, and therefore limit the flexibility for both CDNs and Conten= t=0A= > Providers, or 2) we allow manifest file rewriting in some cases. While I= =0A= > agree that some content providers might consider the manifest as 'content= '=0A= > and therefore don't want it to be modified, this can be handled on an=0A= > individual case by using relative locators in those cases.=0A= >=0A= > Best regards,=0A= >=0A= > Ray=0A= >=0A= >=0A= >=0A= > ________________________________________=0A= > From: Kevin J Ma [kevin.ma@azukisystems.com]=0A= > Sent: Wednesday, March 28, 2012 2:09 AM=0A= > To: Brandenburg, R. (Ray) van; Kent Leung (kleung);=0A= > gilles.bertrand@orange.com; cdni@ietf.org=0A= > Subject: RE: [CDNi] CDNI Requirements for ABR content=0A= >=0A= > Hi Ray,=0A= >=0A= > I think the draft provides a nice description of the options.=0A= > I had a couple of comments:=0A= >=0A= > - The chunk request routing case (section 2.2.3) seems like a degenerat= e=0A= > case of full locator. It is a full URL that points to the CDN RR.=0A= > The=0A= > result is an HTTP redirect to either a surrogate or a dCDN RR? Thoug= h=0A= > the format of the URL may be protocol specific, it should not be CDN= =0A= > specific, and so it does not have to be treated any differenly from= =0A= > any=0A= > other full locator. Note: skipping ahead to the questions in section= =0A= > 3.2.1, I do not think that manifest files should be modified. At=0A= > least=0A= > in the current phase, I believe content adaptation is off the table?= =0A= >=0A= > Wrt to the conclusion that full/relative locators require manifest=0A= > file rewrite (in section 3.2.1), I do not see this as the case. In= =0A= > the worst case, it just means that delegation is not persistent,=0A= > though that is dependent upon how the client handles redirects...=0A= >=0A= > - One of the reasons behind the metadata grouping requirements was to= =0A= > support Chunk Collections and Content Collections. Wrt the questions= =0A= > in section 3.2.1, I think that collections make sense, and that the= =0A= > propogation of metadata could synchronize definitions of collections= =0A= > across CDNs?=0A= >=0A= > thanx.=0A= >=0A= > -- Kevin J. Ma=0A= >=0A= > > -----Original Message-----=0A= > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of= =0A= > > Brandenburg, R. (Ray) van=0A= > > Sent: Monday, March 26, 2012 11:26 AM=0A= > > To: Kent Leung (kleung); gilles.bertrand@orange.com; cdni@ietf.org=0A= > > Subject: Re: [CDNi] CDNI Requirements for ABR content=0A= > >=0A= > > Hi Gilles/Kent/all,=0A= > >=0A= > > It seems to me that the question we keep getting back to is whether the= =0A= > > CDN is aware of ABR content (and if we want to require a CDN to be awar= e=0A= > > of this). This question will probably also come up when discussing othe= r=0A= > > interfaces (especially metadata and request routing).=0A= > >=0A= > > I therefore suggest that we first discuss the high-level=0A= > > requirements/assumptions regarding ABR/HAS and CDNI, come up with some= =0A= > > guidelines for how the CDNI interfaces should deal with ABR/HAS, and=0A= > then=0A= > > apply these guidelines to the various interfaces (such as in this case= =0A= > the=0A= > > logging interface).=0A= > >=0A= > > I wrote a draft for initiating such a discussion, see=0A= > > http://www.ietf.org/id/draft-brandenburg-cdni-has-00.txt. Comments are= =0A= > > welcome.=0A= > >=0A= > > Best regards,=0A= > >=0A= > > Ray=0A= > >=0A= > >=0A= > >=0A= > >=0A= > >=0A= > >=0A= > > ________________________________________=0A= > > From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] on behalf of Kent= =0A= > > Leung (kleung) [kleung@cisco.com]=0A= > > Sent: Monday, March 26, 2012 5:09 PM=0A= > > To: gilles.bertrand@orange.com; cdni@ietf.org=0A= > > Subject: Re: [CDNi] CDNI Requirements for ABR content=0A= > >=0A= > > Hi Gilles. The client has to be ABR-aware to obtain the ABR content. So= =0A= > > the question is only pertinent for the CDN. The methods for CDN to=0A= > > associate delivery of contents for the ABR session are based on cookie= =0A= > or=0A= > > URI tag (BTW, client just passes this info back to the CDN). Also, CDN= =0A= > > needs to understand the manifest file (for HLS/HDS/HSS) to determine th= e=0A= > > abr-protocol, representation, manifest-uri, and content-id.=0A= > >=0A= > > Both Event-Based Logging and Session-Based Logging require CDN to=0A= > > understand the ABR content type. So the implications or impact to the= =0A= > CDN=0A= > > is basically the same for either logging mode. For file-based logging,= =0A= > the=0A= > > CDN treats each content delivery as a file and unaware that it is reall= y=0A= > a=0A= > > segment/chunk/fragment of the whole content. There's no knowledge that= =0A= > > there is a manifest file or different representations or when=0A= > > representation changed.=0A= > >=0A= > > I believe the reason for Event-Based Logging as [HIGH] and Session-Base= d=0A= > > Logging as [MED] is the expectation that most of the content for the AB= R=0A= > > session will be delivered at a steady rate after the initial buffering.= =0A= > >=0A= > > Does that answer your questions?=0A= > >=0A= > > Kent=0A= > >=0A= > > -----Original Message-----=0A= > > From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com]=0A= > > Sent: Monday, March 26, 2012 1:24 AM=0A= > > To: Kent Leung (kleung); cdni@ietf.org=0A= > > Subject: RE: [CDNi] CDNI Requirements for ABR content=0A= > >=0A= > > Hi Kent,=0A= > >=0A= > > About the tagging as "High" of Event-Based Logging support, I would lik= e=0A= > > to understand what it implies=0A= > > - for the CDN and=0A= > > - for the client.=0A= > >=0A= > > I see the following differences between Event-Based Logging and "file-= =0A= > > based logging":=0A= > >=0A= > > - Session: I am not an expert of all adaptive streaming flavors; do=0A= > > existing clients provide a usable session id to the server?=0A= > > - other service level information:=0A= > > # Manifest-uri: could the CDN derive it from the session data?= =0A= > > # Content-id: How could the CDN derive this information: From the= =0A= > > content URL? From the session data? Other?=0A= > > # Representation: How could the CDN derive this information: From= =0A= > > the content URL? From the session data?=0A= > >=0A= > > About the tagging as "Med" of segment based logging, I would also like= =0A= > to=0A= > > understand the impact on the CDN/client:=0A= > > - the CDN sees the chunk requests (except the ones served by a caching-= =0A= > > proxy or the browser cache). So I think this logging format is not more= =0A= > > complex than event based logging for the client (it does not have to=0A= > send=0A= > > specific information). For the CDN, the support of this format only=0A= > > requires the additional ability to:=0A= > > - understand the URL formats to detect the representation=0A= > changes=0A= > > - detect session ends?=0A= > >=0A= > > Best regards,=0A= > >=0A= > > Gilles=0A= > >=0A= > > -----Message d'origine-----=0A= > > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de= =0A= > > Kent Leung (kleung)=0A= > > Envoy=E9 : jeudi 22 mars 2012 17:00=0A= > > =C0 : cdni@ietf.org=0A= > > Objet : [CDNi] CDNI Requirements for ABR content=0A= > >=0A= > > Tracking requirements from CDNI Interface drafts. Based on the=0A= > discussion=0A= > > for draft-lefaucheur-cdni-logging-delivery, we need some inputs from th= e=0A= > > WG on the CDNI Logging requirements.=0A= > >=0A= > > Options for logging requirements for ABR content:=0A= > >=0A= > > 1) Event-Based Logging shall be supported [HIGH], Segment-Based= =0A= > > Logging should be supported [MED], and Summary-Based Logging may be=0A= > > supported [LOW].=0A= > >=0A= > > Reason: The dCDN needs to be aware of ABR content and should lo= g=0A= > > delivery with the ABR-related fields. ABR is expected to be a very=0A= > common=0A= > > delivery format and requires some form of log compression over very=0A= > > voluminous per-segment logging. ABR content needs to be supported by=0A= > CDNs.=0A= > > Related requirement is "GEN-14 [HIGH] The CDNI solution shall support= =0A= > > HTTP Adaptive Bit Rate (ABR) content."=0A= > >=0A= > > OR=0A= > >=0A= > > 2) Event-Based Logging, Segment-Based Logging, and Summary-Base= d=0A= > > Logging may be supported [LOW].=0A= > >=0A= > > Reason: Eliminate the need for dCDN to be aware of ABR content.= =0A= > > For example, dCDN is acting in a pure HTTP reverse proxy mode and may= =0A= > not=0A= > > be aware of that level of information and/or because the control of how= =0A= > to=0A= > > identify those fields is owned by the CSP and none of CDNs may have=0A= > > visibility of that mapping information. Such a requirement to force CDN= s=0A= > > and CDNI in general to require such mappings seems to be overkill.=0A= > >=0A= > >=0A= > > Thoughts?=0A= > >=0A= > > Kent=0A= > >=0A= > >=0A= > > -----Original Message-----=0A= > > From: Francois Le Faucheur (flefauch)=0A= > > Sent: Tuesday, March 13, 2012 11:39 AM=0A= > > To: Kent Leung (kleung); Niven-Jenkins Ben=0A= > > Cc: Francois Le Faucheur (flefauch); cdni@ietf.org; Mahesh Viveganandha= n=0A= > > (mvittal)=0A= > > Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-= =0A= > 00=0A= > >=0A= > > Ben, Kent,=0A= > >=0A= > > Trying to extract the key points from the thread:=0A= > >=0A= > > 1) level of requirement for support of HTTP Adaptive Streaming Logging= =0A= > > Session (ie ABR-aware logs):=0A= > > This is a valid question.=0A= > > The I-D proposes that some form of ABR-aware logging be mandatory. The= =0A= > > rationale is that ABR is expected to be a very common delivery format= =0A= > and=0A= > > requires some form of log compression over very voluminous per-segment= =0A= > > logging. (BTW the I-D currently proposes that both Segment-Based Loggin= g=0A= > > format and Event-Based Logging format be mandatory. But come to think o= f=0A= > > it, having only Event-Based Logging format mandatory would be sufficien= t=0A= > > from my viewpoint).=0A= > > Ben argues that ABR-aware logging should not be mandatory as it require= s=0A= > > extra awareness.=0A= > > To get more input, I'd propose we move that requirement level discussio= n=0A= > > to the cdni-requirements document, and have the logging I-D only talks= =0A= > > about what such logs would look like.=0A= > > =0A= > >=0A= > > _______________________________________________=0A= > > CDNi mailing list=0A= > > CDNi@ietf.org=0A= > > https://www.ietf.org/mailman/listinfo/cdni=0A= > > _______________________________________________=0A= > > CDNi mailing list=0A= > > CDNi@ietf.org=0A= > > https://www.ietf.org/mailman/listinfo/cdni=0A= > > This e-mail and its contents are subject to the DISCLAIMER at=0A= > > http://www.tno.nl/emaildisclaimer=0A= > >=0A= > > _______________________________________________=0A= > > CDNi mailing list=0A= > > CDNi@ietf.org=0A= > > https://www.ietf.org/mailman/listinfo/cdni=0A= From kevin.ma@azukisystems.com Wed Mar 28 09:14:23 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 82FBC21E8248 for ; Wed, 28 Mar 2012 09:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, 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 RNAqC50VLkwJ for ; Wed, 28 Mar 2012 09:14:22 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 786B321E808F for ; Wed, 28 Mar 2012 09:14:21 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 720B88BF789; Wed, 28 Mar 2012 12:14:19 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB028.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 AF8648BF278; Wed, 28 Mar 2012 12:12:49 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB028.mail.lan ([10.110.17.28]) with mapi; Wed, 28 Mar 2012 12:12:49 -0400 From: Kevin J Ma To: "Brandenburg, R. (Ray) van" , "Kent Leung (kleung)" , "gilles.bertrand@orange.com" , "cdni@ietf.org" Date: Wed, 28 Mar 2012 12:12:45 -0400 Thread-Topic: [CDNi] CDNI Requirements for ABR content Thread-Index: AQHNCETi17ClXLSrq0e902XpETmVi5Z8IWcAgABxUYCAACPkYIACFmJwgACISpCAAGWxEIAAHdnMgAAI4QA= Message-ID: <291CC3F9E50E7641901A54E85D0977C65260911597@MAILR002.mail.lan> References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com><7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1DD4@xmb-sjc-235.amer.cisco.com> <8E09C72DBC577D489F13A71228C0B7BF033E0C52@ftrdmel0.rd.francetelecom.fr>, <7A2D6D1F6AC99243A77D32820D8ABBC20E95C703@xmb-sjc-235.amer.cisco.com> , <291CC3F9E50E7641901A54E85D0977C652608722A8@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C65260872386@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] CDNI Requirements for ABR content 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, 28 Mar 2012 16:14:23 -0000 Hi Ray, inline: > -----Original Message----- > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > Sent: Wednesday, March 28, 2012 11:15 AM > To: Kevin J Ma; Kent Leung (kleung); gilles.bertrand@orange.com; > cdni@ietf.org > Subject: RE: [CDNi] CDNI Requirements for ABR content > > Hi Kevin, comment inline. > > Ray > ________________________________________ > From: Kevin J Ma [kevin.ma@azukisystems.com] > Sent: Wednesday, March 28, 2012 3:53 PM > To: Brandenburg, R. (Ray) van; Kent Leung (kleung); > gilles.bertrand@orange.com; cdni@ietf.org > Subject: RE: [CDNi] CDNI Requirements for ABR content > > Hi Ray, > > comment inline: > > > -----Original Message----- > > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > > Sent: Wednesday, March 28, 2012 3:50 AM > > To: Kevin J Ma; Kent Leung (kleung); gilles.bertrand@orange.com; > > cdni@ietf.org > > Subject: RE: [CDNi] CDNI Requirements for ABR content > > > > Hi Kevin, > > > > Thanks for your comments. > > > > Wrt to your comment that Chunk Request Routing is a degenerate version > of > > a Full Locator: While from a Client point of view the two options are > > certainly similar, I think they are actually quite different from a CDN > > functional perspective. The Full Locator as I defined it points to a > > specific file on a specific Delivery Node, which means that the client > > will not be redirected. > > I see. That specific aspect did not register on first read. So, deliver= y > node > in this example refers to a surrogate? In that case, it is not clear to > me why > the manifest would have a URL pointing at a specific delivery node > (without the > assumption that the CDN has already modified the manifest)? A content > provider > who does not run their own CDN is unlikely to know about surrogates. The > URL > is more likely to be the content providers registered DNS address thats > CNAMEd > to the uCDN which follows the normal request routing flow? In the > branding use > case, it is unlikely that the content provider would want URL rewrites? > > [RAY]: One situation where Full Locators are used is in cases where a > particular CDN wants to divide segments across different delivery nodes > (or surrogates using your terminology). Was just trying to conform to the problem statement terminology... ;) > For example, for efficiency > reasons a CDN might want to place a certain subset of the segments on mor= e > nodes (or different nodes) than all of the other segments. In that case, > having Full Locators doesn't require per-chunk request routing, while it > is still possible to have this added flexibility. For live HLS, e.g., the manifest file is going to change every segment; is per-chunk manifest file rewrite better than per-chunk request routing? > I agree that this does > mean that the CDN (in this case the uCDN) has rewritten the manifest it > received from the content provider, but that can be a bilateral agreement > where the content provider does not have any problems with rewriting the > manifest. Assuming there was a list of supported manifest formats, manifest file rewrite may need to be fairly content aware, e.g., recognizing spliced content which may not be in the CDN, and not modifing manifests in any way that would upset the client, wrt recognizing newer versions or any proprietary protocol enhancements. Though I don't think that manifest rewrite is a good idea, wrt CDNI, the uCDN should be redirecting in a way that is acceptable to the dCDN. If the parameters of the bilateral agreement have been accepted by the dCDN, and the dCDN has advertised that capability, then I do not see the need to distinguish the actual format of the URL or how it is processed internally by either CDN? > thanx. > > -- Kevin J. Ma > > > The Chunk Request Routing option (we might need to > > choose a better name) on the other hand points to a request routing > > function, which means that there will definitely be a redirect. The RR > > function may either redirect the client to a specific delivery node in > the > > same CDN or to another RR function in another CDN. For better > > understanding of some of the problems that are described later in the > > document, I think it is better to distinguish between these two methods= . > > > > As for your comment that full locators and chunk request routing do not > > require manifest rewriting, I don't understand this. Assuming that > > delivery nodes are 'dumb' and don't know anything about inter-CDN > request > > routing, and that full locators point to a specific delivery node (let'= s > > say on a uCDN), how can the Full Locator in the manifest line not be > > rewritten when the content is now supposed to be delivered by another > CDN? > > > > Although I agree that it is technically feasible to not rewrite Chunk > > Request Routing urls in the manifest, this would mean that for every > chunk > > requested by the client, the uCDN needs to be involved (since it has to > > redirect the client to the dCDN). > > > > Finally, my personal opinion is that we shouldn't classify manifest fil= e > > rewriting as content adaption in the sense that the CDNI WG shouldn't > work > > on it. In other to provide a scalable solution for allowing the CDNI > > interfaces to deliver content using the various HAS protocols, we > > basically have two options: 1) we impose the use of Relative Locators > for > > all content, and therefore limit the flexibility for both CDNs and > Content > > Providers, or 2) we allow manifest file rewriting in some cases. While = I > > agree that some content providers might consider the manifest as > 'content' > > and therefore don't want it to be modified, this can be handled on an > > individual case by using relative locators in those cases. > > > > Best regards, > > > > Ray > > > > > > > > ________________________________________ > > From: Kevin J Ma [kevin.ma@azukisystems.com] > > Sent: Wednesday, March 28, 2012 2:09 AM > > To: Brandenburg, R. (Ray) van; Kent Leung (kleung); > > gilles.bertrand@orange.com; cdni@ietf.org > > Subject: RE: [CDNi] CDNI Requirements for ABR content > > > > Hi Ray, > > > > I think the draft provides a nice description of the options. > > I had a couple of comments: > > > > - The chunk request routing case (section 2.2.3) seems like a > degenerate > > case of full locator. It is a full URL that points to the CDN RR. > > The > > result is an HTTP redirect to either a surrogate or a dCDN RR? > Though > > the format of the URL may be protocol specific, it should not be CD= N > > specific, and so it does not have to be treated any differenly from > > any > > other full locator. Note: skipping ahead to the questions in > section > > 3.2.1, I do not think that manifest files should be modified. At > > least > > in the current phase, I believe content adaptation is off the table= ? > > > > Wrt to the conclusion that full/relative locators require manifest > > file rewrite (in section 3.2.1), I do not see this as the case. In > > the worst case, it just means that delegation is not persistent, > > though that is dependent upon how the client handles redirects... > > > > - One of the reasons behind the metadata grouping requirements was to > > support Chunk Collections and Content Collections. Wrt the > questions > > in section 3.2.1, I think that collections make sense, and that the > > propogation of metadata could synchronize definitions of collection= s > > across CDNs? > > > > thanx. > > > > -- Kevin J. Ma > > > > > -----Original Message----- > > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > Of > > > Brandenburg, R. (Ray) van > > > Sent: Monday, March 26, 2012 11:26 AM > > > To: Kent Leung (kleung); gilles.bertrand@orange.com; cdni@ietf.org > > > Subject: Re: [CDNi] CDNI Requirements for ABR content > > > > > > Hi Gilles/Kent/all, > > > > > > It seems to me that the question we keep getting back to is whether > the > > > CDN is aware of ABR content (and if we want to require a CDN to be > aware > > > of this). This question will probably also come up when discussing > other > > > interfaces (especially metadata and request routing). > > > > > > I therefore suggest that we first discuss the high-level > > > requirements/assumptions regarding ABR/HAS and CDNI, come up with som= e > > > guidelines for how the CDNI interfaces should deal with ABR/HAS, and > > then > > > apply these guidelines to the various interfaces (such as in this cas= e > > the > > > logging interface). > > > > > > I wrote a draft for initiating such a discussion, see > > > http://www.ietf.org/id/draft-brandenburg-cdni-has-00.txt. Comments ar= e > > > welcome. > > > > > > Best regards, > > > > > > Ray > > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] on behalf of Kent > > > Leung (kleung) [kleung@cisco.com] > > > Sent: Monday, March 26, 2012 5:09 PM > > > To: gilles.bertrand@orange.com; cdni@ietf.org > > > Subject: Re: [CDNi] CDNI Requirements for ABR content > > > > > > Hi Gilles. The client has to be ABR-aware to obtain the ABR content. > So > > > the question is only pertinent for the CDN. The methods for CDN to > > > associate delivery of contents for the ABR session are based on cooki= e > > or > > > URI tag (BTW, client just passes this info back to the CDN). Also, CD= N > > > needs to understand the manifest file (for HLS/HDS/HSS) to determine > the > > > abr-protocol, representation, manifest-uri, and content-id. > > > > > > Both Event-Based Logging and Session-Based Logging require CDN to > > > understand the ABR content type. So the implications or impact to the > > CDN > > > is basically the same for either logging mode. For file-based logging= , > > the > > > CDN treats each content delivery as a file and unaware that it is > really > > a > > > segment/chunk/fragment of the whole content. There's no knowledge tha= t > > > there is a manifest file or different representations or when > > > representation changed. > > > > > > I believe the reason for Event-Based Logging as [HIGH] and Session- > Based > > > Logging as [MED] is the expectation that most of the content for the > ABR > > > session will be delivered at a steady rate after the initial > buffering. > > > > > > Does that answer your questions? > > > > > > Kent > > > > > > -----Original Message----- > > > From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com] > > > Sent: Monday, March 26, 2012 1:24 AM > > > To: Kent Leung (kleung); cdni@ietf.org > > > Subject: RE: [CDNi] CDNI Requirements for ABR content > > > > > > Hi Kent, > > > > > > About the tagging as "High" of Event-Based Logging support, I would > like > > > to understand what it implies > > > - for the CDN and > > > - for the client. > > > > > > I see the following differences between Event-Based Logging and "file= - > > > based logging": > > > > > > - Session: I am not an expert of all adaptive streaming flavors; do > > > existing clients provide a usable session id to the server? > > > - other service level information: > > > # Manifest-uri: could the CDN derive it from the session data= ? > > > # Content-id: How could the CDN derive this information: From > the > > > content URL? From the session data? Other? > > > # Representation: How could the CDN derive this information: > From > > > the content URL? From the session data? > > > > > > About the tagging as "Med" of segment based logging, I would also lik= e > > to > > > understand the impact on the CDN/client: > > > - the CDN sees the chunk requests (except the ones served by a > caching- > > > proxy or the browser cache). So I think this logging format is not > more > > > complex than event based logging for the client (it does not have to > > send > > > specific information). For the CDN, the support of this format only > > > requires the additional ability to: > > > - understand the URL formats to detect the representation > > changes > > > - detect session ends? > > > > > > Best regards, > > > > > > Gilles > > > > > > -----Message d'origine----- > > > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part > de > > > Kent Leung (kleung) > > > Envoy=E9 : jeudi 22 mars 2012 17:00 > > > =C0 : cdni@ietf.org > > > Objet : [CDNi] CDNI Requirements for ABR content > > > > > > Tracking requirements from CDNI Interface drafts. Based on the > > discussion > > > for draft-lefaucheur-cdni-logging-delivery, we need some inputs from > the > > > WG on the CDNI Logging requirements. > > > > > > Options for logging requirements for ABR content: > > > > > > 1) Event-Based Logging shall be supported [HIGH], Segment- > Based > > > Logging should be supported [MED], and Summary-Based Logging may be > > > supported [LOW]. > > > > > > Reason: The dCDN needs to be aware of ABR content and should > log > > > delivery with the ABR-related fields. ABR is expected to be a very > > common > > > delivery format and requires some form of log compression over very > > > voluminous per-segment logging. ABR content needs to be supported by > > CDNs. > > > Related requirement is "GEN-14 [HIGH] The CDNI solution shall suppor= t > > > HTTP Adaptive Bit Rate (ABR) content." > > > > > > OR > > > > > > 2) Event-Based Logging, Segment-Based Logging, and Summary- > Based > > > Logging may be supported [LOW]. > > > > > > Reason: Eliminate the need for dCDN to be aware of ABR > content. > > > For example, dCDN is acting in a pure HTTP reverse proxy mode and may > > not > > > be aware of that level of information and/or because the control of > how > > to > > > identify those fields is owned by the CSP and none of CDNs may have > > > visibility of that mapping information. Such a requirement to force > CDNs > > > and CDNI in general to require such mappings seems to be overkill. > > > > > > > > > Thoughts? > > > > > > Kent > > > > > > > > > -----Original Message----- > > > From: Francois Le Faucheur (flefauch) > > > Sent: Tuesday, March 13, 2012 11:39 AM > > > To: Kent Leung (kleung); Niven-Jenkins Ben > > > Cc: Francois Le Faucheur (flefauch); cdni@ietf.org; Mahesh > Viveganandhan > > > (mvittal) > > > Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging- > delivery- > > 00 > > > > > > Ben, Kent, > > > > > > Trying to extract the key points from the thread: > > > > > > 1) level of requirement for support of HTTP Adaptive Streaming Loggin= g > > > Session (ie ABR-aware logs): > > > This is a valid question. > > > The I-D proposes that some form of ABR-aware logging be mandatory. Th= e > > > rationale is that ABR is expected to be a very common delivery format > > and > > > requires some form of log compression over very voluminous per-segmen= t > > > logging. (BTW the I-D currently proposes that both Segment-Based > Logging > > > format and Event-Based Logging format be mandatory. But come to think > of > > > it, having only Event-Based Logging format mandatory would be > sufficient > > > from my viewpoint). > > > Ben argues that ABR-aware logging should not be mandatory as it > requires > > > extra awareness. > > > To get more input, I'd propose we move that requirement level > discussion > > > to the cdni-requirements document, and have the logging I-D only talk= s > > > about what such logs would look like. > > > > > > > > > _______________________________________________ > > > 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 > > > 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 Wed Mar 28 09:24: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 4356B21F8A07 for ; Wed, 28 Mar 2012 09:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.019 X-Spam-Level: X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5 tests=[AWL=0.485, 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 nTAq4BawEK0K for ; Wed, 28 Mar 2012 09:24:22 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id C8C3521F89FD for ; Wed, 28 Mar 2012 09:24:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,662,1325458800"; d="scan'208";a="14907567" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1b.tno.nl with ESMTP; 28 Mar 2012 18:24:18 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.232]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.02.0283.003; Wed, 28 Mar 2012 18:24:18 +0200 From: "Brandenburg, R. (Ray) van" To: Kevin J Ma , "Kent Leung (kleung)" , "gilles.bertrand@orange.com" , "cdni@ietf.org" Thread-Topic: [CDNi] CDNI Requirements for ABR content Thread-Index: AQHNCETi17ClXLSrq0e902XpETmVi5Z8IWcAgABxUYCAACPkYIACFmJwgACISpCAAGWxEIAAHdnMgAAI4QCAAApPrw== Date: Wed, 28 Mar 2012 16:24:17 +0000 Message-ID: References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com><7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1DD4@xmb-sjc-235.amer.cisco.com> <8E09C72DBC577D489F13A71228C0B7BF033E0C52@ftrdmel0.rd.francetelecom.fr>, <7A2D6D1F6AC99243A77D32820D8ABBC20E95C703@xmb-sjc-235.amer.cisco.com> , <291CC3F9E50E7641901A54E85D0977C652608722A8@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C65260872386@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C65260911597@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C65260911597@MAILR002.mail.lan> 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-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] CDNI Requirements for ABR content 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, 28 Mar 2012 16:24:24 -0000 Hi Kevin, see inline=0A= ________________________________________=0A= From: Kevin J Ma [kevin.ma@azukisystems.com]=0A= Sent: Wednesday, March 28, 2012 6:12 PM=0A= To: Brandenburg, R. (Ray) van; Kent Leung (kleung); gilles.bertrand@orange.= com; cdni@ietf.org=0A= Subject: RE: [CDNi] CDNI Requirements for ABR content=0A= =0A= Hi Ray, inline:=0A= =0A= > -----Original Message-----=0A= > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl]=0A= > Sent: Wednesday, March 28, 2012 11:15 AM=0A= > To: Kevin J Ma; Kent Leung (kleung); gilles.bertrand@orange.com;=0A= > cdni@ietf.org=0A= > Subject: RE: [CDNi] CDNI Requirements for ABR content=0A= >=0A= > Hi Kevin, comment inline.=0A= >=0A= > Ray=0A= > ________________________________________=0A= > From: Kevin J Ma [kevin.ma@azukisystems.com]=0A= > Sent: Wednesday, March 28, 2012 3:53 PM=0A= > To: Brandenburg, R. (Ray) van; Kent Leung (kleung);=0A= > gilles.bertrand@orange.com; cdni@ietf.org=0A= > Subject: RE: [CDNi] CDNI Requirements for ABR content=0A= >=0A= > Hi Ray,=0A= >=0A= > comment inline:=0A= >=0A= > > -----Original Message-----=0A= > > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl]=0A= > > Sent: Wednesday, March 28, 2012 3:50 AM=0A= > > To: Kevin J Ma; Kent Leung (kleung); gilles.bertrand@orange.com;=0A= > > cdni@ietf.org=0A= > > Subject: RE: [CDNi] CDNI Requirements for ABR content=0A= > >=0A= > > Hi Kevin,=0A= > >=0A= > > Thanks for your comments.=0A= > >=0A= > > Wrt to your comment that Chunk Request Routing is a degenerate version= =0A= > of=0A= > > a Full Locator: While from a Client point of view the two options are= =0A= > > certainly similar, I think they are actually quite different from a CDN= =0A= > > functional perspective. The Full Locator as I defined it points to a=0A= > > specific file on a specific Delivery Node, which means that the client= =0A= > > will not be redirected.=0A= >=0A= > I see. That specific aspect did not register on first read. So, deliver= y=0A= > node=0A= > in this example refers to a surrogate? In that case, it is not clear to= =0A= > me why=0A= > the manifest would have a URL pointing at a specific delivery node=0A= > (without the=0A= > assumption that the CDN has already modified the manifest)? A content=0A= > provider=0A= > who does not run their own CDN is unlikely to know about surrogates. The= =0A= > URL=0A= > is more likely to be the content providers registered DNS address thats= =0A= > CNAMEd=0A= > to the uCDN which follows the normal request routing flow? In the=0A= > branding use=0A= > case, it is unlikely that the content provider would want URL rewrites?= =0A= >=0A= > [RAY]: One situation where Full Locators are used is in cases where a=0A= > particular CDN wants to divide segments across different delivery nodes= =0A= > (or surrogates using your terminology).=0A= =0A= Was just trying to conform to the problem statement terminology... ;)=0A= =0A= [Ray]: Agree :)=0A= =0A= > For example, for efficiency=0A= > reasons a CDN might want to place a certain subset of the segments on mor= e=0A= > nodes (or different nodes) than all of the other segments. In that case,= =0A= > having Full Locators doesn't require per-chunk request routing, while it= =0A= > is still possible to have this added flexibility.=0A= =0A= For live HLS, e.g., the manifest file is going to change every segment;=0A= is per-chunk manifest file rewrite better than per-chunk request routing?= =0A= =0A= [Ray]: I agree that is questionable. However, for live content, there is us= ually less reason for wanting to distribute the content across different su= rrogates. =0A= =0A= > I agree that this does=0A= > mean that the CDN (in this case the uCDN) has rewritten the manifest it= =0A= > received from the content provider, but that can be a bilateral agreement= =0A= > where the content provider does not have any problems with rewriting the= =0A= > manifest.=0A= =0A= Assuming there was a list of supported manifest formats, manifest file=0A= rewrite may need to be fairly content aware, e.g., recognizing spliced=0A= content which may not be in the CDN, and not modifing manifests in any=0A= way that would upset the client, wrt recognizing newer versions or any=0A= proprietary protocol enhancements. Though I don't think that manifest=0A= rewrite is a good idea, wrt CDNI, the uCDN should be redirecting in a=0A= way that is acceptable to the dCDN. If the parameters of the bilateral=0A= agreement have been accepted by the dCDN, and the dCDN has advertised=0A= that capability, then I do not see the need to distinguish the actual=0A= format of the URL or how it is processed internally by either CDN?=0A= =0A= [Ray]: I think as long as you only change the location of a segment, and us= e common formatting rules, manifest rewriting can actually be a quite simpl= e process. =0A= =0A= You mention that you don't think manifest rewriting is a good idea, which I= can understand. However, do you know a good alternative apart from using R= elative URLs and limiting flexibility or using per-chunk RR which has scala= bility issues?=0A= =0A= Furthermore, apart from request routing, there might be other reasons for w= anting to do manifest rewriting, such as including CDN-specific keys/tokens= . =0A= =0A= The way I see it, manifest rewriting is probably a necessary evil when you = want to do CDN interconnection for HAS content in a scalable manner. =0A= =0A= > thanx.=0A= >=0A= > -- Kevin J. Ma=0A= >=0A= > > The Chunk Request Routing option (we might need to=0A= > > choose a better name) on the other hand points to a request routing=0A= > > function, which means that there will definitely be a redirect. The RR= =0A= > > function may either redirect the client to a specific delivery node in= =0A= > the=0A= > > same CDN or to another RR function in another CDN. For better=0A= > > understanding of some of the problems that are described later in the= =0A= > > document, I think it is better to distinguish between these two methods= .=0A= > >=0A= > > As for your comment that full locators and chunk request routing do not= =0A= > > require manifest rewriting, I don't understand this. Assuming that=0A= > > delivery nodes are 'dumb' and don't know anything about inter-CDN=0A= > request=0A= > > routing, and that full locators point to a specific delivery node (let'= s=0A= > > say on a uCDN), how can the Full Locator in the manifest line not be=0A= > > rewritten when the content is now supposed to be delivered by another= =0A= > CDN?=0A= > >=0A= > > Although I agree that it is technically feasible to not rewrite Chunk= =0A= > > Request Routing urls in the manifest, this would mean that for every=0A= > chunk=0A= > > requested by the client, the uCDN needs to be involved (since it has to= =0A= > > redirect the client to the dCDN).=0A= > >=0A= > > Finally, my personal opinion is that we shouldn't classify manifest fil= e=0A= > > rewriting as content adaption in the sense that the CDNI WG shouldn't= =0A= > work=0A= > > on it. In other to provide a scalable solution for allowing the CDNI=0A= > > interfaces to deliver content using the various HAS protocols, we=0A= > > basically have two options: 1) we impose the use of Relative Locators= =0A= > for=0A= > > all content, and therefore limit the flexibility for both CDNs and=0A= > Content=0A= > > Providers, or 2) we allow manifest file rewriting in some cases. While = I=0A= > > agree that some content providers might consider the manifest as=0A= > 'content'=0A= > > and therefore don't want it to be modified, this can be handled on an= =0A= > > individual case by using relative locators in those cases.=0A= > >=0A= > > Best regards,=0A= > >=0A= > > Ray=0A= > >=0A= > >=0A= > >=0A= > > ________________________________________=0A= > > From: Kevin J Ma [kevin.ma@azukisystems.com]=0A= > > Sent: Wednesday, March 28, 2012 2:09 AM=0A= > > To: Brandenburg, R. (Ray) van; Kent Leung (kleung);=0A= > > gilles.bertrand@orange.com; cdni@ietf.org=0A= > > Subject: RE: [CDNi] CDNI Requirements for ABR content=0A= > >=0A= > > Hi Ray,=0A= > >=0A= > > I think the draft provides a nice description of the options.=0A= > > I had a couple of comments:=0A= > >=0A= > > - The chunk request routing case (section 2.2.3) seems like a=0A= > degenerate=0A= > > case of full locator. It is a full URL that points to the CDN RR.= =0A= > > The=0A= > > result is an HTTP redirect to either a surrogate or a dCDN RR?=0A= > Though=0A= > > the format of the URL may be protocol specific, it should not be CD= N=0A= > > specific, and so it does not have to be treated any differenly from= =0A= > > any=0A= > > other full locator. Note: skipping ahead to the questions in=0A= > section=0A= > > 3.2.1, I do not think that manifest files should be modified. At= =0A= > > least=0A= > > in the current phase, I believe content adaptation is off the table= ?=0A= > >=0A= > > Wrt to the conclusion that full/relative locators require manifest= =0A= > > file rewrite (in section 3.2.1), I do not see this as the case. In= =0A= > > the worst case, it just means that delegation is not persistent,=0A= > > though that is dependent upon how the client handles redirects...= =0A= > >=0A= > > - One of the reasons behind the metadata grouping requirements was to= =0A= > > support Chunk Collections and Content Collections. Wrt the=0A= > questions=0A= > > in section 3.2.1, I think that collections make sense, and that the= =0A= > > propogation of metadata could synchronize definitions of collection= s=0A= > > across CDNs?=0A= > >=0A= > > thanx.=0A= > >=0A= > > -- Kevin J. Ma=0A= > >=0A= > > > -----Original Message-----=0A= > > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf= =0A= > Of=0A= > > > Brandenburg, R. (Ray) van=0A= > > > Sent: Monday, March 26, 2012 11:26 AM=0A= > > > To: Kent Leung (kleung); gilles.bertrand@orange.com; cdni@ietf.org=0A= > > > Subject: Re: [CDNi] CDNI Requirements for ABR content=0A= > > >=0A= > > > Hi Gilles/Kent/all,=0A= > > >=0A= > > > It seems to me that the question we keep getting back to is whether= =0A= > the=0A= > > > CDN is aware of ABR content (and if we want to require a CDN to be=0A= > aware=0A= > > > of this). This question will probably also come up when discussing=0A= > other=0A= > > > interfaces (especially metadata and request routing).=0A= > > >=0A= > > > I therefore suggest that we first discuss the high-level=0A= > > > requirements/assumptions regarding ABR/HAS and CDNI, come up with som= e=0A= > > > guidelines for how the CDNI interfaces should deal with ABR/HAS, and= =0A= > > then=0A= > > > apply these guidelines to the various interfaces (such as in this cas= e=0A= > > the=0A= > > > logging interface).=0A= > > >=0A= > > > I wrote a draft for initiating such a discussion, see=0A= > > > http://www.ietf.org/id/draft-brandenburg-cdni-has-00.txt. Comments ar= e=0A= > > > welcome.=0A= > > >=0A= > > > Best regards,=0A= > > >=0A= > > > Ray=0A= > > >=0A= > > >=0A= > > >=0A= > > >=0A= > > >=0A= > > >=0A= > > > ________________________________________=0A= > > > From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] on behalf of Kent= =0A= > > > Leung (kleung) [kleung@cisco.com]=0A= > > > Sent: Monday, March 26, 2012 5:09 PM=0A= > > > To: gilles.bertrand@orange.com; cdni@ietf.org=0A= > > > Subject: Re: [CDNi] CDNI Requirements for ABR content=0A= > > >=0A= > > > Hi Gilles. The client has to be ABR-aware to obtain the ABR content.= =0A= > So=0A= > > > the question is only pertinent for the CDN. The methods for CDN to=0A= > > > associate delivery of contents for the ABR session are based on cooki= e=0A= > > or=0A= > > > URI tag (BTW, client just passes this info back to the CDN). Also, CD= N=0A= > > > needs to understand the manifest file (for HLS/HDS/HSS) to determine= =0A= > the=0A= > > > abr-protocol, representation, manifest-uri, and content-id.=0A= > > >=0A= > > > Both Event-Based Logging and Session-Based Logging require CDN to=0A= > > > understand the ABR content type. So the implications or impact to the= =0A= > > CDN=0A= > > > is basically the same for either logging mode. For file-based logging= ,=0A= > > the=0A= > > > CDN treats each content delivery as a file and unaware that it is=0A= > really=0A= > > a=0A= > > > segment/chunk/fragment of the whole content. There's no knowledge tha= t=0A= > > > there is a manifest file or different representations or when=0A= > > > representation changed.=0A= > > >=0A= > > > I believe the reason for Event-Based Logging as [HIGH] and Session-= =0A= > Based=0A= > > > Logging as [MED] is the expectation that most of the content for the= =0A= > ABR=0A= > > > session will be delivered at a steady rate after the initial=0A= > buffering.=0A= > > >=0A= > > > Does that answer your questions?=0A= > > >=0A= > > > Kent=0A= > > >=0A= > > > -----Original Message-----=0A= > > > From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com]= =0A= > > > Sent: Monday, March 26, 2012 1:24 AM=0A= > > > To: Kent Leung (kleung); cdni@ietf.org=0A= > > > Subject: RE: [CDNi] CDNI Requirements for ABR content=0A= > > >=0A= > > > Hi Kent,=0A= > > >=0A= > > > About the tagging as "High" of Event-Based Logging support, I would= =0A= > like=0A= > > > to understand what it implies=0A= > > > - for the CDN and=0A= > > > - for the client.=0A= > > >=0A= > > > I see the following differences between Event-Based Logging and "file= -=0A= > > > based logging":=0A= > > >=0A= > > > - Session: I am not an expert of all adaptive streaming flavors; do= =0A= > > > existing clients provide a usable session id to the server?=0A= > > > - other service level information:=0A= > > > # Manifest-uri: could the CDN derive it from the session data= ?=0A= > > > # Content-id: How could the CDN derive this information: From= =0A= > the=0A= > > > content URL? From the session data? Other?=0A= > > > # Representation: How could the CDN derive this information:=0A= > From=0A= > > > the content URL? From the session data?=0A= > > >=0A= > > > About the tagging as "Med" of segment based logging, I would also lik= e=0A= > > to=0A= > > > understand the impact on the CDN/client:=0A= > > > - the CDN sees the chunk requests (except the ones served by a=0A= > caching-=0A= > > > proxy or the browser cache). So I think this logging format is not=0A= > more=0A= > > > complex than event based logging for the client (it does not have to= =0A= > > send=0A= > > > specific information). For the CDN, the support of this format only= =0A= > > > requires the additional ability to:=0A= > > > - understand the URL formats to detect the representation=0A= > > changes=0A= > > > - detect session ends?=0A= > > >=0A= > > > Best regards,=0A= > > >=0A= > > > Gilles=0A= > > >=0A= > > > -----Message d'origine-----=0A= > > > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part= =0A= > de=0A= > > > Kent Leung (kleung)=0A= > > > Envoy=E9 : jeudi 22 mars 2012 17:00=0A= > > > =C0 : cdni@ietf.org=0A= > > > Objet : [CDNi] CDNI Requirements for ABR content=0A= > > >=0A= > > > Tracking requirements from CDNI Interface drafts. Based on the=0A= > > discussion=0A= > > > for draft-lefaucheur-cdni-logging-delivery, we need some inputs from= =0A= > the=0A= > > > WG on the CDNI Logging requirements.=0A= > > >=0A= > > > Options for logging requirements for ABR content:=0A= > > >=0A= > > > 1) Event-Based Logging shall be supported [HIGH], Segment-=0A= > Based=0A= > > > Logging should be supported [MED], and Summary-Based Logging may be= =0A= > > > supported [LOW].=0A= > > >=0A= > > > Reason: The dCDN needs to be aware of ABR content and should= =0A= > log=0A= > > > delivery with the ABR-related fields. ABR is expected to be a very=0A= > > common=0A= > > > delivery format and requires some form of log compression over very= =0A= > > > voluminous per-segment logging. ABR content needs to be supported by= =0A= > > CDNs.=0A= > > > Related requirement is "GEN-14 [HIGH] The CDNI solution shall suppor= t=0A= > > > HTTP Adaptive Bit Rate (ABR) content."=0A= > > >=0A= > > > OR=0A= > > >=0A= > > > 2) Event-Based Logging, Segment-Based Logging, and Summary-= =0A= > Based=0A= > > > Logging may be supported [LOW].=0A= > > >=0A= > > > Reason: Eliminate the need for dCDN to be aware of ABR=0A= > content.=0A= > > > For example, dCDN is acting in a pure HTTP reverse proxy mode and may= =0A= > > not=0A= > > > be aware of that level of information and/or because the control of= =0A= > how=0A= > > to=0A= > > > identify those fields is owned by the CSP and none of CDNs may have= =0A= > > > visibility of that mapping information. Such a requirement to force= =0A= > CDNs=0A= > > > and CDNI in general to require such mappings seems to be overkill.=0A= > > >=0A= > > >=0A= > > > Thoughts?=0A= > > >=0A= > > > Kent=0A= > > >=0A= > > >=0A= > > > -----Original Message-----=0A= > > > From: Francois Le Faucheur (flefauch)=0A= > > > Sent: Tuesday, March 13, 2012 11:39 AM=0A= > > > To: Kent Leung (kleung); Niven-Jenkins Ben=0A= > > > Cc: Francois Le Faucheur (flefauch); cdni@ietf.org; Mahesh=0A= > Viveganandhan=0A= > > > (mvittal)=0A= > > > Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-=0A= > delivery-=0A= > > 00=0A= > > >=0A= > > > Ben, Kent,=0A= > > >=0A= > > > Trying to extract the key points from the thread:=0A= > > >=0A= > > > 1) level of requirement for support of HTTP Adaptive Streaming Loggin= g=0A= > > > Session (ie ABR-aware logs):=0A= > > > This is a valid question.=0A= > > > The I-D proposes that some form of ABR-aware logging be mandatory. Th= e=0A= > > > rationale is that ABR is expected to be a very common delivery format= =0A= > > and=0A= > > > requires some form of log compression over very voluminous per-segmen= t=0A= > > > logging. (BTW the I-D currently proposes that both Segment-Based=0A= > Logging=0A= > > > format and Event-Based Logging format be mandatory. But come to think= =0A= > of=0A= > > > it, having only Event-Based Logging format mandatory would be=0A= > sufficient=0A= > > > from my viewpoint).=0A= > > > Ben argues that ABR-aware logging should not be mandatory as it=0A= > requires=0A= > > > extra awareness.=0A= > > > To get more input, I'd propose we move that requirement level=0A= > discussion=0A= > > > to the cdni-requirements document, and have the logging I-D only talk= s=0A= > > > about what such logs would look like.=0A= > > > =0A= > > >=0A= > > > _______________________________________________=0A= > > > CDNi mailing list=0A= > > > CDNi@ietf.org=0A= > > > https://www.ietf.org/mailman/listinfo/cdni=0A= > > > _______________________________________________=0A= > > > CDNi mailing list=0A= > > > CDNi@ietf.org=0A= > > > https://www.ietf.org/mailman/listinfo/cdni=0A= > > > This e-mail and its contents are subject to the DISCLAIMER at=0A= > > > http://www.tno.nl/emaildisclaimer=0A= > > >=0A= > > > _______________________________________________=0A= > > > CDNi mailing list=0A= > > > CDNi@ietf.org=0A= > > > https://www.ietf.org/mailman/listinfo/cdni=0A= From kevin.ma@azukisystems.com Wed Mar 28 10:01:55 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 E033F21E82C0 for ; Wed, 28 Mar 2012 10:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 yKxEQ242gyVG for ; Wed, 28 Mar 2012 10:01:54 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id E38E821E82BF for ; Wed, 28 Mar 2012 10:01:53 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 5F6298BE889; Wed, 28 Mar 2012 13:01:53 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.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 9751E8BE61D; Wed, 28 Mar 2012 12:56:53 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Wed, 28 Mar 2012 12:56:45 -0400 From: Kevin J Ma To: "Brandenburg, R. (Ray) van" , "Kent Leung (kleung)" , "gilles.bertrand@orange.com" , "cdni@ietf.org" Date: Wed, 28 Mar 2012 12:56:51 -0400 Thread-Topic: [CDNi] CDNI Requirements for ABR content Thread-Index: AQHNCETi17ClXLSrq0e902XpETmVi5Z8IWcAgABxUYCAACPkYIACFmJwgACISpCAAGWxEIAAHdnMgAAI4QCAAApPr4AAB3yw Message-ID: <291CC3F9E50E7641901A54E85D0977C652609115DE@MAILR002.mail.lan> References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com><7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E8D1DD4@xmb-sjc-235.amer.cisco.com> <8E09C72DBC577D489F13A71228C0B7BF033E0C52@ftrdmel0.rd.francetelecom.fr>, <7A2D6D1F6AC99243A77D32820D8ABBC20E95C703@xmb-sjc-235.amer.cisco.com> , <291CC3F9E50E7641901A54E85D0977C652608722A8@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C65260872386@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C65260911597@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] CDNI Requirements for ABR content 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, 28 Mar 2012 17:01:56 -0000 Hi Ray, I agree that manifest rewrite is a powerful tool. My concern is that, as with other types of content adaptation, there are complexities involved which the wg may or may not want to tackle at this time, and that if it is largely an intra-CDN operation, then it would be out of scope for CDNI? Though, I look forward to hearing other opinions... thanx! -- Kevin J. Ma > -----Original Message----- > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > Sent: Wednesday, March 28, 2012 12:24 PM > To: Kevin J Ma; Kent Leung (kleung); gilles.bertrand@orange.com; > cdni@ietf.org > Subject: RE: [CDNi] CDNI Requirements for ABR content > > Hi Kevin, see inline > ________________________________________ > From: Kevin J Ma [kevin.ma@azukisystems.com] > Sent: Wednesday, March 28, 2012 6:12 PM > To: Brandenburg, R. (Ray) van; Kent Leung (kleung); > gilles.bertrand@orange.com; cdni@ietf.org > Subject: RE: [CDNi] CDNI Requirements for ABR content > > Hi Ray, inline: > > > -----Original Message----- > > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > > Sent: Wednesday, March 28, 2012 11:15 AM > > To: Kevin J Ma; Kent Leung (kleung); gilles.bertrand@orange.com; > > cdni@ietf.org > > Subject: RE: [CDNi] CDNI Requirements for ABR content > > > > Hi Kevin, comment inline. > > > > Ray > > ________________________________________ > > From: Kevin J Ma [kevin.ma@azukisystems.com] > > Sent: Wednesday, March 28, 2012 3:53 PM > > To: Brandenburg, R. (Ray) van; Kent Leung (kleung); > > gilles.bertrand@orange.com; cdni@ietf.org > > Subject: RE: [CDNi] CDNI Requirements for ABR content > > > > Hi Ray, > > > > comment inline: > > > > > -----Original Message----- > > > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > > > Sent: Wednesday, March 28, 2012 3:50 AM > > > To: Kevin J Ma; Kent Leung (kleung); gilles.bertrand@orange.com; > > > cdni@ietf.org > > > Subject: RE: [CDNi] CDNI Requirements for ABR content > > > > > > Hi Kevin, > > > > > > Thanks for your comments. > > > > > > Wrt to your comment that Chunk Request Routing is a degenerate versio= n > > of > > > a Full Locator: While from a Client point of view the two options are > > > certainly similar, I think they are actually quite different from a > CDN > > > functional perspective. The Full Locator as I defined it points to a > > > specific file on a specific Delivery Node, which means that the clien= t > > > will not be redirected. > > > > I see. That specific aspect did not register on first read. So, > delivery > > node > > in this example refers to a surrogate? In that case, it is not clear t= o > > me why > > the manifest would have a URL pointing at a specific delivery node > > (without the > > assumption that the CDN has already modified the manifest)? A content > > provider > > who does not run their own CDN is unlikely to know about surrogates. > The > > URL > > is more likely to be the content providers registered DNS address thats > > CNAMEd > > to the uCDN which follows the normal request routing flow? In the > > branding use > > case, it is unlikely that the content provider would want URL rewrites? > > > > [RAY]: One situation where Full Locators are used is in cases where a > > particular CDN wants to divide segments across different delivery nodes > > (or surrogates using your terminology). > > Was just trying to conform to the problem statement terminology... ;) > > [Ray]: Agree :) > > > For example, for efficiency > > reasons a CDN might want to place a certain subset of the segments on > more > > nodes (or different nodes) than all of the other segments. In that case= , > > having Full Locators doesn't require per-chunk request routing, while i= t > > is still possible to have this added flexibility. > > For live HLS, e.g., the manifest file is going to change every segment; > is per-chunk manifest file rewrite better than per-chunk request routing? > > [Ray]: I agree that is questionable. However, for live content, there is > usually less reason for wanting to distribute the content across differen= t > surrogates. > > > I agree that this does > > mean that the CDN (in this case the uCDN) has rewritten the manifest it > > received from the content provider, but that can be a bilateral > agreement > > where the content provider does not have any problems with rewriting th= e > > manifest. > > Assuming there was a list of supported manifest formats, manifest file > rewrite may need to be fairly content aware, e.g., recognizing spliced > content which may not be in the CDN, and not modifing manifests in any > way that would upset the client, wrt recognizing newer versions or any > proprietary protocol enhancements. Though I don't think that manifest > rewrite is a good idea, wrt CDNI, the uCDN should be redirecting in a > way that is acceptable to the dCDN. If the parameters of the bilateral > agreement have been accepted by the dCDN, and the dCDN has advertised > that capability, then I do not see the need to distinguish the actual > format of the URL or how it is processed internally by either CDN? > > [Ray]: I think as long as you only change the location of a segment, and > use common formatting rules, manifest rewriting can actually be a quite > simple process. > > You mention that you don't think manifest rewriting is a good idea, which > I can understand. However, do you know a good alternative apart from usin= g > Relative URLs and limiting flexibility or using per-chunk RR which has > scalability issues? > > Furthermore, apart from request routing, there might be other reasons for > wanting to do manifest rewriting, such as including CDN-specific > keys/tokens. > > The way I see it, manifest rewriting is probably a necessary evil when yo= u > want to do CDN interconnection for HAS content in a scalable manner. > > > thanx. > > > > -- Kevin J. Ma > > > > > The Chunk Request Routing option (we might need to > > > choose a better name) on the other hand points to a request routing > > > function, which means that there will definitely be a redirect. The R= R > > > function may either redirect the client to a specific delivery node i= n > > the > > > same CDN or to another RR function in another CDN. For better > > > understanding of some of the problems that are described later in the > > > document, I think it is better to distinguish between these two > methods. > > > > > > As for your comment that full locators and chunk request routing do > not > > > require manifest rewriting, I don't understand this. Assuming that > > > delivery nodes are 'dumb' and don't know anything about inter-CDN > > request > > > routing, and that full locators point to a specific delivery node > (let's > > > say on a uCDN), how can the Full Locator in the manifest line not be > > > rewritten when the content is now supposed to be delivered by another > > CDN? > > > > > > Although I agree that it is technically feasible to not rewrite Chunk > > > Request Routing urls in the manifest, this would mean that for every > > chunk > > > requested by the client, the uCDN needs to be involved (since it has > to > > > redirect the client to the dCDN). > > > > > > Finally, my personal opinion is that we shouldn't classify manifest > file > > > rewriting as content adaption in the sense that the CDNI WG shouldn't > > work > > > on it. In other to provide a scalable solution for allowing the CDNI > > > interfaces to deliver content using the various HAS protocols, we > > > basically have two options: 1) we impose the use of Relative Locators > > for > > > all content, and therefore limit the flexibility for both CDNs and > > Content > > > Providers, or 2) we allow manifest file rewriting in some cases. Whil= e > I > > > agree that some content providers might consider the manifest as > > 'content' > > > and therefore don't want it to be modified, this can be handled on an > > > individual case by using relative locators in those cases. > > > > > > Best regards, > > > > > > Ray > > > > > > > > > > > > ________________________________________ > > > From: Kevin J Ma [kevin.ma@azukisystems.com] > > > Sent: Wednesday, March 28, 2012 2:09 AM > > > To: Brandenburg, R. (Ray) van; Kent Leung (kleung); > > > gilles.bertrand@orange.com; cdni@ietf.org > > > Subject: RE: [CDNi] CDNI Requirements for ABR content > > > > > > Hi Ray, > > > > > > I think the draft provides a nice description of the options. > > > I had a couple of comments: > > > > > > - The chunk request routing case (section 2.2.3) seems like a > > degenerate > > > case of full locator. It is a full URL that points to the CDN RR= . > > > The > > > result is an HTTP redirect to either a surrogate or a dCDN RR? > > Though > > > the format of the URL may be protocol specific, it should not be > CDN > > > specific, and so it does not have to be treated any differenly > from > > > any > > > other full locator. Note: skipping ahead to the questions in > > section > > > 3.2.1, I do not think that manifest files should be modified. At > > > least > > > in the current phase, I believe content adaptation is off the > table? > > > > > > Wrt to the conclusion that full/relative locators require manifes= t > > > file rewrite (in section 3.2.1), I do not see this as the case. > In > > > the worst case, it just means that delegation is not persistent, > > > though that is dependent upon how the client handles redirects... > > > > > > - One of the reasons behind the metadata grouping requirements was > to > > > support Chunk Collections and Content Collections. Wrt the > > questions > > > in section 3.2.1, I think that collections make sense, and that > the > > > propogation of metadata could synchronize definitions of > collections > > > across CDNs? > > > > > > thanx. > > > > > > -- Kevin J. Ma > > > > > > > -----Original Message----- > > > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behal= f > > Of > > > > Brandenburg, R. (Ray) van > > > > Sent: Monday, March 26, 2012 11:26 AM > > > > To: Kent Leung (kleung); gilles.bertrand@orange.com; cdni@ietf.org > > > > Subject: Re: [CDNi] CDNI Requirements for ABR content > > > > > > > > Hi Gilles/Kent/all, > > > > > > > > It seems to me that the question we keep getting back to is whether > > the > > > > CDN is aware of ABR content (and if we want to require a CDN to be > > aware > > > > of this). This question will probably also come up when discussing > > other > > > > interfaces (especially metadata and request routing). > > > > > > > > I therefore suggest that we first discuss the high-level > > > > requirements/assumptions regarding ABR/HAS and CDNI, come up with > some > > > > guidelines for how the CDNI interfaces should deal with ABR/HAS, an= d > > > then > > > > apply these guidelines to the various interfaces (such as in this > case > > > the > > > > logging interface). > > > > > > > > I wrote a draft for initiating such a discussion, see > > > > http://www.ietf.org/id/draft-brandenburg-cdni-has-00.txt. Comments > are > > > > welcome. > > > > > > > > Best regards, > > > > > > > > Ray > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] on behalf of > Kent > > > > Leung (kleung) [kleung@cisco.com] > > > > Sent: Monday, March 26, 2012 5:09 PM > > > > To: gilles.bertrand@orange.com; cdni@ietf.org > > > > Subject: Re: [CDNi] CDNI Requirements for ABR content > > > > > > > > Hi Gilles. The client has to be ABR-aware to obtain the ABR content= . > > So > > > > the question is only pertinent for the CDN. The methods for CDN to > > > > associate delivery of contents for the ABR session are based on > cookie > > > or > > > > URI tag (BTW, client just passes this info back to the CDN). Also, > CDN > > > > needs to understand the manifest file (for HLS/HDS/HSS) to determin= e > > the > > > > abr-protocol, representation, manifest-uri, and content-id. > > > > > > > > Both Event-Based Logging and Session-Based Logging require CDN to > > > > understand the ABR content type. So the implications or impact to > the > > > CDN > > > > is basically the same for either logging mode. For file-based > logging, > > > the > > > > CDN treats each content delivery as a file and unaware that it is > > really > > > a > > > > segment/chunk/fragment of the whole content. There's no knowledge > that > > > > there is a manifest file or different representations or when > > > > representation changed. > > > > > > > > I believe the reason for Event-Based Logging as [HIGH] and Session- > > Based > > > > Logging as [MED] is the expectation that most of the content for th= e > > ABR > > > > session will be delivered at a steady rate after the initial > > buffering. > > > > > > > > Does that answer your questions? > > > > > > > > Kent > > > > > > > > -----Original Message----- > > > > From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com= ] > > > > Sent: Monday, March 26, 2012 1:24 AM > > > > To: Kent Leung (kleung); cdni@ietf.org > > > > Subject: RE: [CDNi] CDNI Requirements for ABR content > > > > > > > > Hi Kent, > > > > > > > > About the tagging as "High" of Event-Based Logging support, I would > > like > > > > to understand what it implies > > > > - for the CDN and > > > > - for the client. > > > > > > > > I see the following differences between Event-Based Logging and > "file- > > > > based logging": > > > > > > > > - Session: I am not an expert of all adaptive streaming flavors; do > > > > existing clients provide a usable session id to the server? > > > > - other service level information: > > > > # Manifest-uri: could the CDN derive it from the session > data? > > > > # Content-id: How could the CDN derive this information: From > > the > > > > content URL? From the session data? Other? > > > > # Representation: How could the CDN derive this information: > > From > > > > the content URL? From the session data? > > > > > > > > About the tagging as "Med" of segment based logging, I would also > like > > > to > > > > understand the impact on the CDN/client: > > > > - the CDN sees the chunk requests (except the ones served by a > > caching- > > > > proxy or the browser cache). So I think this logging format is not > > more > > > > complex than event based logging for the client (it does not have t= o > > > send > > > > specific information). For the CDN, the support of this format only > > > > requires the additional ability to: > > > > - understand the URL formats to detect the representation > > > changes > > > > - detect session ends? > > > > > > > > Best regards, > > > > > > > > Gilles > > > > > > > > -----Message d'origine----- > > > > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la par= t > > de > > > > Kent Leung (kleung) > > > > Envoy=E9 : jeudi 22 mars 2012 17:00 > > > > =C0 : cdni@ietf.org > > > > Objet : [CDNi] CDNI Requirements for ABR content > > > > > > > > Tracking requirements from CDNI Interface drafts. Based on the > > > discussion > > > > for draft-lefaucheur-cdni-logging-delivery, we need some inputs fro= m > > the > > > > WG on the CDNI Logging requirements. > > > > > > > > Options for logging requirements for ABR content: > > > > > > > > 1) Event-Based Logging shall be supported [HIGH], Segment- > > Based > > > > Logging should be supported [MED], and Summary-Based Logging may be > > > > supported [LOW]. > > > > > > > > Reason: The dCDN needs to be aware of ABR content and shoul= d > > log > > > > delivery with the ABR-related fields. ABR is expected to be a very > > > common > > > > delivery format and requires some form of log compression over very > > > > voluminous per-segment logging. ABR content needs to be supported b= y > > > CDNs. > > > > Related requirement is "GEN-14 [HIGH] The CDNI solution shall > support > > > > HTTP Adaptive Bit Rate (ABR) content." > > > > > > > > OR > > > > > > > > 2) Event-Based Logging, Segment-Based Logging, and Summary- > > Based > > > > Logging may be supported [LOW]. > > > > > > > > Reason: Eliminate the need for dCDN to be aware of ABR > > content. > > > > For example, dCDN is acting in a pure HTTP reverse proxy mode and > may > > > not > > > > be aware of that level of information and/or because the control of > > how > > > to > > > > identify those fields is owned by the CSP and none of CDNs may have > > > > visibility of that mapping information. Such a requirement to force > > CDNs > > > > and CDNI in general to require such mappings seems to be overkill. > > > > > > > > > > > > Thoughts? > > > > > > > > Kent > > > > > > > > > > > > -----Original Message----- > > > > From: Francois Le Faucheur (flefauch) > > > > Sent: Tuesday, March 13, 2012 11:39 AM > > > > To: Kent Leung (kleung); Niven-Jenkins Ben > > > > Cc: Francois Le Faucheur (flefauch); cdni@ietf.org; Mahesh > > Viveganandhan > > > > (mvittal) > > > > Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging- > > delivery- > > > 00 > > > > > > > > Ben, Kent, > > > > > > > > Trying to extract the key points from the thread: > > > > > > > > 1) level of requirement for support of HTTP Adaptive Streaming > Logging > > > > Session (ie ABR-aware logs): > > > > This is a valid question. > > > > The I-D proposes that some form of ABR-aware logging be mandatory. > The > > > > rationale is that ABR is expected to be a very common delivery > format > > > and > > > > requires some form of log compression over very voluminous per- > segment > > > > logging. (BTW the I-D currently proposes that both Segment-Based > > Logging > > > > format and Event-Based Logging format be mandatory. But come to > think > > of > > > > it, having only Event-Based Logging format mandatory would be > > sufficient > > > > from my viewpoint). > > > > Ben argues that ABR-aware logging should not be mandatory as it > > requires > > > > extra awareness. > > > > To get more input, I'd propose we move that requirement level > > discussion > > > > to the cdni-requirements document, and have the logging I-D only > talks > > > > about what such logs would look like. > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > 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 flefauch@cisco.com Thu Mar 29 00:59:55 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 B0ACC21F8971 for ; Thu, 29 Mar 2012 00:59:55 -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 98NARymc1FlS for ; Thu, 29 Mar 2012 00:59:55 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id EDC8F21F895B for ; Thu, 29 Mar 2012 00:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=2; q=dns/txt; s=iport; t=1333007995; x=1334217595; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=; b=DsR1cxiKnrZc2b2RNFShDwppnht4yh7jbrhqdPMtwgKs3mLOCLkHjcDh vUP2uuoexQBb+8Mqt899VjgUoMnuu40fEUpJFWod82mfY1MUA8ugljqxP NzCr1ob7JyrAflLXjt8K2KO59RyA3l3T2I/ST8Y16eFyJHrKWX+38IGTP 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0GAHcVdE+rRDoG/2dsb2JhbABFiAGxCYEHggUdAQYhgjKFJgeCKRGaLIEnnxaNe4JBYwSVYY5FgWiCaQ X-IronPort-AV: E=Sophos;i="4.73,665,1325462400"; d="scan'208";a="35583118" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 29 Mar 2012 07:59:54 +0000 Received: from sjc-vpn5-65.cisco.com (sjc-vpn5-65.cisco.com [10.21.88.65]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2T7xr6Y000718 for ; Thu, 29 Mar 2012 07:59:54 GMT From: Francois Le Faucheur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 29 Mar 2012 10:00:18 +0200 Message-Id: <49741049-F834-42D5-B0A7-1C508C8E5CED@cisco.com> To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [CDNi] CDNI WG - Volunteers for note taking? please contact the chairs offline 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, 29 Mar 2012 07:59:55 -0000 From richard_woundy@cable.comcast.com Thu Mar 29 01:43: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 14BD721F88EB for ; Thu, 29 Mar 2012 01:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.763 X-Spam-Level: X-Spam-Status: No, score=-101.763 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 ovL6ClC505J1 for ; Thu, 29 Mar 2012 01:43:10 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id DB0EE21F88D8 for ; Thu, 29 Mar 2012 01:43:09 -0700 (PDT) Received: from ([24.40.56.116]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.7532012; Thu, 29 Mar 2012 04:36:57 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Thu, 29 Mar 2012 04:43:13 -0400 From: "Woundy, Richard" To: "cdni@ietf.org" Thread-Topic: CDNI session details for IETF 83 Thread-Index: AQHNDYf1ydZjCd6DOkmpnp2xiqxgOw== Date: Thu, 29 Mar 2012 08:43:04 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.70] Content-Type: multipart/alternative; boundary="_000_CB99E2253AFARichardWoundycablecomcastcom_" MIME-Version: 1.0 Subject: [CDNi] CDNI session details for IETF 83 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:43:11 -0000 --_000_CB99E2253AFARichardWoundycablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, We will meet on Thursday March 29 from 1300-1500 local time in room 252B, a= nd on Friday March 30 from 0900-1100 local time in room 242AB. We are using WebEx to support remote participation. You can find the links = to join the WebEx sessions here: http://www.ietf.org/meeting/83/remote-part= icipation.html#webex. The slides for the CDNI session at IETF 83 can be found here: https://datat= racker.ietf.org/meeting/83/materials.html#wg-cdni. We are likely to cover Rob Murray's draft on CDNI Triggers on Thursday inst= ead of Friday. We still need to upload two more slide decks for Friday's session. -- Rich --_000_CB99E2253AFARichardWoundycablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Folks,
We will meet on Thursday March 29 from 1300-1500 local time in room 25= 2B, and on Friday March 30 from 0900-1100 local time in room 242AB.

We are using WebEx to support remote participation. You can find the l= inks to join the WebEx sessions here: http://www.ietf.org/meeting/83/r= emote-participation.html#webex.

The slides for the CDNI session at IETF 83 can be found here: h= ttps://datatracker.ietf.org/meeting/83/materials.html#wg-cdni.

We are likely to cover Rob Murray's draft on CDNI Triggers on Thursday= instead of Friday.

We still need to upload two more slide decks for Friday's session.

-- Rich
 --_000_CB99E2253AFARichardWoundycablecomcastcom_-- From dan-ietf@danyork.org Thu Mar 29 05:45: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 E480A21F8B05 for ; Thu, 29 Mar 2012 05:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 AO0-yKXM0Jqp for ; Thu, 29 Mar 2012 05:45:45 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC3C721F8AC2 for ; Thu, 29 Mar 2012 05:45:42 -0700 (PDT) Received: by obbta17 with SMTP id ta17so595501obb.31 for ; Thu, 29 Mar 2012 05:45:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=cf9/9xRwl8tWPJIm2PEYIUAOkYoNTgZORpCbvu3XTT4=; b=GaNcvs3Sdb33F+G9ta4hxCKu8Antd7yagD1prew8xq+c8XyB0n4JuvU2e4Z51917kA m8rNVVfnYOZq1+eytIzut2kv8L4YUrWWIyn/QT5zQ8KLZAQkzEs4TIwNJkUnpli8d84O ZXNQMQwTWbfTl0tj/YE9HeCYTALP8ZQJUvdugMB3GupjwRZ+xbiPmfSwljGNUqj5u61m PIqjmIINCYhfBvY/tAHelAbKFWjfp7dYzzMu+mqC957SypW9nwB8cs0KfLwKnv8ct0W2 GRO9EOZUL42VOwrn5XoIU2kclgGHqlriSo87CWghUOo4m1gOFpfMP/WXMhDDYTQpt12A +8Gw== MIME-Version: 1.0 Received: by 10.182.154.7 with SMTP id vk7mr9834323obb.22.1333025142416; Thu, 29 Mar 2012 05:45:42 -0700 (PDT) Received: by 10.182.67.70 with HTTP; Thu, 29 Mar 2012 05:45:42 -0700 (PDT) X-Originating-IP: [2001:df8:0:16:10c5:2a03:88d2:6334] Date: Thu, 29 Mar 2012 14:45:42 +0200 Message-ID: From: Dan York To: CDNi@ietf.org Content-Type: multipart/alternative; boundary=f46d04479fdd1725ef04bc611a47 X-Gm-Message-State: ALoCoQnMssNnLHtIC4JPdREMLvT5UMkCmGvSIO6C8KGiffZ/51fpbB9iMjdoZEUhuItT0otl6oIm Subject: [CDNi] Comment on draft-brandenburg-cdni-has-00 - should use RFC2606 example domain names 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, 29 Mar 2012 12:45:48 -0000 --f46d04479fdd1725ef04bc611a47 Content-Type: text/plain; charset=ISO-8859-1 I noted in looking at the slides today at the CDNi meeting and in reading the draft that it is using "cdn.com" in examples. While I appreciate the desire for nice short addresses in examples, the reality is that "cdn.com" is a real website. I would suggest the authors consider using *.example.* per RFC 2606 ( http://tools.ietf.org/html/rfc2606 ). Example: http://deliverynode.server.example.com/content_1/segments/segment1_1.ts That does make the URL longer, but it would no longer conflict with a real web site. Dan -- Dan York, dan-ietf@danyork.org http://danyork.me http://twitter.com/danyork --f46d04479fdd1725ef04bc611a47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I noted in looking at the slides today at the CDNi meeting and in reading t= he draft that it is using "cdn.com"= ; in examples. =A0While I appreciate the desire for nice short addresses in= examples, the reality is that "cdn.com= " is a real website. =A0I would suggest the authors consider using *.e= xample.* per RFC 2606 (=A0ht= tp://tools.ietf.org/html/rfc2606 ). Example:


That does make= the URL longer,=A0but it would no longer conflict with a real web site.

Dan

--
--f46d04479fdd1725ef04bc611a47-- From Jan.Seedorf@neclab.eu Thu Mar 29 05:51: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 390A021F89F6 for ; Thu, 29 Mar 2012 05:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 5JaBAiQpHQfG for ; Thu, 29 Mar 2012 05:51:22 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 168DA21F89E5 for ; Thu, 29 Mar 2012 05:51:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 6B7B410070D; Thu, 29 Mar 2012 14:51:57 +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 0MizOO6WyeXr; Thu, 29 Mar 2012 14:51:57 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 4FF751006E0; Thu, 29 Mar 2012 14:51:47 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.36]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Thu, 29 Mar 2012 14:50:51 +0200 From: Jan Seedorf To: Dan York , "CDNi@ietf.org" Thread-Topic: [CDNi] Comment on draft-brandenburg-cdni-has-00 - should use RFC2606 example domain names Thread-Index: AQHNDaoNGd8P4IkviEq48gdslmR/1ZaBOVew Date: Thu, 29 Mar 2012 12:50:49 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24F52BC0@Polydeuces.office.hd> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.196] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Comment on draft-brandenburg-cdni-has-00 - should use RFC2606 example domain names 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, 29 Mar 2012 12:51:27 -0000 Thanks Dan, indeed a good comment, I will check the drafts I am (co-)author= ing Jan > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Dan York > Sent: Thursday, March 29, 2012 2:46 PM > To: CDNi@ietf.org > Subject: [CDNi] Comment on draft-brandenburg-cdni-has-00 - should use > RFC2606 example domain names >=20 > I noted in looking at the slides today at the CDNi meeting and in reading= the > draft that it is using "cdn.com" in examples. While I appreciate the des= ire for > nice short addresses in examples, the reality is that "cdn.com" is a real > website. I would suggest the authors consider using *.example.* per RFC > 2606 ( http://tools.ietf.org/html/rfc2606 ). Example: >=20 > http://deliverynode.server.example.com/content_1/segments/segment1_1 > .ts >=20 > That does make the URL longer, but it would no longer conflict with a rea= l > web site. >=20 > Dan >=20 > -- > Dan York, dan-ietf@danyork.org > http://danyork.me http://twitter.com/danyork From richard_woundy@cable.comcast.com Thu Mar 29 06:55: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 8550521F8B9E for ; Thu, 29 Mar 2012 06:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.696 X-Spam-Level: X-Spam-Status: No, score=-101.696 tagged_above=-999 required=5 tests=[AWL=-0.799, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, 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 0pNgibfk3p9Y for ; Thu, 29 Mar 2012 06:55:58 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 448C721F8B99 for ; Thu, 29 Mar 2012 06:55:57 -0700 (PDT) Received: from ([24.40.56.116]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.7550465; Thu, 29 Mar 2012 09:49:42 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Thu, 29 Mar 2012 09:55:47 -0400 From: "Woundy, Richard" Thread-Topic: [CDNi] Comment on draft-brandenburg-cdni-has-00 - should use RFC2606 example domain names Thread-Index: AQHNDan2JQv3vYskzke3h427I2dzTpaBfNuA///PC+s= Date: Thu, 29 Mar 2012 13:55:37 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD131A127DD@PACDCEXMB05.cable.comcast.com> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE24F52BC0@Polydeuces.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.174] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: "'jan.seedorf@neclab.eu'" , "'dan-ietf@danyork.org'" , "'cdni@ietf.org'" Subject: Re: [CDNi] Comment on draft-brandenburg-cdni-has-00 - should use RFC2606 example domain names 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, 29 Mar 2012 13:55:59 -0000 +1. We should do this for all our cdni drafts. ----- Original Message ----- From: Jan Seedorf [mailto:Jan.Seedorf@neclab.eu] Sent: Thursday, March 29, 2012 08:50 AM=0A= To: Dan York ; CDNi@ietf.org Subject: Re: [CDNi] Comment on draft-brandenburg-cdni-has-00 - should use R= FC2606 example domain names Thanks Dan, indeed a good comment, I will check the drafts I am (co-)author= ing Jan > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Dan York > Sent: Thursday, March 29, 2012 2:46 PM > To: CDNi@ietf.org > Subject: [CDNi] Comment on draft-brandenburg-cdni-has-00 - should use > RFC2606 example domain names >=20 > I noted in looking at the slides today at the CDNi meeting and in reading= the > draft that it is using "cdn.com" in examples. While I appreciate the des= ire for > nice short addresses in examples, the reality is that "cdn.com" is a real > website. I would suggest the authors consider using *.example.* per RFC > 2606 ( http://tools.ietf.org/html/rfc2606 ). Example: >=20 > http://deliverynode.server.example.com/content_1/segments/segment1_1 > .ts >=20 > That does make the URL longer, but it would no longer conflict with a rea= l > web site. >=20 > Dan >=20 > -- > Dan York, dan-ietf@danyork.org > http://danyork.me http://twitter.com/danyork _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From ray.vanbrandenburg@tno.nl Thu Mar 29 08:20: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 1EC9721E81EE for ; Thu, 29 Mar 2012 08:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.056 X-Spam-Level: X-Spam-Status: No, score=-0.056 tagged_above=-999 required=5 tests=[AWL=0.448, 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 kev0UHRConTi for ; Thu, 29 Mar 2012 08:20:58 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3E221F8841 for ; Thu, 29 Mar 2012 08:20:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,668,1325458800"; d="scan'208";a="66803860" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 29 Mar 2012 17:20:49 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.232]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0283.003; Thu, 29 Mar 2012 17:20:48 +0200 From: "Brandenburg, R. (Ray) van" To: "dan-ietf@danyork.org" Thread-Topic: [CDNi] Comment on draft-brandenburg-cdni-has-00 - should use RFC2606 example domain names Thread-Index: AQHNDaoEdq7QIqdHk06FfwSYFXLx15aBGEaAgAASG4CAADlTnA== Date: Thu, 29 Mar 2012 15:20:47 +0000 Message-ID: <90AE0CBF-5EBB-44DC-8D4D-ABF37A1F06EB@tno.nl> References: <2779C9F0771F974CAD742BAE6D9904FE24F52BC0@Polydeuces.office.hd>, <1CA25301D2219F40B3AA37201F0EACD131A127DD@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD131A127DD@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "cdni@ietf.org" Subject: Re: [CDNi] Comment on draft-brandenburg-cdni-has-00 - should use RFC2606 example domain names 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, 29 Mar 2012 15:20:59 -0000 Hi Dan, Thanks for the heads-up. I will definitely address it in the next version. = Ray On 29 mrt. 2012, at 15:56, "Woundy, Richard" wrote: > +1. We should do this for all our cdni drafts. > = > ----- Original Message ----- > From: Jan Seedorf [mailto:Jan.Seedorf@neclab.eu] > Sent: Thursday, March 29, 2012 08:50 AM > To: Dan York ; CDNi@ietf.org > Subject: Re: [CDNi] Comment on draft-brandenburg-cdni-has-00 - should use= RFC2606 example domain names > = > Thanks Dan, indeed a good comment, I will check the drafts I am (co-)auth= oring > = > Jan > = >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of >> Dan York >> Sent: Thursday, March 29, 2012 2:46 PM >> To: CDNi@ietf.org >> Subject: [CDNi] Comment on draft-brandenburg-cdni-has-00 - should use >> RFC2606 example domain names >> = >> I noted in looking at the slides today at the CDNi meeting and in readin= g the >> draft that it is using "cdn.com" in examples. While I appreciate the de= sire for >> nice short addresses in examples, the reality is that "cdn.com" is a real >> website. I would suggest the authors consider using *.example.* per RFC >> 2606 ( http://tools.ietf.org/html/rfc2606 ). Example: >> = >> http://deliverynode.server.example.com/content_1/segments/segment1_1 >> .ts >> = >> That does make the URL longer, but it would no longer conflict with a re= al >> web site. >> = >> Dan >> = >> -- >> Dan York, dan-ietf@danyork.org >> http://danyork.me http://twitter.com/danyork > _______________________________________________ > 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 This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From kevin.ma@azukisystems.com Thu Mar 29 09:16:22 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 B5E1C21E824A for ; Thu, 29 Mar 2012 09:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 v2YL7Wo8JMN7 for ; Thu, 29 Mar 2012 09:16:21 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id AE55221E8241 for ; Thu, 29 Mar 2012 09:16:21 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id F191C416C0C; Thu, 29 Mar 2012 12:16:20 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 77918416BFA; Thu, 29 Mar 2012 12:16:05 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Thu, 29 Mar 2012 12:15:48 -0400 From: Kevin J Ma To: HeXiaoyan , "cdni@ietf.org" Date: Thu, 29 Mar 2012 12:16:03 -0400 Thread-Topic: [CDNi] FW: New Version Notification for draft-liu-cdni-metadata-interface-01.txt Thread-Index: Acy+6CdsyhhI5EOrT3S9WWonZBK/jQAAGqkQE7D1o7A= Message-ID: <291CC3F9E50E7641901A54E85D0977C65260911A61@MAILR002.mail.lan> References: <01c001ccbef5$29788150$7c6983f0$@com> In-Reply-To: <01c001ccbef5$29788150$7c6983f0$@com> 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 Subject: Re: [CDNi] FW: New Version Notification for draft-liu-cdni-metadata-interface-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, 29 Mar 2012 16:16:22 -0000 Hi Xiaoyan, I had a questions about condition precedence. The draft states that the "last condition metadata group with matching conditions takes effect". I assume that applies to each individual metadata, i.e., that different metadata may come from different condition groups, and be applied to a given content request? The "last"-based approach gives precedence to newer rules? To properly order the list, a uCDN may be required to re-evaluate and replacing all conditions whenever a new condition is created, which may not scale? Is there a precedence order for the different condition fields? And is there a best match criteria for the condition value types? That might be an alternative? Applying different sets of metadata to a given content item is an interesting idea, however, imo, applying sets of metadata to sets of content is easier to comprehend (especially with large amounts of content and overlapping metadata), i.e., keep URI separate and always match URI first before applying other condition metadata; condition metadata would only apply to specific URIs? thanx. -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > HeXiaoyan > Sent: Tuesday, December 20, 2011 3:56 AM > To: cdni@ietf.org > Subject: [CDNi] FW: New Version Notification for draft-liu-cdni-metadata- > interface-01.txt >=20 > Hi all, > I've uploaded an updated version of draft-liu-cdni-metadata-interface wit= h > some typos corrected. > http://www.ietf.org/id/draft-liu-cdni-metadata-interface-01.txt >=20 > Your comments are welcome. >=20 > Wish you all a happy holiday season! >=20 > Best Regards > Xiaoyan(Susan) He >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, December 20, 2011 3:22 PM > To: hexiaoyan@huawei.com > Cc: hexiaoyan@huawei.com; guna@huawei.com; lijincheng@huawei.com; > xiaomei.sc.liu@huawei.com > Subject: New Version Notification for draft-liu-cdni-metadata-interface- > 01.txt >=20 > A new version of I-D, draft-liu-cdni-metadata-interface-01.txt has been > successfully submitted by Xiaoyan He and posted to the IETF repository. >=20 > Filename: draft-liu-cdni-metadata-interface > Revision: 01 > Title: Content Distribution Network Interconnection (CDNI) > Metadata Interface > Creation date: 2011-12-20 > WG ID: Individual Submission > Number of pages: 22 >=20 > Abstract: > The Metadata Interface is one of the core interfaces defined by the > IETF Content Distribution Network Interconnection (CDNI) Working > Group. The primary function of the CDNI Metadata Interface is to > allow interconnected CDNs to communicate metadata in order to ensure > content delivery and content acquisition. This document defines the > metadata exchange protocol between an upstream CDN and a downstream > CDN for the content delivery. It also defines metadata objects > especially condition metadata object for CDNI. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From richard_woundy@cable.comcast.com Thu Mar 29 10:09:22 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 C605521F8877 for ; Thu, 29 Mar 2012 10:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.806 X-Spam-Level: X-Spam-Status: No, score=-101.806 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 UWxXjuP83oRO for ; Thu, 29 Mar 2012 10:09:22 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 33E2321F8861 for ; Thu, 29 Mar 2012 10:09:22 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.11402798; Thu, 29 Mar 2012 10:56:57 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Thu, 29 Mar 2012 13:09:27 -0400 From: "Woundy, Richard" To: "cdni@ietf.org" Thread-Topic: CDNI session details for IETF 83 Thread-Index: AQHNDYf6sRTvo5QzhkiDBEg8wXAkWJaBgYvp Date: Thu, 29 Mar 2012 17:09:18 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD131A12D34@PACDCEXMB05.cable.comcast.com> References: , In-Reply-To: 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_1CA25301D2219F40B3AA37201F0EACD131A12D34PACDCEXMB05cabl_" MIME-Version: 1.0 Subject: Re: [CDNi] CDNI session details for IETF 83 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:09:22 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD131A12D34PACDCEXMB05cabl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > We are likely to cover Rob Murray's draft on CDNI Triggers on Thursday in= stead of Friday. We will start on Friday at 0900 with CDNI Triggers. > We still need to upload two more slide decks for Friday's session. All slide decks have been uploaded to the IETF website. https://datatracker.ietf.org/meeting/83/materials.html#wg-cdni -- Rich ________________________________ From: Woundy, Richard Sent: Thursday, March 29, 2012 4:43 AM To: cdni@ietf.org Cc: Francois Le Faucheur; Woundy, Richard Subject: CDNI session details for IETF 83 Folks, We will meet on Thursday March 29 from 1300-1500 local time in room 252B, a= nd on Friday March 30 from 0900-1100 local time in room 242AB. We are using WebEx to support remote participation. You can find the links = to join the WebEx sessions here: http://www.ietf.org/meeting/83/remote-part= icipation.html#webex. The slides for the CDNI session at IETF 83 can be found here: https://datat= racker.ietf.org/meeting/83/materials.html#wg-cdni. We are likely to cover Rob Murray's draft on CDNI Triggers on Thursday inst= ead of Friday. We still need to upload two more slide decks for Friday's session. -- Rich --_000_1CA25301D2219F40B3AA37201F0EACD131A12D34PACDCEXMB05cabl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> We are likely to cover Rob Murray's draft on CDNI Triggers on T= hursday instead of Friday.

We will start on Friday at 0900 with CDNI Triggers.

> We still need to upload two more slide decks for Friday's session= .

All slide decks have been uploaded to the IETF website.

https://datatracker.ietf.org/meeting/83/materials.html#wg= -cdni

-- Rich

From: Woundy, Richard
Sent: Thursday, March 29, 2012 4:43 AM
To: cdni@ietf.org
Cc: Francois Le Faucheur; Woundy, Richard
Subject: CDNI session details for IETF 83

Folks,
We will meet on Thursday March 29 from 1300-1500 local time in room 25= 2B, and on Friday March 30 from 0900-1100 local time in room 242AB.

We are using WebEx to support remote participation. You can find the l= inks to join the WebEx sessions here: http://www.iet= f.org/meeting/83/remote-participation.html#webex.

The slides for the CDNI session at IETF 83 can be found here: https://datatracker.ietf.org/meeting/83/materials.html#wg-= cdni.

We are likely to cover Rob Murray's draft on CDNI Triggers on Thursday= instead of Friday.

We still need to upload two more slide decks for Friday's session.

-- Rich
--_000_1CA25301D2219F40B3AA37201F0EACD131A12D34PACDCEXMB05cabl_-- From hexiaoyan@huawei.com Thu Mar 29 12:10: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 AF5B821E804C for ; Thu, 29 Mar 2012 12:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[AWL=-1.802, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 JzUtYYY-dlyl for ; Thu, 29 Mar 2012 12:10:04 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E863621E801B for ; Thu, 29 Mar 2012 12:10:03 -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 AEM49651; Thu, 29 Mar 2012 15:10:03 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 12:09:00 -0700 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 12:08:41 -0700 Received: from SZXEML531-MBX.china.huawei.com ([fe80::61a8:2cb5:62f9:d4a4]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Fri, 30 Mar 2012 03:08:35 +0800 From: HeXiaoyan To: Kevin J Ma , "cdni@ietf.org" Thread-Topic: [CDNi] FW: New Version Notification for draft-liu-cdni-metadata-interface-01.txt Thread-Index: Acy+6CdsyhhI5EOrT3S9WWonZBK/jQAAGqkQE7D1o7AACHILVg== Date: Thu, 29 Mar 2012 19:08:34 +0000 Message-ID: References: <01c001ccbef5$29788150$7c6983f0$@com>, <291CC3F9E50E7641901A54E85D0977C65260911A61@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C65260911A61@MAILR002.mail.lan> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.68] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CDNi] FW: New Version Notification for draft-liu-cdni-metadata-interface-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, 29 Mar 2012 19:10:05 -0000 SGkgS2V2aW4sDQpUaGFua3MgZm9yIHRoZSBjb21tZW50cy4NClBsZWFzZSBzZWUgbXkgcmVzcG9u c2UgaW5saW5lLiAgDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CreivP7IyzogS2V2aW4gSiBNYSBba2V2aW4ubWFAYXp1a2lzeXN0ZW1zLmNvbV0NCreiy83Ksbzk OiAyMDEyxOoz1MIzMMjVIDA6MTYNCrW9OiBIZVhpYW95YW47IGNkbmlAaWV0Zi5vcmcNCtb3zOI6 IFJFOiBbQ0ROaV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGl1LWNk bmktbWV0YWRhdGEtaW50ZXJmYWNlLTAxLnR4dA0KDQpIaSBYaWFveWFuLA0KDQogIEkgaGFkIGEg cXVlc3Rpb25zIGFib3V0IGNvbmRpdGlvbiBwcmVjZWRlbmNlLiAgVGhlIGRyYWZ0IHN0YXRlcyB0 aGF0IHRoZQ0KICAibGFzdCBjb25kaXRpb24gbWV0YWRhdGEgZ3JvdXAgd2l0aCBtYXRjaGluZyBj b25kaXRpb25zIHRha2VzIGVmZmVjdCIuDQogIEkgYXNzdW1lIHRoYXQgYXBwbGllcyB0byBlYWNo IGluZGl2aWR1YWwgbWV0YWRhdGEsIGkuZS4sIHRoYXQgZGlmZmVyZW50DQogIG1ldGFkYXRhIG1h eSBjb21lIGZyb20gZGlmZmVyZW50IGNvbmRpdGlvbiBncm91cHMsIGFuZCBiZSBhcHBsaWVkIHRv IGENCiAgZ2l2ZW4gY29udGVudCByZXF1ZXN0Pw0KW1hpYW95YW5dICBEb24ndCBxdWl0ZSB1bmRl cnN0YW5kIHlvdXIgY29uY2VyIGhlcmUsIGJ1dCBsZXQgbWUgdHJ5IHRvIGdpdmUgc29tZSBleHBs YWluYXRpb24gaGVyZS4NCklmIHlvdSBsb29rIGF0IHRoZSBkYXRhIG1vZGVsLCB0aGUgdG9wIGxl dmVsIG9iamVjdCBpcyAiRGVsaXZlcnkgRG9taWFuIiwNCndoaWNoIG1lYW5zIHRoYXQgdGhlIGJh c2ljIGdyYW51bGFyaXR5IG9mIG1ldGFkYXRhIGFwcGxpY2F0aW9uIHNjb3BlIGlzIGEgZGVsaXZl cnkgZG9tYWluLA0KaS5lLiBhbGwgY29udGVudHMgYmVsb25naW5nIHRvIHRoYXQgZG9tYWluLCBu b3QgYSBzcGVjaWZpYyBjb250ZW50LiBBY3R1YWxseSwgd2UgYmVsaXZlIG1ldGFkYXRhIG9mDQpj b250ZW50cyBiZWxvbmdpbmcgdG8gYSBzYW1lIGRvbWFpbiB3aWxsIG92ZXJsYXAgaW4gbXVjaCwg d2UgZGVzY3JpYmUgdGhlc2UgbWV0YWRhdGENCnZpYSBEb21haW5NZXRhZGF0YSBHcm91cCBpbiBv dXIgZG9jdW1lbnQsIHdoaWNoIG1lYW5zIHlvdSBkbyBub3QgbmVlZCB0byBleHRyYWN0IG1vc3Qg b2YgDQp0aGUgbWV0YWRhdGEgZnJvbSBkaWZmZXJlbnQgY29uZGl0aW9uIGdyb3Vwcy4gVGhleSBz aG91bGQgYmUgdGhlcmUgb25seSBpbiBvbmUgZ3JvdXAsIG5hbWVkIERvbWFpbk1ldGFkYXRhR3Jv dXAuIA0KVGhlIGNvbmRpdGlvbiBtZXRhZGF0YSBvbmx5IGFwcGxpZWQgZm9yIGNvbnRlbnRzIGlu IHRoZSBkb21haW4gd2hpY2ggaGFzIHNwZWNpYWwgY2hhcmFjdGVyaXN0aWNzIGFuZCBzb21lIG9m DQppdHMgbWV0YWRhdGEgbmVlZHMgdG8gYmUgcmVzZXQgYmV5b25kIGRlZmF1bHQgdmFsdWVzIGNv bnRhaW5lZCBpbiBEb21haW5NZXRhZGF0YUdyb3VwLg0KIEFuZCB0aGUgaW50ZW50aW9uIG9mIG11 bHRpcGxlIENPTkRJVElPTiBHUk9VUCBpcyB0byByZXNldCAgbWV0YWRhdGEgcmVxdWlyaW5nIGRp ZmZlcmVudCBjb25kaXRpb25zIG1hdGNoIGFnYWluc3QgcGVyZm9ybWFuY2UsIGl0IGlzIG5vdCBl eHBsaWNpdGx5IGV4Y2x1ZGUNCnRoZSBjYXNlIHRvIHJlc2V0IHNhbWUgbWV0YWRhdGEsIGJ1dCAi bGFzdCBjb25kaXRpb24gbWV0YWRhdGEgZ3JvdXAgdGFrZXMgZWZmZWN0IHRoYXQgaXMgYSBleHRy ZW1lIGNhc2UgZm9yIHJlc2V0aW5nIHNhbWUgbWV0YWRhdGEgdmlhIG11bHRpcGxlIGNvbmRpdGlv biBncm91cCBJIHRoaW5rLg0KDQogIFRoZSAibGFzdCItYmFzZWQgYXBwcm9hY2ggZ2l2ZXMgcHJl Y2VkZW5jZSB0byBuZXdlciBydWxlcz8NCltYaWFveWFuXSBSaWdodCwgYnV0IG9ubHkgdW5kZXIg dGhlIGNhc2UgdGhhdCB0aGUgbGF0dGVyIGNvbmRpdGlvbiBncm91cCBhcmUgdHJ5aW5nIHRvIHJl c2V0IGEgbWV0YWRhdGEgdGhhdCBhbHJlYWR5IHJlc2V0ZWQgYnkgYSBwcmV2aW91cyBjb25kaXRp b24gZ3JvdXAuIElmIHRoZSANCmxhdHRlciBjb25kaXRpb24gZ3JvdXAgaXMgdXNlZCB0byByZXNl dCBkaWZmZXJlbnQgbWV0YWRhdGEgdGhhbiB0aGUgcHJldmlvdXMgb25lcywgdGhlbiAicHJlY2Vk ZW5jZSIgZG9lcyBub3QgbWFrZSBzZW5zZS4NCg0KDQogIFRvIHByb3Blcmx5IG9yZGVyIHRoZSBs aXN0LCBhIHVDRE4gbWF5IGJlIHJlcXVpcmVkIHRvIHJlLWV2YWx1YXRlIGFuZCByZXBsYWNpbmcg YWxsIA0KICBjb25kaXRpb25zIHdoZW5ldmVyIGEgbmV3IGNvbmRpdGlvbiBpcyBjcmVhdGVkLCB3 aGljaCBtYXkgbm90IHNjYWxlPw0KW1hpYW95YW5dIFRoaXMgaXMgbm90IHRydWUuIEEgdUNETiBk b2VzIG5vdCBuZWVkIHRvIGRvIHRoYXQgYXQgYWxsLiAgIA0KTGV0J3MgdGFrZSBhbiBleGFtcGxl ICwgaWYgdGhlcmUgYXJlIGFscmVhZHkgdHdvIGNvbmRpdGlvbiBncm91cCwgQ29uZGl0aW9uIEdy b3VwMSByZXNldCBtZXRhZGF0YSAxIG9uY2UgY29uZGl0aW9uIEEgYW5kIEIgYXJlIG1ldC4gQ29u ZGl0aW4gR3JvdXAgMiByZXNldA0KbWV0YWRhdGEgMiBvbmNlIGNvbmRpdGlvbiBDLCBELCBFIGFy ZSBtZXQuICBOb3cgeW91IHdhbnQgdG8gY3JlYXRlIGEgbmV3IGNvbmRpdGlvbiBGIGZvciBtZXRh ZGF0YSAxLCBpZiB5b3UgZG8gbm90IHJlcXVpcmUgY29uZGl0aW9uIEEgYW5kIEIgDQphcmUgbWV0 ICBzaW11bHRhbmVvdXNseSwganVzdCBjcmVhdGUgYSBuZXcgQ29uZGl0aW9uIEdyb3VwIDMgYW5k IHB1dCBpdCBsYXRlciB0aGFuIENvbmRpdGlvbiBHcm91cDEsIHRoYXQncyBlbm91Z2guICBJZiB5 b3UgcmVxdWlyZSBjb25kaXRpb24gQSAsIEIgYW5kIHRoZSBuZXcgDQpjcmVhdGVkIGNvbmRpdGlv biBGIHNob3VsZCBiZSBtZXQgc2ltdXRhbmVvdXNseSB0byByZXNldCBtZXRhZGF0YTEsIHRoZW4g anVzdCBhZGQgY29uZGl0aW9uIEYgaW50byBjb25kaXRpb24gZ3JvdXAgMS4gICB1Q0ROIGRvZXMg bm90IG5lZWQgcmUtZXZhbHVhdGUgYW5kDQpyZXBsYWNpbmcgYWxsIGNvbmRpdGlvbnMuDQogDQog ICAgDQoNCiAgSXMgdGhlcmUgYSBwcmVjZWRlbmNlIG9yZGVyIGZvciB0aGUgZGlmZmVyZW50IGNv bmRpdGlvbiBmaWVsZHM/ICBBbmQgaXMNCiAgdGhlcmUgYSBiZXN0IG1hdGNoIGNyaXRlcmlhIGZv ciB0aGUgY29uZGl0aW9uIHZhbHVlIHR5cGVzPyAgVGhhdCBtaWdodA0KICBiZSBhbiBhbHRlcm5h dGl2ZT8NCltYaWFveWFuXSBUaGVyZSBpcyBubyBwcmVjZWRlbmNlIG9yZGVyIGZvciB0aGUgZGlm ZmVyZW50IGNvbmRpdGlvbiBmaWVsZHMuIE11bHRpcGxlIGNvbmRpdGlvbnMNCndpdGggZGlmZmVy ZW50IGNvbmRpdGlvbiBmaWVsZHMgaW4gT05FIENPTkRJVElPTiBHUk9VUCBhcmUgdXNlZCBpbiBB TkQgcmVsYXRpb24uICANCg0KICBBcHBseWluZyBkaWZmZXJlbnQgc2V0cyBvZiBtZXRhZGF0YSB0 byBhIGdpdmVuIGNvbnRlbnQgaXRlbSBpcyBhbg0KICBpbnRlcmVzdGluZyBpZGVhLCBob3dldmVy LCBpbW8sIGFwcGx5aW5nIHNldHMgb2YgbWV0YWRhdGEgdG8NCiAgc2V0cyBvZiBjb250ZW50IGlz IGVhc2llciB0byBjb21wcmVoZW5kIChlc3BlY2lhbGx5IHdpdGggbGFyZ2UNCiAgYW1vdW50cyBv ZiBjb250ZW50IGFuZCBvdmVybGFwcGluZyBtZXRhZGF0YSksIA0KDQpbWGlhb3lhbl0gVGhlIG1h aW4gaWRlYSBvZiB0aGlzIGRyYWZ0IGlzIGFwcGx5aW5nIHNhbWUgZG9tYWluICBtZXRhZGF0YSB0 bw0KYWxsIGNvbnRlbnRzIGJlbG9uZ2luZyB0byBhIGRlbGl2ZXJ5IGRvbWFpbiwgIGJlc2lkZXMg dGhhdCB3ZSBnaXZlIGFuIG1lY2hhbmlzbSB0aGF0IHJlZmluZSBzb21lIGtpbmQgb2YgbWV0YWRh dGEgb2Ygc29tZSBzcGVjaWFsIGNvbnRlbnRzIA0KaW4gdGhlIHNhbWUgZG9tYWluLiBJIHRoaW5r IHdlIGFyZSBkb2luZyB0aGUgc2FtZSB0aGluZywgYXBwbHlpbmcgc2V0cyBvZiBtZXRhZGF0YSB0 byBzZXRzIG9mIGNvbnRlbnQuIA0KQW5kIHRoZSBtZXJpdCBvZiBvdXIgcHJvcG9zYWwgaXMgIHdl IGNhbiBzYXZlIHRoZSB2b2x1bWUgb2YgbWV0YWRhdGEgdmVyeSBsYXJnZWx5IGFuZCBwcm92aWRl IGdvb2QgZXh0ZW5zaWJpbGl0eSBhbmQgZmxleGliaWxpdHkgIC4NCg0KaS5lLiwga2VlcCBVUkkg c2VwYXJhdGUNCiAgYW5kIGFsd2F5cyBtYXRjaCBVUkkgZmlyc3QgYmVmb3JlIGFwcGx5aW5nIG90 aGVyIGNvbmRpdGlvbiBtZXRhZGF0YTsNCiAgY29uZGl0aW9uIG1ldGFkYXRhIHdvdWxkIG9ubHkg YXBwbHkgdG8gc3BlY2lmaWMgVVJJcz8NCltYaWFveWFuXSBXZSBkbyBtYXRjaCBVUkkgZmlyc3Qs IGluIG91ciBwcm9wb3NhbCwgb25jZSBhIGRDRE4gcmVjZWl2ZXMgYSBjb250ZW50IHJlcXVlc3Qs DQpob3N0bmFtZSBvZiB0aGUgVVJJIG11c3QgZmlyc3QgYmUgY2hlY2tlZCB0byBmaW5kIG91dCB0 aGUgbWV0YWRhdGEgbmVlZHMgdG8gYmUgYXBwbGllZC4NCkhvcGUgdGhpcyBoZWxwcy4NCg0KdGhh bnguDQoNCi0tICBLZXZpbiBKLiBNYQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IGNkbmktYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mDQo+IEhlWGlhb3lhbg0KPiBTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAy MCwgMjAxMSAzOjU2IEFNDQo+IFRvOiBjZG5pQGlldGYub3JnDQo+IFN1YmplY3Q6IFtDRE5pXSBG VzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saXUtY2RuaS1tZXRhZGF0YS0N Cj4gaW50ZXJmYWNlLTAxLnR4dA0KPg0KPiBIaSBhbGwsDQo+IEkndmUgdXBsb2FkZWQgYW4gdXBk YXRlZCB2ZXJzaW9uIG9mIGRyYWZ0LWxpdS1jZG5pLW1ldGFkYXRhLWludGVyZmFjZSB3aXRoDQo+ IHNvbWUgdHlwb3MgY29ycmVjdGVkLg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWxp dS1jZG5pLW1ldGFkYXRhLWludGVyZmFjZS0wMS50eHQNCj4NCj4gWW91ciBjb21tZW50cyBhcmUg d2VsY29tZS4NCj4NCj4gV2lzaCB5b3UgYWxsIGEgaGFwcHkgaG9saWRheSBzZWFzb24hDQo+DQo+ IEJlc3QgUmVnYXJkcw0KPiBYaWFveWFuKFN1c2FuKSBIZQ0KPg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDIwLCAyMDEx IDM6MjIgUE0NCj4gVG86IGhleGlhb3lhbkBodWF3ZWkuY29tDQo+IENjOiBoZXhpYW95YW5AaHVh d2VpLmNvbTsgZ3VuYUBodWF3ZWkuY29tOyBsaWppbmNoZW5nQGh1YXdlaS5jb207DQo+IHhpYW9t ZWkuc2MubGl1QGh1YXdlaS5jb20NCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1saXUtY2RuaS1tZXRhZGF0YS1pbnRlcmZhY2UtDQo+IDAxLnR4dA0KPg0KPiBB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGl1LWNkbmktbWV0YWRhdGEtaW50ZXJmYWNlLTAx LnR4dCBoYXMgYmVlbg0KPiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFhpYW95YW4gSGUgYW5k IHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KPg0KPiBGaWxlbmFtZTogICAgICBkcmFm dC1saXUtY2RuaS1tZXRhZGF0YS1pbnRlcmZhY2UNCj4gUmV2aXNpb246ICAgICAgMDENCj4gVGl0 bGU6ICAgICAgICAgICAgICAgICBDb250ZW50IERpc3RyaWJ1dGlvbiBOZXR3b3JrIEludGVyY29u bmVjdGlvbiAoQ0ROSSkNCj4gTWV0YWRhdGEgSW50ZXJmYWNlDQo+IENyZWF0aW9uIGRhdGU6ICAg ICAgICAgMjAxMS0xMi0yMA0KPiBXRyBJRDogICAgICAgICAgICAgICAgIEluZGl2aWR1YWwgU3Vi bWlzc2lvbg0KPiBOdW1iZXIgb2YgcGFnZXM6IDIyDQo+DQo+IEFic3RyYWN0Og0KPiAgIFRoZSBN ZXRhZGF0YSBJbnRlcmZhY2UgaXMgb25lIG9mIHRoZSBjb3JlIGludGVyZmFjZXMgZGVmaW5lZCBi eSB0aGUNCj4gICBJRVRGIENvbnRlbnQgRGlzdHJpYnV0aW9uIE5ldHdvcmsgSW50ZXJjb25uZWN0 aW9uIChDRE5JKSBXb3JraW5nDQo+ICAgR3JvdXAuIFRoZSBwcmltYXJ5IGZ1bmN0aW9uIG9mIHRo ZSBDRE5JIE1ldGFkYXRhIEludGVyZmFjZSBpcyB0bw0KPiAgIGFsbG93IGludGVyY29ubmVjdGVk IENETnMgdG8gY29tbXVuaWNhdGUgbWV0YWRhdGEgaW4gb3JkZXIgdG8gZW5zdXJlDQo+ICAgY29u dGVudCBkZWxpdmVyeSBhbmQgY29udGVudCBhY3F1aXNpdGlvbi4gVGhpcyBkb2N1bWVudCBkZWZp bmVzIHRoZQ0KPiAgIG1ldGFkYXRhIGV4Y2hhbmdlIHByb3RvY29sIGJldHdlZW4gYW4gdXBzdHJl YW0gQ0ROIGFuZCBhIGRvd25zdHJlYW0NCj4gICBDRE4gZm9yIHRoZSBjb250ZW50IGRlbGl2ZXJ5 LiBJdCBhbHNvIGRlZmluZXMgbWV0YWRhdGEgb2JqZWN0cw0KPiAgIGVzcGVjaWFsbHkgY29uZGl0 aW9uIG1ldGFkYXRhIG9iamVjdCBmb3IgQ0ROSS4NCj4NCj4NCj4NCj4NCj4gVGhlIElFVEYgU2Vj cmV0YXJpYXQNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gQ0ROaSBtYWlsaW5nIGxpc3QNCj4gQ0ROaUBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nkbmk= From roy@skytide.com Thu Mar 29 17: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 2EA3B21F85DA for ; Thu, 29 Mar 2012 17:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 FFXfHPph2e1t for ; Thu, 29 Mar 2012 17:53:02 -0700 (PDT) Received: from mail-pop3-1.server101.com (ns1.giga-sj-001.net [216.218.210.201]) by ietfa.amsl.com (Postfix) with ESMTP id 582AC21F84F6 for ; Thu, 29 Mar 2012 17:52:24 -0700 (PDT) Received: from [172.16.4.31] (24-104-66-42-ip-static.hfc.comcastbusiness.net [24.104.66.42]) (authenticated as roy@skytide.com with PLAIN (0 bits)) by mail-pop3-1.server101.com (8.13.7/8.12.8) with ESMTP id q2U0qNVr018380 for ; Fri, 30 Mar 2012 10:52:23 +1000 Message-ID: <4F7503C6.20205@skytide.com> Date: Thu, 29 Mar 2012 17:52:22 -0700 From: Roy Peterkofsky User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: cdni@ietf.org Content-Type: multipart/alternative; boundary="------------030506010205050708030400" Subject: [CDNi] Comments on draft-bertrand-cdni-logging-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: Fri, 30 Mar 2012 00:53:04 -0000 This is a multi-part message in MIME format. --------------030506010205050708030400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit First off, by way of introduction, I head product management for Skytide. We are a leading supplier of CDN reporting and analytics software and thus a key consumer of CDN logs. I think this gives us a good perspective on requirements for CDNi logging. Secondly, I am very new to the IETF working group so I apologize if my comments are not in the customary or correct form for this. I did want to get these to the group before you meet in Paris to discuss this subject area so I focused my attention on making the comments timely. Anway: 1) I think there could stand to be some discussion around the impact of even having standardized log formats for interconnected CDNs. I start with the assumption that each individual CDN, as an independent entity, has one (or possibly several) log file formats that it works with internally for its own reporting, billing, etc. (call these the "native" log file formats). What format(s) the CDN uses may well be determined by which platform technology or technologies the CDN uses. If this CDN is the dCDN in a particular scenario, it could either (a) ship the relevant logs to the uCDN in their "native" format(s) or (b) first translate them into a standardized format. Assuming that the uCDN has its own "native" format used internally, in either case, the uCDN would then have to translate the received logs into this native format (from either the dCDN's native format or the standardized format). The use of a common standardized format for all possible dCDNs, of course, will minimize the number of translators/connectors that the uCDN must have available (and ensure that the required data elements are always present). But it also requires two translations to take place (dCDN native format to standardized format to uCDN native format) while simply sending the logs in the dCDN's native format will only require one translation (dCDN native format to uCDN native format). In a high-volume (e.g. ABR/HAS) scenario where reporting/analytics/monitoring are required in real-time, the extra translation step will consume time that is not necessarily available! Based on my work with an analytics system that can easily ingest and parse/translate multiple log file formats, I don't see the need to do so at the uCDN end to be a major issue. 2) I think the specification should consider use cases for both push and pull (or "on demand") log delivery. In the former scenario, the dCDN would dispatch files of appropriate log records to the uCDN on some metered basis (either every X time periods or when Y log records have accumulated, for example). In the latter, the uCDN would request log records meeting some set of criteria (time range at the least, possibly other filter elements as well) from the dCDN. I was happy to see the subject of aggregated log delivery covered, as the "on demand" scenario for log delivery can easily be seen to have one "flavor" which returns every individual log record and another which returns only aggregated data. It would have to be determined which measures (e.g., request, bytes, total duration) are aggregated and at what levels (anywhere from grand totals at one end of the spectrum to, at the other end, aggregation only when every other field of the log record matches). This becomes, actually, more of a "data query" than a "log request" and can be looked at as much as a "reporting interface" as a "logging interface." 3) The value of the logging standards will be greatly enhanced if they allow for (at least optional) inclusion of certain extended/custom fields. User agent and referrer are key extensions to the standard W3C logging formats that are of great value in CDN reporting (these are mentioned in the document). Beyond these, the standard should describe how additional fields can be added so that interconnected CDNs, by mutual agreement, can pass additional data elements without having these extended logs "break" the integration for other CDNs that are only looking for the standard fields. -- Roy Peterkofsky Vice President, Product Management Skytide -- the leader in Digital Media Performance Management www.skytide.com (510) 250-4284 Read our new white paper: The 4 Keys to Telco CDN Success --------------030506010205050708030400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit First off, by way of introduction, I head product management for Skytide.  We are a leading supplier of CDN reporting and analytics software and thus a key consumer of CDN logs.  I think this gives us a good perspective on requirements for CDNi logging.

Secondly, I am very new to the IETF working group so I apologize if my comments are not in the customary or correct form for this.  I did want to get these to the group before you meet in Paris to discuss this subject area so I focused my attention on making the comments timely.

Anway:

1) I think there could stand to be some discussion around the impact of even having standardized log formats for interconnected CDNs.  I start with the assumption that each individual CDN, as an independent entity, has one (or possibly several) log file formats that it works with internally for its own reporting, billing, etc. (call these the "native" log file formats).  What format(s) the CDN uses may well be determined by which platform technology or technologies the CDN uses.  If this CDN is the dCDN in a particular scenario, it could either (a) ship the relevant logs to the uCDN in their "native" format(s) or (b) first translate them into a standardized format.  Assuming that the uCDN has its own "native" format used internally, in either case, the uCDN would then have to translate the received logs into this native format (from either the dCDN's native format or the standardized format).  The use of a common standardized format for all possible dCDNs, of course, will minimize the number of translators/connectors that the uCDN must have available (and ensure that the required data elements are always present).  But it also requires two translations to take place (dCDN native format to standardized format to uCDN native format) while simply sending the logs in the dCDN's native format will only require one translation (dCDN native format to uCDN native format).  In a high-volume (e.g. ABR/HAS) scenario where reporting/analytics/monitoring are required in real-time, the extra translation step will consume time that is not necessarily available!  Based on my work with an analytics system that can easily ingest and parse/translate multiple log file formats, I don't see the need to do so at the uCDN end to be a major issue.

2) I think the specification should consider use cases for both push and pull (or "on demand") log delivery.  In the former scenario, the dCDN would dispatch files of appropriate log records to the uCDN on some metered basis (either every X time periods or when Y log records have accumulated, for example).  In the latter, the uCDN would request log records meeting some set of criteria (time range at the least, possibly other filter elements as well) from the dCDN.  I was happy to see the subject of aggregated log delivery covered, as the "on demand" scenario for log delivery can easily be seen to have one "flavor" which returns every individual log record and another which returns only aggregated data.   It would have to be determined which measures (e.g., request, bytes, total duration) are aggregated and at what levels (anywhere from grand totals at one end of the spectrum to, at the other end, aggregation only when every other field of the log record matches).  This becomes, actually, more of a "data query" than a "log request" and can be looked at as much as a "reporting interface" as a "logging interface."

3) The value of the logging standards will be greatly enhanced if they allow for (at least optional) inclusion of certain extended/custom fields.  User agent and referrer are key extensions to the standard W3C logging formats that are of great value in CDN reporting (these are mentioned in the document).  Beyond these, the standard should describe how additional fields can be added so that interconnected CDNs, by mutual agreement, can pass additional data elements without having these extended logs "break" the integration for other CDNs that are only looking for the standard fields.
--
Roy Peterkofsky
Vice President, Product Management
Skytide -- the leader in Digital Media Performance Management
www.skytide.com
(510) 250-4284

Read our new white paper: The 4 Keys to Telco CDN Success
--------------030506010205050708030400-- From roy@skytide.com Thu Mar 29 18:11: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 7AC9821E8093 for ; Thu, 29 Mar 2012 18:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 dvmnzrwmAXKP for ; Thu, 29 Mar 2012 18:11:56 -0700 (PDT) Received: from mail-pop3-1.server101.com (ns1.giga-sj-001.net [216.218.210.201]) by ietfa.amsl.com (Postfix) with ESMTP id 97A7921E8092 for ; Thu, 29 Mar 2012 18:11:56 -0700 (PDT) Received: from [172.16.4.31] (24-104-66-42-ip-static.hfc.comcastbusiness.net [24.104.66.42]) (authenticated as roy@skytide.com with PLAIN (0 bits)) by mail-pop3-1.server101.com (8.13.7/8.12.8) with ESMTP id q2U1Bumu011759 for ; Fri, 30 Mar 2012 11:11:56 +1000 Message-ID: <4F75085B.4020804@skytide.com> Date: Thu, 29 Mar 2012 18:11:55 -0700 From: Roy Peterkofsky User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: cdni@ietf.org Content-Type: multipart/alternative; boundary="------------060802000006000703010008" Subject: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-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: Fri, 30 Mar 2012 01:11:57 -0000 This is a multi-part message in MIME format. --------------060802000006000703010008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit First off, by way of introduction, I head product management for Skytide. We are a leading supplier of CDN reporting and analytics software and thus a key consumer of CDN logs. I think this gives us a good perspective on requirements for CDNi logging. Secondly, I am very new to the IETF working group so I apologize if my comments are not in the customary or correct form for this. I did want to get these to the group before you meet in Paris to discuss this subject area so I focused my attention on making the comments timely. Anyway: 1) It is certainly a good idea to have a standard for transmitting log records that each describe an entire ABR/HAS session rather than just an individual file from within the session. But we should be aware that there are potentially insurmountable obstacles to producing such records, so the standard cannot demand that ABR/HAS activity be always/only reported in this manner. The obstacles that I refer to have to do with the fact that any entire ABR/HAS session may not be delivered by one single CDN, even in the absence of participation in interconnection/federation activities. The fragments of a single session may be delivered by different CDNs because the content owner is using dynamic CDN-switching methods (like those of Conviva and similar products) or because a mobile user is constantly moving between different wi-fi and/or cellular networks, each of which may be connected to a different ISP and therefore a different CDN. In fact, this is particularly relevant to certain of the working group's documented CDNi use cases, such as overload handling. 2) Even if all chunks of an ABR/HAS session are delivered by a single CDN, or even a single cache/PoP of that CDN, tracking the session as a whole may be difficult and require an internal aggregation point, as logs are usually generated at the server/device level, at which there would not be visibility to the entire session. 3) Obviously, if a CDN is not delivering all elements of an ABR session, then it cannot create log records that describe the entire session. Furthermore, though, there may be obstacles to determining some of the events or metrics that the document suggests capturing. For example, a CDN that does not deliver every element of a session will not always deliver consecutive fragments of the session and, therefore, cannot generally determine if upshifts or downshifts occur. 4) These concerns would no doubt go away if some of the ABR/HAS optimizations discussed in draft-brandenburg-cdni-has-00 (Models for adaptive-streaming-aware CDN Interconnection) were implemented. I am a bit leery of basing logging standards on the assumption that those will become standardized because very few CDNs (or CDN platforms) have those capabilities available -- even for independent CDN operations, let alone CDNi operations -- and because the issues discussed above (like content owners switching CDNs beyond the control of both the uCDN and dCDN) could make them impossible. Clearly, to implement such optimizations would require end-to-end cooperation from the content provider through both CDNs and potentially even to the end user (who may control the software on the user agent). That's a great vision to pursue but the logging standards also need to be able to accommodate the likely reality on the ground. -- Roy Peterkofsky Vice President, Product Management Skytide -- the leader in Digital Media Performance Management www.skytide.com (510) 250-4284 Read our new white paper: The 4 Keys to Telco CDN Success --------------060802000006000703010008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit First off, by way of introduction, I head product management for Skytide.  We are a leading supplier of CDN reporting and analytics software and thus a key consumer of CDN logs.  I think this gives us a good perspective on requirements for CDNi logging.

Secondly, I am very new to the IETF working group so I apologize if my comments are not in the customary or correct form for this.  I did want to get these to the group before you meet in Paris to discuss this subject area so I focused my attention on making the comments timely.

Anyway:

1) It is certainly a good idea to have a standard for transmitting log records that each describe an entire ABR/HAS session rather than just an individual file from within the session.    But we should be aware that there are potentially insurmountable obstacles to producing such records, so the standard cannot demand that ABR/HAS activity be always/only reported in this manner.  The obstacles that I refer to have to do with the fact that any entire ABR/HAS session may not be delivered by one single CDN, even in the absence of participation in interconnection/federation activities.  The fragments of a single session may be delivered by different CDNs because the content owner is using dynamic CDN-switching methods (like those of Conviva and similar products) or because a mobile user is constantly moving between different wi-fi and/or cellular networks, each of which may be connected to a different ISP and therefore a different CDN.  In fact, this is particularly relevant to certain of the working group's documented CDNi use cases, such as overload handling.

2) Even if all chunks of an ABR/HAS session are delivered by a single CDN, or even a single cache/PoP of that CDN, tracking the session as a whole may be difficult and require an internal aggregation point, as logs are usually generated at the server/device level, at which there would not be visibility to the entire session.

3) Obviously, if a CDN is not delivering all elements of an ABR session, then it cannot create log records that describe the entire session.  Furthermore, though, there may be obstacles to determining some of the events or metrics that the document suggests capturing.  For example, a CDN that does not deliver every element of a session will not always deliver consecutive fragments of the session and, therefore, cannot generally determine if upshifts or downshifts occur.

4) These concerns would no doubt go away if some of the ABR/HAS optimizations discussed in draft-brandenburg-cdni-has-00 (Models for adaptive-streaming-aware CDN Interconnection) were implemented.  I am a bit leery of basing logging standards on the assumption that those will become standardized because very few CDNs (or CDN platforms) have those capabilities available -- even for independent CDN operations, let alone CDNi operations -- and because the issues discussed above (like content owners switching CDNs beyond the control of both the uCDN and dCDN) could make them impossible.  Clearly, to implement such optimizations would require end-to-end cooperation from the content provider through both CDNs and potentially even to the end user (who may control the software on the user agent).  That's a great vision to pursue but the logging standards also need to be able to accommodate the likely reality on the ground.


--
Roy Peterkofsky
Vice President, Product Management
Skytide -- the leader in Digital Media Performance Management
www.skytide.com
(510) 250-4284

Read our new white paper: The 4 Keys to Telco CDN Success
--------------060802000006000703010008-- From flefauch@cisco.com Thu Mar 29 22:47: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 EE90A21F856D for ; Thu, 29 Mar 2012 22:47:14 -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 VXcX157B6XzH for ; Thu, 29 Mar 2012 22:47:13 -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 7DE4121F856C for ; Thu, 29 Mar 2012 22:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=38065; q=dns/txt; s=iport; t=1333086433; x=1334296033; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=gEzE5v7yAJ0wo5zVqpLnMwR8F4qiQFNmgeo+9XkyZIk=; b=MF1jJXSAh5rKMPl/7yU0lczxESVFmzYpYV2EGS/TgrROtEwUK4CI6wqI 93k//JQ7P48mFhx6lUZjKYYUcCHpt/ECb+Rrg8jJFmzVYDNAK4mwAkNhK zKmpUb5R7qQKBVycrhYwo2nwkc8er3oW70QDhPbM4j7UnomRG6OgabyPy Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAD1IdU+tJV2Y/2dsb2JhbABBA4JGpUmIHwGIb4EHggkBAQEDAQEBAQ8BGhwlCwULCwcRIAENJzAGEyKHYwULm2ifHY1ngkZjBJVhgRGNNYFogmk X-IronPort-AV: E=Sophos;i="4.75,341,1330905600"; d="scan'208,217";a="70694077" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 30 Mar 2012 05:47:13 +0000 Received: from rtp-vpn3-1009.cisco.com (rtp-vpn3-1009.cisco.com [10.82.219.245]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2U5lBnf013755; Fri, 30 Mar 2012 05:47:11 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-13-444428673 From: Francois Le Faucheur In-Reply-To: <4F75085B.4020804@skytide.com> Date: Fri, 30 Mar 2012 07:47:10 +0200 Message-Id: <58B02B51-56D9-4EB8-A8C6-52F3C63780A6@cisco.com> References: <4F75085B.4020804@skytide.com> To: Roy Peterkofsky X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-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: Fri, 30 Mar 2012 05:47:15 -0000 --Apple-Mail-13-444428673 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Roy, Thanks for your input. Brief comments below: On 30 Mar 2012, at 03:11, Roy Peterkofsky wrote: >=20 > Anyway: >=20 > 1) It is certainly a good idea to have a standard for transmitting log = records that each describe an entire ABR/HAS session rather than just an = individual file from within the session. But we should be aware that = there are potentially insurmountable obstacles to producing such = records, so the standard cannot demand that ABR/HAS activity be = always/only reported in this manner.=20 Noted.=20 Please note that the document discussed different potential flavours of = log format for adaptive: one that aimed for one entry per-session, and = some that aimed at one entry-per event. Some of your points below, do = not apply to the 2nd form. Cheers Francois > The obstacles that I refer to have to do with the fact that any entire = ABR/HAS session may not be delivered by one single CDN, even in the = absence of participation in interconnection/federation activities. The = fragments of a single session may be delivered by different CDNs because = the content owner is using dynamic CDN-switching methods (like those of = Conviva and similar products) or because a mobile user is constantly = moving between different wi-fi and/or cellular networks, each of which = may be connected to a different ISP and therefore a different CDN. In = fact, this is particularly relevant to certain of the working group's = documented CDNi use cases, such as overload handling. >=20 > 2) Even if all chunks of an ABR/HAS session are delivered by a single = CDN, or even a single cache/PoP of that CDN, tracking the session as a = whole may be difficult and require an internal aggregation point, as = logs are usually generated at the server/device level, at which there = would not be visibility to the entire session. >=20 > 3) Obviously, if a CDN is not delivering all elements of an ABR = session, then it cannot create log records that describe the entire = session. Furthermore, though, there may be obstacles to determining = some of the events or metrics that the document suggests capturing. For = example, a CDN that does not deliver every element of a session will not = always deliver consecutive fragments of the session and, therefore, = cannot generally determine if upshifts or downshifts occur.=20 >=20 > 4) These concerns would no doubt go away if some of the ABR/HAS = optimizations discussed in draft-brandenburg-cdni-has-00 (Models for = adaptive-streaming-aware CDN Interconnection) were implemented. I am a = bit leery of basing logging standards on the assumption that those will = become standardized because very few CDNs (or CDN platforms) have those = capabilities available -- even for independent CDN operations, let alone = CDNi operations -- and because the issues discussed above (like content = owners switching CDNs beyond the control of both the uCDN and dCDN) = could make them impossible. Clearly, to implement such optimizations = would require end-to-end cooperation from the content provider through = both CDNs and potentially even to the end user (who may control the = software on the user agent). That's a great vision to pursue but the = logging standards also need to be able to accommodate the likely reality = on the ground. >=20 >=20 > --=20 > Roy Peterkofsky > Vice President, Product Management > Skytide -- the leader in Digital Media Performance Management > www.skytide.com > (510) 250-4284 >=20 > Read our new white paper: The 4 Keys to Telco CDN Success > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --Apple-Mail-13-444428673 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hello Roy,

Thanks for your input. Brief comments below:

On 30 Mar 2012, at 03:11, Roy Peterkofsky wrote:

 Anyway:

1) It is certainly a good idea to have a standard for transmitting log records that each describe an entire ABR/HAS session rather than just an individual file from within the session.    But we should be aware that there are potentially insurmountable obstacles to producing such records, so the standard cannot demand that ABR/HAS activity be always/only reported in this manner. 

Noted. 

Please note that the document discussed different potential flavours of log format for adaptive: one that aimed for one entry per-session, and some that aimed at one entry-per event. Some of your points below, do not apply to the 2nd form.

Cheers

Francois

The obstacles that I refer to have to do with the fact that any entire ABR/HAS session may not be delivered by one single CDN, even in the absence of participation in interconnection/federation activities.  The fragments of a single session may be delivered by different CDNs because the content owner is using dynamic CDN-switching methods (like those of Conviva and similar products) or because a mobile user is constantly moving between different wi-fi and/or cellular networks, each of which may be connected to a different ISP and therefore a different CDN.  In fact, this is particularly relevant to certain of the working group's documented CDNi use cases, such as overload handling.

2) Even if all chunks of an ABR/HAS session are delivered by a single CDN, or even a single cache/PoP of that CDN, tracking the session as a whole may be difficult and require an internal aggregation point, as logs are usually generated at the server/device level, at which there would not be visibility to the entire session.

3) Obviously, if a CDN is not delivering all elements of an ABR session, then it cannot create log records that describe the entire session.  Furthermore, though, there may be obstacles to determining some of the events or metrics that the document suggests capturing.  For example, a CDN that does not deliver every element of a session will not always deliver consecutive fragments of the session and, therefore, cannot generally determine if upshifts or downshifts occur.

4) These concerns would no doubt go away if some of the ABR/HAS optimizations discussed in draft-brandenburg-cdni-has-00 (Models for adaptive-streaming-aware CDN Interconnection) were implemented.  I am a bit leery of basing logging standards on the assumption that those will become standardized because very few CDNs (or CDN platforms) have those capabilities available -- even for independent CDN operations, let alone CDNi operations -- and because the issues discussed above (like content owners switching CDNs beyond the control of both the uCDN and dCDN) could make them impossible.  Clearly, to implement such optimizations would require end-to-end cooperation from the content provider through both CDNs and potentially even to the end user (who may control the software on the user agent).  That's a great vision to pursue but the logging standards also need to be able to accommodate the likely reality on the ground.


--
Roy Peterkofsky
Vice President, Product Management
Skytide -- the leader in Digital Media Performance Management
www.skytide.com
(510) 250-4284

Read our new white paper: The 4 Keys to Telco CDN Success
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

--Apple-Mail-13-444428673-- From richard_woundy@cable.comcast.com Fri Mar 30 00:05: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 5BD6421F86FE for ; Fri, 30 Mar 2012 00:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.671 X-Spam-Level: X-Spam-Status: No, score=-100.671 tagged_above=-999 required=5 tests=[AWL=-1.634, BAYES_20=-0.74, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 lp0ghhXpreBO for ; Fri, 30 Mar 2012 00:05:09 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1C421F86FA for ; Fri, 30 Mar 2012 00:05:09 -0700 (PDT) Received: from ([24.40.56.114]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.7655418; Fri, 30 Mar 2012 02:58:54 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.01.0355.002; Fri, 30 Mar 2012 03:05:05 -0400 From: "Woundy, Richard" Thread-Topic: WebEx is down Thread-Index: Ac0OQ25g6NcDFVSgSR21nCMWZYLtDg== Date: Fri, 30 Mar 2012 07:05:04 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD131A13614@PACDCEXMB05.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_1CA25301D2219F40B3AA37201F0EACD131A13614PACDCEXMB05cabl_" MIME-Version: 1.0 To: "cdni@ietf.org" Subject: [CDNi] WebEx is down 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, 30 Mar 2012 07:05:10 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD131A13614PACDCEXMB05cabl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Apologies but we are having problems with starting the WebEx session (it th= inks we have too many sessions open). We need to start the meeting but will try to fix this issue in parallel. Re= mote participants can also use Jabber today. -- Rich --_000_1CA25301D2219F40B3AA37201F0EACD131A13614PACDCEXMB05cabl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Apologies but we are having problems with starting the WebEx session= (it thinks we have too many sessions open).

We need to start the meeting but will try to fix this issue in parallel. Re= mote participants can also use Jabber today.

-- Rich
--_000_1CA25301D2219F40B3AA37201F0EACD131A13614PACDCEXMB05cabl_-- From richard_woundy@cable.comcast.com Fri Mar 30 00: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 E6A3321E8025 for ; Fri, 30 Mar 2012 00:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.665 X-Spam-Level: X-Spam-Status: No, score=-101.665 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 swaszhYu8ann for ; Fri, 30 Mar 2012 00:17:49 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 23F2421E8015 for ; Fri, 30 Mar 2012 00:17:49 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.11485798; Fri, 30 Mar 2012 01:05:23 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Fri, 30 Mar 2012 03:17:54 -0400 From: "Woundy, Richard" Thread-Topic: Please join now, meeting in progress: cdni Thread-Index: AQHNDkRITcyZmv1G002g4LczYmrHwpaCbavH Importance: high X-Priority: 1 Date: Fri, 30 Mar 2012 07:17:45 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD131A13646@PACDCEXMB05.cable.comcast.com> References: <252201455.1333091465649.JavaMail.nobody@jsj2wl012.webex.com> In-Reply-To: <252201455.1333091465649.JavaMail.nobody@jsj2wl012.webex.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_1CA25301D2219F40B3AA37201F0EACD131A13646PACDCEXMB05cabl_" MIME-Version: 1.0 To: "cdni@ietf.org" Subject: [CDNi] FW: Please join now, meeting in progress: cdni X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 07:17:50 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD131A13646PACDCEXMB05cabl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, I have the webex up and running now. https://workgreen.webex.com/workgreen/e.php?AT=3DMI&EventID=3D192355762&UID= =3D1278387062&PW=3DNZWJmZDAyMDE0&RT=3DMiMyMw%3D%3D -- Rich ________________________________ From: Cindy Morgan [messenger@webex.com] Sent: Friday, March 30, 2012 3:11 AM To: Woundy, Richard Subject: Please join now, meeting in progress: cdni Hello , Please join my meeting that is currently in progress. Topic: cdni Date: Friday, March 30, 2012 Time: 9:11 am, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 966 526 475 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/e.php?AT=3DMI&EventID=3D1923= 55762&UID=3D1278387062&PW=3DNZWJmZDAyMDE0&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". 5. Follow the instructions that appear on your screen. To view in other time zones or languages, please click the link: https://workgreen.webex.com/workgreen/e.php?AT=3DMI&EventID=3D192355762&UID= =3D1278387062&PW=3DNZWJmZDAyMDE0&ORT=3DMiMyMw%3D%3D ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc 2. On the left navigation bar, click "Support". You can contact me at: cmorgan@amsl.com 1-510-492-4085 Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. --_000_1CA25301D2219F40B3AA37201F0EACD131A13646PACDCEXMB05cabl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Folks, I have the webex up and running now.

https://workgreen.webex.com/workgreen/e.php?AT=3DMI&= amp;EventID=3D192355762&UID=3D1278387062&PW=3DNZWJmZDAyMDE0&RT= =3DMiMyMw%3D%3D

-- Rich

From: Cindy Morgan [messenger@webex.com]<= br> Sent: Friday, March 30, 2012 3:11 AM
To: Woundy, Richard
Subject: Please join now, meeting in progress: cdni


Hello ,

Please join my meeting that is currently in progress.

Topic: cdni
Date: Friday, March 30, 2012
Time: 9:11 am, Europe Summer Time (Paris, GMT+02:00)
Meeting Number: 966 526 475
Meeting Password: 1234


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://workgreen.webex.com/workgreen/e.php?AT=3DMI&EventID=3D192355762= &UID=3D1278387062&PW=3DNZWJmZDAyMDE0&RT=3DMiMyMw%3D%3D
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: 1234
4. Click "Join".
5. Follow the instructions that appear on your screen.

To view in other time zones or languages, please click the link:
https://workgreen.webex.com/workgreen/e.php?AT=3DMI= &EventID=3D192355762&UID=3D1278387062&PW=3DNZWJmZDAyMDE0&OR= T=3DMiMyMw%3D%3D


-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://workgreen.webex.com/workgreen/mc
2. On the left navigation bar, click "Support".

You can contact me at:
cmorgan@amsl.com =
1-510-492-4085

Sign up for a free trial of WebEx
http://= www.webex.com/go/mcemfreetrial

http://www.webex.com=



IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the= start of the recording or do not join the session. Please note that any su= ch recordings may be subject to discovery in the event of litigation.
--_000_1CA25301D2219F40B3AA37201F0EACD131A13646PACDCEXMB05cabl_-- From kevin.ma@azukisystems.com Fri Mar 30 02:24: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 2066121F881D for ; Fri, 30 Mar 2012 02:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.166, 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 xcAE1-XoN-1w for ; Fri, 30 Mar 2012 02:24:50 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 7CED921F87D8 for ; Fri, 30 Mar 2012 02:24:50 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 41A5A83F183; Fri, 30 Mar 2012 05:24:45 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB023.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 714CF83EEBB; Fri, 30 Mar 2012 05:24:44 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Fri, 30 Mar 2012 05:24:44 -0400 From: Kevin J Ma To: Francois Le Faucheur , "Kent Leung (kleung)" , Niven-Jenkins Ben Date: Fri, 30 Mar 2012 05:24:41 -0400 Thread-Topic: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 Thread-Index: Ac0BSJ1MbsRA90krTwquE/vNkFYbHgNC6kdQ Message-ID: <291CC3F9E50E7641901A54E85D0977C65260911CB7@MAILR002.mail.lan> References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> 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: "cdni@ietf.org" , Viveganandhan Mahesh Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-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: Fri, 30 Mar 2012 09:24:52 -0000 Hi Francois, Wrt a flexible set of log fields, I think that it is a great idea, and it would be great if we could use metadata to specify log formats for specific content items or sets of content items. It is useful for both content-specific logging (e.g., ABR), as well as client-specific logging (e.g., X-* headers). For the W3C format, a separate log file for each format could result in a lot of files? Would aggregation cover that? thanx. -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Francois Le Faucheur > Sent: Tuesday, March 13, 2012 2:39 PM > To: Kent Leung (kleung); Niven-Jenkins Ben > Cc: cdni@ietf.org; Viveganandhan Mahesh > Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 >=20 > Ben, Kent, >=20 > Trying to extract the key points from the thread: >=20 > 1) level of requirement for support of HTTP Adaptive Streaming Logging > Session (ie ABR-aware logs): > This is a valid question. > The I-D proposes that some form of ABR-aware logging be mandatory. The > rationale is that ABR is expected to be a very common delivery format and > requires some form of log compression over very voluminous per-segment > logging. (BTW the I-D currently proposes that both Segment-Based Logging > format and Event-Based Logging format be mandatory. But come to think of > it, having only Event-Based Logging format mandatory would be sufficient > from my viewpoint). > Ben argues that ABR-aware logging should not be mandatory as it requires > extra awareness. > To get more input, I'd propose we move that requirement level discussion > to the cdni-requirements document, and have the logging I-D only talks > about what such logs would look like. >=20 >=20 > 2) flexible set of log fields: > I agree it is a good idea to allow the uCDN to customize the set of log > fields reported by a dCDN for delivery. I was thinking that we'd start > with defining a few "fixed" set of fields and then later add the > customization, but perhaps we can start directly with customizable sets o= f > fields. > To do that, I'd propose to: > * retain the notion of Format Types (e.g Delivery_HTTP, > Delivery_Adaptive_Event, ...) > * define a set of candidate fields in each Format Type > * have uCDN signal in Metadata interface the desired Format Type + > set of fields needed (ie a subset of the set of candidate fields) > * have dCDN explicitly indicate inside each log file (eg in File > Header), the Format Type and the set of fields actually included > * define handling of potential capability mismatch situations if any > (eg1 uCDN requests a field that is not supported by dCDN if we allow that= , > eg2 dCDN requests a format type that is not supported by dCDN). >=20 >=20 > 3) encoding format: > I also agree the W3C extended log format is a good base candidate to look > at. >=20 >=20 > 4) summarization of Logging info for Adaptive Streaming delivery > I believe some form of summarization is required. The Event-Based Logging > seems like a nice sweet-spot because it achieves a high summarization gai= n > without losing any info (ie any change in bandwidth/quality is logged). > The I-D suggests we may be able to come up with another interesting sweet= - > spot (Summary-Based Log) providing a huge summarization gain at the cost > of losing some details, but does not yet specify this. > Ben, it'd be interesting to provide a brief write-up on the summarization > approach you mention so we can evaluate it (an email to the list woudl be > just fine). >=20 >=20 > Thanks for the discussion. >=20 > Francois >=20 >=20 > On 9 Mar 2012, at 00:48, Kent Leung (kleung) wrote: >=20 > > Comments below. > > > >> > >> -----Original Message----- > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > > Of > >> > >> Some comments on draft-lefaucheur-cdni-logging-delivery-00. > >> > >> 1) In section 3.2.1.2 (Segment-Based Log fields) and section 3.2.2.1 > >> (Event Based Log Triggers) you mandate support for a number of log > >> fields such as abr-protocol, representation, manifest-id and > > content-id > >> that a downstream CDN may have no ability to generate, for example > >> because the downstream CDN is acting in a pure HTTP reverse proxy mode > >> and may not be aware of that level of information and/or because the > >> control of how to identify those fields is owned by the CSP and none > > of > >> CDNs may have visibility of that mapping information. > >> > >> Such a requirement to force CDNs and CDNI in general to require such > >> mappings seems overkill to me. > >> > >> KL> As stated, "... such aggregation requires a degree of application > >> awareness in dCDN to recognize that the many HTTP requests correspond > > to > >> a single video." So the premise is that the dCDN knows that it's > >> delivering ABR content. In some cases, it's possible that the > >> representation may not be known. > > > > And my point is that I don't think that premise holds true and reality > > is the opposite, i.e. in general the dCDN will not know what it's > > delivering and only some dCDNs will have the application awareness to > > produce the log fields you suggest. > > > > KL> Hmm, if the dCDN is not aware about the ABR session, then Section > > 3.2 would not apply since the dCDN considers itself to be delivering > > non-ABR content. Non-ABR content delivery does not require the log > > fields specified in this section. > > > > > >> But in general, the log fields contain > >> information that are pertinent to an ABR content. > > > > I am not exactly sure what you mean by this. I agree the fields you > > suggest would be useful but I don't think having the application > > awareness to generate them should be a mandatory requirement for > > interoperability as suggested by section 3.2 > > > > An implementation of the CDNI Logging interface MUST support logging > > for delivery of content using HTTP adaptive streaming in the Segment- > > Based Logging format and the Event-Based Logging format, and MAY > > support logging in the Summary-Based Logging format. > > > > KL> Are these fields in Sect 3.2 useful or applicable for non-ABR > > content delivery? No. I sense that I'm still missing your point. > > > > > >> 2) In section 6 you propose an additional requirement to allow an > >> upstream CDN to indicate through CDNI metadata the log format the > >> downstream CDN should use. Rather than define a set of specific > > formats, > >> we could allow the upstream CDN to specify CDNI metadata indicating > > the > >> specific log fields it is interested in receiving. The upstream CDN > >> could then tailor what it asks for according to what it requires and > >> avoid the transfer of log fields that it does not need. > >> > >> KL> Agree that it's useful for uCDN to request only the information > >> that's needed without extraneous fields. This can be accomplished with > > a > >> customized log format provided by uCDN. In a sense, this is a superset > >> of selective fields. > > > > That is another approach which would probably make life easier for the > > dCDN. > > > >> 4) If the motivation for summary/aggregated log lines is a concern > > over > >> the volume of data that needs to be transferred then in Velocix we > > have > >> done some experiments on using an alternative lookup table based > >> structure for log lines that retains all the verbosity of the original > >> delivery log lines but by itself appears to give equivalent > > compression > >> to gzip and combined with gzip reduces the size significantly when > >> compared to what gzip alone achieves (in some cases averaging as > > little > >> as 13 bits per complete log line). > >> > >> If the volume of logs to be transferred is a concern and there is > >> interest in investigating this approach further I can write-up more > >> details either in a separate draft or as a section in > >> draft-lefaucheur-cdni-logging-delivery. > >> > >> KL> I think the intent is to summarize succinctly the ABR session in > > the > >> logging. > > > > I think they're two separate things. If we're worried about the volume > > of data our experiments show that can be significantly reduced using > > structured log files with lookup tables. That technique is applicable > > regardless of the actual fields in a log file. > > > > Whether we require ABR session summary information to be logged is a > > separate discussion to how we might optimise the structure of any log > > files we require. > > > > Ben > > > > KL> Sure, I think we can discuss more on this when Francois is availabl= e > > as I'm not clear on his thoughts. > > > > Kent > > > >> I haven't discussed this in finer details with Francois yet. It > >> seems to me that the compression technique can be considered as > >> optimization in delivery of either session-based or event-based > > logging. > >> We can discuss this further if our goals are aligned. > >> > >> Kent > >> > >> 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 richard_woundy@cable.comcast.com Fri Mar 30 02: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 C369C21F8875 for ; Fri, 30 Mar 2012 02:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.64 X-Spam-Level: X-Spam-Status: No, score=-101.64 tagged_above=-999 required=5 tests=[AWL=-0.410, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 C31MACrPQnpR for ; Fri, 30 Mar 2012 02:45:42 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 53EF221F8873 for ; Fri, 30 Mar 2012 02:45:42 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.11488755; Fri, 30 Mar 2012 03:33:14 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Fri, 30 Mar 2012 05:45:46 -0400 From: "Woundy, Richard" To: "cdni@ietf.org" Thread-Topic: Footprint / capabilities advertisement design team Thread-Index: AQHNDlnczajnpWSt2katXRkXHNJFGg== Date: Fri, 30 Mar 2012 09:45:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.73] Content-Type: multipart/alternative; boundary="_000_CB9B4D5F3C5BRichardWoundycablecomcastcom_" MIME-Version: 1.0 Cc: Jon Peterson Subject: [CDNi] Footprint / capabilities advertisement design team 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, 30 Mar 2012 09:45:42 -0000 --_000_CB9B4D5F3C5BRichardWoundycablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CDNI folks, Based on today's discussion, and in the interest of making progress prior t= o our anticipated interim meeting in mid-May, Jon Peterson and Stefano Prev= idi have agreed to lead a design team focused on defining the semantics of = request routing footprint / capabilities advertisement. The focus is on sem= antics, not protocols (e.g. ALTO or BGP). Anyone willing to participate in weekly one hour conference calls is welcom= ed to join the design team. Please reach out to Jon and Stefano directly to= join; they are copied on this email. Operator feedback is especially solic= ited. -- Rich --_000_CB9B4D5F3C5BRichardWoundycablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5915BAC1B2B14F4B856C9620A9DD0CCC@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
CDNI folks,

Based on today's discussion, and in the interest of making progress pr= ior to our anticipated interim meeting in mid-May, Jon Peterson and Stefano= Previdi have agreed to lead a design team focused on defining the semantic= s of request routing footprint / capabilities advertisement. The focus is on semantics, not protocols (e.g.= ALTO or BGP).

Anyone willing to participate in weekly one hour conference calls is w= elcomed to join the design team. Please reach out to Jon and Stefano direct= ly to join; they are copied on this email. Operator feedback is especially = solicited.

-- Rich
--_000_CB9B4D5F3C5BRichardWoundycablecomcastcom_-- From richard_woundy@cable.comcast.com Fri Mar 30 02:47:51 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 2A59F21F85B8 for ; Fri, 30 Mar 2012 02:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.45 X-Spam-Level: X-Spam-Status: No, score=-101.45 tagged_above=-999 required=5 tests=[AWL=-0.554, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 noenbncK7YOq for ; Fri, 30 Mar 2012 02:47:50 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 95D6E21F8593 for ; Fri, 30 Mar 2012 02:47:50 -0700 (PDT) Received: from ([24.40.56.115]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.7658840; Fri, 30 Mar 2012 05:41:33 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Fri, 30 Mar 2012 05:47:44 -0400 From: "Woundy, Richard" To: "cdni@ietf.org" Thread-Topic: Footprint / capabilities advertisement design team Thread-Index: AQHNDlnczajnpWSt2katXRkXHNJFGpaC/CqA Date: Fri, 30 Mar 2012 09:47:43 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.73] Content-Type: multipart/alternative; boundary="_000_CB9B4DA93C60RichardWoundycablecomcastcom_" MIME-Version: 1.0 Subject: Re: [CDNi] Footprint / capabilities advertisement design team 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, 30 Mar 2012 09:47:51 -0000 --_000_CB9B4DA93C60RichardWoundycablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Re-sending to correct Jon's email address=85 CDNI folks, Based on today's discussion, and in the interest of making progress prior t= o our anticipated interim meeting in mid-May, Jon Peterson and Stefano Prev= idi have agreed to lead a design team focused on defining the semantics of = request routing footprint / capabilities advertisement. The focus is on sem= antics, not protocols (e.g. ALTO or BGP). Anyone willing to participate in weekly one hour conference calls is welcom= ed to join the design team. Please reach out to Jon and Stefano directly to= join; they are copied on this email. Operator feedback is especially solic= ited. -- Rich --_000_CB9B4DA93C60RichardWoundycablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6FA0CCDC3286494CADBA6EEF10591705@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
Re-sending to correct Jon's email address=85

CDNI folks,

Based on today's discussion, and in the interest of making progress pr= ior to our anticipated interim meeting in mid-May, Jon Peterson and Stefano= Previdi have agreed to lead a design team focused on defining the semantic= s of request routing footprint / capabilities advertisement. The focus is on semantics, not protocols (e.g.= ALTO or BGP).

Anyone willing to participate in weekly one hour conference calls is w= elcomed to join the design team. Please reach out to Jon and Stefano direct= ly to join; they are copied on this email. Operator feedback is especially = solicited.

-- Rich
 --_000_CB9B4DA93C60RichardWoundycablecomcastcom_-- From kevin.ma@azukisystems.com Fri Mar 30 10:36: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 1B1BE21F871E for ; Fri, 30 Mar 2012 10:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.345 X-Spam-Level: X-Spam-Status: No, score=-0.345 tagged_above=-999 required=5 tests=[AWL=-1.949, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 Sh11wWl2sX+u for ; Fri, 30 Mar 2012 10:36:37 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id BED0F21F871A for ; Fri, 30 Mar 2012 10:36:36 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 04F53553CCB; Fri, 30 Mar 2012 13:36:36 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB024.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id A6497553F4A; Fri, 30 Mar 2012 13:36:17 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Fri, 30 Mar 2012 13:36:01 -0400 From: Kevin J Ma To: HeXiaoyan , "cdni@ietf.org" Date: Fri, 30 Mar 2012 13:36:14 -0400 Thread-Topic: [CDNi] FW: New Version Notification for draft-liu-cdni-metadata-interface-01.txt Thread-Index: Acy+6CdsyhhI5EOrT3S9WWonZBK/jQAAGqkQE7D1o7AACHILVgAxNtFw Message-ID: <291CC3F9E50E7641901A54E85D0977C65260911E5D@MAILR002.mail.lan> References: <01c001ccbef5$29788150$7c6983f0$@com> <291CC3F9E50E7641901A54E85D0977C65260911A61@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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [CDNi] FW: New Version Notification for draft-liu-cdni-metadata-interface-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: Fri, 30 Mar 2012 17:36:38 -0000 SGkgWGlhb3lhbiwNCg0KICBzb21lIGFkZGl0aW9uYWwgY29tbWVudHM6DQoNCj4gW1hpYW95YW5d IFRoZSBtYWluIGlkZWEgb2YgdGhpcyBkcmFmdCBpcyBhcHBseWluZyBzYW1lIGRvbWFpbiAgbWV0 YWRhdGEgdG8NCj4gYWxsIGNvbnRlbnRzIGJlbG9uZ2luZyB0byBhIGRlbGl2ZXJ5IGRvbWFpbiwg IGJlc2lkZXMgdGhhdCB3ZSBnaXZlIGFuDQo+IG1lY2hhbmlzbSB0aGF0IHJlZmluZSBzb21lIGtp bmQgb2YgbWV0YWRhdGEgb2Ygc29tZSBzcGVjaWFsIGNvbnRlbnRzDQo+IGluIHRoZSBzYW1lIGRv bWFpbi4NCg0KICBJIHVuZGVyc3RhbmQgdGhhdCB5b3Ugd2FudCB0byByZWR1Y2UgdGhlIGFtb3Vu dCBvZiBtZXRhZGF0YSwgYnkgcmVseWluZw0KICBvbiBkZWZhdWx0IG1ldGFkYXRhLCBob3dldmVy LCBJIGRvIG5vdCB0aGluayBpdCBpcyByZWFsaXN0aWMgdG8gYXNzdW1lDQogIHRoYXQgYSBzaW5n bGUgbWV0YWRhdGEgdmFsdWUgd2lsbCBhcHBseSB0byBhbGwgY29udGVudCB3aXRoaW4gYSBkb21h aW4uDQogIFdlIGhhbmRsZSB0aG91c2FuZHMgb2YgcGllY2VzIG9mIGNvbnRlbnQgZm9yIG91ciBj dXN0b21lcnMsIGFuZCBtb3N0IG9mDQogIHRoZW0gaGF2ZSBkaWZmZXJlbnQgYXZhaWxhYmlsaXR5 IHdpbmRvd3MuICBFYWNoIHdvdWxkIG5lZWQgYSBjb25kaXRpb24uDQoNCj4gW1hpYW95YW5dIFdl IGRvIG1hdGNoIFVSSSBmaXJzdCwgaW4gb3VyIHByb3Bvc2FsLCBvbmNlIGEgZENETiByZWNlaXZl cyBhDQo+IGNvbnRlbnQgcmVxdWVzdCwNCj4gaG9zdG5hbWUgb2YgdGhlIFVSSSBtdXN0IGZpcnN0 IGJlIGNoZWNrZWQgdG8gZmluZCBvdXQgdGhlIG1ldGFkYXRhIG5lZWRzDQo+IHRvIGJlIGFwcGxp ZWQuDQoNCiAgTWF0Y2hpbmcganVzdCB0aGUgaG9zdG5hbWUgaXMgbm90IHRoZSBzYW1lIGFzIG1h dGNoaW5nIHRoZSBmdWxsIHJlcXVlc3QgVVJJLg0KICBJIGRvIG5vdCB0aGluayBhcHBseWluZyBt ZXRhZGF0YSB0byBqdXN0IHRoZSBGRFFOIGlzIHN1ZmZpY2llbnQgaW4gYWxsIGNhc2VzLg0KICBB cHBseWluZyBkZWZhdWx0IG1ldGFkYXRhIHRvIGEgZG9tYWluIGlzIGp1c3QgYSBkZWdlbmVyYXRl IGNhc2Ugb2YgZnVsbCBVUkkNCiAgbWF0Y2hpbmcgd2hlcmU6IFVSSSA9IC8qLg0KDQo+ICAgVG8g cHJvcGVybHkgb3JkZXIgdGhlIGxpc3QsIGEgdUNETiBtYXkgYmUgcmVxdWlyZWQgdG8gcmUtZXZh bHVhdGUgYW5kDQo+IHJlcGxhY2luZyBhbGwNCj4gICBjb25kaXRpb25zIHdoZW5ldmVyIGEgbmV3 IGNvbmRpdGlvbiBpcyBjcmVhdGVkLCB3aGljaCBtYXkgbm90IHNjYWxlPw0KPiBbWGlhb3lhbl0g VGhpcyBpcyBub3QgdHJ1ZS4gQSB1Q0ROIGRvZXMgbm90IG5lZWQgdG8gZG8gdGhhdCBhdCBhbGwu DQoNCiAgVGhlIGRlZmluaXRpb24gb2YgdGhlIGNvbmRpdGlvbiBvYmplY3QgaXMgdmVyeSBmbGV4 aWJsZS4gIFRoZSBoaWdoDQogIGRlZ3JlZSBvZiBmbGV4aWJpbGl0eSBhbGxvd3MgZm9yIG11Y2gg bW9yZSBjb21wbGV4IGNvbWJpbmF0aW9ucyBvZg0KICBjb25kaXRpb25zIHRoYW4gdGhlIG9uZXMg eW91IGRlc2NyaWJlLiAgV2hlbiB5b3UgZ2V0IHRvIHRob3VzYW5kcyBvZg0KICBjb25kaXRpb24g b2JqZWN0cyB3aXRoIHJlZ2V4IG1hdGNoZXMgdGhlcmVzIGEgaGlnaCBjaGFuY2UgZm9yIGVycm9y Lg0KDQo+ICAgbWV0YWRhdGEgbWF5IGNvbWUgZnJvbSBkaWZmZXJlbnQgY29uZGl0aW9uIGdyb3Vw cywgYW5kIGJlIGFwcGxpZWQgdG8gYQ0KPiAgIGdpdmVuIGNvbnRlbnQgcmVxdWVzdD8NCj4gW1hp YW95YW5dICBEb24ndCBxdWl0ZSB1bmRlcnN0YW5kIHlvdXIgY29uY2VyIGhlcmUsDQoNCiAgTXkg cXVlc3Rpb24gd2FzIGFib3V0IHRoZSBvcmRlciBvZiBwcm9jZXNzaW5nIGluIHRoZSBjb25kaXRp b24gbGlzdC4NCiAgSSB0aGluayB3ZSBuZWVkIHRvIGJlIHZlcnkgcHJlY2lzZSBvbiBvcmRlcmlu Zywgc28gdGhhdCBhbGwgZENETnMgY2FuDQogIGlkZW50aWNhbGx5IGFuZCBkZXRlcm1pbmlzdGlj YWxseSBhcHBseSB0aGUgbWV0YWRhdGEuDQoNCiAgR2l2ZW4gbWV0YWRhdGEgb2JqZWN0czogbTEs IG0yLCBtMw0KICBBc3N1bWUgdGhlIGRvbWFpbmxpc3Qgc2V0czogbTEgPSBBLCBtMiA9IEIsIG0z ID0gQw0KICBBc3N1bWUgYSBjb25kaXRpb24gYzEgd2hpY2ggc2V0czogbTEgPSBXIGFuZCBtMiA9 IFggaWYgdGhlIFVSSSBtYXRjaGVzICovZm9vLyoNCiAgQXNzdW1lIGEgY29uZGl0aW9uIGMyIHdo aWNoIHNldHM6IG0xID0gWSBpZiB0aGUgVVJJIG1hdGNoZXMgKi9iYXIvKiAgDQogIEFzc3VtZSBh IGNvbmRpdGlvbiBjMyB3aGljaCBzZXRzOiBtMiA9IFogaWYgdGhlIHVzZXJBZ2VudCBtYXRjaGVz ICppUGhvbmUqDQoNCiAgR2l2ZW4gYSByZXF1c3QgZm9yIHRoZSBVUkk6IC9mb28vYmFyL2Jhei50 eHQNCg0KICBUaGUgb3JkZXIgb2YgdGhlIGNvbmRpdGlvbnMgY2xlYXJseSBtYXR0ZXJzOg0KDQog IElmIHRoZSBjb25kaXRpb24gY3JlYXRpb24gb3JkZXIgd2FzOiBjMSwgYzIsIGMzDQogICAgYW4g aVBob25lIHdvdWxkIGdldDogbTEgPSBZICwgbTIgPSBaLCBtMyA9IEMNCiAgICBhbiBpUGFkIHdv dWxkIGdldDogbTEgPSBZLCBtMiA9IFgsIG0zID0gQw0KDQogIElmIHRoZSBjb25kaXRpb24gY3Jl YXRpb24gb3JkZXIgd2FzOiBjMywgYzIsIGMxDQogICAgYW4gaVBob25lIHdvdWxkIGdldDogbTEg PSBXICwgbTIgPSBYLCBtMyA9IEMNCiAgICBhbiBpUGFkIHdvdWxkIGdldDogbTEgPSBXLCBtMiA9 IFgsIG0zID0gQw0KDQogIElmIG9uZSBvZiB0aGUgY29uZGl0aW9ucyAoYzMpIHdhcyBuZXcsIGFu ZCB0aGUgZXhpc3RpbmcgY29uZGl0aW9ucyAoYzEsIGMyKQ0KICB3ZXJlIGFscmVhZHkgZW1iZWRk ZWQgaW4gYSBsaXN0IG9mIHRob3VzYW5kcyBvZiBvdGhlciBjb25kaXRpb25zLCBwcm9wZXJseQ0K ICBvcmRlcmluZyB0aGVtIG1heSBub3QgYmUgYXMgc2ltcGxlIGFzIGp1c3QgYWRkaW5nIHRvIHRo ZSBlbmQgb2YgdGhlIGxpc3QsDQogIGVzcGVjaWFsbHkgaWYgdGhlIHJlZ2V4IGV4cHJlc3Npb25z IG92ZXJsYXAgd2l0aCBvdGhlciBleGlzdGluZyBjb25kaXRpb25zPw0KDQp0aGFueC4NCg0KLS0g IEtldmluIEouIE1hDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSGVY aWFveWFuIFttYWlsdG86aGV4aWFveWFuQGh1YXdlaS5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBN YXJjaCAyOSwgMjAxMiAzOjA5IFBNDQo+IFRvOiBLZXZpbiBKIE1hOyBjZG5pQGlldGYub3JnDQo+ IFN1YmplY3Q6IFJlOiBbQ0ROaV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtbGl1LWNkbmktDQo+IG1ldGFkYXRhLWludGVyZmFjZS0wMS50eHQNCj4gDQo+IEhpIEtldmlu LA0KPiBUaGFua3MgZm9yIHRoZSBjb21tZW50cy4NCj4gUGxlYXNlIHNlZSBteSByZXNwb25zZSBp bmxpbmUuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ILeivP7IyzogS2V2aW4gSiBNYSBba2V2aW4ubWFAYXp1a2lzeXN0ZW1zLmNvbV0NCj4gt6LLzcqx vOQ6IDIwMTLE6jPUwjMwyNUgMDoxNg0KPiC1vTogSGVYaWFveWFuOyBjZG5pQGlldGYub3JnDQo+ INb3zOI6IFJFOiBbQ0ROaV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt bGl1LWNkbmktbWV0YWRhdGEtDQo+IGludGVyZmFjZS0wMS50eHQNCj4gDQo+IEhpIFhpYW95YW4s DQo+IA0KPiAgIEkgaGFkIGEgcXVlc3Rpb25zIGFib3V0IGNvbmRpdGlvbiBwcmVjZWRlbmNlLiAg VGhlIGRyYWZ0IHN0YXRlcyB0aGF0IHRoZQ0KPiAgICJsYXN0IGNvbmRpdGlvbiBtZXRhZGF0YSBn cm91cCB3aXRoIG1hdGNoaW5nIGNvbmRpdGlvbnMgdGFrZXMgZWZmZWN0Ii4NCj4gICBJIGFzc3Vt ZSB0aGF0IGFwcGxpZXMgdG8gZWFjaCBpbmRpdmlkdWFsIG1ldGFkYXRhLCBpLmUuLCB0aGF0IGRp ZmZlcmVudA0KPiAgIG1ldGFkYXRhIG1heSBjb21lIGZyb20gZGlmZmVyZW50IGNvbmRpdGlvbiBn cm91cHMsIGFuZCBiZSBhcHBsaWVkIHRvIGENCj4gICBnaXZlbiBjb250ZW50IHJlcXVlc3Q/DQo+ IFtYaWFveWFuXSAgRG9uJ3QgcXVpdGUgdW5kZXJzdGFuZCB5b3VyIGNvbmNlciBoZXJlLCBidXQg bGV0IG1lIHRyeSB0byBnaXZlDQo+IHNvbWUgZXhwbGFpbmF0aW9uIGhlcmUuDQo+IElmIHlvdSBs b29rIGF0IHRoZSBkYXRhIG1vZGVsLCB0aGUgdG9wIGxldmVsIG9iamVjdCBpcyAiRGVsaXZlcnkg RG9taWFuIiwNCj4gd2hpY2ggbWVhbnMgdGhhdCB0aGUgYmFzaWMgZ3JhbnVsYXJpdHkgb2YgbWV0 YWRhdGEgYXBwbGljYXRpb24gc2NvcGUgaXMgYQ0KPiBkZWxpdmVyeSBkb21haW4sDQo+IGkuZS4g YWxsIGNvbnRlbnRzIGJlbG9uZ2luZyB0byB0aGF0IGRvbWFpbiwgbm90IGEgc3BlY2lmaWMgY29u dGVudC4NCj4gQWN0dWFsbHksIHdlIGJlbGl2ZSBtZXRhZGF0YSBvZg0KPiBjb250ZW50cyBiZWxv bmdpbmcgdG8gYSBzYW1lIGRvbWFpbiB3aWxsIG92ZXJsYXAgaW4gbXVjaCwgd2UgZGVzY3JpYmUN Cj4gdGhlc2UgbWV0YWRhdGENCj4gdmlhIERvbWFpbk1ldGFkYXRhIEdyb3VwIGluIG91ciBkb2N1 bWVudCwgd2hpY2ggbWVhbnMgeW91IGRvIG5vdCBuZWVkIHRvDQo+IGV4dHJhY3QgbW9zdCBvZg0K PiB0aGUgbWV0YWRhdGEgZnJvbSBkaWZmZXJlbnQgY29uZGl0aW9uIGdyb3Vwcy4gVGhleSBzaG91 bGQgYmUgdGhlcmUgb25seSBpbg0KPiBvbmUgZ3JvdXAsIG5hbWVkIERvbWFpbk1ldGFkYXRhR3Jv dXAuDQo+IFRoZSBjb25kaXRpb24gbWV0YWRhdGEgb25seSBhcHBsaWVkIGZvciBjb250ZW50cyBp biB0aGUgZG9tYWluIHdoaWNoIGhhcw0KPiBzcGVjaWFsIGNoYXJhY3RlcmlzdGljcyBhbmQgc29t ZSBvZg0KPiBpdHMgbWV0YWRhdGEgbmVlZHMgdG8gYmUgcmVzZXQgYmV5b25kIGRlZmF1bHQgdmFs dWVzIGNvbnRhaW5lZCBpbg0KPiBEb21haW5NZXRhZGF0YUdyb3VwLg0KPiAgQW5kIHRoZSBpbnRl bnRpb24gb2YgbXVsdGlwbGUgQ09ORElUSU9OIEdST1VQIGlzIHRvIHJlc2V0ICBtZXRhZGF0YQ0K PiByZXF1aXJpbmcgZGlmZmVyZW50IGNvbmRpdGlvbnMgbWF0Y2ggYWdhaW5zdCBwZXJmb3JtYW5j ZSwgaXQgaXMgbm90DQo+IGV4cGxpY2l0bHkgZXhjbHVkZQ0KPiB0aGUgY2FzZSB0byByZXNldCBz YW1lIG1ldGFkYXRhLCBidXQgImxhc3QgY29uZGl0aW9uIG1ldGFkYXRhIGdyb3VwIHRha2VzDQo+ IGVmZmVjdCB0aGF0IGlzIGEgZXh0cmVtZSBjYXNlIGZvciByZXNldGluZyBzYW1lIG1ldGFkYXRh IHZpYSBtdWx0aXBsZQ0KPiBjb25kaXRpb24gZ3JvdXAgSSB0aGluay4NCj4gDQo+ICAgVGhlICJs YXN0Ii1iYXNlZCBhcHByb2FjaCBnaXZlcyBwcmVjZWRlbmNlIHRvIG5ld2VyIHJ1bGVzPw0KPiBb WGlhb3lhbl0gUmlnaHQsIGJ1dCBvbmx5IHVuZGVyIHRoZSBjYXNlIHRoYXQgdGhlIGxhdHRlciBj b25kaXRpb24gZ3JvdXANCj4gYXJlIHRyeWluZyB0byByZXNldCBhIG1ldGFkYXRhIHRoYXQgYWxy ZWFkeSByZXNldGVkIGJ5IGEgcHJldmlvdXMNCj4gY29uZGl0aW9uIGdyb3VwLiBJZiB0aGUNCj4g bGF0dGVyIGNvbmRpdGlvbiBncm91cCBpcyB1c2VkIHRvIHJlc2V0IGRpZmZlcmVudCBtZXRhZGF0 YSB0aGFuIHRoZQ0KPiBwcmV2aW91cyBvbmVzLCB0aGVuICJwcmVjZWRlbmNlIiBkb2VzIG5vdCBt YWtlIHNlbnNlLg0KPiANCj4gDQo+ICAgVG8gcHJvcGVybHkgb3JkZXIgdGhlIGxpc3QsIGEgdUNE TiBtYXkgYmUgcmVxdWlyZWQgdG8gcmUtZXZhbHVhdGUgYW5kDQo+IHJlcGxhY2luZyBhbGwNCj4g ICBjb25kaXRpb25zIHdoZW5ldmVyIGEgbmV3IGNvbmRpdGlvbiBpcyBjcmVhdGVkLCB3aGljaCBt YXkgbm90IHNjYWxlPw0KPiBbWGlhb3lhbl0gVGhpcyBpcyBub3QgdHJ1ZS4gQSB1Q0ROIGRvZXMg bm90IG5lZWQgdG8gZG8gdGhhdCBhdCBhbGwuDQo+IExldCdzIHRha2UgYW4gZXhhbXBsZSAsIGlm IHRoZXJlIGFyZSBhbHJlYWR5IHR3byBjb25kaXRpb24gZ3JvdXAsDQo+IENvbmRpdGlvbiBHcm91 cDEgcmVzZXQgbWV0YWRhdGEgMSBvbmNlIGNvbmRpdGlvbiBBIGFuZCBCIGFyZSBtZXQuIENvbmRp dGluDQo+IEdyb3VwIDIgcmVzZXQNCj4gbWV0YWRhdGEgMiBvbmNlIGNvbmRpdGlvbiBDLCBELCBF IGFyZSBtZXQuICBOb3cgeW91IHdhbnQgdG8gY3JlYXRlIGEgbmV3DQo+IGNvbmRpdGlvbiBGIGZv ciBtZXRhZGF0YSAxLCBpZiB5b3UgZG8gbm90IHJlcXVpcmUgY29uZGl0aW9uIEEgYW5kIEINCj4g YXJlIG1ldCAgc2ltdWx0YW5lb3VzbHksIGp1c3QgY3JlYXRlIGEgbmV3IENvbmRpdGlvbiBHcm91 cCAzIGFuZCBwdXQgaXQNCj4gbGF0ZXIgdGhhbiBDb25kaXRpb24gR3JvdXAxLCB0aGF0J3MgZW5v dWdoLiAgSWYgeW91IHJlcXVpcmUgY29uZGl0aW9uIEEgLA0KPiBCIGFuZCB0aGUgbmV3DQo+IGNy ZWF0ZWQgY29uZGl0aW9uIEYgc2hvdWxkIGJlIG1ldCBzaW11dGFuZW91c2x5IHRvIHJlc2V0IG1l dGFkYXRhMSwgdGhlbg0KPiBqdXN0IGFkZCBjb25kaXRpb24gRiBpbnRvIGNvbmRpdGlvbiBncm91 cCAxLiAgIHVDRE4gZG9lcyBub3QgbmVlZCByZS0NCj4gZXZhbHVhdGUgYW5kDQo+IHJlcGxhY2lu ZyBhbGwgY29uZGl0aW9ucy4NCj4gDQo+IA0KPiANCj4gICBJcyB0aGVyZSBhIHByZWNlZGVuY2Ug b3JkZXIgZm9yIHRoZSBkaWZmZXJlbnQgY29uZGl0aW9uIGZpZWxkcz8gIEFuZCBpcw0KPiAgIHRo ZXJlIGEgYmVzdCBtYXRjaCBjcml0ZXJpYSBmb3IgdGhlIGNvbmRpdGlvbiB2YWx1ZSB0eXBlcz8g IFRoYXQgbWlnaHQNCj4gICBiZSBhbiBhbHRlcm5hdGl2ZT8NCj4gW1hpYW95YW5dIFRoZXJlIGlz IG5vIHByZWNlZGVuY2Ugb3JkZXIgZm9yIHRoZSBkaWZmZXJlbnQgY29uZGl0aW9uIGZpZWxkcy4N Cj4gTXVsdGlwbGUgY29uZGl0aW9ucw0KPiB3aXRoIGRpZmZlcmVudCBjb25kaXRpb24gZmllbGRz IGluIE9ORSBDT05ESVRJT04gR1JPVVAgYXJlIHVzZWQgaW4gQU5EDQo+IHJlbGF0aW9uLg0KPiAN Cj4gICBBcHBseWluZyBkaWZmZXJlbnQgc2V0cyBvZiBtZXRhZGF0YSB0byBhIGdpdmVuIGNvbnRl bnQgaXRlbSBpcyBhbg0KPiAgIGludGVyZXN0aW5nIGlkZWEsIGhvd2V2ZXIsIGltbywgYXBwbHlp bmcgc2V0cyBvZiBtZXRhZGF0YSB0bw0KPiAgIHNldHMgb2YgY29udGVudCBpcyBlYXNpZXIgdG8g Y29tcHJlaGVuZCAoZXNwZWNpYWxseSB3aXRoIGxhcmdlDQo+ICAgYW1vdW50cyBvZiBjb250ZW50 IGFuZCBvdmVybGFwcGluZyBtZXRhZGF0YSksDQo+IA0KPiBbWGlhb3lhbl0gVGhlIG1haW4gaWRl YSBvZiB0aGlzIGRyYWZ0IGlzIGFwcGx5aW5nIHNhbWUgZG9tYWluICBtZXRhZGF0YSB0bw0KPiBh bGwgY29udGVudHMgYmVsb25naW5nIHRvIGEgZGVsaXZlcnkgZG9tYWluLCAgYmVzaWRlcyB0aGF0 IHdlIGdpdmUgYW4NCj4gbWVjaGFuaXNtIHRoYXQgcmVmaW5lIHNvbWUga2luZCBvZiBtZXRhZGF0 YSBvZiBzb21lIHNwZWNpYWwgY29udGVudHMNCj4gaW4gdGhlIHNhbWUgZG9tYWluLiBJIHRoaW5r IHdlIGFyZSBkb2luZyB0aGUgc2FtZSB0aGluZywgYXBwbHlpbmcgc2V0cyBvZg0KPiBtZXRhZGF0 YSB0byBzZXRzIG9mIGNvbnRlbnQuDQo+IEFuZCB0aGUgbWVyaXQgb2Ygb3VyIHByb3Bvc2FsIGlz ICB3ZSBjYW4gc2F2ZSB0aGUgdm9sdW1lIG9mIG1ldGFkYXRhIHZlcnkNCj4gbGFyZ2VseSBhbmQg cHJvdmlkZSBnb29kIGV4dGVuc2liaWxpdHkgYW5kIGZsZXhpYmlsaXR5ICAuDQo+IA0KPiBpLmUu LCBrZWVwIFVSSSBzZXBhcmF0ZQ0KPiAgIGFuZCBhbHdheXMgbWF0Y2ggVVJJIGZpcnN0IGJlZm9y ZSBhcHBseWluZyBvdGhlciBjb25kaXRpb24gbWV0YWRhdGE7DQo+ICAgY29uZGl0aW9uIG1ldGFk YXRhIHdvdWxkIG9ubHkgYXBwbHkgdG8gc3BlY2lmaWMgVVJJcz8NCj4gW1hpYW95YW5dIFdlIGRv IG1hdGNoIFVSSSBmaXJzdCwgaW4gb3VyIHByb3Bvc2FsLCBvbmNlIGEgZENETiByZWNlaXZlcyBh DQo+IGNvbnRlbnQgcmVxdWVzdCwNCj4gaG9zdG5hbWUgb2YgdGhlIFVSSSBtdXN0IGZpcnN0IGJl IGNoZWNrZWQgdG8gZmluZCBvdXQgdGhlIG1ldGFkYXRhIG5lZWRzDQo+IHRvIGJlIGFwcGxpZWQu DQo+IEhvcGUgdGhpcyBoZWxwcy4NCj4gDQo+IHRoYW54Lg0KPiANCj4gLS0gIEtldmluIEouIE1h DQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogY2RuaS1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YN Cj4gPiBIZVhpYW95YW4NCj4gPiBTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAyMCwgMjAxMSAzOjU2 IEFNDQo+ID4gVG86IGNkbmlAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBbQ0ROaV0gRlc6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGl1LWNkbmktDQo+IG1ldGFkYXRhLQ0KPiA+ IGludGVyZmFjZS0wMS50eHQNCj4gPg0KPiA+IEhpIGFsbCwNCj4gPiBJJ3ZlIHVwbG9hZGVkIGFu IHVwZGF0ZWQgdmVyc2lvbiBvZiBkcmFmdC1saXUtY2RuaS1tZXRhZGF0YS1pbnRlcmZhY2UNCj4g d2l0aA0KPiA+IHNvbWUgdHlwb3MgY29ycmVjdGVkLg0KPiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcv aWQvZHJhZnQtbGl1LWNkbmktbWV0YWRhdGEtaW50ZXJmYWNlLTAxLnR4dA0KPiA+DQo+ID4gWW91 ciBjb21tZW50cyBhcmUgd2VsY29tZS4NCj4gPg0KPiA+IFdpc2ggeW91IGFsbCBhIGhhcHB5IGhv bGlkYXkgc2Vhc29uIQ0KPiA+DQo+ID4gQmVzdCBSZWdhcmRzDQo+ID4gWGlhb3lhbihTdXNhbikg SGUNCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiA+ IFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDIwLCAyMDExIDM6MjIgUE0NCj4gPiBUbzogaGV4aWFv eWFuQGh1YXdlaS5jb20NCj4gPiBDYzogaGV4aWFveWFuQGh1YXdlaS5jb207IGd1bmFAaHVhd2Vp LmNvbTsgbGlqaW5jaGVuZ0BodWF3ZWkuY29tOw0KPiA+IHhpYW9tZWkuc2MubGl1QGh1YXdlaS5j b20NCj4gPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpdS1j ZG5pLW1ldGFkYXRhLWludGVyZmFjZS0NCj4gPiAwMS50eHQNCj4gPg0KPiA+IEEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC1saXUtY2RuaS1tZXRhZGF0YS1pbnRlcmZhY2UtMDEudHh0IGhhcyBi ZWVuDQo+ID4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBYaWFveWFuIEhlIGFuZCBwb3N0ZWQg dG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gPg0KPiA+IEZpbGVuYW1lOiAgICAgIGRyYWZ0LWxp dS1jZG5pLW1ldGFkYXRhLWludGVyZmFjZQ0KPiA+IFJldmlzaW9uOiAgICAgIDAxDQo+ID4gVGl0 bGU6ICAgICAgICAgICAgICAgICBDb250ZW50IERpc3RyaWJ1dGlvbiBOZXR3b3JrIEludGVyY29u bmVjdGlvbg0KPiAoQ0ROSSkNCj4gPiBNZXRhZGF0YSBJbnRlcmZhY2UNCj4gPiBDcmVhdGlvbiBk YXRlOiAgICAgICAgIDIwMTEtMTItMjANCj4gPiBXRyBJRDogICAgICAgICAgICAgICAgIEluZGl2 aWR1YWwgU3VibWlzc2lvbg0KPiA+IE51bWJlciBvZiBwYWdlczogMjINCj4gPg0KPiA+IEFic3Ry YWN0Og0KPiA+ICAgVGhlIE1ldGFkYXRhIEludGVyZmFjZSBpcyBvbmUgb2YgdGhlIGNvcmUgaW50 ZXJmYWNlcyBkZWZpbmVkIGJ5IHRoZQ0KPiA+ICAgSUVURiBDb250ZW50IERpc3RyaWJ1dGlvbiBO ZXR3b3JrIEludGVyY29ubmVjdGlvbiAoQ0ROSSkgV29ya2luZw0KPiA+ICAgR3JvdXAuIFRoZSBw cmltYXJ5IGZ1bmN0aW9uIG9mIHRoZSBDRE5JIE1ldGFkYXRhIEludGVyZmFjZSBpcyB0bw0KPiA+ ICAgYWxsb3cgaW50ZXJjb25uZWN0ZWQgQ0ROcyB0byBjb21tdW5pY2F0ZSBtZXRhZGF0YSBpbiBv cmRlciB0byBlbnN1cmUNCj4gPiAgIGNvbnRlbnQgZGVsaXZlcnkgYW5kIGNvbnRlbnQgYWNxdWlz aXRpb24uIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUNCj4gPiAgIG1ldGFkYXRhIGV4Y2hhbmdl IHByb3RvY29sIGJldHdlZW4gYW4gdXBzdHJlYW0gQ0ROIGFuZCBhIGRvd25zdHJlYW0NCj4gPiAg IENETiBmb3IgdGhlIGNvbnRlbnQgZGVsaXZlcnkuIEl0IGFsc28gZGVmaW5lcyBtZXRhZGF0YSBv YmplY3RzDQo+ID4gICBlc3BlY2lhbGx5IGNvbmRpdGlvbiBtZXRhZGF0YSBvYmplY3QgZm9yIENE TkkuDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiA+DQo+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBD RE5pIG1haWxpbmcgbGlzdA0KPiA+IENETmlAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkNCg== From roy@skytide.com Fri Mar 30 11:34: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 1713E21F867D for ; Fri, 30 Mar 2012 11:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 fXUSa+SBW+Zm for ; Fri, 30 Mar 2012 11:33:48 -0700 (PDT) Received: from mail-pop3-1.server101.com (ns1.giga-sj-001.net [216.218.210.201]) by ietfa.amsl.com (Postfix) with ESMTP id 7271521F867C for ; Fri, 30 Mar 2012 11:33:48 -0700 (PDT) Received: from [172.16.4.31] (24-104-66-42-ip-static.hfc.comcastbusiness.net [24.104.66.42]) (authenticated as roy@skytide.com with PLAIN (0 bits)) by mail-pop3-1.server101.com (8.13.7/8.12.8) with ESMTP id q2UIXfNw028555; Sat, 31 Mar 2012 04:33:41 +1000 Message-ID: <4F75FC84.2030600@skytide.com> Date: Fri, 30 Mar 2012 11:33:40 -0700 From: Roy Peterkofsky User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Kevin J Ma References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> <291CC3F9E50E7641901A54E85D0977C65260911CB7@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C65260911CB7@MAILR002.mail.lan> Content-Type: multipart/alternative; boundary="------------090404040001020709070006" Cc: "cdni@ietf.org" , Viveganandhan Mahesh Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-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: Fri, 30 Mar 2012 18:34:02 -0000 This is a multi-part message in MIME format. --------------090404040001020709070006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit It sounds like there is clearly a need to have standards for logging that cover two different scenarios: 1) Where the dCDN is ABR-aware and can produce session-level logs 2) Where the dCDN is not ABR-aware and can only produce transaction-level (event- or fragment-level) logs I believe that the second scenario is required while the first is more optional/nice-to-have. It would certainly be better to have it than not although I think it would be by far the less common situation. The discussion of possibly allowing the uCDN to specify (via metadata transfer or other means) which log fields or formats it wishes to receive actually, I feel, calls for stepping back and reviewing whether we should have purely a logging interface or more of a reporting or query interface. That would, I imagine, allow the uCDN to specify: 1) what transactions do I want data about (specified by date range and possibly other filter criteria) 2) what attributes and measures do I want to receive in my data 3) what level of aggregation do I want the data at (including for example, at the session level or individual file level) On 3/30/2012 2:24 AM, Kevin J Ma wrote: > Hi Francois, > > Wrt a flexible set of log fields, I think that it is a great idea, and > it would be great if we could use metadata to specify log formats for > specific content items or sets of content items. It is useful for both > content-specific logging (e.g., ABR), as well as client-specific logging > (e.g., X-* headers). For the W3C format, a separate log file for each > format could result in a lot of files? Would aggregation cover that? > > thanx. > > -- Kevin J. Ma > >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of >> Francois Le Faucheur >> Sent: Tuesday, March 13, 2012 2:39 PM >> To: Kent Leung (kleung); Niven-Jenkins Ben >> Cc: cdni@ietf.org; Viveganandhan Mahesh >> Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 >> >> Ben, Kent, >> >> Trying to extract the key points from the thread: >> >> 1) level of requirement for support of HTTP Adaptive Streaming Logging >> Session (ie ABR-aware logs): >> This is a valid question. >> The I-D proposes that some form of ABR-aware logging be mandatory. The >> rationale is that ABR is expected to be a very common delivery format and >> requires some form of log compression over very voluminous per-segment >> logging. (BTW the I-D currently proposes that both Segment-Based Logging >> format and Event-Based Logging format be mandatory. But come to think of >> it, having only Event-Based Logging format mandatory would be sufficient >> from my viewpoint). >> Ben argues that ABR-aware logging should not be mandatory as it requires >> extra awareness. >> To get more input, I'd propose we move that requirement level discussion >> to the cdni-requirements document, and have the logging I-D only talks >> about what such logs would look like. >> >> >> 2) flexible set of log fields: >> I agree it is a good idea to allow the uCDN to customize the set of log >> fields reported by a dCDN for delivery. I was thinking that we'd start >> with defining a few "fixed" set of fields and then later add the >> customization, but perhaps we can start directly with customizable sets of >> fields. >> To do that, I'd propose to: >> * retain the notion of Format Types (e.g Delivery_HTTP, >> Delivery_Adaptive_Event, ...) >> * define a set of candidate fields in each Format Type >> * have uCDN signal in Metadata interface the desired Format Type + >> set of fields needed (ie a subset of the set of candidate fields) >> * have dCDN explicitly indicate inside each log file (eg in File >> Header), the Format Type and the set of fields actually included >> * define handling of potential capability mismatch situations if any >> (eg1 uCDN requests a field that is not supported by dCDN if we allow that, >> eg2 dCDN requests a format type that is not supported by dCDN). >> >> >> 3) encoding format: >> I also agree the W3C extended log format is a good base candidate to look >> at. >> >> >> 4) summarization of Logging info for Adaptive Streaming delivery >> I believe some form of summarization is required. The Event-Based Logging >> seems like a nice sweet-spot because it achieves a high summarization gain >> without losing any info (ie any change in bandwidth/quality is logged). >> The I-D suggests we may be able to come up with another interesting sweet- >> spot (Summary-Based Log) providing a huge summarization gain at the cost >> of losing some details, but does not yet specify this. >> Ben, it'd be interesting to provide a brief write-up on the summarization >> approach you mention so we can evaluate it (an email to the list woudl be >> just fine). >> >> >> Thanks for the discussion. >> >> Francois >> >> >> On 9 Mar 2012, at 00:48, Kent Leung (kleung) wrote: >> >>> Comments below. >>> >>>> -----Original Message----- >>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf >>> Of >>>> Some comments on draft-lefaucheur-cdni-logging-delivery-00. >>>> >>>> 1) In section 3.2.1.2 (Segment-Based Log fields) and section 3.2.2.1 >>>> (Event Based Log Triggers) you mandate support for a number of log >>>> fields such as abr-protocol, representation, manifest-id and >>> content-id >>>> that a downstream CDN may have no ability to generate, for example >>>> because the downstream CDN is acting in a pure HTTP reverse proxy mode >>>> and may not be aware of that level of information and/or because the >>>> control of how to identify those fields is owned by the CSP and none >>> of >>>> CDNs may have visibility of that mapping information. >>>> >>>> Such a requirement to force CDNs and CDNI in general to require such >>>> mappings seems overkill to me. >>>> >>>> KL> As stated, "... such aggregation requires a degree of application >>>> awareness in dCDN to recognize that the many HTTP requests correspond >>> to >>>> a single video." So the premise is that the dCDN knows that it's >>>> delivering ABR content. In some cases, it's possible that the >>>> representation may not be known. >>> And my point is that I don't think that premise holds true and reality >>> is the opposite, i.e. in general the dCDN will not know what it's >>> delivering and only some dCDNs will have the application awareness to >>> produce the log fields you suggest. >>> >>> KL> Hmm, if the dCDN is not aware about the ABR session, then Section >>> 3.2 would not apply since the dCDN considers itself to be delivering >>> non-ABR content. Non-ABR content delivery does not require the log >>> fields specified in this section. >>> >>> >>>> But in general, the log fields contain >>>> information that are pertinent to an ABR content. >>> I am not exactly sure what you mean by this. I agree the fields you >>> suggest would be useful but I don't think having the application >>> awareness to generate them should be a mandatory requirement for >>> interoperability as suggested by section 3.2 >>> >>> An implementation of the CDNI Logging interface MUST support logging >>> for delivery of content using HTTP adaptive streaming in the Segment- >>> Based Logging format and the Event-Based Logging format, and MAY >>> support logging in the Summary-Based Logging format. >>> >>> KL> Are these fields in Sect 3.2 useful or applicable for non-ABR >>> content delivery? No. I sense that I'm still missing your point. >>> >>> >>>> 2) In section 6 you propose an additional requirement to allow an >>>> upstream CDN to indicate through CDNI metadata the log format the >>>> downstream CDN should use. Rather than define a set of specific >>> formats, >>>> we could allow the upstream CDN to specify CDNI metadata indicating >>> the >>>> specific log fields it is interested in receiving. The upstream CDN >>>> could then tailor what it asks for according to what it requires and >>>> avoid the transfer of log fields that it does not need. >>>> >>>> KL> Agree that it's useful for uCDN to request only the information >>>> that's needed without extraneous fields. This can be accomplished with >>> a >>>> customized log format provided by uCDN. In a sense, this is a superset >>>> of selective fields. >>> That is another approach which would probably make life easier for the >>> dCDN. >>> >>>> 4) If the motivation for summary/aggregated log lines is a concern >>> over >>>> the volume of data that needs to be transferred then in Velocix we >>> have >>>> done some experiments on using an alternative lookup table based >>>> structure for log lines that retains all the verbosity of the original >>>> delivery log lines but by itself appears to give equivalent >>> compression >>>> to gzip and combined with gzip reduces the size significantly when >>>> compared to what gzip alone achieves (in some cases averaging as >>> little >>>> as 13 bits per complete log line). >>>> >>>> If the volume of logs to be transferred is a concern and there is >>>> interest in investigating this approach further I can write-up more >>>> details either in a separate draft or as a section in >>>> draft-lefaucheur-cdni-logging-delivery. >>>> >>>> KL> I think the intent is to summarize succinctly the ABR session in >>> the >>>> logging. >>> I think they're two separate things. If we're worried about the volume >>> of data our experiments show that can be significantly reduced using >>> structured log files with lookup tables. That technique is applicable >>> regardless of the actual fields in a log file. >>> >>> Whether we require ABR session summary information to be logged is a >>> separate discussion to how we might optimise the structure of any log >>> files we require. >>> >>> Ben >>> >>> KL> Sure, I think we can discuss more on this when Francois is available >>> as I'm not clear on his thoughts. >>> >>> Kent >>> >>>> I haven't discussed this in finer details with Francois yet. It >>>> seems to me that the compression technique can be considered as >>>> optimization in delivery of either session-based or event-based >>> logging. >>>> We can discuss this further if our goals are aligned. >>>> >>>> Kent >>>> >>>> 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 >> _______________________________________________ >> 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 > -- Roy Peterkofsky Vice President, Product Management Skytide -- the leader in Digital Media Performance Management www.skytide.com (510) 250-4284 Read our new white paper: The 4 Keys to Telco CDN Success --------------090404040001020709070006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit It sounds like there is clearly a need to have standards for logging that cover two different scenarios:

1) Where the dCDN is ABR-aware and can produce session-level logs
2) Where the dCDN is not ABR-aware and can only produce transaction-level (event- or fragment-level) logs

I believe that the second scenario is required while the first is more optional/nice-to-have.  It would certainly be better to have it than not although I think it would be by far the less common situation.

The discussion of possibly allowing the uCDN to specify (via metadata transfer or other means) which log fields or formats it wishes to receive actually, I feel, calls for stepping back and reviewing whether we should have purely a logging interface or more of a reporting or query interface.  That would, I imagine, allow the uCDN to specify:

1) what transactions do I want data about (specified by date range and possibly other filter criteria)
2) what attributes and measures do I want to receive in my data
3) what level of aggregation do I want the data at (including for example, at the session level or individual file level)

On 3/30/2012 2:24 AM, Kevin J Ma wrote: 
Hi Francois,

  Wrt a flexible set of log fields, I think that it is a great idea, and
  it would be great if we could use metadata to specify log formats for
  specific content items or sets of content items.  It is useful for both
  content-specific logging (e.g., ABR), as well as client-specific logging
  (e.g., X-* headers).  For the W3C format, a separate log file for each
  format could result in a lot of files?  Would aggregation cover that?

thanx.

--  Kevin J. Ma


-----Original Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of
Francois Le Faucheur
Sent: Tuesday, March 13, 2012 2:39 PM
To: Kent Leung (kleung); Niven-Jenkins Ben
Cc: cdni@ietf.org; Viveganandhan Mahesh
Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00

Ben, Kent,

Trying to extract the key points from the thread:

1) level of requirement for support of HTTP Adaptive Streaming Logging
Session (ie ABR-aware logs):
This is a valid question.
The I-D proposes that some form of ABR-aware logging be mandatory. The
rationale is that ABR is expected to be a very common delivery format and
requires some form of log compression over very voluminous per-segment
logging. (BTW the I-D currently proposes that both Segment-Based Logging
format and Event-Based Logging format be mandatory. But come to think of
it, having only Event-Based Logging format mandatory would be sufficient
from my viewpoint).
Ben argues that ABR-aware logging should not be mandatory as it requires
extra awareness.
To get more input, I'd propose we move that requirement level discussion
to the cdni-requirements document, and have the logging I-D only talks
about what such logs would look like.


2) flexible set of log fields:
I agree it is a good idea to allow the uCDN to customize the set of log
fields reported by a dCDN for delivery. I was thinking that we'd start
with defining a few "fixed" set of fields and then later add the
customization, but perhaps we can start directly with customizable sets of
fields.
To do that, I'd propose to:
	* retain the notion of Format Types (e.g Delivery_HTTP,
Delivery_Adaptive_Event, ...)
	* define a set of candidate fields in each Format Type
	* have uCDN signal in Metadata interface the desired Format Type +
set of fields needed (ie a subset of the set of candidate fields)
	* have dCDN explicitly indicate inside each log file (eg in File
Header), the Format Type and the set of fields actually included
	* define handling of potential capability mismatch situations if any
(eg1 uCDN requests a field that is not supported by dCDN if we allow that,
eg2 dCDN requests a format type that is not supported by dCDN).


3) encoding format:
I also agree the W3C extended log format is a good base candidate to look
at.


4) summarization of Logging info for Adaptive Streaming delivery
I believe some form of summarization is required. The Event-Based Logging
seems like a nice sweet-spot because it achieves a high summarization gain
without losing any info (ie any change in bandwidth/quality is logged).
The I-D suggests we may be able to come up with another interesting sweet-
spot (Summary-Based Log) providing a huge summarization gain at the cost
of losing some details, but does not yet specify this.
Ben, it'd be interesting to provide a brief write-up on the summarization
approach you mention so we can evaluate it (an email to the list woudl be
just fine).


Thanks for the discussion.

Francois


On 9 Mar 2012, at 00:48, Kent Leung (kleung) wrote:


Comments below.


-----Original Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf

Of

Some comments on draft-lefaucheur-cdni-logging-delivery-00.

1) In section 3.2.1.2 (Segment-Based Log fields) and section 3.2.2.1
(Event Based Log Triggers) you mandate support for a number of log
fields such as abr-protocol, representation, manifest-id and

content-id

that a downstream CDN may have no ability to generate, for example
because the downstream CDN is acting in a pure HTTP reverse proxy mode
and may not be aware of that level of information and/or because the
control of how to identify those fields is owned by the CSP and none

of

CDNs may have visibility of that mapping information.

Such a requirement to force CDNs and CDNI in general to require such
mappings seems overkill to me.

KL> As stated, "... such aggregation requires a degree of application
awareness in dCDN to recognize that the many HTTP requests correspond

to

a single video." So the premise is that the dCDN knows that it's
delivering ABR content. In some cases, it's possible that the
representation may not be known.

And my point is that I don't think that premise holds true and reality
is the opposite, i.e. in general the dCDN will not know what it's
delivering and only some dCDNs will have the application awareness to
produce the log fields you suggest.

KL> Hmm, if the dCDN is not aware about the ABR session, then Section
3.2 would not apply since the dCDN considers itself to be delivering
non-ABR content.  Non-ABR content delivery does not require the log
fields specified in this section.



But in general, the log fields contain
information that are pertinent to an ABR content.

I am not exactly sure what you mean by this. I agree the fields you
suggest would be useful but I don't think having the application
awareness to generate them should be a mandatory requirement for
interoperability as suggested by section 3.2

  An implementation of the CDNI Logging interface MUST support logging
  for delivery of content using HTTP adaptive streaming in the Segment-
  Based Logging format and the Event-Based Logging format, and MAY
  support logging in the Summary-Based Logging format.

KL> Are these fields in Sect 3.2 useful or applicable for non-ABR
content delivery? No. I sense that I'm still missing your point.



2) In section 6 you propose an additional requirement to allow an
upstream CDN to indicate through CDNI metadata the log format the
downstream CDN should use. Rather than define a set of specific

formats,

we could allow the upstream CDN to specify CDNI metadata indicating

the

specific log fields it is interested in receiving. The upstream CDN
could then tailor what it asks for according to what it requires and
avoid the transfer of log fields that it does not need.

KL> Agree that it's useful for uCDN to request only the information
that's needed without extraneous fields. This can be accomplished with

a

customized log format provided by uCDN. In a sense, this is a superset
of selective fields.

That is another approach which would probably make life easier for the
dCDN.


4) If the motivation for summary/aggregated log lines is a concern

over

the volume of data that needs to be transferred then in Velocix we

have

done some experiments on using an alternative lookup table based
structure for log lines that retains all the verbosity of the original
delivery log lines but by itself appears to give equivalent

compression

to gzip and combined with gzip reduces the size significantly when
compared to what gzip alone achieves (in some cases averaging as

little

as 13 bits per complete log line).

If the volume of logs to be transferred is a concern and there is
interest in investigating this approach further I can write-up more
details either in a separate draft or as a section in
draft-lefaucheur-cdni-logging-delivery.

KL> I think the intent is to summarize succinctly the ABR session in

the

logging.

I think they're two separate things. If we're worried about the volume
of data our experiments show that can be significantly reduced using
structured log files with lookup tables. That technique is applicable
regardless of the actual fields in a log file.

Whether we require ABR session summary information to be logged is a
separate discussion to how we might optimise the structure of any log
files we require.

Ben

KL> Sure, I think we can discuss more on this when Francois is available
as I'm not clear on his thoughts.

Kent


I haven't discussed this in finer details with Francois yet. It
seems to me that the compression technique can be considered as
optimization in delivery of either session-based or event-based

logging.

We can discuss this further if our goals are aligned.

Kent

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

_______________________________________________
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


--
Roy Peterkofsky
Vice President, Product Management
Skytide -- the leader in Digital Media Performance Management
www.skytide.com
(510) 250-4284

Read our new white paper: The 4 Keys to Telco CDN Success
--------------090404040001020709070006-- From kevin.ma@azukisystems.com Fri Mar 30 11:51: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 34A7A21F8622 for ; Fri, 30 Mar 2012 11:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.302, 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 89PbZiI8ZYol for ; Fri, 30 Mar 2012 11:51:24 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id E365B21F861A for ; Fri, 30 Mar 2012 11:51:23 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 1C9098BEAC2; Fri, 30 Mar 2012 14:51:20 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.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 6FB048BE99A; Fri, 30 Mar 2012 14:51:18 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Fri, 30 Mar 2012 14:51:01 -0400 From: Kevin J Ma To: Roy Peterkofsky Date: Fri, 30 Mar 2012 14:51:15 -0400 Thread-Topic: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 Thread-Index: Ac0Oo6WHKiBRJsUgR5q2bPVGSEZbiwAAMgXA Message-ID: <291CC3F9E50E7641901A54E85D0977C65260911EC7@MAILR002.mail.lan> References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> <291CC3F9E50E7641901A54E85D0977C65260911CB7@MAILR002.mail.lan> <4F75FC84.2030600@skytide.com> In-Reply-To: <4F75FC84.2030600@skytide.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_291CC3F9E50E7641901A54E85D0977C65260911EC7MAILR002maill_" MIME-Version: 1.0 Cc: "cdni@ietf.org" , Viveganandhan Mahesh Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-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: Fri, 30 Mar 2012 18:51:27 -0000 --_000_291CC3F9E50E7641901A54E85D0977C65260911EC7MAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roy, > The discussion of possibly allowing the uCDN to specify (via > metadata transfer or other means) which log fields or formats it > wishes to receive actually, I feel, calls for stepping back and > reviewing whether we should have purely a logging interface or more > of a reporting or query interface Regardless of how the data is retrieved (push or pull), the dCDN needs to know whether or not it needs to extract the data. It may be that the dCDN does not automatically extract the X-foo header, and the metadata specifies that the X-foo header is desired. I think that would be needed even if it was a query interface? -- Kevin J. Ma From: Roy Peterkofsky [mailto:roy@skytide.com] Sent: Friday, March 30, 2012 2:34 PM To: Kevin J Ma Cc: Francois Le Faucheur; Kent Leung (kleung); Niven-Jenkins Ben; cdni@ietf= .org; Viveganandhan Mahesh Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 It sounds like there is clearly a need to have standards for logging that c= over two different scenarios: 1) Where the dCDN is ABR-aware and can produce session-level logs 2) Where the dCDN is not ABR-aware and can only produce transaction-level (= event- or fragment-level) logs I believe that the second scenario is required while the first is more opti= onal/nice-to-have. It would certainly be better to have it than not althou= gh I think it would be by far the less common situation. The discussion of possibly allowing the uCDN to specify (via metadata trans= fer or other means) which log fields or formats it wishes to receive actual= ly, I feel, calls for stepping back and reviewing whether we should have pu= rely a logging interface or more of a reporting or query interface. That w= ould, I imagine, allow the uCDN to specify: 1) what transactions do I want data about (specified by date range and poss= ibly other filter criteria) 2) what attributes and measures do I want to receive in my data 3) what level of aggregation do I want the data at (including for example, = at the session level or individual file level) On 3/30/2012 2:24 AM, Kevin J Ma wrote: Hi Francois, Wrt a flexible set of log fields, I think that it is a great idea, and it would be great if we could use metadata to specify log formats for specific content items or sets of content items. It is useful for both content-specific logging (e.g., ABR), as well as client-specific logging (e.g., X-* headers). For the W3C format, a separate log file for each format could result in a lot of files? Would aggregation cover that? thanx. -- Kevin J. Ma -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Francois Le Faucheur Sent: Tuesday, March 13, 2012 2:39 PM To: Kent Leung (kleung); Niven-Jenkins Ben Cc: cdni@ietf.org; Viveganandhan Mahesh Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 Ben, Kent, Trying to extract the key points from the thread: 1) level of requirement for support of HTTP Adaptive Streaming Logging Session (ie ABR-aware logs): This is a valid question. The I-D proposes that some form of ABR-aware logging be mandatory. The rationale is that ABR is expected to be a very common delivery format and requires some form of log compression over very voluminous per-segment logging. (BTW the I-D currently proposes that both Segment-Based Logging format and Event-Based Logging format be mandatory. But come to think of it, having only Event-Based Logging format mandatory would be sufficient from my viewpoint). Ben argues that ABR-aware logging should not be mandatory as it requires extra awareness. To get more input, I'd propose we move that requirement level discussion to the cdni-requirements document, and have the logging I-D only talks about what such logs would look like. 2) flexible set of log fields: I agree it is a good idea to allow the uCDN to customize the set of log fields reported by a dCDN for delivery. I was thinking that we'd start with defining a few "fixed" set of fields and then later add the customization, but perhaps we can start directly with customizable sets of fields. To do that, I'd propose to: * retain the notion of Format Types (e.g Delivery_HTTP, Delivery_Adaptive_Event, ...) * define a set of candidate fields in each Format Type * have uCDN signal in Metadata interface the desired Format Type + set of fields needed (ie a subset of the set of candidate fields) * have dCDN explicitly indicate inside each log file (eg in File Header), the Format Type and the set of fields actually included * define handling of potential capability mismatch situations if any (eg1 uCDN requests a field that is not supported by dCDN if we allow that, eg2 dCDN requests a format type that is not supported by dCDN). 3) encoding format: I also agree the W3C extended log format is a good base candidate to look at. 4) summarization of Logging info for Adaptive Streaming delivery I believe some form of summarization is required. The Event-Based Logging seems like a nice sweet-spot because it achieves a high summarization gain without losing any info (ie any change in bandwidth/quality is logged). The I-D suggests we may be able to come up with another interesting sweet- spot (Summary-Based Log) providing a huge summarization gain at the cost of losing some details, but does not yet specify this. Ben, it'd be interesting to provide a brief write-up on the summarization approach you mention so we can evaluate it (an email to the list woudl be just fine). Thanks for the discussion. Francois On 9 Mar 2012, at 00:48, Kent Leung (kleung) wrote: Comments below. -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Some comments on draft-lefaucheur-cdni-logging-delivery-00. 1) In section 3.2.1.2 (Segment-Based Log fields) and section 3.2.2.1 (Event Based Log Triggers) you mandate support for a number of log fields such as abr-protocol, representation, manifest-id and content-id that a downstream CDN may have no ability to generate, for example because the downstream CDN is acting in a pure HTTP reverse proxy mode and may not be aware of that level of information and/or because the control of how to identify those fields is owned by the CSP and none of CDNs may have visibility of that mapping information. Such a requirement to force CDNs and CDNI in general to require such mappings seems overkill to me. KL> As stated, "... such aggregation requires a degree of application awareness in dCDN to recognize that the many HTTP requests correspond to a single video." So the premise is that the dCDN knows that it's delivering ABR content. In some cases, it's possible that the representation may not be known. And my point is that I don't think that premise holds true and reality is the opposite, i.e. in general the dCDN will not know what it's delivering and only some dCDNs will have the application awareness to produce the log fields you suggest. KL> Hmm, if the dCDN is not aware about the ABR session, then Section 3.2 would not apply since the dCDN considers itself to be delivering non-ABR content. Non-ABR content delivery does not require the log fields specified in this section. But in general, the log fields contain information that are pertinent to an ABR content. I am not exactly sure what you mean by this. I agree the fields you suggest would be useful but I don't think having the application awareness to generate them should be a mandatory requirement for interoperability as suggested by section 3.2 An implementation of the CDNI Logging interface MUST support logging for delivery of content using HTTP adaptive streaming in the Segment- Based Logging format and the Event-Based Logging format, and MAY support logging in the Summary-Based Logging format. KL> Are these fields in Sect 3.2 useful or applicable for non-ABR content delivery? No. I sense that I'm still missing your point. 2) In section 6 you propose an additional requirement to allow an upstream CDN to indicate through CDNI metadata the log format the downstream CDN should use. Rather than define a set of specific formats, we could allow the upstream CDN to specify CDNI metadata indicating the specific log fields it is interested in receiving. The upstream CDN could then tailor what it asks for according to what it requires and avoid the transfer of log fields that it does not need. KL> Agree that it's useful for uCDN to request only the information that's needed without extraneous fields. This can be accomplished with a customized log format provided by uCDN. In a sense, this is a superset of selective fields. That is another approach which would probably make life easier for the dCDN. 4) If the motivation for summary/aggregated log lines is a concern over the volume of data that needs to be transferred then in Velocix we have done some experiments on using an alternative lookup table based structure for log lines that retains all the verbosity of the original delivery log lines but by itself appears to give equivalent compression to gzip and combined with gzip reduces the size significantly when compared to what gzip alone achieves (in some cases averaging as little as 13 bits per complete log line). If the volume of logs to be transferred is a concern and there is interest in investigating this approach further I can write-up more details either in a separate draft or as a section in draft-lefaucheur-cdni-logging-delivery. KL> I think the intent is to summarize succinctly the ABR session in the logging. I think they're two separate things. If we're worried about the volume of data our experiments show that can be significantly reduced using structured log files with lookup tables. That technique is applicable regardless of the actual fields in a log file. Whether we require ABR session summary information to be logged is a separate discussion to how we might optimise the structure of any log files we require. Ben KL> Sure, I think we can discuss more on this when Francois is available as I'm not clear on his thoughts. Kent I haven't discussed this in finer details with Francois yet. It seems to me that the compression technique can be considered as optimization in delivery of either session-based or event-based logging. We can discuss this further if our goals are aligned. Kent 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 _______________________________________________ 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 -- Roy Peterkofsky Vice President, Product Management Skytide -- the leader in Digital Media Performance Management www.skytide.com (510) 250-4284 Read our new white paper: The 4 Keys to Telco CDN Success --_000_291CC3F9E50E7641901A54E85D0977C65260911EC7MAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Roy,

 

> The discussion of possibly allowing the uCD= N to specify (via

> metadata = transfer or other means) which log fields or formats it

> wishes to receive actually, I feel, calls for = stepping back and

> reviewing= whether we should have purely a logging interface or more

> of a reporting or query interface

 

Regardless of how the data is retrieved (push or pull), the dCDN<= o:p>

needs to know whether or not it = needs to extract the data.  It may

be that the dCDN does not automatically extract the X-foo header,

and the metadata specifies that t= he X-foo header is desired.  I

think that would be needed even if it was a query interface?=

 

--  Kevin J. Ma

 

From: Roy Peterkofsky [mailto:roy@skytide.com]
= Sent: Friday, March 30, 2012 2:34 PM
To: Kevin J Ma
= Cc: Francois Le Faucheur; Kent Leung (kleung); Niven-Jenkins Ben; cdni@= ietf.org; Viveganandhan Mahesh
Subject: Re: [CDNi] Comments on dr= aft-lefaucheur-cdni-logging-delivery-00

 

It sounds like= there is clearly a need to have standards for logging that cover two diffe= rent scenarios:

1) Where the dCDN is ABR-aware and can produce sessi= on-level logs
2) Where the dCDN is not ABR-aware and can only produce tr= ansaction-level (event- or fragment-level) logs

I believe that the s= econd scenario is required while the first is more optional/nice-to-have.&n= bsp; It would certainly be better to have it than not although I think it w= ould be by far the less common situation.

The discussion of possibly= allowing the uCDN to specify (via metadata transfer or other means) which = log fields or formats it wishes to receive actually, I feel, calls for step= ping back and reviewing whether we should have purely a logging interface o= r more of a reporting or query interface.  That would, I imagine, allo= w the uCDN to specify:

1) what transactions do I want data about (sp= ecified by date range and possibly other filter criteria)
2) what attrib= utes and measures do I want to receive in my data
3) what level of aggre= gation do I want the data at (including for example, at the session level o= r individual file level)

On 3/30/2012 2:24 AM, Kevin J Ma wrote: 

Hi Francois,
 
<= pre>  Wrt a flexible set of log fields, I think that it is a great ide= a, and
  it would be great if we could use metada=
ta to specify log formats for
  specific content =
items or sets of content items.  It is useful for both
  content-specific logging (e.g., ABR), as well as client-specif=
ic logging
  (e.g., X-* headers).  For the W=
3C format, a separate log file for each
  format =
could result in a lot of files?  Would aggregation cover that?
 
thanx.
=
 
--  Kevin J. Ma
 =
;
-----Original Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of
Francois Le Faucheur
Sent: Tuesday, March 13, =
2012 2:39 PM
To: Kent Leung (kleung); Niven-Jenkins Be=
n
Cc: cdni@ietf.org; Viveganandhan Mahesh
Subject: Re: [CDNi] Comments =
on draft-lefaucheur-cdni-logging-delivery-00
&nbs=
p;
Ben, Kent,
 
<=
pre>Trying to extract the key points from the thread:
=
 
1) level of requirement for support of HTTP Ada=
ptive Streaming Logging
Session (ie ABR-aware logs):
This is a valid question.
The I-D =
proposes that some form of ABR-aware logging be mandatory. The
rationale is that ABR is expected to be a very common delivery for=
mat and
requires some form of log compression over ver=
y voluminous per-segment
logging. (BTW the I-D current=
ly proposes that both Segment-Based Logging
format and=
 Event-Based Logging format be mandatory. But come to think of
it, having only Event-Based Logging format mandatory would be suff=
icient
from my viewpoint).
Ben ar=
gues that ABR-aware logging should not be mandatory as it requires
extra awareness.
To get more input, I'd p=
ropose we move that requirement level discussion
to th=
e cdni-requirements document, and have the logging I-D only talks
about what such logs would look like.
 
 
2) flexible set of log =
fields:
I agree it is a good idea to allow the uCDN to=
 customize the set of log
fields reported by a dCDN fo=
r delivery. I was thinking that we'd start
with defini=
ng a few "fixed" set of fields and then later add the<=
/pre>
customization, but perhaps we can start directly with customizabl=
e sets of
fields.
To do that, I'd=
 propose to:
 * retain the notion of Format Types (e.g=
 Delivery_HTTP,
Delivery_Adaptive_Event, ...)
 * define a set of candidate fields in each Format Type
 * have uCDN signal in Metadata interface the desired Format=
 Type +
set of fields needed (ie a subset of the set o=
f candidate fields)
 * have dCDN explicitly indicate i=
nside each log file (eg in File
Header), the Format Ty=
pe and the set of fields actually included
 * define h=
andling of potential capability mismatch situations if any
=

(eg1 uCDN requests a field that is not supported by dCDN if we allow t=
hat,
eg2 dCDN requests a format type that is not suppo=
rted by dCDN).
 
 =

3) encoding format:
I also agree the =
W3C extended log format is a good base candidate to look
at.
 
 
4) summarization of Logging info for Adaptive Streaming delivery
I believe some form of summarization is required. The E=
vent-Based Logging
seems like a nice sweet-spot becaus=
e it achieves a high summarization gain
without losing=
 any info (ie any change in bandwidth/quality is logged).
<=
pre>The I-D suggests we may be able to come up with another interesting swe=
et-
spot (Summary-Based Log) providing a huge summariz=
ation gain at the cost
of losing some details, but doe=
s not yet specify this.
Ben, it'd be interesting to pr=
ovide a brief write-up on the summarization
approach y=
ou mention so we can evaluate it (an email to the list woudl be<=
/pre>
just fine).
 
 
Thanks for the discussion.
 
Francois
 
 
On 9 Mar 2012, at 00:48, Kent Leung (kl=
eung) wrote:
 
Comments below.
 
 
-----Original Message-----=

From: cdni-b=
ounces@ietf.org [mailto:cdni-b=
ounces@ietf.org] On Behalf
Of
 
Some comments on draft-lefaucheur-cdni-logging-de=
livery-00.
 
1) In section 3=
.2.1.2 (Segment-Based Log fields) and section 3.2.2.1
=
(Event Based Log Triggers) you mandate support for a number of log
fields such as abr-protocol, representation, manifest-id and
content-id
that a downstream CDN may =
have no ability to generate, for example
because the d=
ownstream CDN is acting in a pure HTTP reverse proxy mode
<=
pre>and may not be aware of that level of information and/or because the
control of how to identify those fields is owned by the =
CSP and none
of
CDNs may have visibi=
lity of that mapping information.
 
Such a requirement to force CDNs and CDNI in general to require suc=
h
mappings seems overkill to me.
=
 
KL> As stated, "... such aggregation re=
quires a degree of application
awareness in dCDN to re=
cognize that the many HTTP requests correspond
to
a single video." So the premise is that the dCDN knows t=
hat it's
delivering ABR content. In some cases, it's p=
ossible that the
representation may not be known.=

 
And my point is t=
hat I don't think that premise holds true and reality
=
is the opposite, i.e. in general the dCDN will not know what it's
delivering and only some dCDNs will have the application awaren=
ess to
produce the log fields you suggest.<=
/pre>
 
KL> Hmm, if the dCDN is not aware =
about the ABR session, then Section
3.2 would not appl=
y since the dCDN considers itself to be delivering
non=
-ABR content.  Non-ABR content delivery does not require the log<=
/o:p>
fields specified in this section.
 
 
But in general, the log fields contain<=
o:p>
information that are pertinent to an ABR content.=

 
I am not exactly =
sure what you mean by this. I agree the fields you
sug=
gest would be useful but I don't think having the application
awareness to generate them should be a mandatory requirement for
interoperability as suggested by section 3.2<=
/pre>
 
  An implementation of the CDNI =
Logging interface MUST support logging
  for deli=
very of content using HTTP adaptive streaming in the Segment-
  Based Logging format and the Event-Based Logging format, and=
 MAY
  support logging in the Summary-Based Loggi=
ng format.
 
KL> Are thes=
e fields in Sect 3.2 useful or applicable for non-ABR
=
content delivery? No. I sense that I'm still missing your point.=

 
 
2) In section 6 you prop=
ose an additional requirement to allow an
upstream CDN=
 to indicate through CDNI metadata the log format the
=
downstream CDN should use. Rather than define a set of specific<=
/pre>
formats,
we could allow the upstream CDN to spe=
cify CDNI metadata indicating
the
sp=
ecific log fields it is interested in receiving. The upstream CDN
could then tailor what it asks for according to what it require=
s and
avoid the transfer of log fields that it does no=
t need.
 
KL> Agree that =
it's useful for uCDN to request only the information
t=
hat's needed without extraneous fields. This can be accomplished with<=
/o:p>
a
customized log format provided by uCDN.=
 In a sense, this is a superset
of selective fields.
 
That is anothe=
r approach which would probably make life easier for the
dCDN.
 
4) If the motivation for summary/=
aggregated log lines is a concern
over
the volume of data that needs to be transferred then in Velocix we<=
/o:p>
have
done some experiments on using an al=
ternative lookup table based
structure for log lines t=
hat retains all the verbosity of the original
delivery=
 log lines but by itself appears to give equivalent
compression
to gzip and combined with gzip reduces the size=
 significantly when
compared to what gzip alone achiev=
es (in some cases averaging as
little
as 13 bits per complete log line).
 =

If the volume of logs to be transferred is a concern and there i=
s
interest in investigating this approach further I ca=
n write-up more
details either in a separate draft or =
as a section in
draft-lefaucheur-cdni-logging-delivery=
.
 
KL> I think the inten=
t is to summarize succinctly the ABR session in
the
logging.
 
I think they're two separate things. If we're worried about the=
 volume
of data our experiments show that can be signi=
ficantly reduced using
structured log files with looku=
p tables. That technique is applicable
regardless of t=
he actual fields in a log file.
 
Whether we require ABR session summary information to be logged is a<=
o:p>
separate discussion to how we might optimise the struc=
ture of any log
files we require.
 
Ben
 
KL> Sure, I think we can discuss more on this when Francois is av=
ailable
as I'm not clear on his thoughts.
 
Kent
 <=
/o:p>
=
I haven't discussed this in finer details with Francois yet. It<=
/pre>
seems to me that the compression technique can be considered as
optimization in delivery of either session-based or eve=
nt-based
logging.
We can discuss thi=
s further if our goals are aligned.
 <=
/pre>
Kent
 
Ben
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni=

 
_________________=
______________________________
CDNi mailing list<=
/o:p>
CDNi@ietf.org
https:/=
/www.ietf.org/mailman/listinfo/cdni
<=
o:p> 
_______________________________________________<=
o:p>
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/=
cdni
________________________________=
_______________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/m=
ailman/listinfo/cdni
 
 
-- 
Roy Peterkofsky
Vice President, Product Managem=
ent
Skytide -- the leader in Digital Media Performance Management
www.skytide.com
(510) 250-4284
Read our new white paper: The 4 Keys to Telco CDN Success
= --_000_291CC3F9E50E7641901A54E85D0977C65260911EC7MAILR002maill_-- From roy@skytide.com Fri Mar 30 12:09: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 8028321F8663 for ; Fri, 30 Mar 2012 12:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 kghOyw8Ui5p7 for ; Fri, 30 Mar 2012 12:09:21 -0700 (PDT) Received: from mail-pop3-1.server101.com (ns1.giga-sj-001.net [216.218.210.201]) by ietfa.amsl.com (Postfix) with ESMTP id B9E6221F864F for ; Fri, 30 Mar 2012 12:09:21 -0700 (PDT) Received: from [172.16.4.31] (24-104-66-42-ip-static.hfc.comcastbusiness.net [24.104.66.42]) (authenticated as roy@skytide.com with PLAIN (0 bits)) by mail-pop3-1.server101.com (8.13.7/8.12.8) with ESMTP id q2UJ9FaM022259; Sat, 31 Mar 2012 05:09:15 +1000 Message-ID: <4F7604D9.90309@skytide.com> Date: Fri, 30 Mar 2012 12:09:13 -0700 From: Roy Peterkofsky User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Kevin J Ma References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> <291CC3F9E50E7641901A54E85D0977C65260911CB7@MAILR002.mail.lan> <4F75FC84.2030600@skytide.com> <291CC3F9E50E7641901A54E85D0977C65260911EC7@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C65260911EC7@MAILR002.mail.lan> Content-Type: multipart/alternative; boundary="------------000604030002020809040907" Cc: "cdni@ietf.org" , Viveganandhan Mahesh Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-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: Fri, 30 Mar 2012 19:09:30 -0000 This is a multi-part message in MIME format. --------------000604030002020809040907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I think that getting into the mechanics of how a dCDN would capture data about transactions it delivers is not central to the development of interfaces to other CDNs, as long as the interface standards don't demand anything that is infeasible. I think the point you are getting to maybe refers to the steps involved in transferring rather than capturing the log data? For example a true pull-oriented query interface would actually require all participating dCDNs to store the log data for at least some standardized retention time so that it would be available for uCDNs to pull out. Another option would be that uCDNs could send messages to dCDNs -- in advance of actual delivery transactions -- specifying what data (and in what form) the uCDN wants to receive about ensuing transactions. That messaging could include conditional branches such as IF you are ABR-aware then send me data as follows but IF NOT then send me data in this other way. The upshot of the above would be that the standards to be produced would include: 1) what data elements and levels of aggregation should a dCDN be required to make available to uCDNs, in both ABR-aware and non-ABR-aware circumstances 2) if a dCDN chooses to make additional data elements and/or levels of aggregation available, above and beyond the requirements, how should they communicate this availability to uCDNs 3) what would be the means and format by which uCDNs transmit their specification of desired data to dCDNs, including both the required elements and any optional elements 4) what (if any) is the default logging/reporting to be provided by dCDNs in the absence of such communication from uCDNs 5) what should be the format of the logs/reports sent by dCDNs in response to the communciation sent by the uCDNs about their desired data elements/levels of aggregation Working in that framework would allow most if not all of the issues that have been brought up to be addressed On 3/30/2012 11:51 AM, Kevin J Ma wrote: > > Hi Roy, > > > The discussion of possibly allowing the uCDN to specify (via > > > metadata transfer or other means) which log fields or formats it > > > wishes to receive actually, I feel, calls for stepping back and > > > reviewing whether we should have purely a logging interface or more > > > of a reporting or query interface > > Regardless of how the data is retrieved (push or pull), the dCDN > > needs to know whether or not it needs to extract the data. It may > > be that the dCDN does not automatically extract the X-foo header, > > and the metadata specifies that the X-foo header is desired. I > > think that would be needed even if it was a query interface? > > -- Kevin J. Ma > > *From:*Roy Peterkofsky [mailto:roy@skytide.com] > *Sent:* Friday, March 30, 2012 2:34 PM > *To:* Kevin J Ma > *Cc:* Francois Le Faucheur; Kent Leung (kleung); Niven-Jenkins Ben; > cdni@ietf.org; Viveganandhan Mahesh > *Subject:* Re: [CDNi] Comments on > draft-lefaucheur-cdni-logging-delivery-00 > > It sounds like there is clearly a need to have standards for logging > that cover two different scenarios: > > 1) Where the dCDN is ABR-aware and can produce session-level logs > 2) Where the dCDN is not ABR-aware and can only produce > transaction-level (event- or fragment-level) logs > > I believe that the second scenario is required while the first is more > optional/nice-to-have. It would certainly be better to have it than > not although I think it would be by far the less common situation. > > The discussion of possibly allowing the uCDN to specify (via metadata > transfer or other means) which log fields or formats it wishes to > receive actually, I feel, calls for stepping back and reviewing > whether we should have purely a logging interface or more of a > reporting or query interface. That would, I imagine, allow the uCDN > to specify: > > 1) what transactions do I want data about (specified by date range and > possibly other filter criteria) > 2) what attributes and measures do I want to receive in my data > 3) what level of aggregation do I want the data at (including for > example, at the session level or individual file level) > > On 3/30/2012 2:24 AM, Kevin J Ma wrote: > > Hi Francois, > > Wrt a flexible set of log fields, I think that it is a great idea, and > it would be great if we could use metadata to specify log formats for > specific content items or sets of content items. It is useful for both > content-specific logging (e.g., ABR), as well as client-specific logging > (e.g., X-* headers). For the W3C format, a separate log file for each > format could result in a lot of files? Would aggregation cover that? > > thanx. > > -- Kevin J. Ma > > > -----Original Message----- > > From:cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > > Francois Le Faucheur > > Sent: Tuesday, March 13, 2012 2:39 PM > > To: Kent Leung (kleung); Niven-Jenkins Ben > > Cc:cdni@ietf.org ; Viveganandhan Mahesh > > Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 > > > > Ben, Kent, > > > > Trying to extract the key points from the thread: > > > > 1) level of requirement for support of HTTP Adaptive Streaming Logging > > Session (ie ABR-aware logs): > > This is a valid question. > > The I-D proposes that some form of ABR-aware logging be mandatory. The > > rationale is that ABR is expected to be a very common delivery format and > > requires some form of log compression over very voluminous per-segment > > logging. (BTW the I-D currently proposes that both Segment-Based Logging > > format and Event-Based Logging format be mandatory. But come to think of > > it, having only Event-Based Logging format mandatory would be sufficient > > from my viewpoint). > > Ben argues that ABR-aware logging should not be mandatory as it requires > > extra awareness. > > To get more input, I'd propose we move that requirement level discussion > > to the cdni-requirements document, and have the logging I-D only talks > > about what such logs would look like. > > > > > > 2) flexible set of log fields: > > I agree it is a good idea to allow the uCDN to customize the set of log > > fields reported by a dCDN for delivery. I was thinking that we'd start > > with defining a few "fixed" set of fields and then later add the > > customization, but perhaps we can start directly with customizable sets of > > fields. > > To do that, I'd propose to: > > * retain the notion of Format Types (e.g Delivery_HTTP, > > Delivery_Adaptive_Event, ...) > > * define a set of candidate fields in each Format Type > > * have uCDN signal in Metadata interface the desired Format Type + > > set of fields needed (ie a subset of the set of candidate fields) > > * have dCDN explicitly indicate inside each log file (eg in File > > Header), the Format Type and the set of fields actually included > > * define handling of potential capability mismatch situations if any > > (eg1 uCDN requests a field that is not supported by dCDN if we allow that, > > eg2 dCDN requests a format type that is not supported by dCDN). > > > > > > 3) encoding format: > > I also agree the W3C extended log format is a good base candidate to look > > at. > > > > > > 4) summarization of Logging info for Adaptive Streaming delivery > > I believe some form of summarization is required. The Event-Based Logging > > seems like a nice sweet-spot because it achieves a high summarization gain > > without losing any info (ie any change in bandwidth/quality is logged). > > The I-D suggests we may be able to come up with another interesting sweet- > > spot (Summary-Based Log) providing a huge summarization gain at the cost > > of losing some details, but does not yet specify this. > > Ben, it'd be interesting to provide a brief write-up on the summarization > > approach you mention so we can evaluate it (an email to the list woudl be > > just fine). > > > > > > Thanks for the discussion. > > > > Francois > > > > > > On 9 Mar 2012, at 00:48, Kent Leung (kleung) wrote: > > > > Comments below. > > > > > > -----Original Message----- > > From:cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > > Of > > > > Some comments on draft-lefaucheur-cdni-logging-delivery-00. > > > > 1) In section 3.2.1.2 (Segment-Based Log fields) and section 3.2.2.1 > > (Event Based Log Triggers) you mandate support for a number of log > > fields such as abr-protocol, representation, manifest-id and > > content-id > > that a downstream CDN may have no ability to generate, for example > > because the downstream CDN is acting in a pure HTTP reverse proxy mode > > and may not be aware of that level of information and/or because the > > control of how to identify those fields is owned by the CSP and none > > of > > CDNs may have visibility of that mapping information. > > > > Such a requirement to force CDNs and CDNI in general to require such > > mappings seems overkill to me. > > > > KL> As stated, "... such aggregation requires a degree of application > > awareness in dCDN to recognize that the many HTTP requests correspond > > to > > a single video." So the premise is that the dCDN knows that it's > > delivering ABR content. In some cases, it's possible that the > > representation may not be known. > > > > And my point is that I don't think that premise holds true and reality > > is the opposite, i.e. in general the dCDN will not know what it's > > delivering and only some dCDNs will have the application awareness to > > produce the log fields you suggest. > > > > KL> Hmm, if the dCDN is not aware about the ABR session, then Section > > 3.2 would not apply since the dCDN considers itself to be delivering > > non-ABR content. Non-ABR content delivery does not require the log > > fields specified in this section. > > > > > > But in general, the log fields contain > > information that are pertinent to an ABR content. > > > > I am not exactly sure what you mean by this. I agree the fields you > > suggest would be useful but I don't think having the application > > awareness to generate them should be a mandatory requirement for > > interoperability as suggested by section 3.2 > > > > An implementation of the CDNI Logging interface MUST support logging > > for delivery of content using HTTP adaptive streaming in the Segment- > > Based Logging format and the Event-Based Logging format, and MAY > > support logging in the Summary-Based Logging format. > > > > KL> Are these fields in Sect 3.2 useful or applicable for non-ABR > > content delivery? No. I sense that I'm still missing your point. > > > > > > 2) In section 6 you propose an additional requirement to allow an > > upstream CDN to indicate through CDNI metadata the log format the > > downstream CDN should use. Rather than define a set of specific > > formats, > > we could allow the upstream CDN to specify CDNI metadata indicating > > the > > specific log fields it is interested in receiving. The upstream CDN > > could then tailor what it asks for according to what it requires and > > avoid the transfer of log fields that it does not need. > > > > KL> Agree that it's useful for uCDN to request only the information > > that's needed without extraneous fields. This can be accomplished with > > a > > customized log format provided by uCDN. In a sense, this is a superset > > of selective fields. > > > > That is another approach which would probably make life easier for the > > dCDN. > > > > 4) If the motivation for summary/aggregated log lines is a concern > > over > > the volume of data that needs to be transferred then in Velocix we > > have > > done some experiments on using an alternative lookup table based > > structure for log lines that retains all the verbosity of the original > > delivery log lines but by itself appears to give equivalent > > compression > > to gzip and combined with gzip reduces the size significantly when > > compared to what gzip alone achieves (in some cases averaging as > > little > > as 13 bits per complete log line). > > > > If the volume of logs to be transferred is a concern and there is > > interest in investigating this approach further I can write-up more > > details either in a separate draft or as a section in > > draft-lefaucheur-cdni-logging-delivery. > > > > KL> I think the intent is to summarize succinctly the ABR session in > > the > > logging. > > > > I think they're two separate things. If we're worried about the volume > > of data our experiments show that can be significantly reduced using > > structured log files with lookup tables. That technique is applicable > > regardless of the actual fields in a log file. > > > > Whether we require ABR session summary information to be logged is a > > separate discussion to how we might optimise the structure of any log > > files we require. > > > > Ben > > > > KL> Sure, I think we can discuss more on this when Francois is available > > as I'm not clear on his thoughts. > > > > Kent > > > > I haven't discussed this in finer details with Francois yet. It > > seems to me that the compression technique can be considered as > > optimization in delivery of either session-based or event-based > > logging. > > We can discuss this further if our goals are aligned. > > > > Kent > > > > 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 > > > > _______________________________________________ > > 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 > > > -- > Roy Peterkofsky > Vice President, Product Management > Skytide -- the leader in Digital Media Performance Management > www.skytide.com > (510) 250-4284 > > Read our new white paper: The 4 Keys to Telco CDN Success > > -- Roy Peterkofsky Vice President, Product Management Skytide -- the leader in Digital Media Performance Management www.skytide.com (510) 250-4284 Read our new white paper: The 4 Keys to Telco CDN Success --------------000604030002020809040907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I think that getting into the mechanics of how a dCDN would capture data about transactions it delivers is not central to the development of interfaces to other CDNs, as long as the interface standards don't demand anything that is infeasible.  I think the point you are getting to maybe refers to the steps involved in transferring rather than capturing the log data?  For example a true pull-oriented query interface would actually require all participating dCDNs to store the log data for at least some standardized retention time so that it would be available for uCDNs to pull out.  Another option would be that uCDNs could send messages to dCDNs -- in advance of actual delivery transactions -- specifying what data (and in what form) the uCDN wants to receive about ensuing transactions.  That messaging could include conditional branches such as IF you are ABR-aware then send me data as follows but IF NOT then send me data in this other way.

The upshot of the above would be that the standards to be produced would include:

1) what data elements and levels of aggregation should a dCDN be required to make available  to uCDNs, in both ABR-aware and non-ABR-aware circumstances
2) if a dCDN chooses to make additional data elements and/or levels of aggregation available, above and beyond the requirements, how should they communicate this availability to uCDNs
3) what would be the means and format by which uCDNs transmit their specification of desired data to dCDNs, including both the required elements and any optional elements
4) what (if any) is the default logging/reporting to be provided by dCDNs in the absence of such communication from uCDNs
5) what should be the format of the logs/reports sent by dCDNs in response to the communciation sent by the uCDNs about their desired data elements/levels of aggregation

Working in that framework would allow most if not all of the issues that have been brought up to be addressed

On 3/30/2012 11:51 AM, Kevin J Ma wrote:

Hi Roy,

 

> The discussion of possibly allowing the uCDN to specify (via

> metadata transfer or other means) which log fields or formats it

> wishes to receive actually, I feel, calls for stepping back and

> reviewing whether we should have purely a logging interface or more

> of a reporting or query interface

 

Regardless of how the data is retrieved (push or pull), the dCDN

needs to know whether or not it needs to extract the data.  It may

be that the dCDN does not automatically extract the X-foo header,

and the metadata specifies that the X-foo header is desired.  I

think that would be needed even if it was a query interface?

 

--  Kevin J. Ma

 

From: Roy Peterkofsky [mailto:roy@skytide.com]
Sent: Friday, March 30, 2012 2:34 PM
To: Kevin J Ma
Cc: Francois Le Faucheur; Kent Leung (kleung); Niven-Jenkins Ben; cdni@ietf.org; Viveganandhan Mahesh
Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00

 

It sounds like there is clearly a need to have standards for logging that cover two different scenarios:

1) Where the dCDN is ABR-aware and can produce session-level logs
2) Where the dCDN is not ABR-aware and can only produce transaction-level (event- or fragment-level) logs

I believe that the second scenario is required while the first is more optional/nice-to-have.  It would certainly be better to have it than not although I think it would be by far the less common situation.

The discussion of possibly allowing the uCDN to specify (via metadata transfer or other means) which log fields or formats it wishes to receive actually, I feel, calls for stepping back and reviewing whether we should have purely a logging interface or more of a reporting or query interface.  That would, I imagine, allow the uCDN to specify:

1) what transactions do I want data about (specified by date range and possibly other filter criteria)
2) what attributes and measures do I want to receive in my data
3) what level of aggregation do I want the data at (including for example, at the session level or individual file level)

On 3/30/2012 2:24 AM, Kevin J Ma wrote: 

Hi Francois,
 
  Wrt a flexible set of log fields, I think that it is a great idea, and
  it would be great if we could use metadata to specify log formats for
  specific content items or sets of content items.  It is useful for both
  content-specific logging (e.g., ABR), as well as client-specific logging
  (e.g., X-* headers).  For the W3C format, a separate log file for each
  format could result in a lot of files?  Would aggregation cover that?
 
thanx.
 
--  Kevin J. Ma
 
-----Original Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of
Francois Le Faucheur
Sent: Tuesday, March 13, 2012 2:39 PM
To: Kent Leung (kleung); Niven-Jenkins Ben
Cc: cdni@ietf.org; Viveganandhan Mahesh
Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00
 
Ben, Kent,
 
Trying to extract the key points from the thread:
 
1) level of requirement for support of HTTP Adaptive Streaming Logging
Session (ie ABR-aware logs):
This is a valid question.
The I-D proposes that some form of ABR-aware logging be mandatory. The
rationale is that ABR is expected to be a very common delivery format and
requires some form of log compression over very voluminous per-segment
logging. (BTW the I-D currently proposes that both Segment-Based Logging
format and Event-Based Logging format be mandatory. But come to think of
it, having only Event-Based Logging format mandatory would be sufficient
from my viewpoint).
Ben argues that ABR-aware logging should not be mandatory as it requires
extra awareness.
To get more input, I'd propose we move that requirement level discussion
to the cdni-requirements document, and have the logging I-D only talks
about what such logs would look like.
 
 
2) flexible set of log fields:
I agree it is a good idea to allow the uCDN to customize the set of log
fields reported by a dCDN for delivery. I was thinking that we'd start
with defining a few "fixed" set of fields and then later add the
customization, but perhaps we can start directly with customizable sets of
fields.
To do that, I'd propose to:
 * retain the notion of Format Types (e.g Delivery_HTTP,
Delivery_Adaptive_Event, ...)
 * define a set of candidate fields in each Format Type
 * have uCDN signal in Metadata interface the desired Format Type +
set of fields needed (ie a subset of the set of candidate fields)
 * have dCDN explicitly indicate inside each log file (eg in File
Header), the Format Type and the set of fields actually included
 * define handling of potential capability mismatch situations if any
(eg1 uCDN requests a field that is not supported by dCDN if we allow that,
eg2 dCDN requests a format type that is not supported by dCDN).
 
 
3) encoding format:
I also agree the W3C extended log format is a good base candidate to look
at.
 
 
4) summarization of Logging info for Adaptive Streaming delivery
I believe some form of summarization is required. The Event-Based Logging
seems like a nice sweet-spot because it achieves a high summarization gain
without losing any info (ie any change in bandwidth/quality is logged).
The I-D suggests we may be able to come up with another interesting sweet-
spot (Summary-Based Log) providing a huge summarization gain at the cost
of losing some details, but does not yet specify this.
Ben, it'd be interesting to provide a brief write-up on the summarization
approach you mention so we can evaluate it (an email to the list woudl be
just fine).
 
 
Thanks for the discussion.
 
Francois
 
 
On 9 Mar 2012, at 00:48, Kent Leung (kleung) wrote:
 
Comments below.
 
 
-----Original Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf
Of
 
Some comments on draft-lefaucheur-cdni-logging-delivery-00.
 
1) In section 3.2.1.2 (Segment-Based Log fields) and section 3.2.2.1
(Event Based Log Triggers) you mandate support for a number of log
fields such as abr-protocol, representation, manifest-id and
content-id
that a downstream CDN may have no ability to generate, for example
because the downstream CDN is acting in a pure HTTP reverse proxy mode
and may not be aware of that level of information and/or because the
control of how to identify those fields is owned by the CSP and none
of
CDNs may have visibility of that mapping information.
 
Such a requirement to force CDNs and CDNI in general to require such
mappings seems overkill to me.
 
KL> As stated, "... such aggregation requires a degree of application
awareness in dCDN to recognize that the many HTTP requests correspond
to
a single video." So the premise is that the dCDN knows that it's
delivering ABR content. In some cases, it's possible that the
representation may not be known.
 
And my point is that I don't think that premise holds true and reality
is the opposite, i.e. in general the dCDN will not know what it's
delivering and only some dCDNs will have the application awareness to
produce the log fields you suggest.
 
KL> Hmm, if the dCDN is not aware about the ABR session, then Section
3.2 would not apply since the dCDN considers itself to be delivering
non-ABR content.  Non-ABR content delivery does not require the log
fields specified in this section.
 
 
But in general, the log fields contain
information that are pertinent to an ABR content.
 
I am not exactly sure what you mean by this. I agree the fields you
suggest would be useful but I don't think having the application
awareness to generate them should be a mandatory requirement for
interoperability as suggested by section 3.2
 
  An implementation of the CDNI Logging interface MUST support logging
  for delivery of content using HTTP adaptive streaming in the Segment-
  Based Logging format and the Event-Based Logging format, and MAY
  support logging in the Summary-Based Logging format.
 
KL> Are these fields in Sect 3.2 useful or applicable for non-ABR
content delivery? No. I sense that I'm still missing your point.
 
 
2) In section 6 you propose an additional requirement to allow an
upstream CDN to indicate through CDNI metadata the log format the
downstream CDN should use. Rather than define a set of specific
formats,
we could allow the upstream CDN to specify CDNI metadata indicating
the
specific log fields it is interested in receiving. The upstream CDN
could then tailor what it asks for according to what it requires and
avoid the transfer of log fields that it does not need.
 
KL> Agree that it's useful for uCDN to request only the information
that's needed without extraneous fields. This can be accomplished with
a
customized log format provided by uCDN. In a sense, this is a superset
of selective fields.
 
That is another approach which would probably make life easier for the
dCDN.
 
4) If the motivation for summary/aggregated log lines is a concern
over
the volume of data that needs to be transferred then in Velocix we
have
done some experiments on using an alternative lookup table based
structure for log lines that retains all the verbosity of the original
delivery log lines but by itself appears to give equivalent
compression
to gzip and combined with gzip reduces the size significantly when
compared to what gzip alone achieves (in some cases averaging as
little
as 13 bits per complete log line).
 
If the volume of logs to be transferred is a concern and there is
interest in investigating this approach further I can write-up more
details either in a separate draft or as a section in
draft-lefaucheur-cdni-logging-delivery.
 
KL> I think the intent is to summarize succinctly the ABR session in
the
logging.
 
I think they're two separate things. If we're worried about the volume
of data our experiments show that can be significantly reduced using
structured log files with lookup tables. That technique is applicable
regardless of the actual fields in a log file.
 
Whether we require ABR session summary information to be logged is a
separate discussion to how we might optimise the structure of any log
files we require.
 
Ben
 
KL> Sure, I think we can discuss more on this when Francois is available
as I'm not clear on his thoughts.
 
Kent
 
I haven't discussed this in finer details with Francois yet. It
seems to me that the compression technique can be considered as
optimization in delivery of either session-based or event-based
logging.
We can discuss this further if our goals are aligned.
 
Kent
 
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
 
_______________________________________________
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
 

 

--
Roy Peterkofsky
Vice President, Product Management
Skytide -- the leader in Digital Media Performance Management
www.skytide.com
(510) 250-4284

Read our new white paper: The 4 Keys to Telco CDN Success



--
Roy Peterkofsky
Vice President, Product Management
Skytide -- the leader in Digital Media Performance Management
www.skytide.com
(510) 250-4284

Read our new white paper: The 4 Keys to Telco CDN Success
--------------000604030002020809040907-- From kevin.ma@azukisystems.com Fri Mar 30 13:16: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 629AB21F8675 for ; Fri, 30 Mar 2012 13:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.280, 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 aEV3VomkRwbN for ; Fri, 30 Mar 2012 13:16:41 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6F121F8610 for ; Fri, 30 Mar 2012 13:16:34 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 9BCA483F5F8; Fri, 30 Mar 2012 16:16:34 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB024.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 223C083F300; Fri, 30 Mar 2012 16:16:25 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Fri, 30 Mar 2012 16:16:08 -0400 From: Kevin J Ma To: Roy Peterkofsky Date: Fri, 30 Mar 2012 16:16:22 -0400 Thread-Topic: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 Thread-Index: Ac0OqXhmK2E+IU6ERsOPplCH2uV0ZAACAmvg Message-ID: <291CC3F9E50E7641901A54E85D0977C65260911F4F@MAILR002.mail.lan> References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com> <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com> <291CC3F9E50E7641901A54E85D0977C65260911CB7@MAILR002.mail.lan> <4F75FC84.2030600@skytide.com> <291CC3F9E50E7641901A54E85D0977C65260911EC7@MAILR002.mail.lan> <4F7604D9.90309@skytide.com> In-Reply-To: <4F7604D9.90309@skytide.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_291CC3F9E50E7641901A54E85D0977C65260911F4FMAILR002maill_" MIME-Version: 1.0 Cc: "cdni@ietf.org" , Viveganandhan Mahesh Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-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: Fri, 30 Mar 2012 20:16:43 -0000 --_000_291CC3F9E50E7641901A54E85D0977C65260911F4FMAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > I think the point you are getting to maybe refers to the steps involved > in transferring rather than capturing the log data? No. As I said, if the dCDN does not typically store a given piece of data, it cannot log it, nor can it be queried for it. Telling the dCDN that a specific piece of information may be required for a given content item is fairly orthogonal to how you later retrieve that information. From: Roy Peterkofsky [mailto:roy@skytide.com] Sent: Friday, March 30, 2012 3:09 PM To: Kevin J Ma Cc: Francois Le Faucheur; Kent Leung (kleung); Niven-Jenkins Ben; cdni@ietf= .org; Viveganandhan Mahesh Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 I think that getting into the mechanics of how a dCDN would capture data ab= out transactions it delivers is not central to the development of interface= s to other CDNs, as long as the interface standards don't demand anything t= hat is infeasible. I think the point you are getting to maybe refers to th= e steps involved in transferring rather than capturing the log data? For e= xample a true pull-oriented query interface would actually require all part= icipating dCDNs to store the log data for at least some standardized retent= ion time so that it would be available for uCDNs to pull out. Another opti= on would be that uCDNs could send messages to dCDNs -- in advance of actual= delivery transactions -- specifying what data (and in what form) the uCDN = wants to receive about ensuing transactions. That messaging could include = conditional branches such as IF you are ABR-aware then send me data as foll= ows but IF NOT then send me data in this other way. The upshot of the above would be that the standards to be produced would in= clude: 1) what data elements and levels of aggregation should a dCDN be required t= o make available to uCDNs, in both ABR-aware and non-ABR-aware circumstanc= es 2) if a dCDN chooses to make additional data elements and/or levels of aggr= egation available, above and beyond the requirements, how should they commu= nicate this availability to uCDNs 3) what would be the means and format by which uCDNs transmit their specifi= cation of desired data to dCDNs, including both the required elements and a= ny optional elements 4) what (if any) is the default logging/reporting to be provided by dCDNs i= n the absence of such communication from uCDNs 5) what should be the format of the logs/reports sent by dCDNs in response = to the communciation sent by the uCDNs about their desired data elements/le= vels of aggregation Working in that framework would allow most if not all of the issues that ha= ve been brought up to be addressed On 3/30/2012 11:51 AM, Kevin J Ma wrote: Hi Roy, > The discussion of possibly allowing the uCDN to specify (via > metadata transfer or other means) which log fields or formats it > wishes to receive actually, I feel, calls for stepping back and > reviewing whether we should have purely a logging interface or more > of a reporting or query interface Regardless of how the data is retrieved (push or pull), the dCDN needs to know whether or not it needs to extract the data. It may be that the dCDN does not automatically extract the X-foo header, and the metadata specifies that the X-foo header is desired. I think that would be needed even if it was a query interface? -- Kevin J. Ma From: Roy Peterkofsky [mailto:roy@skytide.com] Sent: Friday, March 30, 2012 2:34 PM To: Kevin J Ma Cc: Francois Le Faucheur; Kent Leung (kleung); Niven-Jenkins Ben; cdni@ietf= .org; Viveganandhan Mahesh Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 It sounds like there is clearly a need to have standards for logging that c= over two different scenarios: 1) Where the dCDN is ABR-aware and can produce session-level logs 2) Where the dCDN is not ABR-aware and can only produce transaction-level (= event- or fragment-level) logs I believe that the second scenario is required while the first is more opti= onal/nice-to-have. It would certainly be better to have it than not althou= gh I think it would be by far the less common situation. The discussion of possibly allowing the uCDN to specify (via metadata trans= fer or other means) which log fields or formats it wishes to receive actual= ly, I feel, calls for stepping back and reviewing whether we should have pu= rely a logging interface or more of a reporting or query interface. That w= ould, I imagine, allow the uCDN to specify: 1) what transactions do I want data about (specified by date range and poss= ibly other filter criteria) 2) what attributes and measures do I want to receive in my data 3) what level of aggregation do I want the data at (including for example, = at the session level or individual file level) On 3/30/2012 2:24 AM, Kevin J Ma wrote: Hi Francois, Wrt a flexible set of log fields, I think that it is a great idea, and it would be great if we could use metadata to specify log formats for specific content items or sets of content items. It is useful for both content-specific logging (e.g., ABR), as well as client-specific logging (e.g., X-* headers). For the W3C format, a separate log file for each format could result in a lot of files? Would aggregation cover that? thanx. -- Kevin J. Ma -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Francois Le Faucheur Sent: Tuesday, March 13, 2012 2:39 PM To: Kent Leung (kleung); Niven-Jenkins Ben Cc: cdni@ietf.org; Viveganandhan Mahesh Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 Ben, Kent, Trying to extract the key points from the thread: 1) level of requirement for support of HTTP Adaptive Streaming Logging Session (ie ABR-aware logs): This is a valid question. The I-D proposes that some form of ABR-aware logging be mandatory. The rationale is that ABR is expected to be a very common delivery format and requires some form of log compression over very voluminous per-segment logging. (BTW the I-D currently proposes that both Segment-Based Logging format and Event-Based Logging format be mandatory. But come to think of it, having only Event-Based Logging format mandatory would be sufficient from my viewpoint). Ben argues that ABR-aware logging should not be mandatory as it requires extra awareness. To get more input, I'd propose we move that requirement level discussion to the cdni-requirements document, and have the logging I-D only talks about what such logs would look like. 2) flexible set of log fields: I agree it is a good idea to allow the uCDN to customize the set of log fields reported by a dCDN for delivery. I was thinking that we'd start with defining a few "fixed" set of fields and then later add the customization, but perhaps we can start directly with customizable sets of fields. To do that, I'd propose to: * retain the notion of Format Types (e.g Delivery_HTTP, Delivery_Adaptive_Event, ...) * define a set of candidate fields in each Format Type * have uCDN signal in Metadata interface the desired Format Type + set of fields needed (ie a subset of the set of candidate fields) * have dCDN explicitly indicate inside each log file (eg in File Header), the Format Type and the set of fields actually included * define handling of potential capability mismatch situations if any (eg1 uCDN requests a field that is not supported by dCDN if we allow that, eg2 dCDN requests a format type that is not supported by dCDN). 3) encoding format: I also agree the W3C extended log format is a good base candidate to look at. 4) summarization of Logging info for Adaptive Streaming delivery I believe some form of summarization is required. The Event-Based Logging seems like a nice sweet-spot because it achieves a high summarization gain without losing any info (ie any change in bandwidth/quality is logged). The I-D suggests we may be able to come up with another interesting sweet- spot (Summary-Based Log) providing a huge summarization gain at the cost of losing some details, but does not yet specify this. Ben, it'd be interesting to provide a brief write-up on the summarization approach you mention so we can evaluate it (an email to the list woudl be just fine). Thanks for the discussion. Francois On 9 Mar 2012, at 00:48, Kent Leung (kleung) wrote: Comments below. -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Some comments on draft-lefaucheur-cdni-logging-delivery-00. 1) In section 3.2.1.2 (Segment-Based Log fields) and section 3.2.2.1 (Event Based Log Triggers) you mandate support for a number of log fields such as abr-protocol, representation, manifest-id and content-id that a downstream CDN may have no ability to generate, for example because the downstream CDN is acting in a pure HTTP reverse proxy mode and may not be aware of that level of information and/or because the control of how to identify those fields is owned by the CSP and none of CDNs may have visibility of that mapping information. Such a requirement to force CDNs and CDNI in general to require such mappings seems overkill to me. KL> As stated, "... such aggregation requires a degree of application awareness in dCDN to recognize that the many HTTP requests correspond to a single video." So the premise is that the dCDN knows that it's delivering ABR content. In some cases, it's possible that the representation may not be known. And my point is that I don't think that premise holds true and reality is the opposite, i.e. in general the dCDN will not know what it's delivering and only some dCDNs will have the application awareness to produce the log fields you suggest. KL> Hmm, if the dCDN is not aware about the ABR session, then Section 3.2 would not apply since the dCDN considers itself to be delivering non-ABR content. Non-ABR content delivery does not require the log fields specified in this section. But in general, the log fields contain information that are pertinent to an ABR content. I am not exactly sure what you mean by this. I agree the fields you suggest would be useful but I don't think having the application awareness to generate them should be a mandatory requirement for interoperability as suggested by section 3.2 An implementation of the CDNI Logging interface MUST support logging for delivery of content using HTTP adaptive streaming in the Segment- Based Logging format and the Event-Based Logging format, and MAY support logging in the Summary-Based Logging format. KL> Are these fields in Sect 3.2 useful or applicable for non-ABR content delivery? No. I sense that I'm still missing your point. 2) In section 6 you propose an additional requirement to allow an upstream CDN to indicate through CDNI metadata the log format the downstream CDN should use. Rather than define a set of specific formats, we could allow the upstream CDN to specify CDNI metadata indicating the specific log fields it is interested in receiving. The upstream CDN could then tailor what it asks for according to what it requires and avoid the transfer of log fields that it does not need. KL> Agree that it's useful for uCDN to request only the information that's needed without extraneous fields. This can be accomplished with a customized log format provided by uCDN. In a sense, this is a superset of selective fields. That is another approach which would probably make life easier for the dCDN. 4) If the motivation for summary/aggregated log lines is a concern over the volume of data that needs to be transferred then in Velocix we have done some experiments on using an alternative lookup table based structure for log lines that retains all the verbosity of the original delivery log lines but by itself appears to give equivalent compression to gzip and combined with gzip reduces the size significantly when compared to what gzip alone achieves (in some cases averaging as little as 13 bits per complete log line). If the volume of logs to be transferred is a concern and there is interest in investigating this approach further I can write-up more details either in a separate draft or as a section in draft-lefaucheur-cdni-logging-delivery. KL> I think the intent is to summarize succinctly the ABR session in the logging. I think they're two separate things. If we're worried about the volume of data our experiments show that can be significantly reduced using structured log files with lookup tables. That technique is applicable regardless of the actual fields in a log file. Whether we require ABR session summary information to be logged is a separate discussion to how we might optimise the structure of any log files we require. Ben KL> Sure, I think we can discuss more on this when Francois is available as I'm not clear on his thoughts. Kent I haven't discussed this in finer details with Francois yet. It seems to me that the compression technique can be considered as optimization in delivery of either session-based or event-based logging. We can discuss this further if our goals are aligned. Kent 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 _______________________________________________ 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 -- Roy Peterkofsky Vice President, Product Management Skytide -- the leader in Digital Media Performance Management www.skytide.com (510) 250-4284 Read our new white paper: The 4 Keys to Telco CDN Success -- Roy Peterkofsky Vice President, Product Management Skytide -- the leader in Digital Media Performance Management www.skytide.com (510) 250-4284 Read our new white paper: The 4 Keys to Telco CDN Success --_000_291CC3F9E50E7641901A54E85D0977C65260911F4FMAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= > I think the point you are getting to maybe refers to the step= s involved

> in transferring = rather than capturing the log data?

 

No.  As I said, = if the dCDN does not typically store a given piece of data,

it cannot log it, nor can it be queried for it.=   Telling the dCDN that a

s= pecific piece of information may be required for a given content item is

fairly orthogonal to how you later= retrieve that information.

 

From: Roy Peterkofsky [mailto:roy@skytide.com]
<= b>Sent: Friday, March 30, 2012 3:09 PM
To: Kevin J Ma
C= c: Francois Le Faucheur; Kent Leung (kleung); Niven-Jenkins Ben; cdni@i= etf.org; Viveganandhan Mahesh
Subject: Re: [CDNi] Comments on dra= ft-lefaucheur-cdni-logging-delivery-00

 

I think that ge= tting into the mechanics of how a dCDN would capture data about transaction= s it delivers is not central to the development of interfaces to other CDNs= , as long as the interface standards don't demand anything that is infeasib= le.  I think the point you are getting to maybe refers to the steps in= volved in transferring rather than capturing the log data?  For exampl= e a true pull-oriented query interface would actually require all participa= ting dCDNs to store the log data for at least some standardized retention t= ime so that it would be available for uCDNs to pull out.  Another opti= on would be that uCDNs could send messages to dCDNs -- in advance of actual= delivery transactions -- specifying what data (and in what form) the uCDN = wants to receive about ensuing transactions.  That messaging could inc= lude conditional branches such as IF you are ABR-aware then send me data as= follows but IF NOT then send me data in this other way.

The upshot = of the above would be that the standards to be produced would include:
<= br>1) what data elements and levels of aggregation should a dCDN be require= d to make available  to uCDNs, in both ABR-aware and non-ABR-aware cir= cumstances
2) if a dCDN chooses to make additional data elements and/or = levels of aggregation available, above and beyond the requirements, how sho= uld they communicate this availability to uCDNs
3) what would be the mea= ns and format by which uCDNs transmit their specification of desired data t= o dCDNs, including both the required elements and any optional elements
= 4) what (if any) is the default logging/reporting to be provided by dCDNs i= n the absence of such communication from uCDNs
5) what should be the for= mat of the logs/reports sent by dCDNs in response to the communciation sent= by the uCDNs about their desired data elements/levels of aggregation
Working in that framework would allow most if not all of the issues that = have been brought up to be addressed

On 3/30/2012 11:51 AM, Kevin J= Ma wrote:

Hi Roy,

 

> The discussion of possibly allowing the uCDN= to specify (via

> m= etadata transfer or other means) which log fields or formats it=

> wishes to receive actually, I= feel, calls for stepping back and

> reviewing whether we should have purely a logging interfac= e or more

> of a rep= orting or query interface

 

Regardless o= f how the data is retrieved (push or pull), the dCDN

<= p class=3DMsoNormal>needs to know whether or not it needs to extr= act the data.  It may

be that the dCDN does not automatically extract the X-foo header,

and the metadata specifies t= hat the X-foo header is desired.  I

think that would be needed even if it was a query interfa= ce?

 <= /o:p>

--  Kevin J. Ma

 

From: Roy = Peterkofsky [mailto:roy@skytide.com]=
Sent: Friday, March 30, 2012 2:34 PM
To: Kevin J MaCc: Francois Le Faucheur; Kent Leung (kleung); Niven-Jenkins Ben; = cdni@ietf.org; Viveganandhan MaheshSubject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-deliv= ery-00

 

It sounds like there is clearly a need to have = standards for logging that cover two different scenarios:

1) Where t= he dCDN is ABR-aware and can produce session-level logs
2) Where the dCD= N is not ABR-aware and can only produce transaction-level (event- or fragme= nt-level) logs

I believe that the second scenario is required while = the first is more optional/nice-to-have.  It would certainly be better= to have it than not although I think it would be by far the less common si= tuation.

The discussion of possibly allowing the uCDN to specify (vi= a metadata transfer or other means) which log fields or formats it wishes t= o receive actually, I feel, calls for stepping back and reviewing whether w= e should have purely a logging interface or more of a reporting or query in= terface.  That would, I imagine, allow the uCDN to specify:

1) = what transactions do I want data about (specified by date range and possibl= y other filter criteria)
2) what attributes and measures do I want to re= ceive in my data
3) what level of aggregation do I want the data at (inc= luding for example, at the session level or individual file level)

O= n 3/30/2012 2:24 AM, Kevin J Ma wrote: 

Hi Francois,
 
  Wrt a flexible set of =
log fields, I think that it is a great idea, and
 =
; it would be great if we could use metadata to specify log formats for
  specific content items or sets of content items.&n=
bsp; It is useful for both
  content-specific log=
ging (e.g., ABR), as well as client-specific logging
&=
nbsp; (e.g., X-* headers).  For the W3C format, a separate log file fo=
r each
  format could result in a lot of files?&n=
bsp; Would aggregation cover that?
 
thanx.
 
--  K=
evin J. Ma
 
-----Original Message-----=

From: cdni-bounce=
s@ietf.org [mailto:cdni-bounce=
s@ietf.org] On Behalf Of
Francois Le Faucheur=

Sent: Tuesday, March 13, 2012 2:39 PM
To: Kent Leung (kleung); Niven-Jenkins Ben
Cc: cdni@ietf.org; Viveganandhan Mahesh
Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-=
delivery-00
 
Ben, Kent,
 
Trying to extract the key poi=
nts from the thread:
 
1) le=
vel of requirement for support of HTTP Adaptive Streaming Logging
Session (ie ABR-aware logs):
This is a val=
id question.
The I-D proposes that some form of ABR-aw=
are logging be mandatory. The
rationale is that ABR is=
 expected to be a very common delivery format and
requ=
ires some form of log compression over very voluminous per-segment
logging. (BTW the I-D currently proposes that both Segment-Bas=
ed Logging
format and Event-Based Logging format be ma=
ndatory. But come to think of
it, having only Event-Ba=
sed Logging format mandatory would be sufficient
from =
my viewpoint).
Ben argues that ABR-aware logging shoul=
d not be mandatory as it requires
extra awareness.
To get more input, I'd propose we move that requirement l=
evel discussion
to the cdni-requirements document, and=
 have the logging I-D only talks
about what such logs =
would look like.
 
 
2) flexible set of log fields:
I ag=
ree it is a good idea to allow the uCDN to customize the set of log
fields reported by a dCDN for delivery. I was thinking that w=
e'd start
with defining a few "fixed" set of=
 fields and then later add the
customization, but perh=
aps we can start directly with customizable sets of
fi=
elds.
To do that, I'd propose to:
* retain the notion of Format Types (e.g Delivery_HTTP,<= pre>Delivery_Adaptive_Event, ...)
 * define a set of c=
andidate fields in each Format Type
 * have uCDN signa=
l in Metadata interface the desired Format Type +
set =
of fields needed (ie a subset of the set of candidate fields)
 * have dCDN explicitly indicate inside each log file (eg in File
Header), the Format Type and the set of fields actually=
 included
 * define handling of potential capability m=
ismatch situations if any
(eg1 uCDN requests a field t=
hat is not supported by dCDN if we allow that,
eg2 dCD=
N requests a format type that is not supported by dCDN).
 
 
3) encoding form=
at:
I also agree the W3C extended log format is a good=
 base candidate to look
at.
 =
;
 
4) summarization of Logg=
ing info for Adaptive Streaming delivery
I believe som=
e form of summarization is required. The Event-Based Logging
seems like a nice sweet-spot because it achieves a high summarizatio=
n gain
without losing any info (ie any change in bandw=
idth/quality is logged).
The I-D suggests we may be ab=
le to come up with another interesting sweet-
spot (Su=
mmary-Based Log) providing a huge summarization gain at the cost=

of losing some details, but does not yet specify this.
Ben, it'd be interesting to provide a brief write-up on the sum=
marization
approach you mention so we can evaluate it =
(an email to the list woudl be
just fine).<=
/pre>
 
 
Thanks fo=
r the discussion.
 
Francois=

 
 
On 9 Mar 2012, at 00:48, Kent Leung (kleung) wrote:
 
Comments below.
 
 
-----Original Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf
Of
 
Some com=
ments on draft-lefaucheur-cdni-logging-delivery-00.
&n=
bsp;
1) In section 3.2.1.2 (Segment-Based Log fields) =
and section 3.2.2.1
(Event Based Log Triggers) you man=
date support for a number of log
fields such as abr-pr=
otocol, representation, manifest-id and
c=
ontent-id
that a downstream CDN may have no ability to generate, for e=
xample
because the downstream CDN is acting in a pure =
HTTP reverse proxy mode
and may not be aware of that l=
evel of information and/or because the
control of how =
to identify those fields is owned by the CSP and none
of
CDNs may have visibility of that mapping information.<=
o:p>
 
Such a requirement to forc=
e CDNs and CDNI in general to require such
mappings se=
ems overkill to me.
 
KL>=
 As stated, "... such aggregation requires a degree of application
awareness in dCDN to recognize that the many HTTP request=
s correspond
to
a single video."=
; So the premise is that the dCDN knows that it's
deli=
vering ABR content. In some cases, it's possible that the
<= pre>representation may not be known.
&nbs=
p;
And my point is that I don't think that premise hol=
ds true and reality
is the opposite, i.e. in general t=
he dCDN will not know what it's
delivering and only so=
me dCDNs will have the application awareness to
produc=
e the log fields you suggest.
 
<= pre>KL> Hmm, if the dCDN is not aware about the ABR session, then Sectio= n
3.2 would not apply since the dCDN considers itself =
to be delivering
non-ABR content.  Non-ABR conten=
t delivery does not require the log
fields specified i=
n this section.
 
 
But in general, the log fields contain
information t=
hat are pertinent to an ABR content.
&nbs=
p;
I am not exactly sure what you mean by this. I agre=
e the fields you
suggest would be useful but I don't t=
hink having the application
awareness to generate them=
 should be a mandatory requirement for
interoperabilit=
y as suggested by section 3.2
 
<= pre>  An implementation of the CDNI Logging interface MUST support log= ging
  for delivery of content using HTTP adaptiv=
e streaming in the Segment-
  Based Logging forma=
t and the Event-Based Logging format, and MAY
  s=
upport logging in the Summary-Based Logging format.
&n=
bsp;
KL> Are these fields in Sect 3.2 useful or app=
licable for non-ABR
content delivery? No. I sense that=
 I'm still missing your point.
 
= 
 
2) In section 6 you propose an additional requirement to a=
llow an
upstream CDN to indicate through CDNI metadata=
 the log format the
downstream CDN should use. Rather =
than define a set of specific
formats,
we could allow the upstream CDN to specify CDNI metadata indicating= 
the
specific log fields it is interested=
 in receiving. The upstream CDN
could then tailor what=
 it asks for according to what it requires and
avoid t=
he transfer of log fields that it does not need.
 =
;
KL> Agree that it's useful for uCDN to request on=
ly the information
that's needed without extraneous fi=
elds. This can be accomplished with
a
customized log format provided by uCDN. In a sense, this is a superset
of selective fields.
&=
nbsp;
That is another approach which would probably ma=
ke life easier for the
dCDN.
&nbs=
p;
4) If the motivation for summary/aggregated log lines is a concern<=
o:p>
over
the volume of data that needs t=
o be transferred then in Velocix we
have<=
o:p>
= 
done some experiments on using an alternative lookup table based<=
/o:p>
structure for log lines that retains all the verbosity of t=
he original
delivery log lines but by itself appears t=
o give equivalent
compression<=
/pre>
to gzi=
p and combined with gzip reduces the size significantly when
compared to what gzip alone achieves (in some cases averaging as
little
as 13 bits per complete log line=
).
 
If the volume of logs t=
o be transferred is a concern and there is
interest in=
 investigating this approach further I can write-up more
details either in a separate draft or as a section in
draft-lefaucheur-cdni-logging-delivery.
 =

KL> I think the intent is to summarize succinctly the A=
BR session in
the
logging.
 
I think they're two se=
parate things. If we're worried about the volume
of da=
ta our experiments show that can be significantly reduced using<=
/pre>
structured log files with lookup tables. That technique is applic=
able
regardless of the actual fields in a log file.
 
Whether we require ABR sessi=
on summary information to be logged is a
separate disc=
ussion to how we might optimise the structure of any log
files we require.
 
Ben
 
KL> Sure, I think we can=
 discuss more on this when Francois is available
as I'=
m not clear on his thoughts.
 
Kent
 
I haven't discussed this in finer =
details with Francois yet. It
seems to me that the com=
pression technique can be considered as
optimization i=
n delivery of either session-based or event-based
logging.
We can discuss this further if our goals are aligned=
.
 
Kent
 
Ben
____________________=
___________________________
CDNi mailing list
CDNi@ietf.org<=
/pre>
https://ww=
w.ietf.org/mailman/listinfo/cdni
&nbs=
p;
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdn=
i
 
_______=
________________________________________
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
 

 

--
Roy Peter= kofsky
Vice President, Product Management
Skytide -- the leader in Di= gital Media Performance Management
ww= w.skytide.com
(510) 250-4284

Read our new white paper: The= 4 Keys to Telco CDN Success

 

--
Roy Peterkofsky
Vice President, Product Management
Sky= tide -- the leader in Digital Media Performance Management
www.skytide.com
(510) 250-4284

Read our= new white paper: The 4 Keys to Telco CDN Success

= --_000_291CC3F9E50E7641901A54E85D0977C65260911F4FMAILR002maill_--