From ray.vanbrandenburg@tno.nl Fri Jun 1 01:59: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 1D61321F8619 for ; Fri, 1 Jun 2012 01:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.243 X-Spam-Level: X-Spam-Status: No, score=0.243 tagged_above=-999 required=5 tests=[AWL=0.747, 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 EtjV5FOxjzD3 for ; Fri, 1 Jun 2012 01:59:32 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 790ED21F8615 for ; Fri, 1 Jun 2012 01:59:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,698,1330902000"; d="scan'208";a="15386001" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 01 Jun 2012 10:59:30 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.96]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.02.0283.003; Fri, 1 Jun 2012 10:59:30 +0200 From: "Brandenburg, R. (Ray) van" To: Francois Le Faucheur , "cdni@ietf.org" Thread-Topic: [CDNi] Notes from May 29 Extended Design Team Meeting on "Adaptive Streaming" Thread-Index: AQHNPzEW2NriJLmwFEOmeJA4nsrxZZblKDYQ Date: Fri, 1 Jun 2012 08:59:29 +0000 Message-ID: References: <5B58A245-3F8F-4BAE-945C-F02D158FCCC4@cisco.com> In-Reply-To: <5B58A245-3F8F-4BAE-945C-F02D158FCCC4@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="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [CDNi] Notes from May 29 Extended Design Team Meeting on "Adaptive Streaming" X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 08:59:33 -0000 Hi Francois, Thanks for the notes. Some minor comments/corrections inline. Ray -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Fra= ncois Le Faucheur Sent: donderdag 31 mei 2012 15:27 To: cdni@ietf.org Subject: [CDNi] Notes from May 29 Extended Design Team Meeting on "Adaptive= Streaming" Folks, Here are draft notes from the May 29 extended design team meeting. Let us k= now if you have comments. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Extended Design Team Meeting of CDNI on "Adaptive Streaming" Date: Tuesday, May 29, 2012 Start Time: 07:00 PDT (e.g San Francisco, USA) =3D 10:00 EDT (e.g Boston, U= SA) =3D 16:00 CET (e.g Paris, France) =3D 22:00 CST (e.g. Beijing, China) F= inish Time: 10:00 PDT (e.g San Francisco, USA) =3D 13:00 EDT (e.g Boston, U= SA) =3D 19:00 CET (e.g Paris, France) =3D 01:00 CST (e.g. Beijing, China) The webex recording for the meeting (missing the first 5-10 minutes of the = discussion) is available at: https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&SP=3DMC&rID=3D61050812&r= Key=3Da34577e4e4e8ec5a = SInce the full details of the discussion is accessible through the webex re= cording, the notes below focus on the Action Items and conclusions of the d= iscussions. (by merge of notes from Scott Wainner and Francois): intro on Extended Design Team Meeting: Francois & Rich =3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * This meeting is not a formal Interim Meeting of WG, it is an extended des= ign team meeting. * Let's remember that we have a strong motivation to develop first what is = REQUIRED to make HAS work. We need to focus on fundamentals to make HAS wor= k vs how to use CDN-I to make things work better. Intro to the new version of draft-brandenburg-cdni-has + recap on key HAS t= erminology: Ray =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D See slides. Action Items: * add to cdni-has a discussion on handling of VoD vs Live when discussing = Manifest Files: Ray * add to cdni-has a discussion on other conceptual differences across HAS = schemes: Ray, with input provided by Kevin * add to cdni-has a discussion on the fact that different chunks of the sa= me "HAS session" may be coming from different origin servers and may be fol= lowing different CDN paths. Include the example of Ad insertion possibly lo= cally sourced: Ray, possibly with input from Kevin * add to cdni-has the distinction between DNS redirection and HTTP redirec= tion in all sections/discussions (e.g. pros & cons discussions) where it is= relevant (e.g. when discussing impact of per-chunk request routing, the im= pact is different for DNS and HTTP): Ray RVB: I will definitely need some input here from people more familiar with = DNS. I seem to remember from our meeting that there was someone who volunte= ered to help me with this (although I don't remember who this was). = * add to cdni-has a clarification that, in some situations, the manifest f= ile follows the same delivery path as the corresponding chunks (and therefo= re may be visible to CDNs on the chunk delivery path) and that in some situ= ations the manifest file follows a different delivery path (e.g. delivery d= irectly by CSP or uCDN to client) and therefore is not visible to dCDN. Ind= icate CDNI must support both situations.: Ray File Management and Content Collections (prezo + discussion): Ray =3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D See slides. They present two options (1.1 and 1.2) Action Items: * add to cdni-has a discussion of a 3rd intermediary option (1.1bis) where= : (Ray) o an "Access Correlation Hint" is distributed in CDNI Metadata for all ch= unks of a Content Collection to indicate those are likely to be requested i= n a short time window. This can help dCDN Surrogate to implement local File= Storage optimization for VoD items (e.g. bundle all files with same Access= Correlation Hint value in a single bundle/file), therefore reducing number= of stored files while minimizing bundling/unbundling overhead. In pros & c= ons discussion indicate that impact on CDNI interfaces is very small (since= the new "Access Correlation Hint" doe snot include any HAS-scheme awarene= ss) but expected benefit is small too. * add to cdni-has a recommendation sub-section under 3.1 indicating that: = (Ray) o recommended approach is 1.1 o approach 1.bis does not seem to bring something significant (Really no = file management optimization ... only file storage benefit), and single CDN= s already do local optimization today without this. It is the responsibilit= y of dCDN to do scaleable file management, not of CDNI. o approach 1.2 would bring benefits but requires full HAS awareness and s= ignificant CDNI extension that would significantly impact our milestones, s= o we don't recommend to include in current work. Good candidate for rechart= ering when initial solution is done. Content Acquisition of Content Collections (prezo + discussion): Ray =3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D See slides. They present two options (2.1 and 2.2) Action Items: * add to cdni-has a recommendation sub-section under 3.2 indicating that: = (Ray) o recommended approach is 2.1. It is definitely sufficient to "make HAS w= ork". o approach 2.2 would bring benefits but requires full HAS awareness and s= ignificant CDNI extension that would significantly impact our milestones, s= o we don't want to include in current work. Good candidate for rechartering= when initial solution is done. * in cdni-has, update the discussion on content acquisition to distinguish= between Dynamic Acquisition of HAS content and Prepositioning of HAS conte= nt. With Dynamic Acquisition, triggered acquisition of subsequent chunks pr= obably has an extra benefit of avoiding acquisition latency on cache-miss. = With Prepositioning, there may be specific ways to enhance those (e.g. a si= ngle CDNI Control prepositioning request lists all chucks to be acquired). = (Ray) Request Routing of HAS content (prezo + discussion): Ray =3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D See slides. They present three options (3.1, 3.2 and 3.3) -( there is a typ= o in the slides so sometimes they show up as 6.x). Action Items: * in cdni-has add statement that client behaviors not always in line with = relative/absolute URIs expected behavior - and therefore needs to be taken = into account when discussing Manifest Manipulation. mention that the issue = with Relative-URL is not specific to HAS; it is also relevant for Web. Page= s have relative-URLs that reference media on the same page which may actual= ly be 'delegated'. (Ray, possibly with input from Ben and Matt) * in cdni-has, in section discussing option 3.1 and Relative URIs, clarify= the exact situation resulting in breaking Relative URIs. Discuss whether t= his already exists in single CDN: Ray (possibly with input from Ben). * in cdni-has, in section discussing option 3.1 and Absolute URIs WIth Red= irection, expand discussion to describe load impact separately for HTTP and= DNS: Ray = RVB: I don't remember this action point. Anyway, I need some input from som= eone who is more familiar with DNS CDNs to help me with this. * in cdni-has, in section discussing option 3.2, clarify that this is some= what transparent to CDNI (i.e. it happens in uCDN before CDNI plays) but th= at it is worth explicitly discussing (in particular in the framework) _if w= e want to allow it_ because it affects how the uCDN will make use of the CD= NI interfaces when using a dCDN. Clarify that, in recursive mode, the case = involving redirection directly to the Surrogate doe snot need the dCDN to "= advertise" topology information, all it requires is the dCDN to indicate th= e Surrogate in the CDN Request Routing/Redirection response : Ray * add to cdni-has a recommendation sub-section under 3.3 indicating that: = (Ray) o options 3.1 must be supported o option 3.2 might be optionally allowed in uCDN (without any specific ex= tensions to CDNI interfaces). We need a little more discussion as to whethe= r it shoudl actually be allowed or not. o option 3.2 would significantly impact our milestones and raises a numbe= r of questions on potential brittleness so we don't recommend to include in= current work. = RVB: I think you mean option 3.3 under the final bullet.. * Do the existing HAS schemes allow combination of use of Relative URLs fo= r normal access to content + use of Absolute URLs with Redirection for back= up access to content (in case normal access fails)? Next steps: =3D=3D=3D=3D=3D=3D=3D=3D * continuation virtual meeting of extended design team on HAS on 7 June 20= 12 * Ray & co-authors to rev up cdni-has * run another virtual meeting of extended design team in 2nd half of June. _______________________________________________ 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 flefauch@cisco.com Fri Jun 1 02:37: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 C296121F8534 for ; Fri, 1 Jun 2012 02:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.519 X-Spam-Level: X-Spam-Status: No, score=-10.519 tagged_above=-999 required=5 tests=[AWL=0.079, 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 0+zHrYYjK6fL for ; Fri, 1 Jun 2012 02:37: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 53B7C21F8532 for ; Fri, 1 Jun 2012 02:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=6165; q=dns/txt; s=iport; t=1338543426; x=1339753026; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=a95PM58KX3uhxCY7byGnfUgeUf3QdsrvsCKmYFl5D9w=; b=ByBl3mxQRCoR8EjhrQ+36vziccTOPPo7DwUbt+YABtbEJtWq6jokX7A2 8uxvI5qc/YILj7C/jZwRr3D5jBatUV9AiFMT20E/GnGi6rFzZ8sH0UVAC YuG1VLuTvaJckUWGMSoGA/zl+4/s/CJ52xaVXp0hTDYDfuBTmuY05UqLw U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALeMyE+Q/khR/2dsb2JhbABEtDWBB4IYAQEBAwESAWYQCxguVwY1h2QFmE+faosPhRVgA5UZjg+BZoJi X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208,217";a="73910206" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 01 Jun 2012 09:37:05 +0000 Received: from ams-flefauch-8713.cisco.com (ams-flefauch-8713.cisco.com [10.55.161.196]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q519b4LF012360; Fri, 1 Jun 2012 09:37:04 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_AEF2ED38-C84D-4766-9001-6E824EC08AE2" From: Francois Le Faucheur In-Reply-To: Date: Fri, 1 Jun 2012 11:37:08 +0200 Message-Id: <7E26733C-8E5D-4D23-93A8-D0B94DAD402F@cisco.com> References: <5B58A245-3F8F-4BAE-945C-F02D158FCCC4@cisco.com> To: "Brandenburg, R. (Ray) van" X-Mailer: Apple Mail (2.1278) Cc: cdni@ietf.org Subject: Re: [CDNi] Notes from May 29 Extended Design Team Meeting on "Adaptive Streaming" X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 09:37:07 -0000 --Apple-Mail=_AEF2ED38-C84D-4766-9001-6E824EC08AE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 1 Jun 2012, at 10:59, Brandenburg, R. (Ray) van wrote: >=20 > * add to cdni-has the distinction between DNS redirection and = HTTP redirection in all sections/discussions (e.g. pros & cons = discussions) where it is relevant (e.g. when discussing impact of = per-chunk request routing, the impact is different for DNS and HTTP): = Ray >=20 > RVB: I will definitely need some input here from people more familiar = with DNS. I seem to remember from our meeting that there was someone who = volunteered to help me with this (although I don't remember who this = was).=20 You probably don't need to go into a lot of details. I think where this = is most relevant is when discussing handling of Absolute URLs with = Redirection and it potential "heavy" load on request routing.=20 Some of the key points that come to mind are: * with DNS, the pure processing cost of handling a request is = slightly lower than with TCP/HTTP because of the lighter protocol stack. = However, the difference is reduced when more fancy decisions are made = (e.g. in the case of recursive mode where the uCDN request router has to = query the dCDN request Router, which is common to both approaches). * with DNS, there is a temptation/opportunity to leverage the = inherent DNS caching mechanism. It is worth mentioning the "scaling vs = accuracy trade-off" that comes into play as soon as you use such caching = (i.e. during caching period, all requests from all clients will be = redirected to exact same IP address as first request from first client, = no matter what). >=20 > * in cdni-has, in section discussing option 3.1 and Absolute = URIs WIth Redirection, expand discussion to describe load impact = separately for HTTP and DNS: Ray=20 >=20 > RVB: I don't remember this action point. Anyway, I need some input = from someone who is more familiar with DNS CDNs to help me with this. Well this is actually the same as the previous action point (only I = listed it also in the context of section 3.1 because it is relevant = there).=20 >=20 > o option 3.2 would significantly impact our milestones = and raises a number of questions on potential brittleness so we don't = recommend to include in current work.=20 >=20 > RVB: I think you mean option 3.3 under the final bullet.. I do. Yes. Thanks Francois= --Apple-Mail=_AEF2ED38-C84D-4766-9001-6E824EC08AE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

* add to = cdni-has the distinction between DNS redirection and HTTP redirection in = all sections/discussions (e.g. pros & cons discussions) where it is = relevant (e.g. when discussing impact of per-chunk request routing, the = impact is different for DNS and HTTP): Ray

RVB: I will definitely = need some input here from people more familiar with DNS. I seem to = remember from our meeting that there was someone who volunteered to help = me with this (although I don't remember who this was). =

You probably don't need to go = into a lot of details. I think where this is most relevant is when = discussing handling of Absolute URLs with Redirection and it potential = "heavy" load on request routing. 
Some of the key points = that come to mind are:
* with DNS, the pure processing = cost of handling a request is slightly lower than with TCP/HTTP because = of the lighter protocol stack. However, the difference is reduced when = more fancy decisions are made (e.g. in the case of recursive mode where = the uCDN request router has to query the dCDN request Router, which is = common to both approaches).
* with DNS, there is a = temptation/opportunity to leverage the inherent DNS caching mechanism. = It is worth mentioning the "scaling vs accuracy trade-off" that comes = into play as soon as you use such caching (i.e. during caching period, = all requests from all clients will be redirected to exact same IP = address as first request from first client, no matter = what).


 * in = cdni-has, in section discussing option 3.1 and Absolute URIs WIth = Redirection, expand discussion to describe load impact separately for = HTTP and DNS:  Ray

RVB: I don't remember this action point. = Anyway, I need some input from someone who is more familiar with DNS = CDNs to help me with = this.

Well this is actually = the same as the previous action point (only I listed it also in the = context of section 3.1 because it is relevant = there). 


 o option = 3.2 would significantly impact our milestones and raises a number of = questions on potential brittleness so we don't recommend to include in = current work.

RVB: I think you mean option 3.3 under the final = bullet..

I do. = Yes.

Thanks

Francois
= --Apple-Mail=_AEF2ED38-C84D-4766-9001-6E824EC08AE2-- From Jan.Seedorf@neclab.eu Fri Jun 1 06:13: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 CF02011E84B5 for ; Fri, 1 Jun 2012 06:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxPFPP4g5vWV for ; Fri, 1 Jun 2012 06:13:14 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id BB36E11E84BD for ; Fri, 1 Jun 2012 06:13:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id D3CC4101356 for ; Fri, 1 Jun 2012 15:13:34 +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 w-EpQLST0cB5 for ; Fri, 1 Jun 2012 15:13:34 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id BA35A101355 for ; Fri, 1 Jun 2012 15:13:29 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.172]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Fri, 1 Jun 2012 15:12:46 +0200 From: Jan Seedorf To: "cdni@ietf.org" Thread-Topic: Notes from May 30th Design Team Conf Call on "Footprint / Capabilities" Thread-Index: Ac0/+AAx1BBZ6z5uSdC8UfhKh9F8Yw== Date: Fri, 1 Jun 2012 13:12:46 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24FD5FA0@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: [CDNi] Notes from May 30th Design Team Conf Call on "Footprint / Capabilities" X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 13:13:15 -0000 Dear all, Please find attached my notes from the "Footprint / Capabilities" design te= am virtual meeting we had this week. - Jan Notes CDNI Footprint/Capabilities Call - May 30, 2012 *************************************************** -- introduction from Francois on goals and scope of the call -- Jon/Stefano: summarize status quo, still quite a few open issues and no = definition for footprint yet, lately some more email activity -- agreement that ISP-owned CDN is a main use case, if not the most importa= nt use case; Francois: use-case doc covers multiple scenarios, incl. ISP-CD= Ns -- Jon: focusing on ISP-CDN may simplify things a lot, if for each IP-addre= ss only one dCDN can serve it; Stefano/Francois: we should not look at only= this case;=20 -- Francois: solution must be able to support a situation with overlapping = footprint, right? Agreement from Stefano, agreement that different dCDN may= claim overlapping footprints -- Francois: business models may have an impact on who makes CDN selection = decisions -- Stefano: why not focus on a single scenario and focus on the mechanism? -- Enrico: should dCDN advertise where they have the caches or what the ban= dwidth is? we need to take the incentive away for the dCDN to cheat -- Jon: there are other choices than prefixes for footprints, e.g. "North A= merica" or cache locations -- Stefano: we should start with a simple case, so prefixes could be a star= ting point -- Allan: location of caches say nothing about the connectivity to endpoint= s on the Internet -- Enrico: we need to have the dCDN advertise something the uCDN can verify= , otherwise dCDN will cheat -- Francois: dCDN information should be verifiable, that's a key point to n= ote down -- Francois: a cheating dCDN may not be the end of the world because there = are strong contractual agreements between uCDN and dCDN -- agreement that we do not consider real-time verification of dCDN stateme= nts but afterwards verification of cheating dCDN is fine -- Francois: let's try to converge - a) upstream CDN makes the decision, b)= let's not try to hard to make dCDN information immediately verifiable, c) = prefix is probably inevitable as one core footprint definition we could sta= rt working with; Jon: agree with this process suggestion -- Jon: how does a over-the-top CDN derive its footprint? -- Stefano: would limit the scope, uCDN decision should be made autonomousl= y -- Jon: we need the semantics of what a footprint is/means -- Francois: semantic of footprint can be simply willingness to serve -- Allan: AS-hops is in fact a metric for quality, hard to define via SLA f= or all users what "good quality" means -- Jon: also a question where the work gets done, at the dCDN or at the uCD= N -- Francois: footprint means "willingness to serve", we have agreed on that= ; we also have agreed that the uCDN needs more information, there are sever= al proposals how to do this -- Jon: need to discuss more on resource advertisement model vs. coverage /= willingness to serve model From flefauch@cisco.com Fri Jun 1 06:49: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 7B9EB11E8229 for ; Fri, 1 Jun 2012 06:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.528 X-Spam-Level: X-Spam-Status: No, score=-10.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 CzFGvJWodfys for ; Fri, 1 Jun 2012 06:49:02 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEE111E8215 for ; Fri, 1 Jun 2012 06:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=856; q=dns/txt; s=iport; t=1338558542; x=1339768142; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=fexc1So5jvTkBVnpgUUhAD9Dsf1ur6cXzZzmQ2AgHJU=; b=aKGf8n7aTLhUcOeNXZtXgo1aI0Myo75hYDyJn7Q6yfIaz2Xqe1rMVAvw Crqbq8WKKKhc3dzTM2eoYbiRkgSdWDe3Cdwka0SGXIX4DXb8rgaXT9Ysk XvZrU+jaIGLUprf9PZIoXMlwIkhTyhZnpAHQuywVtvb/FwWlR6ui8JzRz o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAJLHyE+Q/khR/2dsb2JhbABFtDeBB4IxASeCModplwGBKJ95jW6CNmADlRmOD4FmgmI X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="5265779" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 01 Jun 2012 13:49:01 +0000 Received: from ams-flefauch-8713.cisco.com (ams-flefauch-8713.cisco.com [10.55.161.196]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q51Dn03D027146 for ; Fri, 1 Jun 2012 13:49:01 GMT From: Francois Le Faucheur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jun 2012 15:49:00 +0200 Message-Id: <9FE94F85-3D0B-49A1-87EA-81BD21AA799A@cisco.com> To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [CDNi] draft-ietf-cdni-use-cases to replace RFC3570 "Content Internetworking (CDI) Scenarios" X-BeenThere: cdni@ietf.org X-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, 01 Jun 2012 13:49:03 -0000 Hello, Producing the Document Shepherd writeup for submission of = draft-ietf-cdni-use-cases to IESG review raised the question of whether = any existing RFCs would have their status changed by publication of this = document. We discussed this among co-authors of CDNI documents, chairs and = responsible AD, and concluded that draft-ietf-cdni-use-cases should = replace RFC3570 "Content Internetworking (CDI) Scenarios". And = similarly, we propose that cdni-framework should eventually replace = RFC3466 "A Model for Content Internetworking (CDI)". This is essentially = because these older RFCs touch on very similar scenarios but propose = terminology and models that are slightly different to the more = up-to-date ones proposed in our CDNI documents. Let us know if you have comments or concerns with that. Cheers Francois= From flefauch@cisco.com Mon Jun 4 04:39:02 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A702121F86DD for ; Mon, 4 Jun 2012 04:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.534 X-Spam-Level: X-Spam-Status: No, score=-10.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 NVKPyTSlTivA for ; Mon, 4 Jun 2012 04:39: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 60E3E21F858A for ; Mon, 4 Jun 2012 04:39:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=4409; q=dns/txt; s=iport; t=1338809941; x=1340019541; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=rfjOSrtvJ+xcL+r6QzhtarzhNdVJAwoBVPxXj+4fsyI=; b=BcSujCcuFDRD2pYNgfeENOMsrapBymV5KG3iYRvS1LC2MLC8B3SBBSCq r5aPO1d/mDulWNeslPdAKJSkfZC83tyCaBKias9FLgi1pVTC3rOXp7IJx QRV6vPvCALwNaiIiP1wx8vkVseVR2uilt32EqcshbtkkdeDfL/ZdVkxUd g=; X-IronPort-AV: E=Sophos;i="4.75,712,1330905600"; d="scan'208";a="74000215" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 04 Jun 2012 11:39:00 +0000 Received: from ams-flefauch-8713.cisco.com (ams-flefauch-8713.cisco.com [10.55.161.196]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q54BcxTU011750; Mon, 4 Jun 2012 11:38:59 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Francois Le Faucheur In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE24FD5FA0@Polydeuces.office.hd> Date: Mon, 4 Jun 2012 13:38:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4BCEB5FB-EF80-497F-9084-377564194DCB@cisco.com> References: <2779C9F0771F974CAD742BAE6D9904FE24FD5FA0@Polydeuces.office.hd> To: Jan Seedorf X-Mailer: Apple Mail (2.1278) Cc: "cdni@ietf.org" Subject: Re: [CDNi] Notes from May 30th Design Team Conf Call on "Footprint / Capabilities" X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 11:39:02 -0000 Hello Jan, Thanks for extracting the highlights of our discussion. A few minor = comments below: On 1 Jun 2012, at 15:12, Jan Seedorf wrote: > Dear all, >=20 > Please find attached my notes from the "Footprint / Capabilities" = design team virtual meeting we had this week. >=20 > - Jan >=20 > Notes CDNI Footprint/Capabilities Call - May 30, 2012 > *************************************************** > -- introduction from Francois on goals and scope of the call > -- Jon/Stefano: summarize status quo, still quite a few open issues = and no definition for footprint yet, lately some more email activity > -- agreement that ISP-owned CDN is a main use case, if not the most = important use case; Francois: use-case doc covers multiple scenarios, = incl. ISP-CDNs > -- Jon: focusing on ISP-CDN may simplify things a lot, if for each = IP-address only one dCDN can serve it; Stefano/Francois: we should not = look at only this case;=20 > -- Francois: solution must be able to support a situation with = overlapping footprint, right? Agreement from Stefano, agreement that = different dCDN may claim overlapping footprints > -- Francois: business models may have an impact on who makes CDN = selection decisions Following that, I think there was some discussion and eventually some = agreement that there might be more models but there is one model that we = are clear we need to make work: model where the decision is made by=20 the uCDN (i.e. uCDN selects the dCDN). > -- Stefano: why not focus on a single scenario and focus on the = mechanism? > -- Enrico: should dCDN advertise where they have the caches or what = the bandwidth is? we need to take the incentive away for the dCDN to = cheat > -- Jon: there are other choices than prefixes for footprints, e.g. = "North America" or cache locations > -- Stefano: we should start with a simple case, so prefixes could be a = starting point > -- Allan: location of caches say nothing about the connectivity to = endpoints on the Internet > -- Enrico: we need to have the dCDN advertise something the uCDN can = verify, otherwise dCDN will cheat > -- Francois: dCDN information should be verifiable, that's a key point = to note down Another related point I tried to make then is that "existence of an = incentive to cheat" and "cheat-ability" are more or less common to all = "footprint" approaches. > -- Francois: a cheating dCDN may not be the end of the world because = there are strong contractual agreements between uCDN and dCDN > -- agreement that we do not consider real-time verification of dCDN = statements but afterwards verification of cheating dCDN is fine > -- Francois: let's try to converge - a) upstream CDN makes the = decision, b) let's not try to hard to make dCDN information immediately = verifiable, s/try to hard/try too hard/ > c) prefix is probably inevitable as one core footprint definition we = could start working with; Jon: agree with this process suggestion > -- Jon: how does a over-the-top CDN derive its footprint? > -- Stefano: would limit the scope, uCDN decision should be made = autonomously > -- Jon: we need the semantics of what a footprint is/means > -- Francois: semantic of footprint can be simply willingness to serve > -- Allan: AS-hops is in fact a metric for quality, hard to define via = SLA for all users what "good quality" means > -- Jon: also a question where the work gets done, at the dCDN or at = the uCDN > -- Francois: footprint means "willingness to serve", we have agreed on = that; or perhaps more accurately : footprint means "willingness to serve" + = "some topology information to help uCDN assess in how good a position = the willing CDN actually is to serve well".=20 > we also have agreed that the uCDN needs more information, What I meant here is that the uCDN, to make its dCDN selection, will = likely make use of other information than what is provided by the CDNI = Footprint & Advertisement interface (e.g. price between uCDN and dCDN, = past observation of dCDN quality,=85). Francois > there are several proposals how to do this > -- Jon: need to discuss more on resource advertisement model vs. = coverage / willingness to serve model > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From internet-drafts@ietf.org Tue Jun 5 13:58: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 9CE0421F8855; Tue, 5 Jun 2012 13:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 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 pNZ6vZ+pIIIO; Tue, 5 Jun 2012 13:58:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2309E21F8849; Tue, 5 Jun 2012 13:58:55 -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.02 Message-ID: <20120605205855.17384.94726.idtracker@ietfa.amsl.com> Date: Tue, 05 Jun 2012 13:58:55 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-requirements-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: Tue, 05 Jun 2012 20:58:55 -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) Requ= irements Author(s) : Kent Leung Yiu Lee Filename : draft-ietf-cdni-requirements-03.txt Pages : 21 Date : 2012-06-05 Content Delivery Networks (CDNs) 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. There is a requirement for interconnecting standalone CDNs so that their collective CDN footprint can be leveraged for the end-to-end delivery of content from Content Service Providers (CSPs) to end users. The Content Distribution Network Interconnection (CDNI) working group has been chartered to develop an interoperable and scalable solution for such CDN interconnection. The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group. This draft is a work in progress and requirements may be added, modified, or removed by the working group. Requirements Language The key words "High Priority", "Medium Priority" and "Low Priority" in this document are to be interpreted in the following way: o "High Priority" indicates requirements that are to be supported by the CDNI interfaces. A requirement is stated as "High Priority" when it is established by the working group that it can be met without compromising the targeted schedule for WG deliverables, or when it is established that specifying a solution without meeting this requirement would not make sense and would justify re- adjusting the WG schedule, or both. This is tagged as "[HIGH]". o "Medium Priority" indicates requirements that are to be supported by the CDNI interfaces unless the WG realizes at a later stage that attempting to meet this requirement would compromise the overall WG schedule (for example it would involve complexities that would result in significantly delaying the deliverables). This is tagged as "[MED]". o "Low Priority" indicates requirements that are to be supported by the CDNI interfaces provided that dedicating WG resources to this work does not prevent addressing "High Priority" and "Medium Priority" requirements and that attempting to meet this requirement would not compromise the overall WG schedule. This is tagged as "[LOW]". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cdni-requirements-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-requirements-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-requirements/ From flefauch@cisco.com Wed Jun 6 05:33: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 7C4AD21F8858 for ; Wed, 6 Jun 2012 05:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.059, 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 z3jKae6FC3Dh for ; Wed, 6 Jun 2012 05:33:10 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADB021F8865 for ; Wed, 6 Jun 2012 05:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=16138; q=dns/txt; s=iport; t=1338985989; x=1340195589; h=from:mime-version:subject:date:in-reply-to:to:references: message-id; bh=k0w6AkU5NXkadRVCl9OIvnxBBu26++hZQ7Enp2332ts=; b=THUR/sx05uMHa6zi9IHGvO8V/5HwArBd02UIsg0np3Y5ebwZXH8nPxEZ IEWgoN+4n50yg6Xap8VQCRHIdDL5CEEu/VRzeWOqY2XNlkpo0bgHrC/P1 qGInqC03VP80zq3O65vFb62MBR0bSRsNk3jhpDcWVWmCkoOLMExPTOKst g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALpMz0+Q/khL/2dsb2JhbABFgkWxcIEHghgBAQECAQEBAQEJBgFbEAkCCwcRIwsbDDAZCRmHZAULlyCffgSLEBWFJGADlRyBEI0CgWaCYoFVCA X-IronPort-AV: E=Sophos;i="4.75,724,1330905600"; d="scan'208,217";a="5448878" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 06 Jun 2012 12:33:01 +0000 Received: from ams-flefauch-8713.cisco.com (ams-flefauch-8713.cisco.com [10.55.161.196]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q56CQX3R017642 for ; Wed, 6 Jun 2012 12:33:00 GMT From: Francois Le Faucheur Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_86DED5CE-88F8-49B4-B093-93B816C86877" Date: Wed, 6 Jun 2012 14:28:48 +0200 In-Reply-To: To: cdni@ietf.org References: <5339DEEB-766C-4523-B352-52BC07FA24F3@cisco.com> <31BDC4E6-A560-42CB-804F-A803CEF3D126@cisco.com> Message-Id: X-Mailer: Apple Mail (2.1278) Subject: Re: [CDNi] Continuation of "Extended Design Team Meetings" on "HTTP Adaptive Streaming" : Thursday 7 June X-BeenThere: cdni@ietf.org X-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, 06 Jun 2012 12:33:11 -0000 --Apple-Mail=_86DED5CE-88F8-49B4-B093-93B816C86877 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Just a friendly reminder. Francois On 30 May 2012, at 08:50, Francois Le Faucheur wrote: > Folks, >=20 > As announced we held Yesterday a remote Extended Design Team Meeting = on "HTTP Adaptive Streaming". During that meeting we agreed to schedule = a follow up to continue the discussion since we did not have time to = cover the fill agenda. >=20 > The continuation remote meeting will take place on Thursday 7 June = (same time as Yesterday's meeting). > Details (exact times in different timezones, Webex bridge details, = agenda, pointers to slides, link to Calendar invite) can all be found in = the updated agenda: =20 > = http://www.ietf.org/proceedings/interim/2012/05/29/cdni/agenda/agenda-inte= rim-2012-cdni-1.html >=20 > Looking forward to continuing our discussion (Notes from Yesterday's = discussion will come shortly). >=20 > Cheers >=20 > Francois & Rich >=20 > PS: Nothing has changed regarding our other Extended Design Team = meeting on "CDNI Footprint & Capabilities Advertisement" that will take = place today: > = http://www.ietf.org/proceedings/interim/2012/05/30/cdni/agenda/agenda-inte= rim-2012-cdni-2.html > Talk to you then. >=20 >=20 > On 29 May 2012, at 11:07, Francois Le Faucheur wrote: >=20 >> Folks, >>=20 >> The updated agenda is available at:=20 >> = http://www.ietf.org/proceedings/interim/2012/05/29/cdni/agenda/agenda-inte= rim-2012-cdni-1.html >>=20 >> The slides for the "Logging & HAS" discussion are available at: >> = http://www.ietf.org/proceedings/interim/2012/05/29/cdni/slides/slides-inte= rim-2012-cdni-1-0.pdf >>=20 >> Slides for the other discussions will be made available gradually. >>=20 >> Cheers >>=20 >> Francois & Rich >>=20 >> On 25 May 2012, at 08:12, Francois Le Faucheur wrote: >>=20 >>> Hello, >>>=20 >>> Please note that our two virtual meetings of next week are actually = to be considered as extended design team meetings (instead of formal = Interim Meetings). >>> I am looking forward to those and to our progress towards = convergence on the two corresponding topics.=20 >>>=20 >>> Cheers >>>=20 >>> Francois & Rich >>>=20 >>>=20 >>> * a (3-hour) extended design team meeting on "HTTP Adaptive = Streaming" on Tuesday May 29, 2012 >>> Draft agenda, times and remote attendance details are = accessible from: >>> = http://www.ietf.org/proceedings/interim/2012/05/29/cdni/agenda/agenda-inte= rim-2012-cdni-1.html >>>=20 >>> * a (3-hour) extended design team meeting on "Footprint & = Capabilities Advertisement" on Wednesday May 30, 2012 >>> Draft agenda, times and remote attendance details are = accessible from: >>> = http://www.ietf.org/proceedings/interim/2012/05/30/cdni/agenda/agenda-inte= rim-2012-cdni-2.html >>> _______________________________________________ >>> 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 > Francois Le Faucheur > Distinguished Engineer > Service Provider Video Technology Group =20 > flefauch@cisco.com > Phone: +33 49 723 2619 > Mobile: +33 6 19 98 50 90 >=20 >=20 >=20 > Cisco Systems France > Greenside > 400 Ave de Roumanille > 06410 Sophia Antipolis > France > Cisco.com >=20 >=20 > =20 >=20 > > Think before you print. >=20 > This email may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. >=20 > Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, = Directeur de la publication: Jean-Luc Michel Givone. >=20 > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --Apple-Mail=_86DED5CE-88F8-49B4-B093-93B816C86877 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Just = a friendly reminder.
Francois

On 30 May = 2012, at 08:50, Francois Le Faucheur wrote:


The continuation remote meeting will = take place on Thursday 7 June (same time as Yesterday's = meeting).
Details (exact times in different timezones, Webex = bridge details, agenda, pointers to slides, link to Calendar invite) can = all be found in the updated agenda:  

Looking forward to continuing our discussion (Notes from = Yesterday's discussion will come = shortly).

Cheers

Francoi= s & Rich

PS: Nothing has changed regarding = our other Extended Design Team meeting on "CDNI Footprint & = Capabilities Advertisement" that will take place today:
Talk to = you then.


On 29 May 2012, at 11:07, = Francois Le Faucheur wrote:

Folks,

The = updated agenda is available at: 

The slides for the "Logging & HAS" discussion are available = at:

Slides for the other discussions will be made available = gradually.

Cheers

Franco= is & Rich

On 25 May 2012, at 08:12, Francois = Le Faucheur wrote:

* a = (3-hour) extended design team meeting on "HTTP Adaptive Streaming" on = Tuesday May 29, 2012
Draft agenda, times and remote = attendance details are accessible from:
  http://www.ietf.org/proceedings/interim/2012= /05/29/cdni/agenda/agenda-interim-2012-cdni-1.html

* a = (3-hour) extended design team meeting on "Footprint & Capabilities = Advertisement" on Wednesday May 30, 2012
Draft agenda, times and remote = attendance details are accessible from:
http://www.ietf.org/proceedings/interim/2012= /05/30/cdni/agenda/agenda-interim-2012-cdni-2.html
____= ___________________________________________
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



Francois Le = Faucheur
Distinguished = Engineer
Service Provider Video Technology Group =   

Cisco Systems = France
Greenside
400 Ave de Roumanille
06410 Sophia = Antipolis
France
Cisco.com

 

<green.gif= >
 Think before you = print.
CDNi@ietf.org
https://www.ietf.org/ma= ilman/listinfo/cdni

= --Apple-Mail=_86DED5CE-88F8-49B4-B093-93B816C86877-- From flefauch@cisco.com Fri Jun 8 04:56: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 8CB1621F88EC for ; Fri, 8 Jun 2012 04:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.546 X-Spam-Level: X-Spam-Status: No, score=-9.546 tagged_above=-999 required=5 tests=[AWL=-0.944, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, MIME_QP_LONG_LINE=1.396, 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 wr6NOJQH0pto for ; Fri, 8 Jun 2012 04:56:14 -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 2C4F421F88E9 for ; Fri, 8 Jun 2012 04:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=19592; q=dns/txt; s=iport; t=1339156573; x=1340366173; h=from:subject:date:message-id:cc:to:mime-version; bh=cb2hcfdt6maNNG/zDZIdY3hx2tBXNtffIjgHu5CPoCE=; b=LvGvIX8PCmt+1MME6/RA4HBQCwsjOXY5naiNx67QV4ttRSMvr7zEhmkJ qJqdKgUW2HC1/HoY/QF9GgSP0sy4jZIgPZiIRk+T0W82ieVgYAv9RKJ8z jMFhrpCYdRVFSUjJIvS57WerydyvENziDTgPhBMdfdUY34dAAtHHr+jNU 8=; X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208,217";a="139356973" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 08 Jun 2012 11:56:12 +0000 Received: from ams-flefauch-8713.cisco.com (ams-flefauch-8713.cisco.com [10.55.161.196]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q58BuBdR002101; Fri, 8 Jun 2012 11:56:11 GMT From: Francois Le Faucheur Content-Type: multipart/alternative; boundary="Apple-Mail=_9BDB00E8-F69A-4483-8F73-34418DA22410" Date: Fri, 8 Jun 2012 13:56:05 +0200 Message-Id: To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [CDNi] Notes from June 7 Extended Design Team Meeting on "Adaptive Streaming" X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 11:56:15 -0000 --Apple-Mail=_9BDB00E8-F69A-4483-8F73-34418DA22410 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks, Here are draft notes from the June 7 extended design team meeting. Let = us know if you have comments. Note the decision to run the next Extended Design Team meeting on HAS on = Thursday 28 June (to discus the new rev of dni-has that will be = published by then). Francois=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Extended Design Team Meeting of CDNI on "Adaptive Streaming" Date: Thursday, June 7, 2012 Start Time: 07:00 PDT (e.g San Francisco, USA) =3D 10:00 EDT (e.g = Boston, USA) =3D 16:00 CET (e.g Paris, France) =3D 22:00 CST (e.g. = Beijing, China) Finish Time: 10:30 PDT (e.g San Francisco, USA) =3D 13:30 EDT (e.g = Boston, USA) =3D 19:30 CET (e.g Paris, France) =3D 01:30 CST (e.g. = Beijing, China) The webex recording for the meeting (missing the first 5-10 minutes of = the discussion) is available at: = https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&SP=3DMC&rID=3D61303992&= rKey=3D2a6dac55fc56fbc7=20 SInce the full details of the discussion is accessible through the webex = recording, the notes below focus on the Action Items and conclusions of = the discussions. (by merge of notes from Ray and Francois): intro on Extended Design Team Meeting: Francois =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * This meeting is not a formal Interim Meeting of WG, it is an extended = design team meeting. Logging and HAS: Francois =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D See slides at: = http://www.ietf.org/proceedings/interim/2012/05/29/cdni/slides/slides-inte= rim-2012-cdni-1-0.pdf Option 4.1: - Larry: He suggests that Option 4.1 could actually be used by dCDN to = report "summarized" log info without making any HAS specific changes in = the CDNI Logging interface.=20 - Francois: I don't think that is a good idea. Lack of transparency, = confusing. Eg which URI do you include in the Log record? - Kevin: The uCDN probably needs to know what it is getting from the = dCDN regarding logging. Doing log aggregation in the dCDN without = informing uCDN is not acceptable - Oskar: "Do-Nothing" name is confusing - Francois: clarified that "Do-Nothing" means = "Do-Nothing-specific-for-HAS", but it is still assumed that transport of = logs on CDNI Logging interafce is standardised. * AP: Francois to include a discussion on whether option 4.1 could be = used to also include summarized log info or not. - Francois: Is there anybody who has practical experience with per-chunk = logging and feels the 'Do Nothing'-approach has a real scaling problem? - Ben: In my experience, existing CDNs already have to deal with the = high volume of per-chunk logs today so they are just making it, and the = CSPs are expecting to have access to per-chunk logs. So CDNI should just = assume the same. - Larry: I think CDNs have a scaling problems and as a result will do = aggregation in their dCDN anyways, so we have to deal with aggregated = Logs. - Larry: one important question is how prescriptive can we be on how = aggregation/summarization is performed ? - Francois: I think CDNI can be prescriptive and if a dCDN supporst a = different summarization it will have to convert. But we need a standard = format if we want interoperablity. *AP Francois: add discussion on Larry's point about how "prescriptive" = can CDNI be Option 4.2: - Oskar: Content Collection ID might be useful for other aspects of = dealing with HAS as well (i.e. purge, acquisition, etc.) - Francois: Agreed. But we have to think about whether one identifier = for all aspects or multiple identifiers (one for each aspect) makes more = sense.=20 Option 4.3:=20 - Francois: Important to note that there is a continuum in terms of = trade-offs between level of summarization and amount of information = loss. If this option is chosen, we may have to define a number of = summarization approaches from which the uCDN/dCDN can choose. One of = these options then should be no information loss (and thus no = summarization).=20 - Kevin: Support for particular logging/summarization approaches can be = part of a capability exchange *AP Francois: Add discussion on capability exchange regarding logging to = next version of draft.=20 Option 4.4: - Kent: Proposes 'compressed logs'-approach, where the log files are = compressed at the moment of recording the log (i.e. when two URIs are = similiar, they might be stored more efficiently). This allows advantages = of compression to be used during all steps of the logging process. - Oskar: Log compression is not HAS-specific, but could be used for log = files of any content (i.e. for two unrelated content items from the same = uCDN) *AP Francois: Add additional option proposed by Kent to next version of = draft *AP Francois: Add point made by Oskar regarding general applicability of = log compression to non-HAS *AP: Ben to describe proposed compression approach Option 4.5: - Larry: Problem with this option is that a dCDN does not just have to = be HAS-aware, it has to be HAS-aware in exactly the way defined by the = CDNI standards - Kevin: What happens when some chunks come from one surrogate, and some = other chunks come from another surrogate? - Francois: yes, there are a few challenges that woudl have to be = thought through with summarized logs in the presence of load-balancing. = It might not be such a big issue with 'event-based logging' in case of = change of surrogate mid-session - Kevin: per-chunk load balancing might result in creating more (or at = leats as many) logs as per-chunk logs. - Ray: If we mandate a dCDN to support 'detailed pull', then what is the = advantage of doing all these types of log summarization stuff anyway? - Francois: it allows to use summarized logs on the bulk of the = deliveries and still have access to detailed logs for teh specific = subset of deliveries that require the full details (eg for debugging) - Kevin: Propose to allow CDNs to dynamically communicate regarding = their log capabilities/requests *AP: Francois to add discussion on challenges of summarized logs in case = of load-balancing * AP: Francois to add discussion on supporting both a summarized Push = and a detailed customizable Pull, and discussion on how to deal with = different capabilities. Recommendation: - Option 4.1 is a MUST - If included in CDNI, an additional option with summarization would be = OPTIONAL URI SIgning for HAS content (prezo + discussion): Kent =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Kent presents introduction to URL signing . No slides available, use = cdni-has Option 5.1: *AP Kent: Add table listing possible combinations regarding the URL = signing scenarios to next version of draft *AP Ray/Kent: Add necessary Terminology about different types/levels of = manifests such as "top-level-manifest" (i.e. a manifest might only = describe the different representation levels that are available and = point to other manifest files for describing the chunks that make up a = particular representation level) * AP: Kent: expand the pros & cons discussion to cover the specifics of = each scenario/combination (eg DNS/HTTP, types of URLs, = symmetric/assymetric keys,..) *AP Kent: Clarify effect on CDNI Interfaces for Option 5.1 (or actually = the"lack of effect") - Kevin: I don't think signing the URL of just the top-level manifest = provides any security for HAS content Option 5.3: *AP: Kent to remove separate section for option 5.3 and just mention it = as a special falvor of section 5.2 *AP: Kent : to reflect several concerns raised by Kevin and discussed = (Kent noted them down as we spoke e.g. state that 5.2 provides level of = security afforded by HTTP Cookies). Recommendation: *AP Kent: add a recommendation section stating recommendation to focus = on Option 5.1 Next steps: =3D=3D=3D=3D=3D=3D=3D=3D * Ray & co-authors to rev up cdni-has: target date of 21 June * run another virtual meeting of extended design team for HAS : = Thusrday 28 June. --Apple-Mail=_9BDB00E8-F69A-4483-8F73-34418DA22410 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Date: Thursday, = June 7, 2012
Start Time: 07:00 PDT (e.g San Francisco, USA) =3D 10:00 = EDT (e.g Boston, USA) =3D 16:00 CET (e.g Paris, France) =3D 22:00 CST = (e.g. Beijing, China)
Finish Time: 10:30 PDT (e.g San Francisco, USA) = =3D 13:30 EDT (e.g Boston, USA) =3D 19:30 CET (e.g Paris, France) =3D = 01:30 CST (e.g. Beijing, China)


The webex recording for the = meeting (missing the first 5-10 minutes of the discussion) is available = at:
https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&S= P=3DMC&rID=3D61303992&rKey=3D2a6dac55fc56fbc7 

SInce = the full details of the discussion is accessible through the webex = recording, the notes below focus on the Action Items and conclusions of = the discussions.
(by merge of notes from Ray and = Francois):


intro on Extended Design Team Meeting: = Francois
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
* This meeting is = not a formal Interim Meeting of WG, it is an extended design team = meeting.


Logging and HAS: = Francois
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

Option 4.1:
- Larry:  He suggests that = Option 4.1 could actually be used by dCDN to report "summarized" log = info without making any HAS specific changes in the CDNI Logging = interface. 
- Francois: I don't think that is a good = idea. Lack of transparency, confusing. Eg which URI do you include in = the Log record?
- Kevin: The uCDN probably needs to know what = it is getting from the dCDN regarding logging. Doing log aggregation in = the dCDN without informing uCDN is not acceptable
- Oskar: = "Do-Nothing" name is confusing
- Francois: clarified that = "Do-Nothing" means "Do-Nothing-specific-for-HAS", but it is still = assumed that transport of logs on CDNI Logging interafce is = standardised.

* AP: Francois to include a = discussion on whether option 4.1 could be used to also include = summarized log info or not.

- Francois: Is = there anybody who has practical experience with per-chunk logging and = feels the 'Do Nothing'-approach has a real scaling problem?
- = Ben: In my experience, existing CDNs already have to deal with the high = volume of per-chunk logs today so they are just making it, and the CSPs = are expecting to have access to per-chunk logs. So CDNI should just = assume the same.
- Larry: I think CDNs have a scaling problems = and as a result will do aggregation in their dCDN anyways, so we have to = deal with aggregated Logs.
- Larry: one important question is = how prescriptive can we be on how aggregation/summarization is performed = ?
- Francois: I think CDNI can be prescriptive and if a dCDN = supporst a different summarization it will have to convert. But we need = a standard format if we want = interoperablity.

*AP Francois: add discussion = on Larry's point about how "prescriptive" can CDNI = be

Option 4.2:
- Oskar: Content = Collection ID might be useful for other aspects of dealing with HAS as = well (i.e. purge, acquisition, etc.)
- Francois: Agreed. But = we have to think about whether one identifier for all aspects or = multiple identifiers (one for each aspect) makes more = sense. 

Option 4.3: 
- = Francois: Important to note that there is a continuum in terms of = trade-offs between level of summarization and amount of information = loss. If this option is chosen, we may have to define a number of = summarization approaches from which the uCDN/dCDN can choose. One of = these options then should be no information loss (and thus no = summarization). 
- Kevin: Support for particular = logging/summarization approaches can be part of a capability = exchange

*AP Francois: Add discussion on = capability exchange regarding logging to next version of = draft. 

Option 4.4:
- Kent: = Proposes 'compressed logs'-approach, where the log files are compressed = at the moment of recording the log (i.e. when two URIs are similiar, = they might be stored more efficiently). This allows advantages of = compression to be used during all steps of the logging = process.
- Oskar: Log compression is not HAS-specific, but = could be used for log files of any content (i.e. for two unrelated = content items from the same uCDN)

*AP Francois: = Add additional option proposed by Kent to next version of = draft
*AP Francois: Add point made by Oskar regarding general = applicability of log compression to non-HAS
*AP: Ben to = describe proposed compression approach

Option = 4.5:
- Larry: Problem with this option is that a dCDN does not = just have to be HAS-aware, it has to be HAS-aware in exactly the way = defined by the CDNI standards
- Kevin: What happens when some = chunks come from one surrogate, and some other chunks come from another = surrogate?
- Francois: yes, there are a few challenges that = woudl have to be thought through with summarized logs in the presence of = load-balancing. It might not be such a big issue with 'event-based = logging' in case of change of surrogate mid-session
- Kevin: = per-chunk load balancing might result in creating more (or at leats as = many) logs as per-chunk logs.
- Ray: If we mandate a dCDN to = support 'detailed pull', then what is the advantage of doing all these = types of log summarization stuff anyway?
- Francois: it allows = to use summarized logs on the bulk of the deliveries and still have = access to detailed logs for teh specific subset of deliveries that = require the full details (eg for debugging)
- Kevin: = Propose to allow CDNs to dynamically communicate regarding their log = capabilities/requests


*AP: = Francois to add discussion on challenges of summarized logs in case of = load-balancing
* AP: Francois to add discussion on supporting = both a summarized Push and a detailed customizable Pull, and discussion = on how to deal with different = capabilities.

Recommendation:
- = Option 4.1 is a MUST
- If included in CDNI, an additional = option with summarization would be = OPTIONAL



URI = SIgning for HAS content (prezo + discussion): = Kent
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Kent = presents introduction to URL signing . No slides available, use = cdni-has

Option 5.1:
*AP Kent: Add = table listing possible combinations regarding the URL signing scenarios = to next version of draft
*AP Ray/Kent: Add necessary = Terminology about different types/levels of manifests such as = "top-level-manifest" (i.e. a manifest might only describe the different = representation levels that are available and point to other manifest = files for describing the chunks that make up a particular representation = level)
* AP: Kent: expand the pros & cons discussion to = cover the specifics of each scenario/combination (eg DNS/HTTP, types of = URLs, symmetric/assymetric keys,..)
*AP Kent: Clarify effect = on CDNI Interfaces for Option 5.1 (or actually the"lack of = effect")

- Kevin: I don't think signing the URL = of just the top-level manifest provides any security for HAS = content

Option 5.3:
*AP: Kent to = remove separate section for option 5.3 and just mention it as a special = falvor of section 5.2


*AP: = Kent : to reflect several concerns raised by Kevin and discussed (Kent = noted them down as we spoke e.g. state that 5.2 provides level of = security afforded by HTTP = Cookies).

Recommendation:
*AP Kent: = add a recommendation section stating recommendation to focus on Option = 5.1



Next = steps:
=3D=3D=3D=3D=3D=3D=3D=3D
* Ray = & co-authors to rev up cdni-has: target date of 21 June
* run = another virtual meeting of extended design team for HAS : Thusrday 28 = June.

= --Apple-Mail=_9BDB00E8-F69A-4483-8F73-34418DA22410-- From ietfdbh@comcast.net Fri Jun 8 08:18: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 2F0BC21F894F for ; Fri, 8 Jun 2012 08:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.833 X-Spam-Level: X-Spam-Status: No, score=-101.833 tagged_above=-999 required=5 tests=[AWL=0.766, 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 CEduF8Xu4dtC for ; Fri, 8 Jun 2012 08:18:03 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 6D21521F894E for ; Fri, 8 Jun 2012 08:18:03 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta15.westchester.pa.mail.comcast.net with comcast id Kofe1j00B1YDfWL5FrJ2Vr; Fri, 08 Jun 2012 15:18:02 +0000 Received: from [192.168.1.34] ([71.233.85.150]) by omta20.westchester.pa.mail.comcast.net with comcast id KrJ01j01V3Ecudz3grJ19p; Fri, 08 Jun 2012 15:18:02 +0000 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Fri, 08 Jun 2012 11:17:59 -0400 From: David Harrington To: Message-ID: Thread-Topic: [CDNi] Notes from June 7 Extended Design Team Meeting on "Adaptive Streaming" In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [CDNi] Notes from June 7 Extended Design Team Meeting on "Adaptive Streaming" X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 15:18:05 -0000 Hi, I recommend your Intro discuss the purpose of the design team meeting, rather than focusing on whether it is an official Interim. i.e., What is the goal of the design team meeting? Expand HAS on first use ... The WG seems to be getting awfully wish-listy to me. I get concerned when I see a WG start to add features on features ... Unnecessary complexity can seriously hamper a standard in the field. How many of these features MUST be implemented to meet operational requirements (e.g., legal requirements)? How many are nice-to-haves? (uCDN/dCDN standardized logging, log aggregation, multiple summarization approaches, log compression, multiple IDs, multiple URL signing scenarios, multiple levels of manifests, ...) If you mandate all these nice-to-have-but-not-critical features, implementers will ignore the standard. If you add these nice-to-have but make them optional, implementers won't implement them (to reduce costs), and you'll lose interoperability. Focus on standardizing the core functionality that is actually NEEDED. It is not a surprise when a group of protocol designers get together and recommend designing a protocol ;-) Are you starting to invent a whole new logging protocol for CDNI when widely-used logging standards (syslog, ipfix, etc.) already exist? The SNMP community were convinced they needed their own SNMP-specific security. Operators balked at having to maintain an extra security system just for SNMP. They didn't want to pay operators to attend classes to learn another new security system, and have to make multiple systems work together, etc. Existing tools already know how to gather, correlate, aggregate, forward, and filter the existing standard logging formats. Think of the CDNI logging customers -- the operators, regulators, law enforcement people. Are you going to make operators/regulators/law enforcement learn a whole new logging protocol, and buy a whole new set of tools, just to support CDNI? I think the WG would be wise to look at the existing logging systems and see how to use those to meet requirements. What are operators using NOW for their logging requirements? If not all requirements can be met (CDNI-specific data fields, aggregation, compression, negotiation), maybe you should propose extended capabilities for existing systems rather than inventing a whole new protocol. -- David Harrington Ietfdbh@comcast.net On 6/8/12 7:56 AM, "Francois Le Faucheur" wrote: >Folks, > >Here are draft notes from the June 7 extended design team meeting. Let us >know if you have comments.Note the decision to run the next Extended >Design Team meeting on HAS on Thursday 28 June (to discus the new rev of >dni-has that will be published by then). > >Francois > >========================================================================= > >Extended Design Team Meeting of CDNI on "Adaptive Streaming" >Date: Thursday, June 7, 2012 >Start Time: 07:00 PDT (e.g San Francisco, USA) = 10:00 EDT (e.g Boston, >USA) = 16:00 CET (e.g Paris, France) = 22:00 CST (e.g. Beijing, China) >Finish Time: 10:30 PDT (e.g San Francisco, USA) = 13:30 EDT (e.g Boston, >USA) = 19:30 CET (e.g Paris, France) = 01:30 CST (e.g. Beijing, China) > > >The webex recording for the meeting (missing the first 5-10 minutes of >the discussion) is available at: >https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=61303992&rKey=2 >a6dac55fc56fbc7 > >SInce the full details of the discussion is accessible through the webex >recording, the notes below focus on the Action Items and conclusions of >the discussions. >(by merge of notes from Ray and Francois): > > >intro on Extended Design Team Meeting: Francois >===================================== >* This meeting is not a formal Interim Meeting of WG, it is an extended >design team meeting. > > > >Logging and HAS: Francois >==================== >See slides at: >http://www.ietf.org/proceedings/interim/2012/05/29/cdni/slides/slides-inte >rim-2012-cdni-1-0.pdf > >Option 4.1: >- Larry: He suggests that Option 4.1 could actually be used by dCDN to >report "summarized" log info without making any HAS specific changes in >the CDNI Logging interface. >- Francois: I don't think that is a good idea. Lack of transparency, >confusing. Eg which URI do you include in the Log record? >- Kevin: The uCDN probably needs to know what it is getting from the dCDN >regarding logging. Doing log aggregation in the dCDN without informing >uCDN is not acceptable >- Oskar: "Do-Nothing" name is confusing >- Francois: clarified that "Do-Nothing" means >"Do-Nothing-specific-for-HAS", but it is still assumed that transport of >logs on CDNI Logging interafce is standardised. > >* AP: Francois to include a discussion on whether option 4.1 could be >used to also include summarized log info or not. > >- Francois: Is there anybody who has practical experience with per-chunk >logging and feels the 'Do Nothing'-approach has a real scaling problem? >- Ben: In my experience, existing CDNs already have to deal with the high >volume of per-chunk logs today so they are just making it, and the CSPs >are expecting to have access to per-chunk logs. So CDNI should just >assume the same. >- Larry: I think CDNs have a scaling problems and as a result will do >aggregation in their dCDN anyways, so we have to deal with aggregated >Logs. >- Larry: one important question is how prescriptive can we be on how >aggregation/summarization is performed ? >- Francois: I think CDNI can be prescriptive and if a dCDN supporst a >different summarization it will have to convert. But we need a standard >format if we want interoperablity. > >*AP Francois: add discussion on Larry's point about how "prescriptive" >can CDNI be > >Option 4.2: >- Oskar: Content Collection ID might be useful for other aspects of >dealing with HAS as well (i.e. purge, acquisition, etc.) >- Francois: Agreed. But we have to think about whether one identifier for >all aspects or multiple identifiers (one for each aspect) makes more >sense. > >Option 4.3: >- Francois: Important to note that there is a continuum in terms of >trade-offs between level of summarization and amount of information loss. >If this option is chosen, we may have to define a number of summarization >approaches from which the uCDN/dCDN can choose. One of these options then >should be no information loss (and thus no summarization). >- Kevin: Support for particular logging/summarization approaches can be >part of a capability exchange > >*AP Francois: Add discussion on capability exchange regarding logging to >next version of draft. > >Option 4.4: >- Kent: Proposes 'compressed logs'-approach, where the log files are >compressed at the moment of recording the log (i.e. when two URIs are >similiar, they might be stored more efficiently). This allows advantages >of compression to be used during all steps of the logging process. >- Oskar: Log compression is not HAS-specific, but could be used for log >files of any content (i.e. for two unrelated content items from the same >uCDN) > >*AP Francois: Add additional option proposed by Kent to next version of >draft >*AP Francois: Add point made by Oskar regarding general applicability of >log compression to non-HAS >*AP: Ben to describe proposed compression approach > >Option 4.5: >- Larry: Problem with this option is that a dCDN does not just have to be >HAS-aware, it has to be HAS-aware in exactly the way defined by the CDNI >standards >- Kevin: What happens when some chunks come from one surrogate, and some >other chunks come from another surrogate? >- Francois: yes, there are a few challenges that woudl have to be thought >through with summarized logs in the presence of load-balancing. It might >not be such a big issue with 'event-based logging' in case of change of >surrogate mid-session >- Kevin: per-chunk load balancing might result in creating more (or at >leats as many) logs as per-chunk logs. >- Ray: If we mandate a dCDN to support 'detailed pull', then what is the >advantage of doing all these types of log summarization stuff anyway? >- Francois: it allows to use summarized logs on the bulk of the >deliveries and still have access to detailed logs for teh specific subset >of deliveries that require the full details (eg for debugging) >- Kevin: Propose to allow CDNs to dynamically communicate regarding their >log capabilities/requests > > > >*AP: Francois to add discussion on challenges of summarized logs in case >of load-balancing >* AP: Francois to add discussion on supporting both a summarized Push and >a detailed customizable Pull, and discussion on how to deal with >different capabilities. > >Recommendation: >- Option 4.1 is a MUST >- If included in CDNI, an additional option with summarization would be >OPTIONAL > > > >URI SIgning for HAS content (prezo + discussion): Kent >======================================== >Kent presents introduction to URL signing . No slides available, use >cdni-has > >Option 5.1: >*AP Kent: Add table listing possible combinations regarding the URL >signing scenarios to next version of draft >*AP Ray/Kent: Add necessary Terminology about different types/levels of >manifests such as "top-level-manifest" (i.e. a manifest might only >describe the different representation levels that are available and point >to other manifest files for describing the chunks that make up a >particular representation level) >* AP: Kent: expand the pros & cons discussion to cover the specifics of >each scenario/combination (eg DNS/HTTP, types of URLs, >symmetric/assymetric keys,..) >*AP Kent: Clarify effect on CDNI Interfaces for Option 5.1 (or actually >the"lack of effect") > >- Kevin: I don't think signing the URL of just the top-level manifest >provides any security for HAS content > >Option 5.3: >*AP: Kent to remove separate section for option 5.3 and just mention it >as a special falvor of section 5.2 > > > >*AP: Kent : to reflect several concerns raised by Kevin and discussed >(Kent noted them down as we spoke e.g. state that 5.2 provides level of >security afforded by HTTP Cookies). > >Recommendation: >*AP Kent: add a recommendation section stating recommendation to focus on >Option 5.1 > > > >Next steps: >======== > * Ray & co-authors to rev up cdni-has: target date of 21 June > * run another virtual meeting of extended design team for HAS : Thusrday >28 June. > > > > >_______________________________________________ >CDNi mailing list >CDNi@ietf.org >https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Fri Jun 8 10:51: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 0D1C821F8846 for ; Fri, 8 Jun 2012 10:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.177 X-Spam-Level: X-Spam-Status: No, score=-10.177 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, J_CHICKENPOX_34=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 a4-Nda+JqFmk for ; Fri, 8 Jun 2012 10:51:50 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB0311E8083 for ; Fri, 8 Jun 2012 10:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=15398; q=dns/txt; s=iport; t=1339177909; x=1340387509; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=DUMhuaPBtzCY5m7BeDA1Nz0hLqRLP+atZpjm8AeQOS8=; b=jb0Mw+/FWsqGwoS5diEZLvShTGqJZXDsXeiLrIDEZ52xqHXnztolZ95n N778H7WBxDoh/yJ4452EqtQPTKKq/WMOunXdShn9Fa65hlv9mu74lp2nW GiBAU3JWE1ycN0ybtrj5e+UMPvfVVnGnO/+lo2QXHpQlGOacuMUZYhll0 I=; X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="5565250" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 08 Jun 2012 17:51:48 +0000 Received: from ams-flefauch-8713.cisco.com (ams-flefauch-8713.cisco.com [10.55.161.196]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q58Hplwa028536; Fri, 8 Jun 2012 17:51:47 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Francois Le Faucheur In-Reply-To: Date: Fri, 8 Jun 2012 19:51:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0CFDE26C-933F-4042-9241-7F90A6E910B8@cisco.com> References: To: David Harrington X-Mailer: Apple Mail (2.1278) Cc: cdni@ietf.org Subject: Re: [CDNi] Notes from June 7 Extended Design Team Meeting on "Adaptive Streaming" X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 17:51:52 -0000 Hi David, On 8 Jun 2012, at 17:17, David Harrington wrote: > Hi, >=20 > I recommend your Intro discuss the purpose of the design team meeting, > rather than focusing on whether it is an official Interim. > i.e., What is the goal of the design team meeting? See the agenda that was announced before: = http://www.ietf.org/proceedings/interim/2012/05/29/cdni/agenda/agenda-inte= rim-2012-cdni-1.html. >=20 > Expand HAS on first use =85 These are notes intended to facilitate the work of the design team = focusing on HAS. Also, this is a follow up from the first extended HAS = design team meeting that happend the week before. So the target audience = is very familair with HAS. We are sharing the notes with the rest of the = group for transparency and to invite feedback, but we may not want to be = too strict about accuracy or editorial aspects of these notes. However, = volunteers for good note-taking are very welcome. HAS is also expanded in the agenda that was announced before: = http://www.ietf.org/proceedings/interim/2012/05/29/cdni/agenda/agenda-inte= rim-2012-cdni-1.html. > The WG seems to be getting awfully wish-listy to me. I am not sure how much context you have here, but let me restate that = there is incomplete understanding of the interactions of HTTP Adaptive = Streaming with CDNI and different opinions have been expressed in terms = of how CDNI should handle HTTP Adaptive Streaming (ie do nothing = special, do some light-weight optimization, do a lot of optimization). = Thi question has been slowing the progress of the WG (e.g. we can not = close parts of the cdni-requirements, cdni-framework documents). In = Paris, we identified a plan to go about that, which involves documenting = these interactions and the options for dealing with them in the form of = draft-brandeburg-cdni-has and use that to drive enough concensus for = decisions. These design team meetinsg are mostly about accelerating = this. I'd concede that perhaps we could be a little more "aggressive" about = dropping out options. But, since they come up we feel we may as well = record the at the sae time, so the future decisiosn are well documented. > I get concerned when I see a WG start to add features on features =85 At this stage no feature has been added. Options are documented so that = decisions can be made. If you look at the draft recommendations discussed in the I-D or in the = design team meetings, you may get a sense that the recommendations ted = to err on the "go simple" side. > Unnecessary complexity can seriously hamper a standard in the field. > How many of these features MUST be implemented to meet operational > requirements (e.g., legal requirements)? > How many are nice-to-haves? (uCDN/dCDN standardized logging, log > aggregation, multiple summarization approaches, log compression, = multiple > IDs, multiple URL signing scenarios, multiple levels of manifests, = ...) > If you mandate all these nice-to-have-but-not-critical features, > implementers will ignore the standard. > If you add these nice-to-have but make them optional, implementers = won't > implement them (to reduce costs), and you'll lose interoperability. > Focus on standardizing the core functionality that is actually NEEDED. As per the "Notes from May 29 Extended Design Team Meeting on "Adaptive = Streaming", the Introduction to the Meeting included the following = statement: " * Let's remember that we have a strong motivation to develop first what = is REQUIRED to make HAS work. We need to focus on fundamentals to make = HAS work vs how to use CDN-I to make things work better " So it sounds like we are in synch. >=20 > =20 > It is not a surprise when a group of protocol designers get together = and > recommend designing a protocol ;-) > Are you starting to invent a whole new logging protocol for CDNI when > widely-used logging standards (syslog, ipfix, etc.) already exist? This team is not designing any protocol. It is trying to help decide how = little (or how much) incremental functionality needs to be supported by = the CDNI interfaces specifically for HTTP Adaptive Streaming. Most of us = share your objective of leveraging what exisits (specifically for = Logging). Regarding the specific protocol candidate you mention below, the working = group has not yet started working on specific detailed protocols for = encoding/transport of logging information. Specific proposals levering = existing protocols would be very timely.=20 Thanks for sharing your concerns. Francois >=20 >=20 > The SNMP community were convinced they needed their own SNMP-specific > security. > Operators balked at having to maintain an extra security system just = for > SNMP. > They didn't want to pay operators to attend classes to learn another = new > security system, and have to make multiple systems work together, etc. >=20 > Existing tools already know how to gather, correlate, aggregate, = forward, > and filter the existing standard logging formats. > Think of the CDNI logging customers -- the operators, regulators, law > enforcement people. > Are you going to make operators/regulators/law enforcement learn a = whole > new logging protocol, and buy a whole new set of tools, just to = support > CDNI? >=20 > I think the WG would be wise to look at the existing logging systems = and > see how to use those to meet requirements. > What are operators using NOW for their logging requirements? > If not all requirements can be met (CDNI-specific data fields, > aggregation, compression, negotiation), maybe you should propose = extended > capabilities for existing systems rather than inventing a whole new > protocol. > >=20 > -- > David Harrington > Ietfdbh@comcast.net >=20 >=20 >=20 > On 6/8/12 7:56 AM, "Francois Le Faucheur" wrote: >=20 >> Folks, >>=20 >> Here are draft notes from the June 7 extended design team meeting. = Let us >> know if you have comments.Note the decision to run the next Extended >> Design Team meeting on HAS on Thursday 28 June (to discus the new rev = of >> dni-has that will be published by then). >>=20 >> Francois=20 >>=20 >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Extended Design Team Meeting of CDNI on "Adaptive Streaming" >> Date: Thursday, June 7, 2012 >> Start Time: 07:00 PDT (e.g San Francisco, USA) =3D 10:00 EDT (e.g = Boston, >> USA) =3D 16:00 CET (e.g Paris, France) =3D 22:00 CST (e.g. Beijing, = China) >> Finish Time: 10:30 PDT (e.g San Francisco, USA) =3D 13:30 EDT (e.g = Boston, >> USA) =3D 19:30 CET (e.g Paris, France) =3D 01:30 CST (e.g. Beijing, = China) >>=20 >>=20 >> The webex recording for the meeting (missing the first 5-10 minutes = of >> the discussion) is available at: >> = https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&SP=3DMC&rID=3D61303992&= rKey=3D2 >> a6dac55fc56fbc7=20 >>=20 >> SInce the full details of the discussion is accessible through the = webex >> recording, the notes below focus on the Action Items and conclusions = of >> the discussions. >> (by merge of notes from Ray and Francois): >>=20 >>=20 >> intro on Extended Design Team Meeting: Francois >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> * This meeting is not a formal Interim Meeting of WG, it is an = extended >> design team meeting. >>=20 >>=20 >>=20 >> Logging and HAS: Francois >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> See slides at:=20 >> = http://www.ietf.org/proceedings/interim/2012/05/29/cdni/slides/slides-inte= >> rim-2012-cdni-1-0.pdf >>=20 >> Option 4.1: >> - Larry: He suggests that Option 4.1 could actually be used by dCDN = to >> report "summarized" log info without making any HAS specific changes = in >> the CDNI Logging interface. >> - Francois: I don't think that is a good idea. Lack of transparency, >> confusing. Eg which URI do you include in the Log record? >> - Kevin: The uCDN probably needs to know what it is getting from the = dCDN >> regarding logging. Doing log aggregation in the dCDN without = informing >> uCDN is not acceptable >> - Oskar: "Do-Nothing" name is confusing >> - Francois: clarified that "Do-Nothing" means >> "Do-Nothing-specific-for-HAS", but it is still assumed that transport = of >> logs on CDNI Logging interafce is standardised. >>=20 >> * AP: Francois to include a discussion on whether option 4.1 could be >> used to also include summarized log info or not. >>=20 >> - Francois: Is there anybody who has practical experience with = per-chunk >> logging and feels the 'Do Nothing'-approach has a real scaling = problem? >> - Ben: In my experience, existing CDNs already have to deal with the = high >> volume of per-chunk logs today so they are just making it, and the = CSPs >> are expecting to have access to per-chunk logs. So CDNI should just >> assume the same. >> - Larry: I think CDNs have a scaling problems and as a result will do >> aggregation in their dCDN anyways, so we have to deal with aggregated >> Logs. >> - Larry: one important question is how prescriptive can we be on how >> aggregation/summarization is performed ? >> - Francois: I think CDNI can be prescriptive and if a dCDN supporst a >> different summarization it will have to convert. But we need a = standard >> format if we want interoperablity. >>=20 >> *AP Francois: add discussion on Larry's point about how = "prescriptive" >> can CDNI be >>=20 >> Option 4.2: >> - Oskar: Content Collection ID might be useful for other aspects of >> dealing with HAS as well (i.e. purge, acquisition, etc.) >> - Francois: Agreed. But we have to think about whether one identifier = for >> all aspects or multiple identifiers (one for each aspect) makes more >> sense.=20 >>=20 >> Option 4.3:=20 >> - Francois: Important to note that there is a continuum in terms of >> trade-offs between level of summarization and amount of information = loss. >> If this option is chosen, we may have to define a number of = summarization >> approaches from which the uCDN/dCDN can choose. One of these options = then >> should be no information loss (and thus no summarization). >> - Kevin: Support for particular logging/summarization approaches can = be >> part of a capability exchange >>=20 >> *AP Francois: Add discussion on capability exchange regarding logging = to >> next version of draft. >>=20 >> Option 4.4: >> - Kent: Proposes 'compressed logs'-approach, where the log files are >> compressed at the moment of recording the log (i.e. when two URIs are >> similiar, they might be stored more efficiently). This allows = advantages >> of compression to be used during all steps of the logging process. >> - Oskar: Log compression is not HAS-specific, but could be used for = log >> files of any content (i.e. for two unrelated content items from the = same >> uCDN) >>=20 >> *AP Francois: Add additional option proposed by Kent to next version = of >> draft >> *AP Francois: Add point made by Oskar regarding general applicability = of >> log compression to non-HAS >> *AP: Ben to describe proposed compression approach >>=20 >> Option 4.5: >> - Larry: Problem with this option is that a dCDN does not just have = to be >> HAS-aware, it has to be HAS-aware in exactly the way defined by the = CDNI >> standards >> - Kevin: What happens when some chunks come from one surrogate, and = some >> other chunks come from another surrogate? >> - Francois: yes, there are a few challenges that woudl have to be = thought >> through with summarized logs in the presence of load-balancing. It = might >> not be such a big issue with 'event-based logging' in case of change = of >> surrogate mid-session >> - Kevin: per-chunk load balancing might result in creating more (or = at >> leats as many) logs as per-chunk logs. >> - Ray: If we mandate a dCDN to support 'detailed pull', then what is = the >> advantage of doing all these types of log summarization stuff anyway? >> - Francois: it allows to use summarized logs on the bulk of the >> deliveries and still have access to detailed logs for teh specific = subset >> of deliveries that require the full details (eg for debugging) >> - Kevin: Propose to allow CDNs to dynamically communicate regarding = their >> log capabilities/requests >>=20 >>=20 >>=20 >> *AP: Francois to add discussion on challenges of summarized logs in = case >> of load-balancing >> * AP: Francois to add discussion on supporting both a summarized Push = and >> a detailed customizable Pull, and discussion on how to deal with >> different capabilities. >>=20 >> Recommendation: >> - Option 4.1 is a MUST >> - If included in CDNI, an additional option with summarization would = be >> OPTIONAL >>=20 >>=20 >>=20 >> URI SIgning for HAS content (prezo + discussion): Kent >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Kent presents introduction to URL signing . No slides available, use >> cdni-has >>=20 >> Option 5.1: >> *AP Kent: Add table listing possible combinations regarding the URL >> signing scenarios to next version of draft >> *AP Ray/Kent: Add necessary Terminology about different types/levels = of >> manifests such as "top-level-manifest" (i.e. a manifest might only >> describe the different representation levels that are available and = point >> to other manifest files for describing the chunks that make up a >> particular representation level) >> * AP: Kent: expand the pros & cons discussion to cover the specifics = of >> each scenario/combination (eg DNS/HTTP, types of URLs, >> symmetric/assymetric keys,..) >> *AP Kent: Clarify effect on CDNI Interfaces for Option 5.1 (or = actually >> the"lack of effect") >>=20 >> - Kevin: I don't think signing the URL of just the top-level manifest >> provides any security for HAS content >>=20 >> Option 5.3: >> *AP: Kent to remove separate section for option 5.3 and just mention = it >> as a special falvor of section 5.2 >>=20 >>=20 >>=20 >> *AP: Kent : to reflect several concerns raised by Kevin and discussed >> (Kent noted them down as we spoke e.g. state that 5.2 provides level = of >> security afforded by HTTP Cookies). >>=20 >> Recommendation: >> *AP Kent: add a recommendation section stating recommendation to = focus on >> Option 5.1 >>=20 >>=20 >>=20 >> Next steps: >> =3D=3D=3D=3D=3D=3D=3D=3D >> * Ray & co-authors to rev up cdni-has: target date of 21 June >> * run another virtual meeting of extended design team for HAS : = Thusrday >> 28 June. >>=20 >>=20 >>=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 internet-drafts@ietf.org Mon Jun 11 06:19: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 9407621F8559; Mon, 11 Jun 2012 06:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 PsDmlxJrx5vn; Mon, 11 Jun 2012 06:19:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE00221F850B; Mon, 11 Jun 2012 06:19:44 -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.02 Message-ID: <20120611131944.20217.16607.idtracker@ietfa.amsl.com> Date: Mon, 11 Jun 2012 06:19:44 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-use-cases-07.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, 11 Jun 2012 13:19:45 -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 Trevor Burbridge Philip Eardley Kevin J. Ma Grant Watson Filename : draft-ietf-cdni-use-cases-07.txt Pages : 16 Date : 2012-06-11 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 CDN Interconnection (CDNI) interfaces. It obsoletes RFC 3570. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-07.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-07.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-use-cases/ From haibin.song@huawei.com Tue Jun 12 00:31:20 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D14E21F85B5 for ; Tue, 12 Jun 2012 00:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 zj7L4CxLQuhM for ; Tue, 12 Jun 2012 00:31:19 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D07AB21F85AF for ; Tue, 12 Jun 2012 00:31:19 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHC61175; Tue, 12 Jun 2012 03:31:19 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 12 Jun 2012 00:30:02 -0700 Received: from SZXEML435-HUB.china.huawei.com (10.72.61.63) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 12 Jun 2012 00:30:05 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.45]) by szxeml435-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Tue, 12 Jun 2012 15:30:00 +0800 From: Songhaibin To: "cdni@ietf.org" Thread-Topic: One comment on draft-bertrand-cdni-footprint-discovery Thread-Index: Ac1IbSuBAY/4oOUSRhaTUoLHb2A6Hg== Date: Tue, 12 Jun 2012 07:29:59 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [CDNi] One comment on draft-bertrand-cdni-footprint-discovery X-BeenThere: cdni@ietf.org X-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, 12 Jun 2012 07:31:20 -0000 Hi, I do not know if the following requirement from the draft was discussed bef= ore. But I'm not sure it is required. FPT-3 [MED] A uCDN should not forward to any other CDN the Footprint and De= livery Proximity information that it has discovered about a dCDN without th= e explicit agreement of this dCDN. What kind of confidential information or relationship between uCDN and dCDN= prevent the disclosure of this information? If it is a requirement, does i= t imply there is a requirement for a dCDN to authorize a uCDN to discovery = its footprint? BR, -Haibin From flefauch@cisco.com Fri Jun 15 08:42: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 4BCE721F84AF for ; Fri, 15 Jun 2012 08:42:42 -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 kwNahXgQVGGn for ; Fri, 15 Jun 2012 08:42:41 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 641D621F84A6 for ; Fri, 15 Jun 2012 08:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=1705; q=dns/txt; s=iport; t=1339774961; x=1340984561; h=from:subject:date:message-id:to:mime-version; bh=ttdjR4gfanl3PDKqm7I1zF/Bo3CiKtTFVODhjuT6EVQ=; b=bnrmnaVUuw2g965bHmsU2mPDbW7FcX9nfyOwUY3z+Wd6foZd8Ev+CW6g qXDicrNxR1IF6I5ST1Piky5bCchtWGaapKiQPZE56ON7YvdTOI+iD8bF3 c3R5dh7r5JzSt8OLJfOYj5o2+55AKBbUiLa9fP39uJn+lBEjUXQGx2HDX 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4IAN1W20+tJXG8/2dsb2JhbABFrG2IZoEHgg8iAYEEAYE7GYdpC5hAgSigKY4sgjtgA5UkjheBZoJi X-IronPort-AV: E=Sophos;i="4.75,778,1330905600"; d="scan'208,217";a="92827576" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 15 Jun 2012 15:42:41 +0000 Received: from rtp-vpn4-499.cisco.com (rtp-vpn4-499.cisco.com [10.82.209.243]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5FFgdqi002848 for ; Fri, 15 Jun 2012 15:42:40 GMT From: Francois Le Faucheur Content-Type: multipart/alternative; boundary="Apple-Mail=_807BD4AE-F098-47E5-A920-75E5F3788920" Date: Fri, 15 Jun 2012 17:42:07 +0200 Message-Id: To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [CDNi] next "Extended Design Team Meetings" on "HTTP Adaptive Streaming" : Thursday 28 June X-BeenThere: cdni@ietf.org X-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, 15 Jun 2012 15:42:42 -0000 --Apple-Mail=_807BD4AE-F098-47E5-A920-75E5F3788920 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks, The next Extended Design Team Meeting on "HTTP Adaptive Streaming" will = take place on 28 June (as agreed during our last meeting on 7 June). =20 Details (exact times in different timezones, Webex bridge details, = agenda, link to Calendar invite) can all be found in the on-line agenda: = =20 = http://www.ietf.org/proceedings/interim/2012/06/28/cdni/agenda/agenda-inte= rim-2012-cdni-3.html Looking forward to continuing our discussion. Cheers Francois & Rich --Apple-Mail=_807BD4AE-F098-47E5-A920-75E5F3788920 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Folks,

The next Extended Design Team Meeting on "HTTP Adaptive Streaming" will take place on 28 June (as agreed during our last meeting on 7 June).
 
Details (exact times in different timezones, Webex bridge details, agenda, link to Calendar invite) can all be found in the on-line agenda:  

Looking forward to continuing our discussion.

Cheers

Francois & Rich

--Apple-Mail=_807BD4AE-F098-47E5-A920-75E5F3788920-- From flefauch@cisco.com Fri Jun 15 09:06: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 D335821F8459 for ; Fri, 15 Jun 2012 09:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBWrreBPW9ff for ; Fri, 15 Jun 2012 09:06:13 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8D521F8458 for ; Fri, 15 Jun 2012 09:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=520; q=dns/txt; s=iport; t=1339776373; x=1340985973; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=ZJo69RS1jpBIGh3ldCas0f/G9vprnn0JNRnrrupLC8w=; b=XjhEec8pYuBhtXRpTC186bk3zwAW3a69ztdoS2Ey0PrvWvkBcwEd4cup /Ws6bVXBcfqqnnRS2aKJUp2kL9lsgixZeyi3R4kxTMSxtNkGMZVIYCq33 2CBdXjM+w2u3B9nk5Ob4RLm7LcDlzGmBEB6EwnCQz11C022vMKmQgRIa7 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACxc20+tJXG+/2dsb2JhbABFtVOBB4IZAQEEEgEnTwtGVyIZh2kLmV+gKo4sgjtgA5UkjheBZoJi X-IronPort-AV: E=Sophos;i="4.75,778,1330905600"; d="scan'208";a="92843041" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 15 Jun 2012 16:06:12 +0000 Received: from rtp-vpn4-499.cisco.com (rtp-vpn4-499.cisco.com [10.82.209.243]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5FG6BLi021858 for ; Fri, 15 Jun 2012 16:06:12 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Francois Le Faucheur In-Reply-To: Date: Fri, 15 Jun 2012 18:05:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0CC594F8-E9A7-42A0-8BEA-5F137BB32E3A@cisco.com> References: To: cdni@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [CDNi] next "Extended Design Team Meetings" on "HTTP Adaptive Streaming" : Thursday 28 June X-BeenThere: cdni@ietf.org X-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, 15 Jun 2012 16:06:13 -0000 (resending with fixed link) Folks, The next Extended Design Team Meeting on "HTTP Adaptive Streaming" will = take place on 28 June (as agreed during our last meeting on 7 June). =20 Details (exact times in different timezones, Webex bridge details, = agenda, link to Calendar invite) can all be found in the on-line agenda: = =20 = http://www.ietf.org/proceedings/interim/2012/06/28/cdni/agenda/agenda-inte= rim-2012-cdni-3.html Looking forward to continuing our discussion. Cheers Francois & Rich From internet-drafts@ietf.org Mon Jun 18 01:53:31 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 3A0E921F859B; Mon, 18 Jun 2012 01:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcB5HtCqtEHN; Mon, 18 Jun 2012 01:53:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBEA21F8499; Mon, 18 Jun 2012 01:53:30 -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.20 Message-ID: <20120618085330.506.27918.idtracker@ietfa.amsl.com> Date: Mon, 18 Jun 2012 01:53:30 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-use-cases-08.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 08:53:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : Use Cases for Content Delivery Network Interconnection Author(s) : Gilles Bertrand Stephan Emile Trevor Burbridge Philip Eardley Kevin J. Ma Grant Watson Filename : draft-ietf-cdni-use-cases-08.txt Pages : 16 Date : 2012-06-18 Abstract: 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 CDN Interconnection (CDNI) interfaces. It obsoletes RFC 3570. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-use-cases There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-use-cases-08 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-use-cases-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From vumip1@gmail.com Tue Jun 19 07:24: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 8068421F8594 for ; Tue, 19 Jun 2012 07:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usMNcdjssmUe for ; Tue, 19 Jun 2012 07:24:08 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B6E1621F858A for ; Tue, 19 Jun 2012 07:24:08 -0700 (PDT) Received: by ghbg16 with SMTP id g16so5160399ghb.31 for ; Tue, 19 Jun 2012 07:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=MQ6OsLNxSHoomDpeD9ivMCHw0O9ggAp9aSjpp2eCqgo=; b=nirA4H2saPxkDLKizp//3WYXgRQYGkyKwgpFT6K6bzE+9h9YYQ/KDDj+K0A/VPdbwg 09PChaV7Q1YP1x+DcdKFaK3KVjMPAlXPw7+wOC9I00SjNUkBVDB+8L8gdYAv+vbKt9lw 2jrX95vC1I0hCzOd83Pvv8pP7aQOgxWCnGvO8YnDwJ2zbyYxEFx1BL/u8yQ03hKO5iW8 TnZWPW+vu8nzibdsTOkTNhM1cbF4cdzj4hlD2+CbDXVn00G4aAuzzD7iQK1s/XvzCZju +FJLjBlP68Er0vepmajnq9N05uGzPrafZDtOOwCSFcugI/9eLHpWwJn/CAmzNces/67R tgNw== MIME-Version: 1.0 Received: by 10.60.9.134 with SMTP id z6mr19799631oea.46.1340115848102; Tue, 19 Jun 2012 07:24:08 -0700 (PDT) Received: by 10.182.12.100 with HTTP; Tue, 19 Jun 2012 07:24:08 -0700 (PDT) Date: Tue, 19 Jun 2012 10:24:08 -0400 Message-ID: From: Bhumip Khasnabish To: cdni@ietf.org Content-Type: multipart/alternative; boundary=e89a8ff2502015847e04c2d409dd Subject: [CDNi] requesting comments on Content De-duplication draft X-BeenThere: cdni@ietf.org X-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, 19 Jun 2012 14:24:09 -0000 --e89a8ff2502015847e04c2d409dd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, We recently published a draft (draft-jin-cdni-content-deduplication-optimization-01.txt) on Content De-duplication. Would appreciate your comments, suggestions, and thoughts on this very important topics. Thanks. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Content De-duplication for CDNi Optimization Author(s) : WeiYi Jin Mian Li Bhumip Khasnabish Filename : draft-jin-cdni-content-deduplication-optimization-01.txt Pages : 17 Date : 2012-06-18 Abstract: Recent explosive growth of content delivery/distribution networks (CDNs) and their interconnection are causing unintended repetition of content storage in the same dCDN. This can be avoided by using a suitable de-duplication mechanism. This document explores the scenarios which create the problems, and then discusses the approaches to eliminate the duplicated transmission of the same content from uCDN(s) to dCDN in CDNi networks. To implement the optimization, some enhancements to the CDNi metadata model and interface are required. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-jin-cdni-content-deduplication-optim= ization There's also a htmlized version available at: http://tools.ietf.org/html/draft-jin-cdni-content-deduplication-optimizatio= n-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-jin-cdni-content-deduplication-o= ptimization-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Best. Bhumip Bhumip Khasnabish vumip1@gmail.com +1-781-752-8003 (mobile) http://tinyurl.com/bhumip __o _ `\ <, _ .......... ( =95 ) / ( =95 ) ...................... --e89a8ff2502015847e04c2d409dd Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hello,
=A0
We recently published a
draft (draft-jin-cdni-content-deduplication-optimization-01.txt)
on Content De-duplication.
=A0
Would appreciate your comments, suggestions, and thoughts
on this very important topics. Thanks.
=A0
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
=A0
A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.


Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : Content De-dupli= cation for CDNi Optimization
Author(s)=A0=A0=A0=A0=A0=A0 : WeiYi Jin
= =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= Mian Li
=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= Bhumip Khasnabish
Filename=A0=A0=A0=A0=A0=A0=A0 : draft-jin-cdni-conten= t-deduplication-optimization-01.txt
Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = : 17
Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2012-06-18

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


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

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

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


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

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Best.
=A0
Bhumip
=A0
Bhumip Khasnabish

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 __o
=A0= =A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0 _ `\ <, _
.......... ( =95 ) / ( =95 = ) ......................

--e89a8ff2502015847e04c2d409dd-- From flefauch@cisco.com Tue Jun 19 09:40: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 5BE9A11E80B7 for ; Tue, 19 Jun 2012 09:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1f+m3V2LWFc for ; Tue, 19 Jun 2012 09:40:17 -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 A053811E8099 for ; Tue, 19 Jun 2012 09:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=4557; q=dns/txt; s=iport; t=1340124017; x=1341333617; h=from:subject:date:references:to:message-id:mime-version; bh=FHzMkm6ML4tjlXTgwPjFrg16Pybx3KcsPsKlxol9298=; b=kUMYW7B/DD7kSxh2z5+1wd8SogWMam5H9J8HNt1phFqhnne/UhVEWPMp GkEfmI9og7hilSfU1XozFCBSC4JlcKQ7EpIY2srvQXeRWHmGgS+gsF+KA IkbUh6JC4yXPjcA7gYg7Q5Jm3rHpwzFxQNRcls9mMEW6Nubq7g9Y6kmKa U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHWq4E+rRDoH/2dsb2JhbABFtWuBB4IYAQEBAwESAWsLDw0DAQIkC00CCBkih2QEDJkhoDkEiy+CfoI7YAOIQ4xijheBZoMA X-IronPort-AV: E=Sophos;i="4.75,799,1330905600"; d="scan'208,217";a="46937320" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 19 Jun 2012 16:40:17 +0000 Received: from dhcp-171-68-20-103.cisco.com (dhcp-171-68-20-103.cisco.com [171.68.20.103]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5JGeHSD022432 for ; Tue, 19 Jun 2012 16:40:17 GMT From: Francois Le Faucheur Content-Type: multipart/alternative; boundary="Apple-Mail=_FBE6799D-A4CC-4B27-88FB-7FCAA932D106" Date: Tue, 19 Jun 2012 09:40:16 -0700 References: <20120619155435.9957.86171.idtracker@ietfa.amsl.com> To: cdni@ietf.org Message-Id: <2338DA55-B4FE-4607-881B-B01C1553D5E6@cisco.com> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [CDNi] Fwd: IPR Disclosure: Koninklijke KPN N.V.'s Statement about IPR related to draft-brandenburg-cdni-has-01 X-BeenThere: cdni@ietf.org X-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, 19 Jun 2012 16:40:18 -0000 --Apple-Mail=_FBE6799D-A4CC-4B27-88FB-7FCAA932D106 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI Begin forwarded message: > From: IETF Secretariat > Subject: IPR Disclosure: Koninklijke KPN N.V.'s Statement about IPR = related to draft-brandenburg-cdni-has-01 > Date: 19 June 2012 08:54:35 PDT > To: oskar.vandeventer@tno.nl, ray.vanbrandenburg@tno.nl, = flefauch@cisco.com, kleung@cisco.com > Cc: housley@vigilsec.com, ipr-announce@ietf.org >=20 >=20 > Dear Oskar van Deventer, Ray van Brandenburg, Francois Le Faucheur, = Kent Leung: >=20 > An IPR disclosure that pertains to your Internet-Draft entitled = "Models for > adaptive-streaming-aware CDN Interconnection" = (draft-brandenburg-cdni-has) was > submitted to the IETF Secretariat on 2012-06-19 and has been posted on = the "IETF > Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1803/). The title of the IPR = disclosure is > "Koninklijke KPN N.V.'s Statement about IPR related to = draft-brandenburg-cdni- > has-01.""); >=20 > The IETF Secretariat >=20 --Apple-Mail=_FBE6799D-A4CC-4B27-88FB-7FCAA932D106 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: IETF Secretariat = <ietf-ipr@ietf.org>
Subject: = IPR Disclosure: Koninklijke KPN N.V.'s Statement = about IPR related to = draft-brandenburg-cdni-has-01
Date: 19 June 2012 = 08:54:35 PDT
Cc: housley@vigilsec.com, ipr-announce@ietf.org
=


Dear Oskar van Deventer, Ray van Brandenburg, = Francois Le Faucheur, Kent Leung:

An IPR disclosure that = pertains to your Internet-Draft entitled "Models = for
adaptive-streaming-aware CDN Interconnection" = (draft-brandenburg-cdni-has) was
submitted to the IETF Secretariat on = 2012-06-19 and has been posted on the "IETF
Page of Intellectual = Property Rights Disclosures"
(https://datatracker.ietf.o= rg/ipr/1803/). The title of the IPR disclosure is
"Koninklijke = KPN N.V.'s Statement about IPR related to = draft-brandenburg-cdni-
has-01."");

The IETF = Secretariat


In-Reply-To: Date: Tue, 19 Jun 2012 11:18:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5388986F-034F-4E38-A5A3-78B6E30F56A5@cisco.com> <8E09C72DBC577D489F13A71228C0B7BF035ED73B@ftrdmel0.rd.francetelecom.fr> <89ACE04E-3414-4D68-9106-97FF36AE2F2B@cisco.com> <3BE12F3B-51F6-4524-BBD2-C152C4F1F4C0@verivue.com> To: "Deventer, M.O. (Oskar) van" X-Mailer: Apple Mail (2.1278) Cc: cdni@ietf.org Subject: Re: [CDNi] Two additional definitions for cdni-framework X-BeenThere: cdni@ietf.org X-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, 19 Jun 2012 18:18:57 -0000 Hello Oskar, Some early thoughts (as an individual): >=20 > -----Original Message----- > From: Deventer, M.O. (Oskar) van=20 > Sent: maandag 11 juni 2012 9:24 > To: cdni@ietf.org > Subject: RE: [CDNi] Two additional definitions for cdni-framework >=20 > Dear all, >=20 > Here are the main points from my previous email, summarized for easy = reading.=20 > 1) Proposal to define "upstream" and "downstream" in terms of = distribution, instead of redirection. Not sure there is a problem with the current definition. I would see a number of problems with trying to define uCDN/dCDN based = on the distribution flow e.g. while the content would typically flow = from the uCDN to the dCDN, this will not always be the case. ie a dCDN = may acquire the content from somewhere else than the uCDN (eg CSP, = another CDN) > 2) Proposal to reduce the number of CDNi interfaces to two (c.f. ETSI = approach). I don't think we need and want to redefine our set of CDNI interfaces at = this stage.=20 > 3) Proposal for a more strict definition of Content Item (see ETSI = definition). I'll have to look at the proposed alternative definition. I suggest you = look at the terminology introduced in draft-brandeburg-cdni-has for = segemnted content. Francois > 4) Proposal to distinguish logging ("recording event ...") from = reporting ("providing access to recorded events ...").=20 > Arguments: see my previous email below. >=20 > These proposals would impact (at least) the following documents = http://tools.ietf.org/wg/cdni/draft-ietf-cdni-problem-statement/ > http://tools.ietf.org/wg/cdni/draft-ietf-cdni-framework/ >=20 > Best regards, >=20 > Oskar From iesg-secretary@ietf.org Wed Jun 20 06:14: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 BFD5B21F8763; Wed, 20 Jun 2012 06:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 gpt9-JgtqDhe; Wed, 20 Jun 2012 06:14:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB2A21F875C; Wed, 20 Jun 2012 06:14:55 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120620131455.24890.88386.idtracker@ietfa.amsl.com> Date: Wed, 20 Jun 2012 06:14:55 -0700 Cc: cdni@ietf.org Subject: [CDNi] Last Call: (Use Cases for Content Delivery Network Interconnection) to Informational RFC X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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, 20 Jun 2012 13:14:56 -0000 The IESG has received a request from the Content Delivery Networks Interconnection WG (cdni) to consider the following document: - 'Use Cases for Content Delivery Network Interconnection' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-07-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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 CDN Interconnection (CDNI) interfaces. It obsoletes RFC 3570. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-cdni-use-cases/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-cdni-use-cases/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1764/ From dan-ietf@danyork.org Thu Jun 21 19:31: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 9997621F844B for ; Thu, 21 Jun 2012 19:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=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 ewsSJVC-2iQL for ; Thu, 21 Jun 2012 19:31:58 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 5518221F8448 for ; Thu, 21 Jun 2012 19:31:58 -0700 (PDT) Received: by qabj34 with SMTP id j34so131003qab.4 for ; Thu, 21 Jun 2012 19:31:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:mime-version:content-type:subject:date:references:cc:to :message-id:x-mailer:x-gm-message-state; bh=d9KTnUz3YvXRMtfUHOzMjW5+KuN0/TNAj0AAbz9YyTE=; b=Q2iEfQo/01nuClnX+EuG18JVeWVm1RFTbZRgyxP995SlRAF2QCMGOyGpMx24fRVcY5 mgBhz7nw6XKcvBR8bXp+osRgbRl4G2ENO1SS+rCjWXpZadsD7bxIK0MB45DC5flaM4DX EjQ13G7JaAQFl63CtIbhhZJtNYoXrWxufncwXcHPqduYRzzZNiG4q7jOYEvStaJcICoS 2CYf51hG31MIdegp1WPTYbXFM/06YRwq7tzXHdEoAHhl7uGOJv/bSHyuzAVIqSwzLDMv qW9/tOUoYFE3JD8V9LTyAqqOqdMnDKwTu8N7A0Y2G9UQQLRSqLnwrBFuHPINNCjGF2CZ tsQw== Received: by 10.224.58.201 with SMTP id i9mr3523736qah.39.1340332317659; Thu, 21 Jun 2012 19:31:57 -0700 (PDT) Received: from [172.20.12.152] (cpe-74-75-92-114.maine.res.rr.com. [74.75.92.114]) by mx.google.com with ESMTPS id j12sm46518074qak.15.2012.06.21.19.31.56 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jun 2012 19:31:57 -0700 (PDT) From: Dan York Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_1FC4C94A-3510-4F1A-9B2F-CDFE747C2C5E" Date: Thu, 21 Jun 2012 22:31:50 -0400 References: <3A900E99-5226-4023-BB23-F06DF648A0B2@danyork.org> To: IETF-Discussion list Message-Id: <4D8B1F16-20F2-4C55-834B-65DE1DA2BA58@danyork.org> X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnxd4zW0oOs2q/ZidyjocjcjTKQjzjk6QNiHjt/hm6yffSzK4fSgsyb0f1/GWNffNOA2Ect Cc: cdni@ietf.org Subject: Re: [CDNi] Last Call: (Use Cases for Content Delivery Network Interconnection) to Informational RFC X-BeenThere: cdni@ietf.org X-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, 22 Jun 2012 02:31:59 -0000 --Apple-Mail=_1FC4C94A-3510-4F1A-9B2F-CDFE747C2C5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Responding to the Last Call for comments, I think the draft is well done = and will be very useful in helping people understand what the CDNI = effort is all about. My only substantive comment is that there is another use case related to = IPv6 that could be spelled out under section 4.1, "Device and Network = Technology Extension": http://tools.ietf.org/html/draft-ietf-cdni-use-cases-08#section-4.1 The text for the additional use case could be: ---- 3. CDN-A only supports IPv4 within its infrastructure but wants to = deliver content over IPv6. CDN-B supports both IPv4 and IPv6 within its = infrastructure. CDN-A interconnects with CDN-B to serve out its content = over native IPv6 connections. ---- In truth this could be seen as a variation of use case #1 in this = section, "CDN-A cannot support a specific delivery protocol," and is = similar to the reference to HTTPS in use case #1. However, when I read = that use case I find myself thinking about higher level delivery = protocols and not something as fundamental as IP. =20 Plus, given that we'll be in the IPv4/IPv6 transition for some time, it = may be useful to specifically highlight how CDNI could assist in the = transition to IPv6. Again, I think it's a good document that should be published. My 2 cents, Dan P.S. Well, I will also admit that the comma in the first sentence of the = abstract bothers me: "Content Delivery Networks (CDNs) are commonly used = for improving the End User experience of a content delivery service, at = a reasonable cost." I think that comma could be removed... but I'll = leave that for the grammarians to duke it out... :-) On Jun 20, 2012, at 9:14 AM, The IESG wrote: >=20 > The IESG has received a request from the Content Delivery Networks > Interconnection WG (cdni) to consider the following document: > - 'Use Cases for Content Delivery Network Interconnection' > as Informational RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-07-04. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=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 focuses on use cases that correspond to > identified industry needs and that are expected to be realized once > open interfaces and protocols supporting interconnection of CDNs are > specified and implemented. The document can be used to guide the > definition of the requirements to be supported by CDN = Interconnection > (CDNI) interfaces. It obsoletes RFC 3570. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-cdni-use-cases/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-cdni-use-cases/ballot/ >=20 >=20 > The following IPR Declarations may be related to this I-D: >=20 > http://datatracker.ietf.org/ipr/1764/ >=20 >=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --=20 Dan York dyork@lodestar2.com http://danyork.me/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork -------------------------------------------------------- All comments and opinions are entirely my own and have no connection = whatsoever to any employer, past or present. Indeed, by tomorrow even I = might be disavowing these comments. -------------------------------------------------------- --=20 Dan York dyork@lodestar2.com http://www.danyork.com/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork -------------------------------------------------------- All comments and opinions are entirely my own and have no connection = whatsoever to any employer, past or present. Indeed, by tomorrow even I = might be disavowing these comments. -------------------------------------------------------- --Apple-Mail=_1FC4C94A-3510-4F1A-9B2F-CDFE747C2C5E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Responding to the Last Call for comments, I = think the draft is well done and will be very useful in helping people = understand what the CDNI effort is all about.

My only = substantive comment is that there is another use case related to IPv6 = that could be spelled out under section 4.1, "Device and Network = Technology Extension":


The text for the additional use case could = be:
----
3. CDN-A only supports IPv4 within its = infrastructure but wants to deliver content over IPv6.  CDN-B = supports both IPv4 and IPv6 within its infrastructure. CDN-A = interconnects with CDN-B to serve out its content over native IPv6 = connections.
----

In truth this could = be seen as a variation of use case #1 in this section, "CDN-A cannot = support a specific delivery protocol," and is similar to the reference = to HTTPS in use case #1.  However, when I read that use case I find = myself thinking about higher level delivery protocols and not something = as fundamental as IP.  

Plus, given that = we'll be in the IPv4/IPv6 transition for some time, it may be useful to = specifically highlight how CDNI could assist in the transition to = IPv6.

Again, I think it's a good document that = should be published.

My 2 = cents,
Dan

P.S. Well, I will also = admit that the comma in the first sentence of the abstract bothers me: = "Content Delivery Networks (CDNs) are commonly used for improving = the End User experience of a content delivery service, at a = reasonable cost." I think that comma could be removed... but I'll = leave that for the grammarians to duke it out... = :-)

On Jun 20, 2012, at 9:14 AM, The IESG = wrote:


The IESG has received a request from the Content = Delivery Networks
Interconnection WG (cdni) to consider the following = document:
- 'Use Cases for Content Delivery Network = Interconnection'
 <draft-ietf-cdni-use-cases-08.txt> as = Informational RFC

The IESG plans to make a decision in the next = few weeks, and solicits
final comments on this action. Please send = substantive comments to the
ietf@ietf.org mailing lists by = 2012-07-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, = please retain the
beginning of the Subject line to allow automated = sorting.

Abstract


  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 CDN Interconnection
  (CDNI) interfaces.  It = obsoletes RFC 3570.




The file can be obtained = via
http:/= /datatracker.ietf.org/doc/draft-ietf-cdni-use-cases/

IESG = discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-cdni-use-cases/ballot/
=

The following IPR Declarations may be related to this = I-D:

=   http://datatracker.ietf.org/ipr/1764/



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

-- 
Dan York  dyork@lodestar2.com
http://danyork.me/   skype:danyork
Phone: = +1-802-735-1624
Twitter - http://twitter.com/danyork
All comments and opinions are = entirely my own and have no connection whatsoever to any employer, past = or present. Indeed, by tomorrow even I might be disavowing these = comments.
-- 
Dan York  dyork@lodestar2.com
http://www.danyork.com/  &n= bsp;skype:danyork
Phone: = +1-802-735-1624
Twitter - http://twitter.com/danyork
All comments and opinions are = entirely my own and have no connection whatsoever to any employer, past = or present. Indeed, by tomorrow even I might be disavowing these = comments.
Date: Sat, 23 Jun 2012 12:51:40 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-problem-statement-07.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, 23 Jun 2012 19:51:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : Content Distribution Network Interconnection (CDNI) Prob= lem Statement Author(s) : Ben Niven-Jenkins Francois Le Faucheur Nabil Bitar Filename : draft-ietf-cdni-problem-statement-07.txt Pages : 40 Date : 2012-06-23 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-problem-statement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-problem-statement-07 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-problem-statement-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ben@niven-jenkins.co.uk Sat Jun 23 13:28: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 4179B21F8557 for ; Sat, 23 Jun 2012 13:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.639 X-Spam-Level: X-Spam-Status: No, score=-100.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 0hO5nZQ5B-J0 for ; Sat, 23 Jun 2012 13:28:01 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 486FC21F8555 for ; Sat, 23 Jun 2012 13:28:01 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginmedia.com ([86.14.227.47] helo=[192.168.0.4]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SiWw4-0002FD-8I for cdni@ietf.org; Sat, 23 Jun 2012 21:28:00 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Ben Niven-Jenkins In-Reply-To: <20120623195140.25738.17059.idtracker@ietfa.amsl.com> Date: Sat, 23 Jun 2012 21:27:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120623195140.25738.17059.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-07.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, 23 Jun 2012 20:28:02 -0000 Colleagues, This version addresses a number of DISCUSSes & COMMENTs raised as part = of IESG review. Ben On 23 Jun 2012, at 20:51, 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-07.txt > Pages : 40 > Date : 2012-06-23 >=20 > Abstract: > 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 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cdni-problem-statement >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-cdni-problem-statement-07 >=20 > A diff from previous version is available at: > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-problem-statement-07 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From internet-drafts@ietf.org Mon Jun 25 04:09: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 70FF421F8496; Mon, 25 Jun 2012 04:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 PlB1o4bOxn+q; Mon, 25 Jun 2012 04:09:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3ED21F8484; Mon, 25 Jun 2012 04:08:45 -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.21 Message-ID: <20120625110845.10514.50993.idtracker@ietfa.amsl.com> Date: Mon, 25 Jun 2012 04:08:45 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-problem-statement-08.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 11:09:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : Content Distribution Network Interconnection (CDNI) Prob= lem Statement Author(s) : Ben Niven-Jenkins Francois Le Faucheur Nabil Bitar Filename : draft-ietf-cdni-problem-statement-08.txt Pages : 40 Date : 2012-06-25 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-problem-statement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-problem-statement-08 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-problem-statement-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=51646ec13=allan.guillou@sfr.com Mon Jun 25 05:17: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 6D7E921F845F for ; Mon, 25 Jun 2012 05:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2qAcnDS10xr for ; Mon, 25 Jun 2012 05:17:02 -0700 (PDT) Received: from mx3-buro.sfr.fr (mx3-buro.sfr.fr [217.70.85.106]) by ietfa.amsl.com (Postfix) with ESMTP id DAB3821F8475 for ; Mon, 25 Jun 2012 05:17:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,471,1336341600"; d="scan'208";a="145439282" Received: from unknown (HELO EXCH011.encara.local.ads) ([10.29.105.2]) by mx3int-buro.prod with ESMTP; 25 Jun 2012 14:16:57 +0200 Received: from EXCN015.encara.local.ads ([fe80::f109:6a12:5ba6:f568]) by EXCH011.encara.local.ads ([::1]) with mapi id 14.02.0298.004; Mon, 25 Jun 2012 14:16:57 +0200 From: "GUILLOU, Allan" To: Francois Le Faucheur , Jan Seedorf Thread-Topic: [CDNi] Notes from May 30th Design Team Conf Call on "Footprint / Capabilities" Thread-Index: AQHNQkaq/wLLI8/hxES/1cmVnGTl55cLE/aQ Date: Mon, 25 Jun 2012 12:16:56 +0000 Message-ID: References: <2779C9F0771F974CAD742BAE6D9904FE24FD5FA0@Polydeuces.office.hd> <4BCEB5FB-EF80-497F-9084-377564194DCB@cisco.com> In-Reply-To: <4BCEB5FB-EF80-497F-9084-377564194DCB@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.141.56] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Notes from May 30th Design Team Conf Call on "Footprint / Capabilities" X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 12:17:06 -0000 Hello, What is the next step of the "Footprint / Capabilities" design team? --- Allan > -----Message d'origine----- > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de > Francois Le Faucheur > Envoy=E9 : lundi 4 juin 2012 13:39 > =C0 : Jan Seedorf > Cc : cdni@ietf.org > Objet : Re: [CDNi] Notes from May 30th Design Team Conf Call on "Footprin= t > / Capabilities" > > Hello Jan, > > Thanks for extracting the highlights of our discussion. A few minor > comments below: > > On 1 Jun 2012, at 15:12, Jan Seedorf wrote: > > > Dear all, > > > > Please find attached my notes from the "Footprint / Capabilities" desig= n > team virtual meeting we had this week. > > > > - Jan > > > > Notes CDNI Footprint/Capabilities Call - May 30, 2012 > > *************************************************** > > -- introduction from Francois on goals and scope of the call > > -- Jon/Stefano: summarize status quo, still quite a few open issues and > no definition for footprint yet, lately some more email activity > > -- agreement that ISP-owned CDN is a main use case, if not the most > important use case; Francois: use-case doc covers multiple scenarios, > incl. ISP-CDNs > > -- Jon: focusing on ISP-CDN may simplify things a lot, if for each IP- > address only one dCDN can serve it; Stefano/Francois: we should not look > at only this case; > > -- Francois: solution must be able to support a situation with > overlapping footprint, right? Agreement from Stefano, agreement that > different dCDN may claim overlapping footprints > > -- Francois: business models may have an impact on who makes CDN > selection decisions > > Following that, I think there was some discussion and eventually some > agreement that there might be more models but there is one model that we > are clear we need to make work: model where the decision is made by > the uCDN (i.e. uCDN selects the dCDN). > > > -- Stefano: why not focus on a single scenario and focus on the > mechanism? > > -- Enrico: should dCDN advertise where they have the caches or what the > bandwidth is? we need to take the incentive away for the dCDN to cheat > > -- Jon: there are other choices than prefixes for footprints, e.g. > "North America" or cache locations > > -- Stefano: we should start with a simple case, so prefixes could be a > starting point > > -- Allan: location of caches say nothing about the connectivity to > endpoints on the Internet > > -- Enrico: we need to have the dCDN advertise something the uCDN can > verify, otherwise dCDN will cheat > > -- Francois: dCDN information should be verifiable, that's a key point > to note down > > Another related point I tried to make then is that "existence of an > incentive to cheat" and "cheat-ability" are more or less common to all > "footprint" approaches. > > > -- Francois: a cheating dCDN may not be the end of the world because > there are strong contractual agreements between uCDN and dCDN > > -- agreement that we do not consider real-time verification of dCDN > statements but afterwards verification of cheating dCDN is fine > > -- Francois: let's try to converge - a) upstream CDN makes the decision= , > b) let's not try to hard to make dCDN information immediately verifiable, > > s/try to hard/try too hard/ > > > c) prefix is probably inevitable as one core footprint definition we > could start working with; Jon: agree with this process suggestion > > -- Jon: how does a over-the-top CDN derive its footprint? > > -- Stefano: would limit the scope, uCDN decision should be made > autonomously > > -- Jon: we need the semantics of what a footprint is/means > > -- Francois: semantic of footprint can be simply willingness to serve > > -- Allan: AS-hops is in fact a metric for quality, hard to define via > SLA for all users what "good quality" means > > -- Jon: also a question where the work gets done, at the dCDN or at the > uCDN > > -- Francois: footprint means "willingness to serve", we have agreed on > that; > > or perhaps more accurately : footprint means "willingness to serve" + > "some topology information to help uCDN assess in how good a position the > willing CDN actually is to serve well". > > > we also have agreed that the uCDN needs more information, > > What I meant here is that the uCDN, to make its dCDN selection, will > likely make use of other information than what is provided by the CDNI > Footprint & Advertisement interface (e.g. price between uCDN and dCDN, > past observation of dCDN quality,...). > > Francois > > > there are several proposals how to do this > > -- Jon: need to discuss more on resource advertisement model vs. > coverage / willingness to serve model > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Mon Jun 25 06:52: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 3C3A921F8621 for ; Mon, 25 Jun 2012 06:52:13 -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 13Hh+zRFXU7R for ; Mon, 25 Jun 2012 06:52:08 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B705A21F8604 for ; Mon, 25 Jun 2012 06:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=5666; q=dns/txt; s=iport; t=1340632328; x=1341841928; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6GUSr8BEbVWg+5V9OrFWsYSBp9YkS060ke7AfZiS6u0=; b=M881tZ4FMsp5zWro6YZ5jFvPO9KShGM23nMJBu3R/eWmjvYOIP3cxbum VA8NMfs0elg8ROq6j2ZSIBH1fXJRWaZ+qCvkzcMQyjWkqDY2DmzHGg/Hs 4vsHTBGzoea/5HunqS6bN4H5NaTsz5YuXADXvxFKiE6H2w2NcZQUbDMFt 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOpr6E+tJV2a/2dsb2JhbABEtiuBB4IYAQEBAwEBAQEPAVsLBQsCAQgYJwcnCxQRAgQBDQUbB4dkBQuYf59GBIV1hT4VhQ1gA4gVhB6Ie44bgWaCX4FXCA X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208";a="95656005" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 25 Jun 2012 13:52:08 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5PDq8Ds013003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Jun 2012 13:52:08 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0298.004; Mon, 25 Jun 2012 08:52:07 -0500 From: "Francois Le Faucheur (flefauch)" To: Allan GUILLOU , Jon Peterson , "Stefano Previdi (sprevidi)" Thread-Topic: [CDNi] Notes from May 30th Design Team Conf Call on "Footprint / Capabilities" Thread-Index: AQHNQkaq/wLLI8/hxES/1cmVnGTl55cLE/aQgABusoA= Date: Mon, 25 Jun 2012 13:52:07 +0000 Message-ID: <4CA4DC62-E84C-4392-89FD-C20C1CB6EB6D@cisco.com> References: <2779C9F0771F974CAD742BAE6D9904FE24FD5FA0@Polydeuces.office.hd> <4BCEB5FB-EF80-497F-9084-377564194DCB@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18994.004 x-tm-as-result: No--50.108900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6DDCA3D64BAEB84ABF173167F39CF64E@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Notes from May 30th Design Team Conf Call on "Footprint / Capabilities" X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 13:52:13 -0000 Allan, Jon and Stefano indicated that we did not need another "extended design tea= m" meeting before the Vancouver IETF meeting and that the input from the 30= th May meeting will be folded into the work of the "regular" Design Team le= d by them. Jon, Stefano, Have you been able to schedule the regular calls for the Design Team?=20 Any update on your progress? Thanks Francois On 25 Jun 2012, at 14:16, GUILLOU, Allan wrote: > Hello, >=20 > What is the next step of the "Footprint / Capabilities" design team? >=20 >=20 > --- > Allan >=20 >> -----Message d'origine----- >> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de >> Francois Le Faucheur >> Envoy=E9 : lundi 4 juin 2012 13:39 >> =C0 : Jan Seedorf >> Cc : cdni@ietf.org >> Objet : Re: [CDNi] Notes from May 30th Design Team Conf Call on "Footpri= nt >> / Capabilities" >>=20 >> Hello Jan, >>=20 >> Thanks for extracting the highlights of our discussion. A few minor >> comments below: >>=20 >> On 1 Jun 2012, at 15:12, Jan Seedorf wrote: >>=20 >>> Dear all, >>>=20 >>> Please find attached my notes from the "Footprint / Capabilities" desig= n >> team virtual meeting we had this week. >>>=20 >>> - Jan >>>=20 >>> Notes CDNI Footprint/Capabilities Call - May 30, 2012 >>> *************************************************** >>> -- introduction from Francois on goals and scope of the call >>> -- Jon/Stefano: summarize status quo, still quite a few open issues and >> no definition for footprint yet, lately some more email activity >>> -- agreement that ISP-owned CDN is a main use case, if not the most >> important use case; Francois: use-case doc covers multiple scenarios, >> incl. ISP-CDNs >>> -- Jon: focusing on ISP-CDN may simplify things a lot, if for each IP- >> address only one dCDN can serve it; Stefano/Francois: we should not look >> at only this case; >>> -- Francois: solution must be able to support a situation with >> overlapping footprint, right? Agreement from Stefano, agreement that >> different dCDN may claim overlapping footprints >>> -- Francois: business models may have an impact on who makes CDN >> selection decisions >>=20 >> Following that, I think there was some discussion and eventually some >> agreement that there might be more models but there is one model that we >> are clear we need to make work: model where the decision is made by >> the uCDN (i.e. uCDN selects the dCDN). >>=20 >>> -- Stefano: why not focus on a single scenario and focus on the >> mechanism? >>> -- Enrico: should dCDN advertise where they have the caches or what the >> bandwidth is? we need to take the incentive away for the dCDN to cheat >>> -- Jon: there are other choices than prefixes for footprints, e.g. >> "North America" or cache locations >>> -- Stefano: we should start with a simple case, so prefixes could be a >> starting point >>> -- Allan: location of caches say nothing about the connectivity to >> endpoints on the Internet >>> -- Enrico: we need to have the dCDN advertise something the uCDN can >> verify, otherwise dCDN will cheat >>> -- Francois: dCDN information should be verifiable, that's a key point >> to note down >>=20 >> Another related point I tried to make then is that "existence of an >> incentive to cheat" and "cheat-ability" are more or less common to all >> "footprint" approaches. >>=20 >>> -- Francois: a cheating dCDN may not be the end of the world because >> there are strong contractual agreements between uCDN and dCDN >>> -- agreement that we do not consider real-time verification of dCDN >> statements but afterwards verification of cheating dCDN is fine >>> -- Francois: let's try to converge - a) upstream CDN makes the decision= , >> b) let's not try to hard to make dCDN information immediately verifiable= , >>=20 >> s/try to hard/try too hard/ >>=20 >>> c) prefix is probably inevitable as one core footprint definition we >> could start working with; Jon: agree with this process suggestion >>> -- Jon: how does a over-the-top CDN derive its footprint? >>> -- Stefano: would limit the scope, uCDN decision should be made >> autonomously >>> -- Jon: we need the semantics of what a footprint is/means >>> -- Francois: semantic of footprint can be simply willingness to serve >>> -- Allan: AS-hops is in fact a metric for quality, hard to define via >> SLA for all users what "good quality" means >>> -- Jon: also a question where the work gets done, at the dCDN or at the >> uCDN >>> -- Francois: footprint means "willingness to serve", we have agreed on >> that; >>=20 >> or perhaps more accurately : footprint means "willingness to serve" + >> "some topology information to help uCDN assess in how good a position th= e >> willing CDN actually is to serve well". >>=20 >>> we also have agreed that the uCDN needs more information, >>=20 >> What I meant here is that the uCDN, to make its dCDN selection, will >> likely make use of other information than what is provided by the CDNI >> Footprint & Advertisement interface (e.g. price between uCDN and dCDN, >> past observation of dCDN quality,...). >>=20 >> Francois >>=20 >>> there are several proposals how to do this >>> -- Jon: need to discuss more on resource advertisement model vs. >> coverage / willingness to serve model >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Wed Jun 27 03:42: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 2A3CB21F86B1 for ; Wed, 27 Jun 2012 03:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUJGRwMarLLv for ; Wed, 27 Jun 2012 03:42:28 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 534ED21F86A8 for ; Wed, 27 Jun 2012 03:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=871; q=dns/txt; s=iport; t=1340793748; x=1342003348; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=KeOAxFxeEXZIoh++FT3X0MoKRUkupB3XM8cAdJa81y8=; b=SWGbXkB/ighV6nv+MAyl2rujJTW0UrDwr55RLngImZyyrqFfgCqT1t8Q eJePSvMM931l2eW1Mh34nxLCYYNI/HGJh8Yd4QMCpb7KR5sdPD9rcK5wp +RQMjGSecJxosSqm56yNi5fYoS37NvikxbkcV/vE6kG+lmzHQhGTDUnLv E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKfi6k+tJV2d/2dsb2JhbABFtiWBB4IYAQEBAwEBAQEPASc0EAsCAQg2ECcLJQIEEwkZh2QFC5kHoDKLN4UqYAOVMo4dgWaCXw X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="96209807" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 27 Jun 2012 10:42:27 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q5RAgRRW002218 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 27 Jun 2012 10:42:27 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Wed, 27 Jun 2012 05:42:27 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: [CDNi] next "Extended Design Team Meetings" on "HTTP Adaptive Streaming" : Thursday 28 June Thread-Index: AQHNVFGLOo7OqmTZPkSWe6ik2q5ZUA== Date: Wed, 27 Jun 2012 10:42:26 +0000 Message-ID: <8865276E-359E-495B-889D-F2021E80CC24@cisco.com> References: <0CC594F8-E9A7-42A0-8BEA-5F137BB32E3A@cisco.com> In-Reply-To: <0CC594F8-E9A7-42A0-8BEA-5F137BB32E3A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.53.149] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19000.003 x-tm-as-result: No--39.295700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] next "Extended Design Team Meetings" on "HTTP Adaptive Streaming" : Thursday 28 June X-BeenThere: cdni@ietf.org X-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, 27 Jun 2012 10:42:29 -0000 Hi, Just a friendly reminder for those interested in attending our next "Extend= ed Design Team Meetings" on "HTTP Adaptive Streaming". Francois On 15 Jun 2012, at 18:05, Francois Le Faucheur wrote: > Folks, >=20 > The next Extended Design Team Meeting on "HTTP Adaptive Streaming" will t= ake place on 28 June (as agreed during our last meeting on 7 June). >=20 > Details (exact times in different timezones, Webex bridge details, agenda= , link to Calendar invite) can all be found in the on-line agenda: =20 > http://www.ietf.org/proceedings/interim/2012/06/28/cdni/agenda/agenda-int= erim-2012-cdni-3.html >=20 > Looking forward to continuing our discussion. >=20 > Cheers >=20 > Francois & Rich >=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Thu Jun 28 01:11: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 DE0EE21F88A3 for ; Thu, 28 Jun 2012 01:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 49Mkzd0K05gl for ; Thu, 28 Jun 2012 01:11:43 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B303621F889E for ; Thu, 28 Jun 2012 01:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=7181; q=dns/txt; s=iport; t=1340871099; x=1342080699; h=from:to:subject:date:message-id:references:mime-version; bh=RqsnZgYh2dSoeBssA5z7fEcbCR6jCu7a451GB1FjDCA=; b=fN41fwdMXmDXnagj8TlS3wX0k3ylUdXtAp2JJHP2Ki6fhsZOO1f77Y5k YgsdMw8PYIkNnSqnolBQU0z4uLzbk4SYpIJR2Pa01MzGJQt6ax/5PzGgO tz/wzGkLNQ9nBed4gzQIuhsczwGAww1hXMjyewAXOxXPY2RliJezeJxqN Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFQQ7E+tJV2d/2dsb2JhbABFtjWBB4IUBAEBAQQBAQEPAVsbAgEZAwECKAcnCxQHAggCBBMJGYUnB4IkFwuYNaBXizeFKmADlTKBEol0gxeBZoJf X-IronPort-AV: E=Sophos;i="4.77,489,1336348800"; d="scan'208,217";a="96760458" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 28 Jun 2012 08:11:37 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q5S8Bb8J010604 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 28 Jun 2012 08:11:37 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Thu, 28 Jun 2012 03:11:36 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: I-D Action: draft-brandenburg-cdni-has-02.txt Thread-Index: AQHNVQSmx8MVETB5wk6Bh8UbdtDn9Q== Date: Thu, 28 Jun 2012 08:11:35 +0000 Message-ID: References: <20120628073739.12777.79984.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.197] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19002.004 x-tm-as-result: No--30.601500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_B41592DA117445A3BF6D94A051628377ciscocom_" MIME-Version: 1.0 Subject: [CDNi] Fwd: I-D Action: draft-brandenburg-cdni-has-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 08:11:48 -0000 --_000_B41592DA117445A3BF6D94A051628377ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI Begin forwarded message: From: > Subject: I-D Action: draft-brandenburg-cdni-has-02.txt Date: 28 June 2012 09:37:39 CEST To: > Reply-To: > A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Models for adaptive-streaming-aware CDN Interconnection Author(s) : Ray van Brandenburg Oskar van Deventer Francois Le Faucheur Kent Leung Filename : draft-brandenburg-cdni-has-02.txt Pages : 42 Date : 2012-06-28 Abstract: This documents presents thoughts on the potential impact of supporting HTTP Adaptive Streaming technologies in CDN Interconnection scenarios. Our intent is to spur discussion on how the different CDNI interfaces could, and should, deal with content delivered using adaptive streaming technologies and to facilitate working group decisions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-brandenburg-cdni-has There's also a htmlized version available at: http://tools.ietf.org/html/draft-brandenburg-cdni-has-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-brandenburg-cdni-has-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --_000_B41592DA117445A3BF6D94A051628377ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <09D21C7476F15947A80399E697994F0C@cisco.com> Content-Transfer-Encoding: quoted-printable FYI

Begin forwarded message:

From: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=
Subject: I-= D Action: draft-brandenburg-cdni-has-02.txt
Date: 28 Ju= ne 2012 09:37:39 CEST
To: <<= a href=3D"mailto:i-d-announce@ietf.org">i-d-announce@ietf.org>
Reply-To: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=


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


Title  = ;         : Models for adaptiv= e-streaming-aware CDN Interconnection
Author(s) &= nbsp;     : Ray van Brandenburg
            &nb= sp;            = Oskar van Deventer
            &nb= sp;            = Francois Le Faucheur
            &nb= sp;            = Kent Leung
Filename &n= bsp;      : draft-brandenburg-cdni-has-02.txt=
Pages  = ;         : 42
Date  =           : 2012-06-28
Abstract:
  This documents presents thoughts on the potential impact of
  supporting HTTP Adaptive Streaming technologies in CDN
  Interconnection scenarios.  Our intent is to spur discussi= on on how
  the different CDNI interfaces could, and should, deal with cont= ent
  delivered using adaptive streaming technologies and to facilita= te
  working group decisions.


The IETF datatracker status page for this draft is:
htt= ps://datatracker.ietf.org/doc/draft-brandenburg-cdni-has

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-brandenburg-cdni-has-02

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=3Ddraft-brandenburg-cdni-has-02


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

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

--_000_B41592DA117445A3BF6D94A051628377ciscocom_-- From ray.vanbrandenburg@tno.nl Thu Jun 28 03: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 4055121F852E for ; Thu, 28 Jun 2012 03:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.58 X-Spam-Level: X-Spam-Status: No, score=0.58 tagged_above=-999 required=5 tests=[AWL=1.084, 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 CubHu3a8u4Ho for ; Thu, 28 Jun 2012 03:10:04 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id B30F821F889A for ; Thu, 28 Jun 2012 01:08:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,489,1336341600"; d="scan'208";a="15616308" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1b.tno.nl with ESMTP; 28 Jun 2012 10:08:10 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.152]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.02.0298.004; Thu, 28 Jun 2012 10:08:10 +0200 From: "Brandenburg, R. (Ray) van" To: "cdni@ietf.org" Thread-Topic: New version of CDNI-HAS available Thread-Index: Ac1VBSg0exei20yIRvq2E1ym+BDscg== Date: Thu, 28 Jun 2012 08:08:10 +0000 Message-ID: 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" Content-ID: <3F1521C1D714E0408E2A3152D92A9D42@tno.nl> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: [CDNi] New version of CDNI-HAS available X-BeenThere: cdni@ietf.org X-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, 28 Jun 2012 10:10:05 -0000 Hi all, In preparation for today's CDNI HAS design team meeting, we've uploaded a n= ew version of the draft. It is available at: http://www.ietf.org/id/draft-brandenburg-cdni-has-02.txt Looking forward to your comments and speaking to you this afternoon. Best regards, Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From flefauch@cisco.com Fri Jun 29 04:55: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 68E7721F86F1 for ; Fri, 29 Jun 2012 04:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aR7EHEWtrFJ5 for ; Fri, 29 Jun 2012 04:55:28 -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 7F8C221F86B5 for ; Fri, 29 Jun 2012 04:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=4372; q=dns/txt; s=iport; t=1340970928; x=1342180528; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=3aGwwfPbPfneWX1FvAYwGdv6WKlZ1qI4FmzSfBX1mto=; b=WpJxn3gzHRWBeHa8XAvLAyuhf7zvo9QDe8Yk2vQ04MIy0KYDgDBar/dl LCIKtPs+jLt0R44Uy32I+thYHpg+7/Y5T6KtrSVnMj7jWvgaRwMtYQ/9i 7PVgQnoC3sJWTgabsMNItBTGhjskupjEpApdzTkN4eQYrK7tydabITtHp c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAICW7U+tJXHA/2dsb2JhbAArGrZLgQeCHxIBJ1EBHCJCJwQcGYdpCymZfYEooGCLN4UqYAOVMo4dgWaCX4FYIw X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="97243867" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 29 Jun 2012 11:55:28 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q5TBtRrD013040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 29 Jun 2012 11:55:27 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Fri, 29 Jun 2012 06:55:27 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Notes from June 28 Extended Design Team Meeting on "Adaptive Streaming" Thread-Index: AQHNVe4Szt28nUMEEku2jb6DoN4u2Q== Date: Fri, 29 Jun 2012 11:55:26 +0000 Message-ID: <7AA34B4F-D6EB-4C09-B7F9-F6125DA273F1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.197] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19004.004 x-tm-as-result: No--47.004600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <248E254BC2CCFB4F94169E420C65DB4D@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Notes from June 28 Extended Design Team Meeting on "Adaptive Streaming" X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 11:55:30 -0000 Folks, Here are notes from the June 28 extended design team meeting. Let us know i= f you have comments. The outcomes of this meeting will be reflected in the next rev of draft-bra= ndenburg-cdni-has that will be posted for Vancouver. We do not plan to run another design team meeting before Vancouver. Francois=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Extended Design Team Meeting of CDNI on "Adaptive Streaming" Date: Thursday, June 28, 2012 Start Time: 07:00 PDT (e.g San Francisco, USA) =3D 10:00 EDT (e.g Boston, U= SA) =3D 16:00 CET (e.g Paris, France) =3D 22:00 CST (e.g. Beijing, China) Finish Time: 10:30 PDT (e.g San Francisco, USA) =3D 13:30 EDT (e.g Boston, = USA) =3D 19:30 CET (e.g Paris, France) =3D 01:30 CST (e.g. Beijing, China) Agenda and slides accessible at: http://www.ietf.org/proceedings/interim/2012/06/28/cdni/agenda/agenda-inter= im-2012-cdni-3 Attendees: Bhumip Khasnabish, Jan Seedorf, Kent Leung, Kevin Ma, Kevin Johns, Matt Cau= lfield, Oskar van Deventer, Ray van Brandenburg, Scott Wainner, Alex Giladi= , Stef van der Ziel, Roy Peterkofsky, Bill Creighton, Larry Peterson, Rich= ard Woundy, Francois Le Faucher The webex recording for the meeting is available at: https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&SP=3DMC&rID=3D61807497&r= Key=3Da3e37f3635dbe0fa=20 SInce the full details of the discussion is accessible through the webex re= cording, the notes below focus on the Action Items and conclusions of the d= iscussions. The Notes were taken by Scott Wainner (Thanks Scott!): File Management ----------------------- Stef - Doesn't agree with the recommendation to make CDN-I have no HAS awar= eness - Recommends CDN-I have the ability know a dCDN is HAS aware - Wants a Capability Exchange for HAS awareness - ACTION: Stef to provide input to Ray on proposed capability exchange Content Acquisition and Content Collections -------------------------------------------------------------- Kevin - Challenged the position that CDN-I Metadata couldn't provide HAS in= formation Stef - Capability required to determine if dCDN supports byte-range request= s - ACTION: Stef to provide Ray and team with requirement for dCDN byte-rang= e request support - CONFIRMED: Incuded a method for pre-positioning of content to dCDN - ACTION: Consider a method to optimize pre-positioning all chunks of an a= sset - ACTION: Consider if Option 2.1 is compatible with HAS methods Request Routing and Manifest Files -------------------------------------------------------------- Ray - ACTION: Need to define conditions for 'brittle' case defined in 3.3.= 2.1 - ACTION: Option 3.2 includes case where manifest is re-written or created= by uCDN - ACTION: Option 3.3 includes case where the manifest is re-written or cre= ated Stef - Case where uCDN creates manifest - Requirement to incorporate session control (either in client or CDN-I) HAS Logging -------------------------------------------------------------- Scott - Requirement for incorporating Session-based logging; CCID only iden= tifies content Stef - CCID is a mandatory requirement, but needs session-based logging too - Option A: Client-side - Option B: Manifest modification - Option C: Cache-centric Francois ACTION: Need corresponding capability advertisement from the dCDN of CCID = support? consider adding Session-ID. URL Signing -------------------------------------------------------------- Kent - ACTION: CDN-I Metadata required for URL-Signing Kevin - ACTION: CDN-I Metadata requirement for dCDN to obtain the key Ray - NOTE: Use of COOKIE requires legal permission from User via App - NOTE: Emphasize legal implications of use of COOKIE Kevin - ACTION: Need formalized COOKIE validation method for Option #3 Oscar - Option #3 requires manifest file to be delivered by dCDN - Recommendation to kill option #3 due to non-browser support Oscar - Option #2 requires uCDN to be HAS aware. - ACTION: Include option for CSP or uCDN to serve the signed manifest URL Ray - ACTION: Option 4# needs to be more clearly differentiated from Option= #2 From myungki.shin@gmail.com Fri Jun 29 07:43: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 BA15B21F86D4 for ; Fri, 29 Jun 2012 07:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.889 X-Spam-Level: X-Spam-Status: No, score=-2.889 tagged_above=-999 required=5 tests=[AWL=0.710, 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 ncbWmU0irh07 for ; Fri, 29 Jun 2012 07:43:14 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 51DB621F86E8 for ; Fri, 29 Jun 2012 07:43:14 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so4801734pbc.31 for ; Fri, 29 Jun 2012 07:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=bO/DSN7eiz/+0J9nJVOEtW1WxNnzIZ9uFPMLvSkpkRs=; b=dG+ssS2WvZyqa3qDCZ38fyT7asO2hZglO8ok4sjncyQrlxyvmVcEVSHCfLUlmmoPlb nCa8r3zq1+WDTzYEGBz/7Cy4gYWjfU0J/IFoK9AVtCexT569ido/I4L6rI5WuL/8V2PV WTibdaguxPNRdPRBb4aL2Bow5pDb8EKI9rEUwEITcInFiY/7dIssL5k2ScnOUrhNni2B iAvMDWUM+9rVr6tQ6aE0yQUM/jPhKqj2br/dtPjwiUGeUHfdAXFbFI6YaiEZ1Ppfyu5Z Y4C5rS2A4w0zi85xc9YdbsXdCvzYbAXmsyrlT4qlm91C690VkLt0RJhxjFuTJbiW4yf7 0TJg== Received: by 10.68.233.225 with SMTP id tz1mr7563398pbc.4.1340980993595; Fri, 29 Jun 2012 07:43:13 -0700 (PDT) Received: from userPC ([129.254.16.216]) by mx.google.com with ESMTPS id tk1sm5646033pbc.8.2012.06.29.07.43.09 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 07:43:11 -0700 (PDT) From: "Myung-Ki Shin" To: Date: Fri, 29 Jun 2012 23:43:06 +0900 Message-ID: <000601cd5605$816ef450$844cdcf0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac1WBVFcwzgW173lSI6/MT+PdbSe2Q== Content-Language: ko Cc: sdn@irtf.org Subject: [CDNi] FW: New Version Notification for draft-shin-cdni-request-routing-sdn-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, 29 Jun 2012 14:43:16 -0000 Hi all, =20 We have uploaded a new I-D related to 'CDNI Request Routing with SDN'. We think that SDN could be also considered as one of candidates to = facilitate CDNI Request Routing.=20 This document discusses how SDN can be used for downstream CDN selection = within CDNI request routing. Comments are welcome.=20 Thanks,=20 Myung-Ki,=20 -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Friday, June 29, 2012 11:03 PM To: =EC=8B=A0=EB=AA=85=EA=B8=B0 Cc: tkkwon98@gmail.com; dhchang@mmlab.snu.ac.kr Subject: New Version Notification for = draft-shin-cdni-request-routing-sdn-00.txt A new version of I-D, draft-shin-cdni-request-routing-sdn-00.txt has been successfully submitted by Myung-Ki Shin and posted to the IETF = repository. Filename: draft-shin-cdni-request-routing-sdn Revision: 00 Title: CDNI Request Routing with SDN Creation date: 2012-07-01 WG ID: Individual Submission Number of pages: 9 URL: = http://www.ietf.org/internet-drafts/draft-shin-cdni-request-routing-sdn-0= 0.txt Status: = http://datatracker.ietf.org/doc/draft-shin-cdni-request-routing-sdn Htmlized: = http://tools.ietf.org/html/draft-shin-cdni-request-routing-sdn-00 Abstract: Software-defined networking (SDN) is emerging and intensively discussed as one of the most promising technologies to provide centralized, programmable control planes for network service providers (NSPs). In this sense, SDN could be also considered as one of candidates to facilitate CDNI Request Routing. This document discusses how SDN can be used for downstream CDN selection within CDNI request routing. = =20 The IETF Secretariat From vumip1@gmail.com Sat Jun 30 05:10: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 B83C221F85C5 for ; Sat, 30 Jun 2012 05:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hc5jJlO9sikn for ; Sat, 30 Jun 2012 05:10:09 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 226B321F859E for ; Sat, 30 Jun 2012 05:10:02 -0700 (PDT) Received: by wibhm11 with SMTP id hm11so1470000wib.13 for ; Sat, 30 Jun 2012 05:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2L8IK7GEwaU+Hg9rEYdaYt3dhpey6m+NiIalO802THE=; b=EFZN//fCbY1305GwMhpcvVMPpmpq1LdO/liBQfjL4/8SbLUqNXbtqUxz8Kce8NjprN +PslX+LFKnVOSFWm9dXESMRdE3QlthNHqb+OinKT4GoKlNSAJy8EnHY4eiMnFViZi+Qd M27dJV/v8T7Z0NPz8RecTeqV5K6wesPYo64UyvYUbaZuQUjRIC307VU5u64nuL1Q/IIf 0xrVDdJZI2vuKKhbgPRbCAMhihKcUylxID/+GRP7IbVyRC4xfT9mW7cNhbV4vo/5X9RT 6Ngj2y57gy0OtN03H9B7rWQVnG1WT3AbGAR/kZuOPzmw+SE5h9O+ZyzSeQNujMBSycrN 0f3A== MIME-Version: 1.0 Received: by 10.216.208.151 with SMTP id q23mr2540278weo.20.1341058202504; Sat, 30 Jun 2012 05:10:02 -0700 (PDT) Received: by 10.227.13.79 with HTTP; Sat, 30 Jun 2012 05:10:02 -0700 (PDT) Date: Sat, 30 Jun 2012 08:10:02 -0400 Message-ID: From: Bhumip Khasnabish To: cdni@ietf.org Content-Type: multipart/alternative; boundary=0016e6d975f7c88e8d04c3af71bd Subject: [CDNi] requesting review and comments on a draft on Request Routing and Content Acquisition experiment X-BeenThere: cdni@ietf.org X-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, 30 Jun 2012 12:10:11 -0000 --0016e6d975f7c88e8d04c3af71bd Content-Type: text/plain; charset=ISO-8859-1 Hello, We recently published a draft on Request Routing and Content Acquisition, and requesting review and comments. Thanks. Best. Bhumip ======================================================== A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Request Routing and Content Acquisition Author(s) : Ge Chen Mian Li Hongfei Xia Jie Liang Filename : draft-chen-cdni-rr-content-acquisition-00.txt Pages : 12 Date : 2012-06-27 Abstract: This document illustrates the details of an alternative method that can be used to provide request routing and content acquisition services. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-chen-cdni-rr-content-acquisition There's also a htmlized version available at: http://tools.ietf.org/html/draft-chen-cdni-rr-content-acquisition-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ======================================================== --0016e6d975f7c88e8d04c3af71bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,
We recently published a draft on Re= quest Routing and Content
Acquisition, and requesting review and comments. Thanks.
Best.
Bhumip
=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
=A0
A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.


Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : Request Routing = and Content Acquisition
Author(s)=A0=A0=A0=A0=A0=A0 : Ge Chen
=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 Mian = Li
=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= Hongfei Xia
=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 Jie Liang
Filename=A0=A0=A0=A0=A0=A0=A0 : draft-chen-= cdni-rr-content-acquisition-00.txt
Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 := 12
Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2012-06-27

Abstract:<= br>=A0=A0 This document illustrates the details of an alternative method th= at
=A0=A0 can be used to provide request routing and content acquisition
= =A0=A0 services.


The IETF datatracker status page for this draft= is:
https://datatracker.ietf.org/doc/draft-ch= en-cdni-rr-content-acquisition

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-chen-cdni-rr-content-acquisition-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.or= g/internet-drafts/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
--0016e6d975f7c88e8d04c3af71bd-- From vumip1@gmail.com Sat Jun 30 05:14:31 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 68F2C21F859E for ; Sat, 30 Jun 2012 05:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqQknsH-s83K for ; Sat, 30 Jun 2012 05:14:30 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 62F6921F8419 for ; Sat, 30 Jun 2012 05:14:30 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1465229wib.13 for ; Sat, 30 Jun 2012 05:14:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=P72CtvWQDMyP6GRUQ1PEvLESEctaiekWNmAXQ7pShRg=; b=zZEnWujFjqpEg3OQxHEC/rkKGadpqwaL6QwXHqWwQJ/MOV1qZyqdTPlWqIuH/1eBxe SvnDJpwJIDSJcx073fz+zWgxPzOn/0r9zJKgzzzmSDtp3OtszjTyFTPol1ZTZLYaqDyz OJuRvOALjlK1yaEN3TDxVgj83WkS3iGH7/IY1L4TxsJU922FqYu+zSDHX4IYxIrCyEOE zpT01l6Ykxc640Pq2KXYc6AzpLODOZGCmD5GWCzx0u6kVvMAPf1mqswtQWBewd0cXyoL xdOBCVs5kOB9qwtRhLPNTO/JNjtuXSu7LYlBQA4m3eqFkiF5wU3ssotGu60pB50r0Syv sWNQ== MIME-Version: 1.0 Received: by 10.180.105.234 with SMTP id gp10mr4569719wib.11.1341058469847; Sat, 30 Jun 2012 05:14:29 -0700 (PDT) Received: by 10.227.13.79 with HTTP; Sat, 30 Jun 2012 05:14:29 -0700 (PDT) Date: Sat, 30 Jun 2012 08:14:29 -0400 Message-ID: From: Bhumip Khasnabish To: cdni@ietf.org Content-Type: multipart/alternative; boundary=f46d044288b2b7e3ca04c3af8133 Subject: [CDNi] Requesting review and comments on Intra-CDN Provider CDNi Experiment X-BeenThere: cdni@ietf.org X-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, 30 Jun 2012 12:14:31 -0000 --f46d044288b2b7e3ca04c3af8133 Content-Type: text/plain; charset=ISO-8859-1 Hello, We recently published the results of an experiment on Intra-CDN Provider CDNi, and requesting review and comments ASAP. Thanks. Best. Bhumip ========================================================================= A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Intra-CDN Provider CDNi Experiment Author(s) : Ge Chen Mian Li Hongfei Xia Jie Liang Filename : draft-chen-cdni-intra-cdn-provider-cdni-experiment-00.txt Pages : 17 Date : 2012-06-27 Abstract: In [I-D.ietf-cdni-use-cases], the Inter-Affiliates CDN Interconnection use case is described. In this scenario, a large CDN Provider may have several autonomous or semi-autonomous subsidiaries that each operates on their own CDN. The CDN Provider needs to make these down-stream CDNs interoperate to provide a consistent service to its customers on the whole collective footprint. This document illustrates in details the CDNi experiment that has been carried out by China Telecom, and the lessons and experiences to CDNi standardization work. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-chen-cdni-intra-cdn-provider-cdni-experiment There's also a htmlized version available at: http://tools.ietf.org/html/draft-chen-cdni-intra-cdn-provider-cdni-experiment-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =========================================================================== --f46d044288b2b7e3ca04c3af8133 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,
=A0
We recently published the results o= f an experiment on
=A0
Intra-CDN Provider CDNi,
=A0
and requesting review and comments = ASAP.=A0
=A0
Thanks.
=A0
Best.
=A0
Bhumip

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
A New Internet-Draft is available from the on-line In= ternet-Drafts directories.


Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 := Intra-CDN Provider CDNi Experiment
Author(s)=A0=A0=A0=A0=A0=A0 : Ge Chen
=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 Mian Li
=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 Hongfei Xia
=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 Ji= e Liang
Filename=A0=A0=A0=A0=A0=A0=A0 : draft-chen-cdni-intra-cdn-provid= er-cdni-experiment-00.txt
Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 17
Date=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 : 2012-06-27

Abstract:
=A0=A0 In [I-D.ietf-cdni-use-cases]= , the Inter-Affiliates CDN
=A0=A0 Interconnection use case is described.= =A0 In this scenario, a large CDN
=A0=A0 Provider may have several auton= omous or semi-autonomous subsidiaries
=A0=A0 that each operates on their own CDN.=A0 The CDN Provider needs to ma= ke
=A0=A0 these down-stream CDNs interoperate to provide a consistent se= rvice
=A0=A0 to its customers on the whole collective footprint.

= =A0=A0 This document illustrates in details the CDNi experiment that has =A0=A0 been carried out by China Telecom, and the lessons and experiences t= o
=A0=A0 CDNi standardization work.


The IETF datatracker stat= us page for this draft is:
https:/= /datatracker.ietf.org/doc/draft-chen-cdni-intra-cdn-provider-cdni-experimen= t

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-chen-cdni-intra-cdn-provi= der-cdni-experiment-00


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

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--f46d044288b2b7e3ca04c3af8133--