From internet-drafts@ietf.org Thu May 3 03:30:51 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8880E21F85C6; Thu, 3 May 2012 03:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 Mzf+u6xwmK3Z; Thu, 3 May 2012 03:30:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17AA421F854A; Thu, 3 May 2012 03:30:51 -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: <20120503103051.20864.36885.idtracker@ietfa.amsl.com> Date: Thu, 03 May 2012 03:30:51 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-problem-statement-05.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, 03 May 2012 10:30:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnec= tion Working Group of the IETF. Title : Content Distribution Network Interconnection (CDNI) Prob= lem Statement Author(s) : Ben Niven-Jenkins Francois Le Faucheur Nabil Bitar Filename : draft-ietf-cdni-problem-statement-05.txt Pages : 39 Date : 2012-05-03 Content Delivery Networks (CDNs) provide numerous benefits: reduced delivery cost for cacheable content, improved quality of experience for End Users and increased robustness of delivery. For these reasons they are frequently used for large-scale content delivery. As a result, existing CDN Providers are scaling up their infrastructure and many Network Service Providers (NSPs) are deploying their own CDNs. It is generally desirable that a given content item can be delivered to an End User regardless of that End User's location or attachment network. This is the motivation for interconnecting standalone CDNs so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. However, no standards or open specifications currently exist to facilitate such CDN interconnection. The goal of this document is to outline the problem area of CDN interconnection for the IETF CDNI (CDN Interconnection) working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cdni-problem-statement-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cdni-problem-statement-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-problem-statement/ From flefauch@cisco.com Thu May 3 04:56: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 C312C21F849C for ; Thu, 3 May 2012 04:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.366 X-Spam-Level: X-Spam-Status: No, score=-8.366 tagged_above=-999 required=5 tests=[AWL=-1.367, BAYES_00=-2.599, GB_MUTUALBENEFIT=2, J_BACKHAIR_11=1, J_CHICKENPOX_31=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 z8Bif7gndOjQ for ; Thu, 3 May 2012 04:56:04 -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 DDC0421F8496 for ; Thu, 3 May 2012 04:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=18621; q=dns/txt; s=iport; t=1336046163; x=1337255763; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=0O2ibGzOV6Ylq7XGvQWgiRibppHwXVDQQ/yS6372s6c=; b=C17Eb3pKHbsXTjcrFdLBUr8zGVU+JhCEKgA+ZSeci2MQ4rdoYVpGzUQk wDuzP1tsJGHxaWg4rvAuw6szBakCSzE7oIEciywycZWt9kICPbStvOBjL JW8jFBgNrbVclYmPkkin8yJ1fFZjDV7HZdJLfucIv3/0kz+k/f67qnLsP Q=; X-IronPort-AV: E=Sophos;i="4.75,522,1330905600"; d="scan'208";a="72351626" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 03 May 2012 11:56:00 +0000 Received: from ams-flefauch-8714.cisco.com (ams-flefauch-8714.cisco.com [10.55.161.197]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q43BtwPR017287; Thu, 3 May 2012 11:55:59 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Francois Le Faucheur In-Reply-To: <291CC3F9E50E7641901A54E85D0977C65260C10A38@MAILR002.mail.lan> Date: Thu, 3 May 2012 13:56:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8CF9783A-C3CB-40E5-A2EF-16D258B115DA@cisco.com> References: <5388986F-034F-4E38-A5A3-78B6E30F56A5@cisco.com> <6596CC9C-13AE-4CAB-96DF-5BD50B7CDC9F@niven-jenkins.co.uk> <291CC3F9E50E7641901A54E85D0977C65260C10A38@MAILR002.mail.lan> To: Kevin J Ma X-Mailer: Apple Mail (2.1257) Cc: "draft-ietf-cdni-use-cases@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss 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, 03 May 2012 11:56:05 -0000 On 26 Apr 2012, at 23:46, Kevin J Ma wrote: > Hi Ben, >=20 >> I agree with what you said, i.e. CSPs handle fancy policy and then = grant >> tokens/whatever that the dCDN can validate to ensure they are only >> delivering to End Users the CSP has granted access too. >=20 > I do not disagree with your statement. I just will note that if the = CSP > is nolonger in control of which dCDN the request will ultimately be = delegated > to, the "whatever" has to be enforced across all dCDNs. Agreed. And this is why the CDNI working group has to agree on the = definition of "whatever". At this stage I think the expectation is that = the "whatever" that has to be enforced by the dCDN will comprise: *a* a few explicit basic policies (geo-blocking, time-woindow)=20= *b* a validation of pre-authorization performed by CSP (URI = signing, token) *c* possibly an escape call-back to the uCDN for double-checking = (as presented by Larry in Paris and agreed to). With respect to the use-case document, I support the idea that the = document discusses the notion of how do we ensure that the dCDN can = enforce CSP policies. But I believe we need to be careful and explicitly = distinguish between: (i) arbitrarily sophisticated specific creative CSP policies = and=20 (ii) a small set of basic policies to be signaled through CDNI = protocol;=20 and we need to explain how *b* and *c* can be used to support the fancy = policies of (i) relying on basic policies of (ii). If we agree on these premises, I recommend the use-case discussion on = policy enforcement be expanded to convey these points. Cheers Francois =20 >=20 > thanx. >=20 > -- Kevin J. Ma >=20 >=20 >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of >> Ben Niven-Jenkins >> Sent: Wednesday, April 25, 2012 1:39 PM >> To: Francois Le Faucheur >> Cc: draft-ietf-cdni-use-cases@tools.ietf.org; cdni@ietf.org >> Subject: Re: [CDNi] Document Sheperd review of = draft-ietf-cdni-use-cases >>=20 >> Francois, >>=20 >> On 25 Apr 2012, at 17:45, Francois Le Faucheur wrote: >>=20 >>> I identified two remaining significant points to be addressed, and = also >> have included many suggestions to improve the document. >>> I suggest we resolve the two significant points on the list and = leave it >> to editor/authors to decide how to dispose of the suggestions for >> improvement offline. >>>=20 >>> Cheers >>>=20 >>> Francois >>>=20 >>>=20 >>> Significant points >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> *** section 8 security considerations >>> I have a few specific issues with the current text of the Security >> Considerations section. But I don't really see the need to have an >> expanded Security Considerations section in both the use-case = document and >> the problem-statement (particularly considering that the first IESG = review >> comments on problem-statement suggest expanding the security >> considerations section there), in particular because the security >> considerations currently brought up in use-cases are not specific to >> individual use cases bur rather generic to the whole CDN = interconnection >> problem space. >>> So my proposal would be to remove the whole discussion from = use-cases >> (i.e. the first 4 paragraphs) and refer to the Security = Considerations >> section of the Problem Statement e.g.. by replacing: >>> " >>> This document focuses on the motivational use cases for CDN >> Interconnection, and does not analyze these threats in detail. >>> " >>> with: >>> " >>> This document focuses on the motivational use cases for CDN >> Interconnection, and does not analyze the associated threats. Those = are >> discussed in [I-D.ietf-cdni-problem-statement]. >>> " >>=20 >> Works for me. As part of reworking the Security Considerations = section in >> the problem statement I will see what text from the use cases draft = can be >> reused. >>=20 >>> ***section A.1: >>> I still have a problem with the text of that section. >>> I thought we had converged on an agreement that the text would: >>> * explain that CSPs may take into account very >> multiple/arbitrary/specific criteria in their policy >>> * explain that the CDNs are only expected to enforce a few = specific >> policy rules (e.g. geo-blocking, time window) and for enforcement of = all >> fancy CSP policy we propose that the responsibilities be divided into = (1) >> the CSP being responsible for the fancy policy decision and (ii) the = CDN >> for merely enforcing the CSP decision without having to understand = the >> policy (e.g. via URI signing). >>> Do we not agree on that or not? >>=20 >> I agree with what you said, i.e. CSPs handle fancy policy and then = grant >> tokens/whatever that the dCDN can validate to ensure they are only >> delivering to End Users the CSP has granted access too. >>=20 >> CDN policies should not be CSP specific - they should just cover = things >> like geo-blocking rules etc. >>=20 >> Ben >>=20 >>>=20 >>> The current text says that CDN selection and surrogate selection = "are >> influenced by these policies" (referring to the fancy CSP policies). = I do >> not agree with that. I don;t think we want CDN Selection or Surrogate >> selection to be influenced by whether a movie shoudl be available 14 = or 28 >> days after DVD release, or whether a given resolution is "too high" = for a >> particular user or terminal. >>>=20 >>> Also, the paragraph keeps talking about "dCDN selection or Surrogate >> selection" may fail for some fancy policy reasons. I don't understand = what >> it means to "fail" , but more importantly again, I don't think we = want CDN >> request routing decisions to be factoring very fancy CSP policy = rules. >>> Do we agree or not? >>>=20 >>> The last paragraphs gives examples of the CSP objectives of = supporting >> delivery policies in CDNs, and those are fine and can be achieved = with the >> set of mechanisms discussed above (i.e. goeblocking + time window + = URI >> signing). >>>=20 >>>=20 >>> Suggestions for improvements >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> ***Abstract >>> replace "CDNI" by "CDN Interconnection". >>>=20 >>> *** section 1: >>> expand the first instance of CDNI into "CDN Interconnection (CDNI)". >>>=20 >>> *** section 1: >>> "Then, the document highlights the need for interoperability to >>> exchange and enforce content delivery policies (Section 5)." >>> I'd suggest replacing "for interoperability to exchange" by "for >> interoperability to allow exchange" or by "for interoperability in = order >> to exchange" >>>=20 >>> *** section 1.1: >>> Do you feel that the two additional terms are really specific to the >> use-case document (in which case their definition should stay in this >> document) or are they likely useful in other documents (in which case >> their definition should be migrated to the framework document)? >>> Personally, I would say that those terms might be useful in other >> documents/discussions (eg I am pretty sure we'd need to refer to the >> "Delivering CDN" in other context). >>>=20 >>> *** section 1.1: >>> "Access CDN: >>> A CDN that is directly connected to the End User's access." >>> I think this definition needs to be a little more specific. = "Directly >> connected" does not mean "L2 connectivity" (because an on-net cache = maybe >> a few L2 hops away), nor does it mean "L3 connectivity" (because an = OTT >> CDN cache has IP connectivity to an enduser). I think you mean = something >> in between, more or less that the CDN and the access are within the = same >> IP administrative domain, or something close to that. Can you try = refine >> that definition? >>>=20 >>> *** section 1.3: >>> " o improve the experience for the End User; for instance delivery = has >>> lower latency (decreased round-trip-time between the user and the >>> delivery server) and better robustness," >>> To be more comprehensive in justifying the claims, how about: >>> " o improve the experience for the End User; for instance delivery = has >>> lower latency (decreased round-trip-time and higher throughput >> between the user and the >>> delivery server) and better robustness (ability to use multiple >> delivery servers)," >>>=20 >>> *** section 1.3: >>> "o reduce the Content Service Provider's (CSP) costs, such as >>> datacenter capacity, space, and electricity consumption, as >>> popular content is delivered through the CDN rather than through >>> the CSP's servers." >>> The current wording raises the question of "if it reduces the costs = by >> reducing expenses in the CSP datacenter, why does it not = correspondingly >> increase the cost by increasing expenses in the CDN (which the CDN >> provider then charges back to the CSP)?" >>> I think the gain is in the scale and effective pooling of CDN = resources >> across many CSPs. Could you refine the wording to explain why there = is >> indeed a net gain? >>>=20 >>> *** section 1.3: >>> Replace: >>> " >>> An example is depicted in Figure 1. Two CDN Providers establish a = CDN >> Interconnection. >>> " >>> with: >>> " >>> An example is depicted in Figure 1 where two CDN Providers establish = a >> CDN Interconnection. >>> " >>> (this is to minimize the redundancy with the sentence coming below: = "CDN >> Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs.") >>>=20 >>>=20 >>> *** section 1.3: >>> replace: >>> " >>> "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their >> CDNs." >>> with: >>> "Independently, CDN Provider 'A' and CDN Provider 'B' agree to >> interconnect their CDNs." >>> this is to clarify that the A<->B agreement is not specific to the = 1<->A >> agreement >>>=20 >>>=20 >>> *** section 1.3: >>> replace: >>> " >>> When a User Agent requests content from CSP-1, CDN-A considers that >> delivery by CDN-B is appropriate >>> " >>> with: >>> " >>> When a given User Agent requests content from CSP-1, CDN-A may = consider >> that delivery by CDN-B is appropriate >>> " >>>=20 >>>=20 >>> *** section 1.3: >>> replace: >>> " >>> CDN-A has delegated the handling of requests for CSP-1's content = through >> the CDN Interconnection agreement, thus, the content is actually = delivered >> from CDN-B. >>> " >>> with: >>> " >>> Through the CDN Interconnection arrangements put in place between = CDN-A >> and CDN-B (as a result of the CDN Interconnection agreement = established >> between CDN Provider 'A' and CDN Provider 'B'), CDN-A can redirect = the >> request to CDN-B and the content is actually delivered to the User = Agent >> by CDN-B. >>> " >>> (the current wording suggests that all deliveries of CSP1 content = would >> be handled by CDN-B, which is typically not the case i.e. only a = subset of >> the requests are redirected thy CDN-A to CDN-B) >>>=20 >>>=20 >>> *** section 1.3: >>> replace: >>> " >>> CSP-1 benefits because it only needs to make one business agreement = and >> one physical connection, with CDN Provider 'A' >>> " >>> with: >>> " >>> CSP-1 benefits because it only needs to make one business agreement = and >> one technical arrangement with CDN Provider 'A' >>> " >>> (this is because the interfacing between CSP and uCDN comprises more >> than "physical connection"). >>>=20 >>>=20 >>> *** section 1.3: >>> replace: >>> " >>> CSP-1 had also gone to the trouble of making a business agreement = with >> CDN Provider 'B' >>> " >>> with: >>> " >>> CSP-1 had also gone to the trouble of making a business agreement = and >> technical arrangemement with CDN Provider 'B' >>> " >>>=20 >>> *** section 1.3: >>> replace: >>> " >>> But it does not want >>> " >>> with: >>> " >>> However, CSP-2 may not want >>> " >>>=20 >>> *** section 2.1: >>> after >>> " >>> o without incurring additional transit and other network costs that >>> would result from serving content from geographically or >>> topologically remote Surrogates. >>> " >>> add: >>> " >>> o without incurring the cost of deploying and operating Surrogates = and >> the associated CDN infrastructure that may not be justified in the >> corresponding geographic region (e.g. because of relatively low = delivery >> volume, or conversely because of the high investments that would be = needed >> to satisfy the high volume) >>> " >>>=20 >>>=20 >>> *** section 2.2: >>> replace: >>> " >>> A large CDN Provider may also operate CDNs from several subsidiaries >> (which may rely on different CDN technologies, see Section 4.2). In >> certain circumstances, the CDN Provider needs to make its CDNs >> interoperate to provide a consistent service to its customers on its = whole >> footprint. >>> " >>> with: >>> " >>> A large CDN Provider may have several subsidiaries that also each >> operate their own CDN (which may rely on different CDN technologies, = see >> Section 4.2). In certain circumstances, the CDN Provider needs to = make >> these CDNs interoperate to provide a consistent service to its = customers >> on the whole collective footprint. >>> " >>>=20 >>>=20 >>> *** section 2.3: >>> replace: >>> " >>> injected into the access network >>> " >>> with: >>> " >>> injected into the ISP network >>> " >>>=20 >>> *** section 2.3: >>> replace: >>> " >>> There are mutual benefits to the Access CDN, >>> " >>> with: >>> " >>> There are mutual benefits to the ISP (acting as an Access CDN), >>> " >>>=20 >>>=20 >>> *** section 2.3: >>> replace: >>> " >>> for example, QoS and reduced round trip time. >>> " >>> with: >>> " >>> for example, reduced content startup time or increased video quality = and >> resolution of adaptive streaming content. >>> " >>> (I don't think RTT is very meaningful to a CSP customer) >>>=20 >>>=20 >>> *** section 2.4: >>> The nomadic user is currently defined as "moving between CDNs" which = is >> sort of a self-serving definition to justify CDN interconnection. I = think >> we should rather define the nomadic user as "moving between access >> networks" and then justify that leveraging local CDNs can bring a lot = of >> benefits. >>> This requires the following text edits: >>> s/who move between CDNs/who move between access networks/ >>> s/moving between different CDN Providers/moving between different = access >> networks/ >>>=20 >>> *** section 2.4: >>> replace: >>> " >>> which may reside >>> " >>> with: >>> " >>> which may be located >>> " >>>=20 >>> *** section 2.4:" >>> I propose to remove the sentence: >>> " >>> The term "Nomadic" does not necessarily relate to geographic = roaming. >>> " >>> because this point has already been fully (and better) clarified in = the >> preceding paragraph. >>>=20 >>>=20 >>>=20 >>> *** section 2.4: >>> replace: >>> " >>> the WiFi or mobile provider >>> " >>> with: >>> " >>> the WiFi or mobile provider (NSP B) >>> " >>>=20 >>>=20 >>> *** section 3.1: >>> replace: >>> " >>> needs CDN capacities >>> " >>> with: >>> " >>> needs CDN capacity >>> " >>>=20 >>> *** section 3.2.1: >>> The text mentions two options (use OS, use another CDN). I think the >> section shoudl probably also mention the most obvious option (i.e. = use >> other surrogates in the same CDN). Or alternatively, clarify that the >> considered situation is where there is a partial failure of some >> surrogates resulting in the remaining surrogates being fully loaded. >>>=20 >>>=20 >>> *** section 3.2.1: >>> replace: >>> " >>> to both distribute load between origin servers and attempt content >> acquisition from alternate origin servers when acquisition failures = occur. >> When normal content acquisition fails, a CDN may need to try other = origin >> server options, >>> " >>> with: >>> " >>> to both distribute load between content sources and attempt content >> acquisition from alternate content sources when acquisition failures >> occur. When normal content acquisition fails, a CDN may need to try = other >> content source options, >>> " >>> (I believe everywhere else we use "origin server" to refer to the OS = of >> the CSP and "content source" as the generic term for getting content >> including origin server and uCDN) >>>=20 >>> *** section 3.2.2: >>> replace: >>> " >>> the selection of content acquisition sources should be considered. >>> " >>> with: >>> " >>> the selection of content acquisition sources should be considered = and >> facilitated. >>> " >>> (i.e. it is not just a matter of "thinking" about it: it must be >> explicitly allowed or at leads made easier). >>>=20 >>>=20 >>> *** section 4.1: >>> "to serve a proportion of its traffic that requires HTTPS." >>> can you include a reference for HTTPS? >>>=20 >>>=20 >>> *** section 5: >>> replace: >>> " >>> An important aspect of the above use cases >>> " >>> with: >>> " >>> An important aspect common to all the above use cases >>> " >>>=20 >>>=20 >>> *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on = line >> 618, but no explicit reference was found in the text >>> I'd suggest you add an explicit reference. For example, in "1. >> Introduction" you could replace: >>> " >>> The document can be used to guide the definition of the requirements = to >> be supported by the various CDNI interfaces defined in = [I-D.ietf-cdni- >> problem-statement]. >>> " >>> by >>> " >>> The document can be used to guide the definition of the requirements = (as >> documented in [I-D.ietf-cdni-requirements]) to be supported by the = set of >> CDNI interfaces defined in [I-D.ietf-cdni-problem-statement]. >>> " >>> (BTW, independely of the reference issue, "the set of CDNI = interfaces" >> might read better than "the various CDNI interfaces"). >>>=20 >>>=20 >>> *** The document has a disclaimer for pre-RFC5378 work, but was = first >> submitted on or after 10 November 2008. Does it really need the >> disclaimer? >>> _______________________________________________ >>> 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 Fri May 4 04:53:26 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864FD21F8755 for ; Fri, 4 May 2012 04:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.095 X-Spam-Level: X-Spam-Status: No, score=-10.095 tagged_above=-999 required=5 tests=[AWL=0.504, 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 8Pfpo6YzfPer for ; Fri, 4 May 2012 04:53:25 -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 533A421F858F for ; Fri, 4 May 2012 04:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=3310; q=dns/txt; s=iport; t=1336132405; x=1337342005; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=A+bNOU/6hEJm/ddJdwX1Cu+RFMzCFZSR0k9/VPM7ALE=; b=kArQI15+P/+qBSHPpf8vQrl8VpTcjKtJ5odnyM4uM4y5pNHMKidBYdlj Pfjr4pMcMUkPrAhELGEh416ITb4O9VmPp9WM+MNAzijwhlzUe+nsNIe6R myNGt8XQElQhQt22sQgG3zQiZcqF35mai5CfVHbf2w7SxdCRc8Qx3dO+1 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAI7Co0+Q/khM/2dsb2JhbABFsmGBB4IJAQEBAwEBAQEPAVsQCwtGJzAZIodmBQuaYaANkCpjBJV+gRGNSIFpgmo X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="137045559" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 04 May 2012 11:53:24 +0000 Received: from ams-flefauch-8714.cisco.com (ams-flefauch-8714.cisco.com [10.55.161.197]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q44BrN1c018622 for ; Fri, 4 May 2012 11:53:23 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1257) From: Francois Le Faucheur In-Reply-To: <4223D895-FF04-457E-9ED2-A259AB29B520@cisco.com> Date: Fri, 4 May 2012 13:53:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4223D895-FF04-457E-9ED2-A259AB29B520@cisco.com> To: cdni@ietf.org X-Mailer: Apple Mail (2.1257) Subject: Re: [CDNi] Charter adjustement: milestones related to the Request Routing Interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 11:53:26 -0000 Hello, Just to keep everyone posted, the adjustment discussed below has now = been incorporated in the charter = (http://tools.ietf.org/wg/cdni/charters). Cheers Francois On 18 Apr 2012, at 14:27, Francois Le Faucheur wrote: > Folks, >=20 > As you know, what we had initially identified as one CDNI interface = (the Request Routing Interface) actually comprises two different = components, with different requirements, that will likely be realized by = leveraging different base protocols (e.g. web-services/HTTP/DNS for one, = e.g. BGP/ALTO for the other) and that will be progressed at different = pace. These two components are: > * "Request Routing Interface/Redirection": to support the = synchronous operation of actually redirecting a user request. > * "Request Routing Interface/Footprint & Capabilities = Advertisement": to support the asynchronous advertisement of footprint = and capabilities by a dCDN that allows a uCDN to decide whether to = redirect particular user requests to that dCDN. >=20 > The working-group chairs and ADs propose to bring the charter in = alignment with that, and specifically to adjust the list of milestones = of the CDN charter.=20 >=20 > The proposed change is: > OLD: > " > Dec 2012 - Submit specification of the CDNI Request Routing interface = to IESG as Proposed Standard > " > NEW: > " > Dec 2012 - Submit specification of the CDNI Request = Routing/Redirection interface to IESG as Proposed Standard > Jun 2013 - Submit specification of the CDNI Request Routing/Footprint = & Capabilities Advertisement interface to IESG as Proposed Standard > " >=20 > Please let us know if you have any objections, concerns or comments on = this proposed charter adjustment. >=20 > Thank you >=20 > Francois & Rich >=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=3D=3D= =3D=3D=3D >=20 > A little more optional background, just in case: >=20 > Here is some text straight from the CDNI framework document about the = two components of the Request Routing Interface: > " > We may think of the request routing interface as comprising two parts: > 1.the asynchronous advertisement of footprint and capabilities by a = dCDN that allows a uCDN to decide whether to redirect particular user = requests to that dCDN; and > 2. the synchronous operation of actually redirecting a user request. > (These are somewhat analogous to the operations of routing and = forwarding in IP.) =94 > " >=20 > Here is the definition of the Request Routing Interface as per current = charter. I believe that definition still stands as is and need not be = modified since it is broad enough to encompass the two components: > " > * A specification of the "CDNI request-routing interface". This > interface will allow an upstream CDN request routing system to = obtain > from the downstream CDN the information necessary to perform = request > redirection. > " >=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Fri May 4 08:28:41 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0B221F8763 for ; Fri, 4 May 2012 08:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.323 X-Spam-Level: X-Spam-Status: No, score=-8.323 tagged_above=-999 required=5 tests=[AWL=-1.324, BAYES_00=-2.599, GB_MUTUALBENEFIT=2, J_BACKHAIR_11=1, J_CHICKENPOX_31=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 Q6kvAW+BzQyA for ; Fri, 4 May 2012 08:28:39 -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 E87D121F8760 for ; Fri, 4 May 2012 08:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=22328; q=dns/txt; s=iport; t=1336145318; x=1337354918; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=2k13xRRRgLrwzjaTg/Pq3116Dgf2Qt9ImL7Zstzvm4w=; b=KxqzNpPCe+4SHoP1wKSdDhsDA7V4SOGGHtZ70R0PoiKqbuozga3atLqw yptf0e6endbU6GTpWHKWUo7bxdpMI4kD0d1LdbFZtESEomcsDq32TG5TH 83uTNyTabO/jPeSkvzdYiTFYO6ozEb/EyZFwQvb/xpO0svTVMT5UDdp4X 0=; X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208";a="137073003" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 04 May 2012 15:28:36 +0000 Received: from ams-flefauch-8714.cisco.com (ams-flefauch-8714.cisco.com [10.55.161.197]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q44FSYTI022807; Fri, 4 May 2012 15:28:34 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Francois Le Faucheur In-Reply-To: <291CC3F9E50E7641901A54E85D0977C65260C10A37@MAILR002.mail.lan> Date: Fri, 4 May 2012 17:28:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5C88F9C0-F28D-4B77-88AA-3D9058E8FE8A@cisco.com> References: <5388986F-034F-4E38-A5A3-78B6E30F56A5@cisco.com> <291CC3F9E50E7641901A54E85D0977C65260C10A37@MAILR002.mail.lan> To: Kevin J Ma X-Mailer: Apple Mail (2.1257) Cc: "draft-ietf-cdni-use-cases@tools.ietf.org" , "cdni@ietf.org" Subject: [CDNi] Tie between Request-Routing and policy Re: Document Shepherd review of draft-ietf-cdni-use-cases X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss 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, 04 May 2012 15:28:41 -0000 Hi Kevin, I think the discussion below touches on two topics: *A* delivery policies to be communicated and enforced by a dCDN *B* potential interactions between request-routing and the = ability of a CDN to enforce an aspect of policy=20 Regarding *A*, I expressed my thoughts in = http://www.ietf.org/mail-archive/web/cdni/current/msg00988.html. Please = let me know if that makes sense to you. Regarding *B*: So I think your concern is "how do we deal with potential = situations where an uCDN may redirect a request to a dCDN that is not = capable to enforce all aspects of the distribution policy?". That is a = good point. My proposal would be: * let's settle on a small set of well-defined policies (as = discussed in = http://www.ietf.org/mail-archive/web/cdni/current/msg00988.html.) such = as geoblocking + time-window + pre-authrization-enforcement (e.g. URI = signing), then we may virtually eliminate the situation altogether in = the common cases (at least in the initial incarnation of the CDNI = solution) since all dCDNs could support that set of policies (i.e. they = would be mandatory) * to allow flexibility in the future (e.g. to allow introduction = of additional policies in subsequent versions of CDNI), let's rely on = the "Capabilities Advertisement" of the Request Routing interface. This = would allow the dCDN to advertise to the uCDN what sort of capabilities = it supports in the area of distribution policy enforcement. The design = team will look into the details of those but they might come at = different levels of granularity; for example, the dCDN may allow a dCDN = to say "I support the delivery policies defined in CDNI v1" or "I = support the delivery policies defined in CDNI v1 and in CDNIv2" or, if = needed, "I support the delivery policies defined in CDNI v1 and the 1st = subset of delivery policies defined in CDNIv2 but not the 2nd subset". = This can be factored by the uCDN Request Routing system (e.g. it can = consider the metadata and based on those could decide to consider the = dCDN advertised policy capabilities). I am not sure we need that sort of = things for our initial CDNI solution, but arguably that depends on if we = can settle for a single set of delivery policies that we all make = mandatory. * in any case, we have the "escape" mechanism discussed by Larry = in Paris: if a dCDN is explicitly told so, or if it is not capable of = enforcing a particular policy aspect requested in the metadata, then it = can do a per-request authorization check into the uCDN. Do you agree with the above? To your specific question about my concern with the current text. I just = don't get the point it is trying to make. For example it says: " dCDN delegation and Surrogate selection decisions are influenced by these policies: ... o dCDN delegation may fail if the content resolution has been specified by the CSP as being too high for distribution via the dCDN, " =03I understand this to mean that dCDN selection by the uCDN is supped = to take into account things like whether a given resolution is deemed to = high by the CSP for delivery via a CDN. I disagree with this. The uCDN should not have to be aware of that sort = of policies. All it would know is whether a content is to be delivered = or not (it really does not care whether this is because of excessively = good resolution or any CSP-meaningful but CDN-meaningless reasons). Again, to me the whole point of that section is precisely to clarify = that CSPs may have fancy policies and that those can be enforced in a = multi-CDN environment without having to make these fancy policy = understood by the CDNs. The current text is suggesting quite the = opposite to me. Or maybe I am misreading it. Cheers Francois On 26 Apr 2012, at 23:46, Kevin J Ma wrote: > Hi Francois, >=20 >> * explain that the CDNs are only expected to enforce a few = specific >> policy rules (e.g. geo-blocking, time window) and for enforcement of = all >> fancy CSP policy we propose that the responsibilities be divided into = (1) >> the CSP being responsible for the fancy policy decision and (ii) the = CDN >> for merely enforcing the CSP decision without having to understand = the >> policy (e.g. via URI signing). >> Do we not agree on that or not? >=20 > I agree that the CDN should enforce any policy that is defined in = metadata. > If a supported metadata dictates a restriction, regardless of any = individual > interpretation of the semantic fanciness, the restriction should be = enforced. > If a dCDN does not support a given metadata, it can express that to = the uCDN, > which should influence the inter-CDN request routing. >=20 >> Also, the paragraph keeps talking about "dCDN selection or Surrogate >> selection" may fail for some fancy policy reasons. I don't understand = what >> it means to "fail", but more importantly again, I don't think we want = CDN >> request routing decisions to be factoring very fancy CSP policy = rules. >> Do we agree or not? >=20 > The failure could probably be a more generic delivery failure, due to > restrictions defined in the metadata, though, the framework document > shows the metadata checks as part of request routing decision making > which presumably influences dCDN/Surrogate selection? >=20 > The fanciness of the policy should not matter, as long as the > metadata which conveys the enforcement of that policy is clear and > succinct. The inter-CDN request routing should be aware of the > capabilities of each dCDN and not delegate to dCDNs that lack support > for capabilities which are deemed mandatory. >=20 > The use cases do not dictate any specific implementations. They do = not > require request routing to implement fancy policy rules. A valid > implementation could wrap all the fancy policy rules into a nice neat > boolean value. An equally valid implementation could implement extra > super fancy policy rules. The use case does not mandate one or the = other. >=20 > Is the concern that specific portions are not valid, or that the = descriptions > are unclear, or is the concern about an assumed implementation's = fanciness? >=20 > thanx. >=20 > -- Kevin J. Ma >=20 >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of >> Francois Le Faucheur >> Sent: Wednesday, April 25, 2012 12:46 PM >> To: draft-ietf-cdni-use-cases@tools.ietf.org >> Cc: cdni@ietf.org >> Subject: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases >>=20 >> To use-cases authors, >>=20 >> Below are my shepherd review comments of cdni-uses-cases. >>=20 >> I think the document is in a good shape and captures well the key = targeted >> use cases. >> I identified two remaining significant points to be addressed, and = also >> have included many suggestions to improve the document. >> I suggest we resolve the two significant points on the list and leave = it >> to editor/authors to decide how to dispose of the suggestions for >> improvement offline. >>=20 >> Cheers >>=20 >> Francois >>=20 >>=20 >> Significant points >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> *** section 8 security considerations >> I have a few specific issues with the current text of the Security >> Considerations section. But I don't really see the need to have an >> expanded Security Considerations section in both the use-case = document and >> the problem-statement (particularly considering that the first IESG = review >> comments on problem-statement suggest expanding the security >> considerations section there), in particular because the security >> considerations currently brought up in use-cases are not specific to >> individual use cases bur rather generic to the whole CDN = interconnection >> problem space. >> So my proposal would be to remove the whole discussion from use-cases >> (i.e. the first 4 paragraphs) and refer to the Security = Considerations >> section of the Problem Statement e.g.. by replacing: >> " >> This document focuses on the motivational use cases for CDN >> Interconnection, and does not analyze these threats in detail. >> " >> with: >> " >> This document focuses on the motivational use cases for CDN >> Interconnection, and does not analyze the associated threats. Those = are >> discussed in [I-D.ietf-cdni-problem-statement]. >> " >>=20 >>=20 >> ***section A.1: >> I still have a problem with the text of that section. >> I thought we had converged on an agreement that the text would: >> * explain that CSPs may take into account very >> multiple/arbitrary/specific criteria in their policy >> * explain that the CDNs are only expected to enforce a few = specific >> policy rules (e.g. geo-blocking, time window) and for enforcement of = all >> fancy CSP policy we propose that the responsibilities be divided into = (1) >> the CSP being responsible for the fancy policy decision and (ii) the = CDN >> for merely enforcing the CSP decision without having to understand = the >> policy (e.g. via URI signing). >> Do we not agree on that or not? >>=20 >> The current text says that CDN selection and surrogate selection "are >> influenced by these policies" (referring to the fancy CSP policies). = I do >> not agree with that. I don;t think we want CDN Selection or Surrogate >> selection to be influenced by whether a movie shoudl be available 14 = or 28 >> days after DVD release, or whether a given resolution is "too high" = for a >> particular user or terminal. >>=20 >> Also, the paragraph keeps talking about "dCDN selection or Surrogate >> selection" may fail for some fancy policy reasons. I don't understand = what >> it means to "fail" , but more importantly again, I don't think we = want CDN >> request routing decisions to be factoring very fancy CSP policy = rules. >> Do we agree or not? >>=20 >> The last paragraphs gives examples of the CSP objectives of = supporting >> delivery policies in CDNs, and those are fine and can be achieved = with the >> set of mechanisms discussed above (i.e. goeblocking + time window + = URI >> signing). >>=20 >>=20 >> Suggestions for improvements >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> ***Abstract >> replace "CDNI" by "CDN Interconnection". >>=20 >> *** section 1: >> expand the first instance of CDNI into "CDN Interconnection (CDNI)". >>=20 >> *** section 1: >> "Then, the document highlights the need for interoperability to >> exchange and enforce content delivery policies (Section 5)." >> I'd suggest replacing "for interoperability to exchange" by "for >> interoperability to allow exchange" or by "for interoperability in = order >> to exchange" >>=20 >> *** section 1.1: >> Do you feel that the two additional terms are really specific to the = use- >> case document (in which case their definition should stay in this >> document) or are they likely useful in other documents (in which case >> their definition should be migrated to the framework document)? >> Personally, I would say that those terms might be useful in other >> documents/discussions (eg I am pretty sure we'd need to refer to the >> "Delivering CDN" in other context). >>=20 >> *** section 1.1: >> "Access CDN: >> A CDN that is directly connected to the End User's access." >> I think this definition needs to be a little more specific. "Directly >> connected" does not mean "L2 connectivity" (because an on-net cache = maybe >> a few L2 hops away), nor does it mean "L3 connectivity" (because an = OTT >> CDN cache has IP connectivity to an enduser). I think you mean = something >> in between, more or less that the CDN and the access are within the = same >> IP administrative domain, or something close to that. Can you try = refine >> that definition? >>=20 >> *** section 1.3: >> " o improve the experience for the End User; for instance delivery = has >> lower latency (decreased round-trip-time between the user and the >> delivery server) and better robustness," >> To be more comprehensive in justifying the claims, how about: >> " o improve the experience for the End User; for instance delivery = has >> lower latency (decreased round-trip-time and higher throughput >> between the user and the >> delivery server) and better robustness (ability to use multiple >> delivery servers)," >>=20 >> *** section 1.3: >> "o reduce the Content Service Provider's (CSP) costs, such as >> datacenter capacity, space, and electricity consumption, as >> popular content is delivered through the CDN rather than through >> the CSP's servers." >> The current wording raises the question of "if it reduces the costs = by >> reducing expenses in the CSP datacenter, why does it not = correspondingly >> increase the cost by increasing expenses in the CDN (which the CDN >> provider then charges back to the CSP)?" >> I think the gain is in the scale and effective pooling of CDN = resources >> across many CSPs. Could you refine the wording to explain why there = is >> indeed a net gain? >>=20 >> *** section 1.3: >> Replace: >> " >> An example is depicted in Figure 1. Two CDN Providers establish a = CDN >> Interconnection. >> " >> with: >> " >> An example is depicted in Figure 1 where two CDN Providers establish = a CDN >> Interconnection. >> " >> (this is to minimize the redundancy with the sentence coming below: = "CDN >> Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs.") >>=20 >>=20 >> *** section 1.3: >> replace: >> " >> "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their = CDNs." >> with: >> "Independently, CDN Provider 'A' and CDN Provider 'B' agree to >> interconnect their CDNs." >> this is to clarify that the A<->B agreement is not specific to the = 1<->A >> agreement >>=20 >>=20 >> *** section 1.3: >> replace: >> " >> When a User Agent requests content from CSP-1, CDN-A considers that >> delivery by CDN-B is appropriate >> " >> with: >> " >> When a given User Agent requests content from CSP-1, CDN-A may = consider >> that delivery by CDN-B is appropriate >> " >>=20 >>=20 >> *** section 1.3: >> replace: >> " >> CDN-A has delegated the handling of requests for CSP-1's content = through >> the CDN Interconnection agreement, thus, the content is actually = delivered >> from CDN-B. >> " >> with: >> " >> Through the CDN Interconnection arrangements put in place between = CDN-A >> and CDN-B (as a result of the CDN Interconnection agreement = established >> between CDN Provider 'A' and CDN Provider 'B'), CDN-A can redirect = the >> request to CDN-B and the content is actually delivered to the User = Agent >> by CDN-B. >> " >> (the current wording suggests that all deliveries of CSP1 content = would be >> handled by CDN-B, which is typically not the case i.e. only a subset = of >> the requests are redirected thy CDN-A to CDN-B) >>=20 >>=20 >> *** section 1.3: >> replace: >> " >> CSP-1 benefits because it only needs to make one business agreement = and >> one physical connection, with CDN Provider 'A' >> " >> with: >> " >> CSP-1 benefits because it only needs to make one business agreement = and >> one technical arrangement with CDN Provider 'A' >> " >> (this is because the interfacing between CSP and uCDN comprises more = than >> "physical connection"). >>=20 >>=20 >> *** section 1.3: >> replace: >> " >> CSP-1 had also gone to the trouble of making a business agreement = with CDN >> Provider 'B' >> " >> with: >> " >> CSP-1 had also gone to the trouble of making a business agreement and >> technical arrangemement with CDN Provider 'B' >> " >>=20 >> *** section 1.3: >> replace: >> " >> But it does not want >> " >> with: >> " >> However, CSP-2 may not want >> " >>=20 >> *** section 2.1: >> after >> " >> o without incurring additional transit and other network costs that >> would result from serving content from geographically or >> topologically remote Surrogates. >> " >> add: >> " >> o without incurring the cost of deploying and operating Surrogates = and the >> associated CDN infrastructure that may not be justified in the >> corresponding geographic region (e.g. because of relatively low = delivery >> volume, or conversely because of the high investments that would be = needed >> to satisfy the high volume) >> " >>=20 >>=20 >> *** section 2.2: >> replace: >> " >> A large CDN Provider may also operate CDNs from several subsidiaries >> (which may rely on different CDN technologies, see Section 4.2). In >> certain circumstances, the CDN Provider needs to make its CDNs >> interoperate to provide a consistent service to its customers on its = whole >> footprint. >> " >> with: >> " >> A large CDN Provider may have several subsidiaries that also each = operate >> their own CDN (which may rely on different CDN technologies, see = Section >> 4.2). In certain circumstances, the CDN Provider needs to make these = CDNs >> interoperate to provide a consistent service to its customers on the = whole >> collective footprint. >> " >>=20 >>=20 >> *** section 2.3: >> replace: >> " >> injected into the access network >> " >> with: >> " >> injected into the ISP network >> " >>=20 >> *** section 2.3: >> replace: >> " >> There are mutual benefits to the Access CDN, >> " >> with: >> " >> There are mutual benefits to the ISP (acting as an Access CDN), >> " >>=20 >>=20 >> *** section 2.3: >> replace: >> " >> for example, QoS and reduced round trip time. >> " >> with: >> " >> for example, reduced content startup time or increased video quality = and >> resolution of adaptive streaming content. >> " >> (I don't think RTT is very meaningful to a CSP customer) >>=20 >>=20 >> *** section 2.4: >> The nomadic user is currently defined as "moving between CDNs" which = is >> sort of a self-serving definition to justify CDN interconnection. I = think >> we should rather define the nomadic user as "moving between access >> networks" and then justify that leveraging local CDNs can bring a lot = of >> benefits. >> This requires the following text edits: >> s/who move between CDNs/who move between access networks/ >> s/moving between different CDN Providers/moving between different = access >> networks/ >>=20 >> *** section 2.4: >> replace: >> " >> which may reside >> " >> with: >> " >> which may be located >> " >>=20 >> *** section 2.4:" >> I propose to remove the sentence: >> " >> The term "Nomadic" does not necessarily relate to geographic roaming. >> " >> because this point has already been fully (and better) clarified in = the >> preceding paragraph. >>=20 >>=20 >>=20 >> *** section 2.4: >> replace: >> " >> the WiFi or mobile provider >> " >> with: >> " >> the WiFi or mobile provider (NSP B) >> " >>=20 >>=20 >> *** section 3.1: >> replace: >> " >> needs CDN capacities >> " >> with: >> " >> needs CDN capacity >> " >>=20 >> *** section 3.2.1: >> The text mentions two options (use OS, use another CDN). I think the >> section shoudl probably also mention the most obvious option (i.e. = use >> other surrogates in the same CDN). Or alternatively, clarify that the >> considered situation is where there is a partial failure of some >> surrogates resulting in the remaining surrogates being fully loaded. >>=20 >>=20 >> *** section 3.2.1: >> replace: >> " >> to both distribute load between origin servers and attempt content >> acquisition from alternate origin servers when acquisition failures = occur. >> When normal content acquisition fails, a CDN may need to try other = origin >> server options, >> " >> with: >> " >> to both distribute load between content sources and attempt content >> acquisition from alternate content sources when acquisition failures >> occur. When normal content acquisition fails, a CDN may need to try = other >> content source options, >> " >> (I believe everywhere else we use "origin server" to refer to the OS = of >> the CSP and "content source" as the generic term for getting content >> including origin server and uCDN) >>=20 >> *** section 3.2.2: >> replace: >> " >> the selection of content acquisition sources should be considered. >> " >> with: >> " >> the selection of content acquisition sources should be considered and >> facilitated. >> " >> (i.e. it is not just a matter of "thinking" about it: it must be >> explicitly allowed or at leads made easier). >>=20 >>=20 >> *** section 4.1: >> "to serve a proportion of its traffic that requires HTTPS." >> can you include a reference for HTTPS? >>=20 >>=20 >> *** section 5: >> replace: >> " >> An important aspect of the above use cases >> " >> with: >> " >> An important aspect common to all the above use cases >> " >>=20 >>=20 >> *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line = 618, >> but no explicit reference was found in the text >> I'd suggest you add an explicit reference. For example, in "1. >> Introduction" you could replace: >> " >> The document can be used to guide the definition of the requirements = to be >> supported by the various CDNI interfaces defined in [I-D.ietf-cdni- >> problem-statement]. >> " >> by >> " >> The document can be used to guide the definition of the requirements = (as >> documented in [I-D.ietf-cdni-requirements]) to be supported by the = set of >> CDNI interfaces defined in [I-D.ietf-cdni-problem-statement]. >> " >> (BTW, independely of the reference issue, "the set of CDNI = interfaces" >> might read better than "the various CDNI interfaces"). >>=20 >>=20 >> *** The document has a disclaimer for pre-RFC5378 work, but was first >> submitted on or after 10 November 2008. Does it really need the >> disclaimer? >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni From gilles.bertrand@orange.com Wed May 9 08:20:21 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0709921F8523 for ; Wed, 9 May 2012 08:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.891 X-Spam-Level: X-Spam-Status: No, score=-3.891 tagged_above=-999 required=5 tests=[AWL=-1.242, BAYES_00=-2.599, GB_MUTUALBENEFIT=2, HELO_EQ_FR=0.35, J_BACKHAIR_11=1, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8I9EcgVP2cQ7 for ; Wed, 9 May 2012 08:20:19 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id C820321F84FC for ; Wed, 9 May 2012 08:20:18 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E94C516C003; Wed, 9 May 2012 17:20:17 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id D6A7B5D8A49; Wed, 9 May 2012 17:20:17 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 May 2012 17:20:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 May 2012 17:19:21 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF035ED73B@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <5388986F-034F-4E38-A5A3-78B6E30F56A5@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases Thread-Index: Ac0jAuNnLfnZZ3+DTOemIJ5qJbzsRgK8salQ References: <5388986F-034F-4E38-A5A3-78B6E30F56A5@cisco.com> From: To: , X-OriginalArrivalTime: 09 May 2012 15:20:17.0981 (UTC) FILETIME=[3DC07ED0:01CD2DF7] Cc: cdni@ietf.org Subject: Re: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss 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, 09 May 2012 15:20:21 -0000 Hi Fran=E7ois, Thanks for your review. We are integrating your comments.=20 About your comments on Section 1.1, I definitely think the terms "Access = CDN" and "Delivering CDN" are useful more broadly than just in the use = cases document. Therefore, I would be in favor of moving them to the = framework document as you propose. Access CDN: A CDN that includes Surrogates in the same network (e.g., same = Autonomous System) as the End User. An Access CDN may have specific = information about the End User and the network, for instance, End User's profile and access capabilities. Delivering CDN: The CDN that delivers the requested piece of content to the End User. In particular, the Delivering CDN can be an Access CDN. Best regards, Gilles -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part = de Francois Le Faucheur Envoy=E9=A0: mercredi 25 avril 2012 18:46 =C0=A0: draft-ietf-cdni-use-cases@tools.ietf.org Cc=A0: cdni@ietf.org Objet=A0: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases To use-cases authors, Below are my shepherd review comments of cdni-uses-cases. I think the document is in a good shape and captures well the key = targeted use cases. I identified two remaining significant points to be addressed, and also = have included many suggestions to improve the document. I suggest we resolve the two significant points on the list and leave it = to editor/authors to decide how to dispose of the suggestions for = improvement offline. Cheers Francois Significant points =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D *** section 8 security considerations I have a few specific issues with the current text of the Security = Considerations section. But I don't really see the need to have an = expanded Security Considerations section in both the use-case document = and the problem-statement (particularly considering that the first IESG = review comments on problem-statement suggest expanding the security = considerations section there), in particular because the security = considerations currently brought up in use-cases are not specific to = individual use cases bur rather generic to the whole CDN interconnection = problem space. So my proposal would be to remove the whole discussion from use-cases = (i.e. the first 4 paragraphs) and refer to the Security Considerations = section of the Problem Statement e.g.. by replacing: "=20 This document focuses on the motivational use cases for CDN = Interconnection, and does not analyze these threats in detail. " with: " This document focuses on the motivational use cases for CDN = Interconnection, and does not analyze the associated threats. Those are = discussed in [I-D.ietf-cdni-problem-statement]. " ***section A.1: I still have a problem with the text of that section. I thought we had converged on an agreement that the text would: * explain that CSPs may take into account very = multiple/arbitrary/specific criteria in their policy * explain that the CDNs are only expected to enforce a few specific = policy rules (e.g. geo-blocking, time window) and for enforcement of all = fancy CSP policy we propose that the responsibilities be divided into = (1) the CSP being responsible for the fancy policy decision and (ii) the = CDN for merely enforcing the CSP decision without having to understand = the policy (e.g. via URI signing). Do we not agree on that or not? The current text says that CDN selection and surrogate selection "are = influenced by these policies" (referring to the fancy CSP policies). I = do not agree with that. I don;t think we want CDN Selection or Surrogate = selection to be influenced by whether a movie shoudl be available 14 or = 28 days after DVD release, or whether a given resolution is "too high" = for a particular user or terminal.=20 Also, the paragraph keeps talking about "dCDN selection or Surrogate = selection" may fail for some fancy policy reasons. I don't understand = what it means to "fail" , but more importantly again, I don't think we = want CDN request routing decisions to be factoring very fancy CSP policy = rules. Do we agree or not? The last paragraphs gives examples of the CSP objectives of supporting = delivery policies in CDNs, and those are fine and can be achieved with = the set of mechanisms discussed above (i.e. goeblocking + time window + = URI signing). Suggestions for improvements =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ***Abstract replace "CDNI" by "CDN Interconnection". *** section 1: expand the first instance of CDNI into "CDN Interconnection (CDNI)". *** section 1: "Then, the document highlights the need for interoperability to exchange and enforce content delivery policies (Section 5)." I'd suggest replacing "for interoperability to exchange" by "for = interoperability to allow exchange" or by "for interoperability in order = to exchange" *** section 1.1: Do you feel that the two additional terms are really specific to the = use-case document (in which case their definition should stay in this = document) or are they likely useful in other documents (in which case = their definition should be migrated to the framework document)? Personally, I would say that those terms might be useful in other = documents/discussions (eg I am pretty sure we'd need to refer to the = "Delivering CDN" in other context). *** section 1.1: "Access CDN: A CDN that is directly connected to the End User's access." I think this definition needs to be a little more specific. "Directly = connected" does not mean "L2 connectivity" (because an on-net cache = maybe a few L2 hops away), nor does it mean "L3 connectivity" (because = an OTT CDN cache has IP connectivity to an enduser). I think you mean = something in between, more or less that the CDN and the access are = within the same IP administrative domain, or something close to that. = Can you try refine that definition? *** section 1.3: " o improve the experience for the End User; for instance delivery has lower latency (decreased round-trip-time between the user and the delivery server) and better robustness," To be more comprehensive in justifying the claims, how about: " o improve the experience for the End User; for instance delivery has lower latency (decreased round-trip-time and higher throughput = between the user and the delivery server) and better robustness (ability to use multiple = delivery servers)," *** section 1.3: "o reduce the Content Service Provider's (CSP) costs, such as datacenter capacity, space, and electricity consumption, as popular content is delivered through the CDN rather than through the CSP's servers." The current wording raises the question of "if it reduces the costs by = reducing expenses in the CSP datacenter, why does it not correspondingly = increase the cost by increasing expenses in the CDN (which the CDN = provider then charges back to the CSP)?" I think the gain is in the scale and effective pooling of CDN resources = across many CSPs. Could you refine the wording to explain why there is = indeed a net gain? *** section 1.3: Replace: " An example is depicted in Figure 1. Two CDN Providers establish a CDN = Interconnection. " with: " An example is depicted in Figure 1 where two CDN Providers establish a = CDN Interconnection. " (this is to minimize the redundancy with the sentence coming below: "CDN = Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs.") *** section 1.3: replace: " "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their = CDNs." with: "Independently, CDN Provider 'A' and CDN Provider 'B' agree to = interconnect their CDNs." this is to clarify that the A<->B agreement is not specific to the 1<->A = agreement *** section 1.3: replace: " When a User Agent requests content from CSP-1, CDN-A considers that = delivery by CDN-B is appropriate " with: " When a given User Agent requests content from CSP-1, CDN-A may consider = that delivery by CDN-B is appropriate " *** section 1.3: replace: " CDN-A has delegated the handling of requests for CSP-1's content through = the CDN Interconnection agreement, thus, the content is actually = delivered from CDN-B. " with: " Through the CDN Interconnection arrangements put in place between CDN-A = and CDN-B (as a result of the CDN Interconnection agreement established = between CDN Provider 'A' and CDN Provider 'B'), CDN-A can redirect the = request to CDN-B and the content is actually delivered to the User Agent = by CDN-B. " (the current wording suggests that all deliveries of CSP1 content would = be handled by CDN-B, which is typically not the case i.e. only a subset = of the requests are redirected thy CDN-A to CDN-B)=20 *** section 1.3: replace: " CSP-1 benefits because it only needs to make one business agreement and = one physical connection, with CDN Provider 'A' " with: " CSP-1 benefits because it only needs to make one business agreement and = one technical arrangement with CDN Provider 'A' " (this is because the interfacing between CSP and uCDN comprises more = than "physical connection"). *** section 1.3: replace: " CSP-1 had also gone to the trouble of making a business agreement with = CDN Provider 'B' " with: " CSP-1 had also gone to the trouble of making a business agreement and = technical arrangemement with CDN Provider 'B' " *** section 1.3: replace: " But it does not want " with: " However, CSP-2 may not want " *** section 2.1: after " o without incurring additional transit and other network costs that would result from serving content from geographically or topologically remote Surrogates. " add: " o without incurring the cost of deploying and operating Surrogates and = the associated CDN infrastructure that may not be justified in the = corresponding geographic region (e.g. because of relatively low delivery = volume, or conversely because of the high investments that would be = needed to satisfy the high volume) " *** section 2.2: replace: " A large CDN Provider may also operate CDNs from several subsidiaries = (which may rely on different CDN technologies, see Section 4.2). In = certain circumstances, the CDN Provider needs to make its CDNs = interoperate to provide a consistent service to its customers on its = whole footprint. " with: " A large CDN Provider may have several subsidiaries that also each = operate their own CDN (which may rely on different CDN technologies, see = Section 4.2). In certain circumstances, the CDN Provider needs to make = these CDNs interoperate to provide a consistent service to its customers = on the whole collective footprint.=20 " *** section 2.3: replace: " injected into the access network " with: " injected into the ISP network " *** section 2.3: replace: " There are mutual benefits to the Access CDN, " with: " There are mutual benefits to the ISP (acting as an Access CDN), " *** section 2.3: replace: " for example, QoS and reduced round trip time. " with: " for example, reduced content startup time or increased video quality and = resolution of adaptive streaming content. " (I don't think RTT is very meaningful to a CSP customer) *** section 2.4: The nomadic user is currently defined as "moving between CDNs" which is = sort of a self-serving definition to justify CDN interconnection. I = think we should rather define the nomadic user as "moving between access = networks" and then justify that leveraging local CDNs can bring a lot of = benefits. This requires the following text edits: s/who move between CDNs/who move between access networks/ s/moving between different CDN Providers/moving between different access = networks/ *** section 2.4: replace: " which may reside " with: " which may be located " *** section 2.4:" I propose to remove the sentence: " The term "Nomadic" does not necessarily relate to geographic roaming. " because this point has already been fully (and better) clarified in the = preceding paragraph. *** section 2.4: replace: " the WiFi or mobile provider " with: " the WiFi or mobile provider (NSP B) " *** section 3.1: replace: " needs CDN capacities " with: " needs CDN capacity " *** section 3.2.1: The text mentions two options (use OS, use another CDN). I think the = section shoudl probably also mention the most obvious option (i.e. use = other surrogates in the same CDN). Or alternatively, clarify that the = considered situation is where there is a partial failure of some = surrogates resulting in the remaining surrogates being fully loaded. *** section 3.2.1: replace: " to both distribute load between origin servers and attempt content = acquisition from alternate origin servers when acquisition failures = occur. When normal content acquisition fails, a CDN may need to try = other origin server options, " with: " to both distribute load between content sources and attempt content = acquisition from alternate content sources when acquisition failures = occur. When normal content acquisition fails, a CDN may need to try = other content source options, " (I believe everywhere else we use "origin server" to refer to the OS of = the CSP and "content source" as the generic term for getting content = including origin server and uCDN) *** section 3.2.2: replace: " the selection of content acquisition sources should be considered. " with: " the selection of content acquisition sources should be considered and = facilitated. " (i.e. it is not just a matter of "thinking" about it: it must be = explicitly allowed or at leads made easier). *** section 4.1: "to serve a proportion of its traffic that requires HTTPS." can you include a reference for HTTPS? *** section 5: replace: " An important aspect of the above use cases " with: " An important aspect common to all the above use cases " *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line = 618, but no explicit reference was found in the text I'd suggest you add an explicit reference. For example, in "1. = Introduction" you could replace: " The document can be used to guide the definition of the requirements to = be supported by the various CDNI interfaces defined in = [I-D.ietf-cdni-problem-statement]. " by " The document can be used to guide the definition of the requirements (as = documented in [I-D.ietf-cdni-requirements]) to be supported by the set = of CDNI interfaces defined in [I-D.ietf-cdni-problem-statement]. " (BTW, independely of the reference issue, "the set of CDNI interfaces" = might read better than "the various CDNI interfaces"). *** The document has a disclaimer for pre-RFC5378 work, but was first = submitted on or after 10 November 2008. Does it really need the = disclaimer? _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Wed May 9 08:47: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 CD0E021F8463 for ; Wed, 9 May 2012 08:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.253 X-Spam-Level: X-Spam-Status: No, score=-8.253 tagged_above=-999 required=5 tests=[AWL=-1.254, BAYES_00=-2.599, GB_MUTUALBENEFIT=2, J_BACKHAIR_11=1, J_CHICKENPOX_31=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 Q1vhJs0pfQcH for ; Wed, 9 May 2012 08:47:41 -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 8A09321F8418 for ; Wed, 9 May 2012 08:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=16386; q=dns/txt; s=iport; t=1336578460; x=1337788060; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=hv13M+jLOY9fUKN+Mf11r8S96m+SqNkfLgTH8/sNW98=; b=mdgOq0mqrvlncfizWwLqUVJC2umgfQOng4oTD9vD157RX1XkFlHi5kQg wt4TRRkvzv9N1LBDG4GeHVw+SUj1INMg/gb5mmT0FTpV1cIH800HxNy+I B99DGinCVkGNhQiFY0azVxpMr94560KEemMJg35F8f1mBydO6QGYwMUQi Q=; X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="72807109" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 09 May 2012 15:47:37 +0000 Received: from ams-flefauch-8714.cisco.com (ams-flefauch-8714.cisco.com [10.55.161.197]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q49Flav2019304; Wed, 9 May 2012 15:47:36 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Francois Le Faucheur In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF035ED73B@ftrdmel0.rd.francetelecom.fr> Date: Wed, 9 May 2012 17:47:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <89ACE04E-3414-4D68-9106-97FF36AE2F2B@cisco.com> References: <5388986F-034F-4E38-A5A3-78B6E30F56A5@cisco.com> <8E09C72DBC577D489F13A71228C0B7BF035ED73B@ftrdmel0.rd.francetelecom.fr> To: "Peterson, Larry" X-Mailer: Apple Mail (2.1257) Cc: cdni@ietf.org Subject: [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: Wed, 09 May 2012 15:47:42 -0000 Hi Larry, Can you confirm this can be done in next rev of cdni-framework? Tx Francois On 9 May 2012, at 17:19, wrote: > Hi Fran=E7ois, >=20 > Thanks for your review. We are integrating your comments.=20 >=20 > About your comments on Section 1.1, I definitely think the terms = "Access CDN" and "Delivering CDN" are useful more broadly than just in = the use cases document. Therefore, I would be in favor of moving them to = the framework document as you propose. >=20 > Access CDN: > A CDN that includes Surrogates in the same network (e.g., same = Autonomous System) as the End User. An Access CDN may have specific = information about > the End User and the network, for instance, End User's > profile and access capabilities. >=20 > Delivering CDN: > The CDN that delivers the requested piece of content to > the End User. In particular, the Delivering CDN can be an > Access CDN. >=20 >=20 > Best regards, >=20 > Gilles >=20 >=20 > -----Message d'origine----- > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part = de Francois Le Faucheur > Envoy=E9 : mercredi 25 avril 2012 18:46 > =C0 : draft-ietf-cdni-use-cases@tools.ietf.org > Cc : cdni@ietf.org > Objet : [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases >=20 > To use-cases authors, >=20 > Below are my shepherd review comments of cdni-uses-cases. >=20 > I think the document is in a good shape and captures well the key = targeted use cases. > I identified two remaining significant points to be addressed, and = also have included many suggestions to improve the document. > I suggest we resolve the two significant points on the list and leave = it to editor/authors to decide how to dispose of the suggestions for = improvement offline. >=20 > Cheers >=20 > Francois >=20 >=20 > Significant points > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > *** section 8 security considerations > I have a few specific issues with the current text of the Security = Considerations section. But I don't really see the need to have an = expanded Security Considerations section in both the use-case document = and the problem-statement (particularly considering that the first IESG = review comments on problem-statement suggest expanding the security = considerations section there), in particular because the security = considerations currently brought up in use-cases are not specific to = individual use cases bur rather generic to the whole CDN interconnection = problem space. > So my proposal would be to remove the whole discussion from use-cases = (i.e. the first 4 paragraphs) and refer to the Security Considerations = section of the Problem Statement e.g.. by replacing: > "=20 > This document focuses on the motivational use cases for CDN = Interconnection, and does not analyze these threats in detail. > " > with: > " > This document focuses on the motivational use cases for CDN = Interconnection, and does not analyze the associated threats. Those are = discussed in [I-D.ietf-cdni-problem-statement]. > " >=20 >=20 > ***section A.1: > I still have a problem with the text of that section. > I thought we had converged on an agreement that the text would: > * explain that CSPs may take into account very = multiple/arbitrary/specific criteria in their policy > * explain that the CDNs are only expected to enforce a few = specific policy rules (e.g. geo-blocking, time window) and for = enforcement of all fancy CSP policy we propose that the responsibilities = be divided into (1) the CSP being responsible for the fancy policy = decision and (ii) the CDN for merely enforcing the CSP decision without = having to understand the policy (e.g. via URI signing). > Do we not agree on that or not? >=20 > The current text says that CDN selection and surrogate selection "are = influenced by these policies" (referring to the fancy CSP policies). I = do not agree with that. I don;t think we want CDN Selection or Surrogate = selection to be influenced by whether a movie shoudl be available 14 or = 28 days after DVD release, or whether a given resolution is "too high" = for a particular user or terminal.=20 >=20 > Also, the paragraph keeps talking about "dCDN selection or Surrogate = selection" may fail for some fancy policy reasons. I don't understand = what it means to "fail" , but more importantly again, I don't think we = want CDN request routing decisions to be factoring very fancy CSP policy = rules. > Do we agree or not? >=20 > The last paragraphs gives examples of the CSP objectives of supporting = delivery policies in CDNs, and those are fine and can be achieved with = the set of mechanisms discussed above (i.e. goeblocking + time window + = URI signing). >=20 >=20 > Suggestions for improvements > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > ***Abstract > replace "CDNI" by "CDN Interconnection". >=20 > *** section 1: > expand the first instance of CDNI into "CDN Interconnection (CDNI)". >=20 > *** section 1: > "Then, the document highlights the need for interoperability to > exchange and enforce content delivery policies (Section 5)." > I'd suggest replacing "for interoperability to exchange" by "for = interoperability to allow exchange" or by "for interoperability in order = to exchange" >=20 > *** section 1.1: > Do you feel that the two additional terms are really specific to the = use-case document (in which case their definition should stay in this = document) or are they likely useful in other documents (in which case = their definition should be migrated to the framework document)? > Personally, I would say that those terms might be useful in other = documents/discussions (eg I am pretty sure we'd need to refer to the = "Delivering CDN" in other context). >=20 > *** section 1.1: > "Access CDN: > A CDN that is directly connected to the End User's access." > I think this definition needs to be a little more specific. "Directly = connected" does not mean "L2 connectivity" (because an on-net cache = maybe a few L2 hops away), nor does it mean "L3 connectivity" (because = an OTT CDN cache has IP connectivity to an enduser). I think you mean = something in between, more or less that the CDN and the access are = within the same IP administrative domain, or something close to that. = Can you try refine that definition? >=20 > *** section 1.3: > " o improve the experience for the End User; for instance delivery = has > lower latency (decreased round-trip-time between the user and the > delivery server) and better robustness," > To be more comprehensive in justifying the claims, how about: > " o improve the experience for the End User; for instance delivery = has > lower latency (decreased round-trip-time and higher throughput = between the user and the > delivery server) and better robustness (ability to use multiple = delivery servers)," >=20 > *** section 1.3: > "o reduce the Content Service Provider's (CSP) costs, such as > datacenter capacity, space, and electricity consumption, as > popular content is delivered through the CDN rather than through > the CSP's servers." > The current wording raises the question of "if it reduces the costs by = reducing expenses in the CSP datacenter, why does it not correspondingly = increase the cost by increasing expenses in the CDN (which the CDN = provider then charges back to the CSP)?" > I think the gain is in the scale and effective pooling of CDN = resources across many CSPs. Could you refine the wording to explain why = there is indeed a net gain? >=20 > *** section 1.3: > Replace: > " > An example is depicted in Figure 1. Two CDN Providers establish a CDN = Interconnection. > " > with: > " > An example is depicted in Figure 1 where two CDN Providers establish a = CDN Interconnection. > " > (this is to minimize the redundancy with the sentence coming below: = "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their = CDNs.") >=20 >=20 > *** section 1.3: > replace: > " > "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their = CDNs." > with: > "Independently, CDN Provider 'A' and CDN Provider 'B' agree to = interconnect their CDNs." > this is to clarify that the A<->B agreement is not specific to the = 1<->A agreement >=20 >=20 > *** section 1.3: > replace: > " > When a User Agent requests content from CSP-1, CDN-A considers that = delivery by CDN-B is appropriate " > with: > " > When a given User Agent requests content from CSP-1, CDN-A may = consider that delivery by CDN-B is appropriate " >=20 >=20 > *** section 1.3: > replace: > " > CDN-A has delegated the handling of requests for CSP-1's content = through the CDN Interconnection agreement, thus, the content is actually = delivered from CDN-B. > " > with: > " > Through the CDN Interconnection arrangements put in place between = CDN-A and CDN-B (as a result of the CDN Interconnection agreement = established between CDN Provider 'A' and CDN Provider 'B'), CDN-A can = redirect the request to CDN-B and the content is actually delivered to = the User Agent by CDN-B. > " > (the current wording suggests that all deliveries of CSP1 content = would be handled by CDN-B, which is typically not the case i.e. only a = subset of the requests are redirected thy CDN-A to CDN-B)=20 >=20 >=20 > *** section 1.3: > replace: > " > CSP-1 benefits because it only needs to make one business agreement = and one physical connection, with CDN Provider 'A' > " > with: > " > CSP-1 benefits because it only needs to make one business agreement = and one technical arrangement with CDN Provider 'A' > " > (this is because the interfacing between CSP and uCDN comprises more = than "physical connection"). >=20 >=20 > *** section 1.3: > replace: > " > CSP-1 had also gone to the trouble of making a business agreement with = CDN Provider 'B' > " > with: > " > CSP-1 had also gone to the trouble of making a business agreement and = technical arrangemement with CDN Provider 'B' > " >=20 > *** section 1.3: > replace: > " > But it does not want > " > with: > " > However, CSP-2 may not want > " >=20 > *** section 2.1: > after > " > o without incurring additional transit and other network costs that > would result from serving content from geographically or > topologically remote Surrogates. > " > add: > " > o without incurring the cost of deploying and operating Surrogates and = the associated CDN infrastructure that may not be justified in the = corresponding geographic region (e.g. because of relatively low delivery = volume, or conversely because of the high investments that would be = needed to satisfy the high volume) " >=20 >=20 > *** section 2.2: > replace: > " > A large CDN Provider may also operate CDNs from several subsidiaries = (which may rely on different CDN technologies, see Section 4.2). In = certain circumstances, the CDN Provider needs to make its CDNs = interoperate to provide a consistent service to its customers on its = whole footprint. > " > with: > " > A large CDN Provider may have several subsidiaries that also each = operate their own CDN (which may rely on different CDN technologies, see = Section 4.2). In certain circumstances, the CDN Provider needs to make = these CDNs interoperate to provide a consistent service to its customers = on the whole collective footprint.=20 > " >=20 >=20 > *** section 2.3: > replace: > " > injected into the access network > " > with: > " > injected into the ISP network > " >=20 > *** section 2.3: > replace: > " > There are mutual benefits to the Access CDN, > " > with: > " > There are mutual benefits to the ISP (acting as an Access CDN), > " >=20 >=20 > *** section 2.3: > replace: > " > for example, QoS and reduced round trip time. > " > with: > " > for example, reduced content startup time or increased video quality = and resolution of adaptive streaming content. > " > (I don't think RTT is very meaningful to a CSP customer) >=20 >=20 > *** section 2.4: > The nomadic user is currently defined as "moving between CDNs" which = is sort of a self-serving definition to justify CDN interconnection. I = think we should rather define the nomadic user as "moving between access = networks" and then justify that leveraging local CDNs can bring a lot of = benefits. > This requires the following text edits: > s/who move between CDNs/who move between access networks/ > s/moving between different CDN Providers/moving between different = access networks/ >=20 > *** section 2.4: > replace: > " > which may reside > " > with: > " > which may be located > " >=20 > *** section 2.4:" > I propose to remove the sentence: > " > The term "Nomadic" does not necessarily relate to geographic roaming. > " > because this point has already been fully (and better) clarified in = the preceding paragraph. >=20 >=20 >=20 > *** section 2.4: > replace: > " > the WiFi or mobile provider > " > with: > " > the WiFi or mobile provider (NSP B) > " >=20 >=20 > *** section 3.1: > replace: > " > needs CDN capacities > " > with: > " > needs CDN capacity > " >=20 > *** section 3.2.1: > The text mentions two options (use OS, use another CDN). I think the = section shoudl probably also mention the most obvious option (i.e. use = other surrogates in the same CDN). Or alternatively, clarify that the = considered situation is where there is a partial failure of some = surrogates resulting in the remaining surrogates being fully loaded. >=20 >=20 > *** section 3.2.1: > replace: > " > to both distribute load between origin servers and attempt content = acquisition from alternate origin servers when acquisition failures = occur. When normal content acquisition fails, a CDN may need to try = other origin server options, > " > with: > " > to both distribute load between content sources and attempt content = acquisition from alternate content sources when acquisition failures = occur. When normal content acquisition fails, a CDN may need to try = other content source options, > " > (I believe everywhere else we use "origin server" to refer to the OS = of the CSP and "content source" as the generic term for getting content = including origin server and uCDN) >=20 > *** section 3.2.2: > replace: > " > the selection of content acquisition sources should be considered. > " > with: > " > the selection of content acquisition sources should be considered and = facilitated. > " > (i.e. it is not just a matter of "thinking" about it: it must be = explicitly allowed or at leads made easier). >=20 >=20 > *** section 4.1: > "to serve a proportion of its traffic that requires HTTPS." > can you include a reference for HTTPS? >=20 >=20 > *** section 5: > replace: > " > An important aspect of the above use cases > " > with: > " > An important aspect common to all the above use cases > " >=20 >=20 > *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line = 618, but no explicit reference was found in the text > I'd suggest you add an explicit reference. For example, in "1. = Introduction" you could replace: > " > The document can be used to guide the definition of the requirements = to be supported by the various CDNI interfaces defined in = [I-D.ietf-cdni-problem-statement]. > " > by > " > The document can be used to guide the definition of the requirements = (as documented in [I-D.ietf-cdni-requirements]) to be supported by the = set of CDNI interfaces defined in [I-D.ietf-cdni-problem-statement]. > " > (BTW, independely of the reference issue, "the set of CDNI interfaces" = might read better than "the various CDNI interfaces"). >=20 >=20 > *** The document has a disclaimer for pre-RFC5378 work, but was first = submitted on or after 10 November 2008. Does it really need the = disclaimer? > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From lpeterson@verivue.com Wed May 9 10:06:08 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F050521F854E for ; Wed, 9 May 2012 10:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_MUTUALBENEFIT=2, J_BACKHAIR_11=1, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2dJa2pVzzMM for ; Wed, 9 May 2012 10:06:07 -0700 (PDT) Received: from exprod8og112.obsmtp.com (exprod8og112.obsmtp.com [64.18.3.24]) by ietfa.amsl.com (Postfix) with SMTP id 91EB321F854D for ; Wed, 9 May 2012 10:06:05 -0700 (PDT) Received: from vvexch.verivue.com ([38.83.192.68]) by exprod8ob112.postini.com ([64.18.7.12]) with SMTP ID DSNKT6qj/J9lg6XtK+UuIS1aE07bVyCeTn7M@postini.com; Wed, 09 May 2012 10:06:06 PDT Received: from vvexch.verivue.com ([10.160.6.20]) by vvexch.verivue.com ([10.160.6.20]) with mapi; Wed, 9 May 2012 13:06:00 -0400 From: "Peterson, Larry" To: Francois Le Faucheur Date: Wed, 9 May 2012 13:05:59 -0400 Thread-Topic: Two additional definitions for cdni-framework Thread-Index: Ac0uBgGqXBYFgxrOT8WR+9bvfX6MQQ== Message-ID: <3BE12F3B-51F6-4524-BBD2-C152C4F1F4C0@verivue.com> References: <5388986F-034F-4E38-A5A3-78B6E30F56A5@cisco.com> <8E09C72DBC577D489F13A71228C0B7BF035ED73B@ftrdmel0.rd.francetelecom.fr> <89ACE04E-3414-4D68-9106-97FF36AE2F2B@cisco.com> In-Reply-To: <89ACE04E-3414-4D68-9106-97FF36AE2F2B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Wed, 09 May 2012 17:06:09 -0000 Yes... Generally, it would be good to do a survey of terminology various docs have introduced recently, and converge on the core definitions. Larry On May 9, 2012, at 11:47 AM, Francois Le Faucheur wrote: > Hi Larry, > > Can you confirm this can be done in next rev of cdni-framework? > > Tx > > Francois > > > On 9 May 2012, at 17:19, wrote: > >> Hi Fran=E7ois, >> >> Thanks for your review. We are integrating your comments. >> >> About your comments on Section 1.1, I definitely think the terms "Access= CDN" and "Delivering CDN" are useful more broadly than just in the use cas= es document. Therefore, I would be in favor of moving them to the framework= document as you propose. >> >> Access CDN: >> A CDN that includes Surrogates in the same network (e.g., same Aut= onomous System) as the End User. An Access CDN may have specific informatio= n about >> the End User and the network, for instance, End User's >> profile and access capabilities. >> >> Delivering CDN: >> The CDN that delivers the requested piece of content to >> the End User. In particular, the Delivering CDN can be an >> Access CDN. >> >> >> Best regards, >> >> Gilles >> >> >> -----Message d'origine----- >> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de = Francois Le Faucheur >> Envoy=E9 : mercredi 25 avril 2012 18:46 >> =C0 : draft-ietf-cdni-use-cases@tools.ietf.org >> Cc : cdni@ietf.org >> Objet : [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases >> >> To use-cases authors, >> >> Below are my shepherd review comments of cdni-uses-cases. >> >> I think the document is in a good shape and captures well the key target= ed use cases. >> I identified two remaining significant points to be addressed, and also = have included many suggestions to improve the document. >> I suggest we resolve the two significant points on the list and leave it= to editor/authors to decide how to dispose of the suggestions for improvem= ent offline. >> >> Cheers >> >> Francois >> >> >> Significant points >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> *** section 8 security considerations >> I have a few specific issues with the current text of the Security Consi= derations section. But I don't really see the need to have an expanded Secu= rity Considerations section in both the use-case document and the problem-s= tatement (particularly considering that the first IESG review comments on p= roblem-statement suggest expanding the security considerations section ther= e), in particular because the security considerations currently brought up = in use-cases are not specific to individual use cases bur rather generic to= the whole CDN interconnection problem space. >> So my proposal would be to remove the whole discussion from use-cases (i= .e. the first 4 paragraphs) and refer to the Security Considerations sectio= n of the Problem Statement e.g.. by replacing: >> " >> This document focuses on the motivational use cases for CDN Interconnect= ion, and does not analyze these threats in detail. >> " >> with: >> " >> This document focuses on the motivational use cases for CDN Interconnect= ion, and does not analyze the associated threats. Those are discussed in [I= -D.ietf-cdni-problem-statement]. >> " >> >> >> ***section A.1: >> I still have a problem with the text of that section. >> I thought we had converged on an agreement that the text would: >> * explain that CSPs may take into account very multiple/arbitrary/s= pecific criteria in their policy >> * explain that the CDNs are only expected to enforce a few specific= policy rules (e.g. geo-blocking, time window) and for enforcement of all f= ancy CSP policy we propose that the responsibilities be divided into (1) th= e CSP being responsible for the fancy policy decision and (ii) the CDN for = merely enforcing the CSP decision without having to understand the policy (= e.g. via URI signing). >> Do we not agree on that or not? >> >> The current text says that CDN selection and surrogate selection "are in= fluenced by these policies" (referring to the fancy CSP policies). I do not= agree with that. I don;t think we want CDN Selection or Surrogate selectio= n to be influenced by whether a movie shoudl be available 14 or 28 days aft= er DVD release, or whether a given resolution is "too high" for a particula= r user or terminal. >> >> Also, the paragraph keeps talking about "dCDN selection or Surrogate sel= ection" may fail for some fancy policy reasons. I don't understand what it = means to "fail" , but more importantly again, I don't think we want CDN req= uest routing decisions to be factoring very fancy CSP policy rules. >> Do we agree or not? >> >> The last paragraphs gives examples of the CSP objectives of supporting d= elivery policies in CDNs, and those are fine and can be achieved with the s= et of mechanisms discussed above (i.e. goeblocking + time window + URI sign= ing). >> >> >> Suggestions for improvements >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> ***Abstract >> replace "CDNI" by "CDN Interconnection". >> >> *** section 1: >> expand the first instance of CDNI into "CDN Interconnection (CDNI)". >> >> *** section 1: >> "Then, the document highlights the need for interoperability to >> exchange and enforce content delivery policies (Section 5)." >> I'd suggest replacing "for interoperability to exchange" by "for interop= erability to allow exchange" or by "for interoperability in order to exchan= ge" >> >> *** section 1.1: >> Do you feel that the two additional terms are really specific to the use= -case document (in which case their definition should stay in this document= ) or are they likely useful in other documents (in which case their definit= ion should be migrated to the framework document)? >> Personally, I would say that those terms might be useful in other docume= nts/discussions (eg I am pretty sure we'd need to refer to the "Delivering = CDN" in other context). >> >> *** section 1.1: >> "Access CDN: >> A CDN that is directly connected to the End User's access." >> I think this definition needs to be a little more specific. "Directly co= nnected" does not mean "L2 connectivity" (because an on-net cache maybe a f= ew L2 hops away), nor does it mean "L3 connectivity" (because an OTT CDN ca= che has IP connectivity to an enduser). I think you mean something in betwe= en, more or less that the CDN and the access are within the same IP admini= strative domain, or something close to that. Can you try refine that defini= tion? >> >> *** section 1.3: >> " o improve the experience for the End User; for instance delivery has >> lower latency (decreased round-trip-time between the user and the >> delivery server) and better robustness," >> To be more comprehensive in justifying the claims, how about: >> " o improve the experience for the End User; for instance delivery has >> lower latency (decreased round-trip-time and higher throughput betwee= n the user and the >> delivery server) and better robustness (ability to use multiple deliv= ery servers)," >> >> *** section 1.3: >> "o reduce the Content Service Provider's (CSP) costs, such as >> datacenter capacity, space, and electricity consumption, as >> popular content is delivered through the CDN rather than through >> the CSP's servers." >> The current wording raises the question of "if it reduces the costs by r= educing expenses in the CSP datacenter, why does it not correspondingly inc= rease the cost by increasing expenses in the CDN (which the CDN provider th= en charges back to the CSP)?" >> I think the gain is in the scale and effective pooling of CDN resources = across many CSPs. Could you refine the wording to explain why there is inde= ed a net gain? >> >> *** section 1.3: >> Replace: >> " >> An example is depicted in Figure 1. Two CDN Providers establish a CDN I= nterconnection. >> " >> with: >> " >> An example is depicted in Figure 1 where two CDN Providers establish a C= DN Interconnection. >> " >> (this is to minimize the redundancy with the sentence coming below: "CDN= Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs.") >> >> >> *** section 1.3: >> replace: >> " >> "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs.= " >> with: >> "Independently, CDN Provider 'A' and CDN Provider 'B' agree to interconn= ect their CDNs." >> this is to clarify that the A<->B agreement is not specific to the 1<->A= agreement >> >> >> *** section 1.3: >> replace: >> " >> When a User Agent requests content from CSP-1, CDN-A considers that deli= very by CDN-B is appropriate " >> with: >> " >> When a given User Agent requests content from CSP-1, CDN-A may consider = that delivery by CDN-B is appropriate " >> >> >> *** section 1.3: >> replace: >> " >> CDN-A has delegated the handling of requests for CSP-1's content through= the CDN Interconnection agreement, thus, the content is actually delivered= from CDN-B. >> " >> with: >> " >> Through the CDN Interconnection arrangements put in place between CDN-A = and CDN-B (as a result of the CDN Interconnection agreement established bet= ween CDN Provider 'A' and CDN Provider 'B'), CDN-A can redirect the request= to CDN-B and the content is actually delivered to the User Agent by CDN-B. >> " >> (the current wording suggests that all deliveries of CSP1 content would = be handled by CDN-B, which is typically not the case i.e. only a subset of = the requests are redirected thy CDN-A to CDN-B) >> >> >> *** section 1.3: >> replace: >> " >> CSP-1 benefits because it only needs to make one business agreement and = one physical connection, with CDN Provider 'A' >> " >> with: >> " >> CSP-1 benefits because it only needs to make one business agreement and = one technical arrangement with CDN Provider 'A' >> " >> (this is because the interfacing between CSP and uCDN comprises more tha= n "physical connection"). >> >> >> *** section 1.3: >> replace: >> " >> CSP-1 had also gone to the trouble of making a business agreement with C= DN Provider 'B' >> " >> with: >> " >> CSP-1 had also gone to the trouble of making a business agreement and te= chnical arrangemement with CDN Provider 'B' >> " >> >> *** section 1.3: >> replace: >> " >> But it does not want >> " >> with: >> " >> However, CSP-2 may not want >> " >> >> *** section 2.1: >> after >> " >> o without incurring additional transit and other network costs that >> would result from serving content from geographically or >> topologically remote Surrogates. >> " >> add: >> " >> o without incurring the cost of deploying and operating Surrogates and t= he associated CDN infrastructure that may not be justified in the correspon= ding geographic region (e.g. because of relatively low delivery volume, or = conversely because of the high investments that would be needed to satisfy = the high volume) " >> >> >> *** section 2.2: >> replace: >> " >> A large CDN Provider may also operate CDNs from several subsidiaries (wh= ich may rely on different CDN technologies, see Section 4.2). In certain ci= rcumstances, the CDN Provider needs to make its CDNs interoperate to provid= e a consistent service to its customers on its whole footprint. >> " >> with: >> " >> A large CDN Provider may have several subsidiaries that also each operat= e their own CDN (which may rely on different CDN technologies, see Section = 4.2). In certain circumstances, the CDN Provider needs to make these CDNs i= nteroperate to provide a consistent service to its customers on the whole c= ollective footprint. >> " >> >> >> *** section 2.3: >> replace: >> " >> injected into the access network >> " >> with: >> " >> injected into the ISP network >> " >> >> *** section 2.3: >> replace: >> " >> There are mutual benefits to the Access CDN, >> " >> with: >> " >> There are mutual benefits to the ISP (acting as an Access CDN), >> " >> >> >> *** section 2.3: >> replace: >> " >> for example, QoS and reduced round trip time. >> " >> with: >> " >> for example, reduced content startup time or increased video quality and= resolution of adaptive streaming content. >> " >> (I don't think RTT is very meaningful to a CSP customer) >> >> >> *** section 2.4: >> The nomadic user is currently defined as "moving between CDNs" which is = sort of a self-serving definition to justify CDN interconnection. I think w= e should rather define the nomadic user as "moving between access networks"= and then justify that leveraging local CDNs can bring a lot of benefits. >> This requires the following text edits: >> s/who move between CDNs/who move between access networks/ >> s/moving between different CDN Providers/moving between different access= networks/ >> >> *** section 2.4: >> replace: >> " >> which may reside >> " >> with: >> " >> which may be located >> " >> >> *** section 2.4:" >> I propose to remove the sentence: >> " >> The term "Nomadic" does not necessarily relate to geographic roaming. >> " >> because this point has already been fully (and better) clarified in the = preceding paragraph. >> >> >> >> *** section 2.4: >> replace: >> " >> the WiFi or mobile provider >> " >> with: >> " >> the WiFi or mobile provider (NSP B) >> " >> >> >> *** section 3.1: >> replace: >> " >> needs CDN capacities >> " >> with: >> " >> needs CDN capacity >> " >> >> *** section 3.2.1: >> The text mentions two options (use OS, use another CDN). I think the sec= tion shoudl probably also mention the most obvious option (i.e. use other s= urrogates in the same CDN). Or alternatively, clarify that the considered s= ituation is where there is a partial failure of some surrogates resulting i= n the remaining surrogates being fully loaded. >> >> >> *** section 3.2.1: >> replace: >> " >> to both distribute load between origin servers and attempt content acqui= sition from alternate origin servers when acquisition failures occur. When= normal content acquisition fails, a CDN may need to try other origin serve= r options, >> " >> with: >> " >> to both distribute load between content sources and attempt content acqu= isition from alternate content sources when acquisition failures occur. Wh= en normal content acquisition fails, a CDN may need to try other content so= urce options, >> " >> (I believe everywhere else we use "origin server" to refer to the OS of = the CSP and "content source" as the generic term for getting content includ= ing origin server and uCDN) >> >> *** section 3.2.2: >> replace: >> " >> the selection of content acquisition sources should be considered. >> " >> with: >> " >> the selection of content acquisition sources should be considered and fa= cilitated. >> " >> (i.e. it is not just a matter of "thinking" about it: it must be explici= tly allowed or at leads made easier). >> >> >> *** section 4.1: >> "to serve a proportion of its traffic that requires HTTPS." >> can you include a reference for HTTPS? >> >> >> *** section 5: >> replace: >> " >> An important aspect of the above use cases >> " >> with: >> " >> An important aspect common to all the above use cases >> " >> >> >> *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line 61= 8, but no explicit reference was found in the text >> I'd suggest you add an explicit reference. For example, in "1. Introduc= tion" you could replace: >> " >> The document can be used to guide the definition of the requirements to = be supported by the various CDNI interfaces defined in [I-D.ietf-cdni-probl= em-statement]. >> " >> by >> " >> The document can be used to guide the definition of the requirements (as= documented in [I-D.ietf-cdni-requirements]) to be supported by the set of = CDNI interfaces defined in [I-D.ietf-cdni-problem-statement]. >> " >> (BTW, independely of the reference issue, "the set of CDNI interfaces" m= ight read better than "the various CDNI interfaces"). >> >> >> *** The document has a disclaimer for pre-RFC5378 work, but was first s= ubmitted on or after 10 November 2008. Does it really need the disclaimer? >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni > From kevin.ma@azukisystems.com Wed May 9 16:32:42 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C3711E80AF for ; Wed, 9 May 2012 16:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_MUTUALBENEFIT=2, J_BACKHAIR_11=1, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKL-9xyS69Pb for ; Wed, 9 May 2012 16:32:40 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 3B76611E80AA for ; Wed, 9 May 2012 16:32:34 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id DC9638BF088; Wed, 9 May 2012 19:32:07 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 94D0A8BF0DC; Wed, 9 May 2012 19:32:06 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Wed, 9 May 2012 19:31:46 -0400 From: Kevin J Ma To: Francois Le Faucheur Date: Wed, 9 May 2012 19:32:04 -0400 Thread-Topic: Tie between Request-Routing and policy Re: [CDNi] Document Shepherd review of draft-ietf-cdni-use-cases Thread-Index: Ac0qCpjPdVex+wI2TRexMENwSQ3KHgEJQ0rA Message-ID: <291CC3F9E50E7641901A54E85D0977C65260E2D1BF@MAILR002.mail.lan> References: <5388986F-034F-4E38-A5A3-78B6E30F56A5@cisco.com> <291CC3F9E50E7641901A54E85D0977C65260C10A37@MAILR002.mail.lan> <5C88F9C0-F28D-4B77-88AA-3D9058E8FE8A@cisco.com> In-Reply-To: <5C88F9C0-F28D-4B77-88AA-3D9058E8FE8A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-cdni-use-cases@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] Tie between Request-Routing and policy Re: Document Shepherd review of draft-ietf-cdni-use-cases X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss 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, 09 May 2012 23:32:42 -0000 Hi Francois, > * to allow flexibility in the future (e.g. to allow introduction of > additional policies in subsequent versions of CDNI), let's rely on the > "Capabilities Advertisement" of the Request Routing interface. Just to clarify, are you proposing that the list of supported metadata are exchanged in the RR capabilities, but, the metadata would still be applied to the individual (or groups of) content items? I would agree with this, noting that the actual metadata value applied to any given content asset may still be rejected later. > * in any case, we have the "escape" mechanism I agree that rejection support (per the META-13 requirement) is needed. > levels of granularity; for example, the dCDN may allow a dCDN to say "I > support the delivery policies defined in CDNI v1" or "I support the > delivery policies defined in CDNI v1 and in CDNIv2" or, if needed, "I > support the delivery policies defined in CDNI v1 and the 1st subset of > delivery policies defined in CDNIv2 but not the 2nd subset". These examples concern me in that they might imply that only those policies (and therefore only those metadata) officially blessed by the CDNI working group will be allowed. I would think that there should be a way to include opaque and vendor defined metadata with the capabilities advertisement as well. > I understand this to mean that dCDN selection by the uCDN is supped to > take into account things like whether a given resolution is deemed to hig= h > by the CSP for delivery via a CDN. The intent was to show that CP may have policies that they wish to enforce. If a CP has a resolution policy, this is not to imply that the CDN needs to know the resolution, only that the CP may be motivated by something like resolution, to define a policy. > Again, to me the whole point of that section is precisely to clarify that > CSPs may have fancy policies and that those can be enforced in a multi-CD= N > environment without having to make these fancy policy understood by the > CDNs. I agree with this statement. > The current text is suggesting quite the opposite to me. Or maybe I > am misreading it. We will address this. thanx. -- Kevin J. Ma > -----Original Message----- > From: Francois Le Faucheur [mailto:flefauch@cisco.com] > Sent: Friday, May 04, 2012 11:28 AM > To: Kevin J Ma > Cc: Francois Le Faucheur; draft-ietf-cdni-use-cases@tools.ietf.org; > cdni@ietf.org > Subject: Tie between Request-Routing and policy Re: [CDNi] Document > Shepherd review of draft-ietf-cdni-use-cases > > Hi Kevin, > > I think the discussion below touches on two topics: > *A* delivery policies to be communicated and enforced by a dCDN > *B* potential interactions between request-routing and the ability > of a CDN to enforce an aspect of policy > > Regarding *A*, I expressed my thoughts in http://www.ietf.org/mail- > archive/web/cdni/current/msg00988.html. Please let me know if that makes > sense to you. > > Regarding *B*: So I think your concern is "how do we deal with potential > situations where an uCDN may redirect a request to a dCDN that is not > capable to enforce all aspects of the distribution policy?". That is a > good point. > My proposal would be: > * let's settle on a small set of well-defined policies (as discusse= d > in http://www.ietf.org/mail-archive/web/cdni/current/msg00988.html.) such > as geoblocking + time-window + pre-authrization-enforcement (e.g. URI > signing), then we may virtually eliminate the situation altogether in the > common cases (at least in the initial incarnation of the CDNI solution) > since all dCDNs could support that set of policies (i.e. they would be > mandatory) > * to allow flexibility in the future (e.g. to allow introduction of > additional policies in subsequent versions of CDNI), let's rely on the > "Capabilities Advertisement" of the Request Routing interface. This would > allow the dCDN to advertise to the uCDN what sort of capabilities it > supports in the area of distribution policy enforcement. The design team > will look into the details of those but they might come at different > levels of granularity; for example, the dCDN may allow a dCDN to say "I > support the delivery policies defined in CDNI v1" or "I support the > delivery policies defined in CDNI v1 and in CDNIv2" or, if needed, "I > support the delivery policies defined in CDNI v1 and the 1st subset of > delivery policies defined in CDNIv2 but not the 2nd subset". This can be > factored by the uCDN Request Routing system (e.g. it can consider the > metadata and based on those could decide to consider the dCDN advertised > policy capabilities). I am not sure we need that sort of things for our > initial CDNI solution, but arguably that depends on if we can settle for = a > single set of delivery policies that we all make mandatory. > * in any case, we have the "escape" mechanism discussed by Larry in > Paris: if a dCDN is explicitly told so, or if it is not capable of > enforcing a particular policy aspect requested in the metadata, then it > can do a per-request authorization check into the uCDN. > > Do you agree with the above? > > To your specific question about my concern with the current text. I just > don't get the point it is trying to make. For example it says: > " > dCDN delegation and Surrogate selection decisions are influenced by > these policies: > > ... > o dCDN delegation may fail if the content resolution has been > specified by the CSP as being too high for distribution via the > dCDN, > " > =03I understand this to mean that dCDN selection by the uCDN is supped to > take into account things like whether a given resolution is deemed to hig= h > by the CSP for delivery via a CDN. > I disagree with this. The uCDN should not have to be aware of that sort o= f > policies. All it would know is whether a content is to be delivered or no= t > (it really does not care whether this is because of excessively good > resolution or any CSP-meaningful but CDN-meaningless reasons). > > Again, to me the whole point of that section is precisely to clarify that > CSPs may have fancy policies and that those can be enforced in a multi-CD= N > environment without having to make these fancy policy understood by the > CDNs. The current text is suggesting quite the opposite to me. Or maybe I > am misreading it. > > Cheers > > Francois > > > On 26 Apr 2012, at 23:46, Kevin J Ma wrote: > > > Hi Francois, > > > >> * explain that the CDNs are only expected to enforce a few > specific > >> policy rules (e.g. geo-blocking, time window) and for enforcement of > all > >> fancy CSP policy we propose that the responsibilities be divided into > (1) > >> the CSP being responsible for the fancy policy decision and (ii) the > CDN > >> for merely enforcing the CSP decision without having to understand the > >> policy (e.g. via URI signing). > >> Do we not agree on that or not? > > > > I agree that the CDN should enforce any policy that is defined in > metadata. > > If a supported metadata dictates a restriction, regardless of any > individual > > interpretation of the semantic fanciness, the restriction should be > enforced. > > If a dCDN does not support a given metadata, it can express that to the > uCDN, > > which should influence the inter-CDN request routing. > > > >> Also, the paragraph keeps talking about "dCDN selection or Surrogate > >> selection" may fail for some fancy policy reasons. I don't understand > what > >> it means to "fail", but more importantly again, I don't think we want > CDN > >> request routing decisions to be factoring very fancy CSP policy rules. > >> Do we agree or not? > > > > The failure could probably be a more generic delivery failure, due to > > restrictions defined in the metadata, though, the framework document > > shows the metadata checks as part of request routing decision making > > which presumably influences dCDN/Surrogate selection? > > > > The fanciness of the policy should not matter, as long as the > > metadata which conveys the enforcement of that policy is clear and > > succinct. The inter-CDN request routing should be aware of the > > capabilities of each dCDN and not delegate to dCDNs that lack support > > for capabilities which are deemed mandatory. > > > > The use cases do not dictate any specific implementations. They do not > > require request routing to implement fancy policy rules. A valid > > implementation could wrap all the fancy policy rules into a nice neat > > boolean value. An equally valid implementation could implement extra > > super fancy policy rules. The use case does not mandate one or the > other. > > > > Is the concern that specific portions are not valid, or that the > descriptions > > are unclear, or is the concern about an assumed implementation's > fanciness? > > > > thanx. > > > > -- Kevin J. Ma > > > >> -----Original Message----- > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf O= f > >> Francois Le Faucheur > >> Sent: Wednesday, April 25, 2012 12:46 PM > >> To: draft-ietf-cdni-use-cases@tools.ietf.org > >> Cc: cdni@ietf.org > >> Subject: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases > >> > >> To use-cases authors, > >> > >> Below are my shepherd review comments of cdni-uses-cases. > >> > >> I think the document is in a good shape and captures well the key > targeted > >> use cases. > >> I identified two remaining significant points to be addressed, and als= o > >> have included many suggestions to improve the document. > >> I suggest we resolve the two significant points on the list and leave > it > >> to editor/authors to decide how to dispose of the suggestions for > >> improvement offline. > >> > >> Cheers > >> > >> Francois > >> > >> > >> Significant points > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> *** section 8 security considerations > >> I have a few specific issues with the current text of the Security > >> Considerations section. But I don't really see the need to have an > >> expanded Security Considerations section in both the use-case document > and > >> the problem-statement (particularly considering that the first IESG > review > >> comments on problem-statement suggest expanding the security > >> considerations section there), in particular because the security > >> considerations currently brought up in use-cases are not specific to > >> individual use cases bur rather generic to the whole CDN > interconnection > >> problem space. > >> So my proposal would be to remove the whole discussion from use-cases > >> (i.e. the first 4 paragraphs) and refer to the Security Considerations > >> section of the Problem Statement e.g.. by replacing: > >> " > >> This document focuses on the motivational use cases for CDN > >> Interconnection, and does not analyze these threats in detail. > >> " > >> with: > >> " > >> This document focuses on the motivational use cases for CDN > >> Interconnection, and does not analyze the associated threats. Those ar= e > >> discussed in [I-D.ietf-cdni-problem-statement]. > >> " > >> > >> > >> ***section A.1: > >> I still have a problem with the text of that section. > >> I thought we had converged on an agreement that the text would: > >> * explain that CSPs may take into account very > >> multiple/arbitrary/specific criteria in their policy > >> * explain that the CDNs are only expected to enforce a few > specific > >> policy rules (e.g. geo-blocking, time window) and for enforcement of > all > >> fancy CSP policy we propose that the responsibilities be divided into > (1) > >> the CSP being responsible for the fancy policy decision and (ii) the > CDN > >> for merely enforcing the CSP decision without having to understand the > >> policy (e.g. via URI signing). > >> Do we not agree on that or not? > >> > >> The current text says that CDN selection and surrogate selection "are > >> influenced by these policies" (referring to the fancy CSP policies). I > do > >> not agree with that. I don;t think we want CDN Selection or Surrogate > >> selection to be influenced by whether a movie shoudl be available 14 o= r > 28 > >> days after DVD release, or whether a given resolution is "too high" fo= r > a > >> particular user or terminal. > >> > >> Also, the paragraph keeps talking about "dCDN selection or Surrogate > >> selection" may fail for some fancy policy reasons. I don't understand > what > >> it means to "fail" , but more importantly again, I don't think we want > CDN > >> request routing decisions to be factoring very fancy CSP policy rules. > >> Do we agree or not? > >> > >> The last paragraphs gives examples of the CSP objectives of supporting > >> delivery policies in CDNs, and those are fine and can be achieved with > the > >> set of mechanisms discussed above (i.e. goeblocking + time window + UR= I > >> signing). > >> > >> > >> Suggestions for improvements > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> ***Abstract > >> replace "CDNI" by "CDN Interconnection". > >> > >> *** section 1: > >> expand the first instance of CDNI into "CDN Interconnection (CDNI)". > >> > >> *** section 1: > >> "Then, the document highlights the need for interoperability to > >> exchange and enforce content delivery policies (Section 5)." > >> I'd suggest replacing "for interoperability to exchange" by "for > >> interoperability to allow exchange" or by "for interoperability in > order > >> to exchange" > >> > >> *** section 1.1: > >> Do you feel that the two additional terms are really specific to the > use- > >> case document (in which case their definition should stay in this > >> document) or are they likely useful in other documents (in which case > >> their definition should be migrated to the framework document)? > >> Personally, I would say that those terms might be useful in other > >> documents/discussions (eg I am pretty sure we'd need to refer to the > >> "Delivering CDN" in other context). > >> > >> *** section 1.1: > >> "Access CDN: > >> A CDN that is directly connected to the End User's access." > >> I think this definition needs to be a little more specific. "Directly > >> connected" does not mean "L2 connectivity" (because an on-net cache > maybe > >> a few L2 hops away), nor does it mean "L3 connectivity" (because an OT= T > >> CDN cache has IP connectivity to an enduser). I think you mean > something > >> in between, more or less that the CDN and the access are within the > same > >> IP administrative domain, or something close to that. Can you try > refine > >> that definition? > >> > >> *** section 1.3: > >> " o improve the experience for the End User; for instance delivery ha= s > >> lower latency (decreased round-trip-time between the user and the > >> delivery server) and better robustness," > >> To be more comprehensive in justifying the claims, how about: > >> " o improve the experience for the End User; for instance delivery ha= s > >> lower latency (decreased round-trip-time and higher throughput > >> between the user and the > >> delivery server) and better robustness (ability to use multiple > >> delivery servers)," > >> > >> *** section 1.3: > >> "o reduce the Content Service Provider's (CSP) costs, such as > >> datacenter capacity, space, and electricity consumption, as > >> popular content is delivered through the CDN rather than through > >> the CSP's servers." > >> The current wording raises the question of "if it reduces the costs by > >> reducing expenses in the CSP datacenter, why does it not > correspondingly > >> increase the cost by increasing expenses in the CDN (which the CDN > >> provider then charges back to the CSP)?" > >> I think the gain is in the scale and effective pooling of CDN resource= s > >> across many CSPs. Could you refine the wording to explain why there is > >> indeed a net gain? > >> > >> *** section 1.3: > >> Replace: > >> " > >> An example is depicted in Figure 1. Two CDN Providers establish a CDN > >> Interconnection. > >> " > >> with: > >> " > >> An example is depicted in Figure 1 where two CDN Providers establish a > CDN > >> Interconnection. > >> " > >> (this is to minimize the redundancy with the sentence coming below: > "CDN > >> Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs.") > >> > >> > >> *** section 1.3: > >> replace: > >> " > >> "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their > CDNs." > >> with: > >> "Independently, CDN Provider 'A' and CDN Provider 'B' agree to > >> interconnect their CDNs." > >> this is to clarify that the A<->B agreement is not specific to the 1<- > >A > >> agreement > >> > >> > >> *** section 1.3: > >> replace: > >> " > >> When a User Agent requests content from CSP-1, CDN-A considers that > >> delivery by CDN-B is appropriate > >> " > >> with: > >> " > >> When a given User Agent requests content from CSP-1, CDN-A may conside= r > >> that delivery by CDN-B is appropriate > >> " > >> > >> > >> *** section 1.3: > >> replace: > >> " > >> CDN-A has delegated the handling of requests for CSP-1's content > through > >> the CDN Interconnection agreement, thus, the content is actually > delivered > >> from CDN-B. > >> " > >> with: > >> " > >> Through the CDN Interconnection arrangements put in place between CDN-= A > >> and CDN-B (as a result of the CDN Interconnection agreement establishe= d > >> between CDN Provider 'A' and CDN Provider 'B'), CDN-A can redirect the > >> request to CDN-B and the content is actually delivered to the User > Agent > >> by CDN-B. > >> " > >> (the current wording suggests that all deliveries of CSP1 content woul= d > be > >> handled by CDN-B, which is typically not the case i.e. only a subset o= f > >> the requests are redirected thy CDN-A to CDN-B) > >> > >> > >> *** section 1.3: > >> replace: > >> " > >> CSP-1 benefits because it only needs to make one business agreement an= d > >> one physical connection, with CDN Provider 'A' > >> " > >> with: > >> " > >> CSP-1 benefits because it only needs to make one business agreement an= d > >> one technical arrangement with CDN Provider 'A' > >> " > >> (this is because the interfacing between CSP and uCDN comprises more > than > >> "physical connection"). > >> > >> > >> *** section 1.3: > >> replace: > >> " > >> CSP-1 had also gone to the trouble of making a business agreement with > CDN > >> Provider 'B' > >> " > >> with: > >> " > >> CSP-1 had also gone to the trouble of making a business agreement and > >> technical arrangemement with CDN Provider 'B' > >> " > >> > >> *** section 1.3: > >> replace: > >> " > >> But it does not want > >> " > >> with: > >> " > >> However, CSP-2 may not want > >> " > >> > >> *** section 2.1: > >> after > >> " > >> o without incurring additional transit and other network costs that > >> would result from serving content from geographically or > >> topologically remote Surrogates. > >> " > >> add: > >> " > >> o without incurring the cost of deploying and operating Surrogates and > the > >> associated CDN infrastructure that may not be justified in the > >> corresponding geographic region (e.g. because of relatively low > delivery > >> volume, or conversely because of the high investments that would be > needed > >> to satisfy the high volume) > >> " > >> > >> > >> *** section 2.2: > >> replace: > >> " > >> A large CDN Provider may also operate CDNs from several subsidiaries > >> (which may rely on different CDN technologies, see Section 4.2). In > >> certain circumstances, the CDN Provider needs to make its CDNs > >> interoperate to provide a consistent service to its customers on its > whole > >> footprint. > >> " > >> with: > >> " > >> A large CDN Provider may have several subsidiaries that also each > operate > >> their own CDN (which may rely on different CDN technologies, see > Section > >> 4.2). In certain circumstances, the CDN Provider needs to make these > CDNs > >> interoperate to provide a consistent service to its customers on the > whole > >> collective footprint. > >> " > >> > >> > >> *** section 2.3: > >> replace: > >> " > >> injected into the access network > >> " > >> with: > >> " > >> injected into the ISP network > >> " > >> > >> *** section 2.3: > >> replace: > >> " > >> There are mutual benefits to the Access CDN, > >> " > >> with: > >> " > >> There are mutual benefits to the ISP (acting as an Access CDN), > >> " > >> > >> > >> *** section 2.3: > >> replace: > >> " > >> for example, QoS and reduced round trip time. > >> " > >> with: > >> " > >> for example, reduced content startup time or increased video quality > and > >> resolution of adaptive streaming content. > >> " > >> (I don't think RTT is very meaningful to a CSP customer) > >> > >> > >> *** section 2.4: > >> The nomadic user is currently defined as "moving between CDNs" which i= s > >> sort of a self-serving definition to justify CDN interconnection. I > think > >> we should rather define the nomadic user as "moving between access > >> networks" and then justify that leveraging local CDNs can bring a lot > of > >> benefits. > >> This requires the following text edits: > >> s/who move between CDNs/who move between access networks/ > >> s/moving between different CDN Providers/moving between different > access > >> networks/ > >> > >> *** section 2.4: > >> replace: > >> " > >> which may reside > >> " > >> with: > >> " > >> which may be located > >> " > >> > >> *** section 2.4:" > >> I propose to remove the sentence: > >> " > >> The term "Nomadic" does not necessarily relate to geographic roaming. > >> " > >> because this point has already been fully (and better) clarified in th= e > >> preceding paragraph. > >> > >> > >> > >> *** section 2.4: > >> replace: > >> " > >> the WiFi or mobile provider > >> " > >> with: > >> " > >> the WiFi or mobile provider (NSP B) > >> " > >> > >> > >> *** section 3.1: > >> replace: > >> " > >> needs CDN capacities > >> " > >> with: > >> " > >> needs CDN capacity > >> " > >> > >> *** section 3.2.1: > >> The text mentions two options (use OS, use another CDN). I think the > >> section shoudl probably also mention the most obvious option (i.e. use > >> other surrogates in the same CDN). Or alternatively, clarify that the > >> considered situation is where there is a partial failure of some > >> surrogates resulting in the remaining surrogates being fully loaded. > >> > >> > >> *** section 3.2.1: > >> replace: > >> " > >> to both distribute load between origin servers and attempt content > >> acquisition from alternate origin servers when acquisition failures > occur. > >> When normal content acquisition fails, a CDN may need to try other > origin > >> server options, > >> " > >> with: > >> " > >> to both distribute load between content sources and attempt content > >> acquisition from alternate content sources when acquisition failures > >> occur. When normal content acquisition fails, a CDN may need to try > other > >> content source options, > >> " > >> (I believe everywhere else we use "origin server" to refer to the OS o= f > >> the CSP and "content source" as the generic term for getting content > >> including origin server and uCDN) > >> > >> *** section 3.2.2: > >> replace: > >> " > >> the selection of content acquisition sources should be considered. > >> " > >> with: > >> " > >> the selection of content acquisition sources should be considered and > >> facilitated. > >> " > >> (i.e. it is not just a matter of "thinking" about it: it must be > >> explicitly allowed or at leads made easier). > >> > >> > >> *** section 4.1: > >> "to serve a proportion of its traffic that requires HTTPS." > >> can you include a reference for HTTPS? > >> > >> > >> *** section 5: > >> replace: > >> " > >> An important aspect of the above use cases > >> " > >> with: > >> " > >> An important aspect common to all the above use cases > >> " > >> > >> > >> *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line > 618, > >> but no explicit reference was found in the text > >> I'd suggest you add an explicit reference. For example, in "1. > >> Introduction" you could replace: > >> " > >> The document can be used to guide the definition of the requirements t= o > be > >> supported by the various CDNI interfaces defined in [I-D.ietf-cdni- > >> problem-statement]. > >> " > >> by > >> " > >> The document can be used to guide the definition of the requirements > (as > >> documented in [I-D.ietf-cdni-requirements]) to be supported by the set > of > >> CDNI interfaces defined in [I-D.ietf-cdni-problem-statement]. > >> " > >> (BTW, independely of the reference issue, "the set of CDNI interfaces" > >> might read better than "the various CDNI interfaces"). > >> > >> > >> *** The document has a disclaimer for pre-RFC5378 work, but was first > >> submitted on or after 10 November 2008. Does it really need the > >> disclaimer? > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Sat May 12 16:25:54 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B0E21F861B for ; Sat, 12 May 2012 16:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.33 X-Spam-Level: X-Spam-Status: No, score=-3.33 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_06_12=1.069, GB_MUTUALBENEFIT=2, J_BACKHAIR_11=1, J_CHICKENPOX_31=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 bNnGtAYu7NWj for ; Sat, 12 May 2012 16:25:52 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0A521F862A for ; Sat, 12 May 2012 16:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=27240; q=dns/txt; s=iport; t=1336865152; x=1338074752; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=1oo7JlqoQZs8+t1TyvyyR9ukdSh+pYHmdvHYqSw9wWc=; b=gEWy2yqeSAIHirb1YddlbG6uJx8nkvxNY4fMaaEtHru5I8uPCNg7lUnK yV7CYvHX0s0a63XRdMsX7GcS/izU7F3KErEs2nh/JuE2SwhLgMfChLGsy 4Qosk9/9xQACMmsROMtMjXx5eHDF+bthR2udiAPJkXF66imXqtntYuIaD k=; X-IronPort-AV: E=Sophos;i="4.75,577,1330905600"; d="scan'208";a="44478506" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 12 May 2012 23:25:52 +0000 Received: from [10.21.76.68] ([10.21.76.68]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q4CNPmfC016988; Sat, 12 May 2012 23:25:51 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Francois Le Faucheur In-Reply-To: <291CC3F9E50E7641901A54E85D0977C65260E2D1BF@MAILR002.mail.lan> Date: Sat, 12 May 2012 19:15:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5388986F-034F-4E38-A5A3-78B6E30F56A5@cisco.com> <291CC3F9E50E7641901A54E85D0977C65260C10A37@MAILR002.mail.lan> <5C88F9C0-F28D-4B77-88AA-3D9058E8FE8A@cisco.com> <291CC3F9E50E7641901A54E85D0977C65260E2D1BF@MAILR002.mail.lan> To: Kevin J Ma X-Mailer: Apple Mail (2.1278) Cc: "draft-ietf-cdni-use-cases@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] Tie between Request-Routing and policy Re: Document Shepherd review of draft-ietf-cdni-use-cases X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss 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, 12 May 2012 23:25:54 -0000 On 10 May 2012, at 01:32, Kevin J Ma wrote: > Hi Francois, >=20 >> * to allow flexibility in the future (e.g. to allow introduction = of >> additional policies in subsequent versions of CDNI), let's rely on = the >> "Capabilities Advertisement" of the Request Routing interface. >=20 > Just to clarify, are you proposing that the list of supported metadata > are exchanged in the RR capabilities, but, the metadata would still be > applied to the individual (or groups of) content items? Right. With the clarification that the RR capabilities mechanism may distribute = information about which metadata/policy-rules are supported by a dCDN in = an aggregate manner (e.g. indicate that a given set of = metadata/policy-rules are supported) as opposed to necessary = individually (e.g. listing each and every individual = metadata/policy-rules). >=20 > I would agree with this, noting that the actual metadata value applied > to any given content asset may still be rejected later. >=20 >> * in any case, we have the "escape" mechanism >=20 Right. > I agree that rejection support (per the META-13 requirement) is = needed. >=20 >> levels of granularity; for example, the dCDN may allow a dCDN to say = "I >> support the delivery policies defined in CDNI v1" or "I support the >> delivery policies defined in CDNI v1 and in CDNIv2" or, if needed, "I >> support the delivery policies defined in CDNI v1 and the 1st subset = of >> delivery policies defined in CDNIv2 but not the 2nd subset". >=20 > These examples concern me in that they might imply that only those > policies (and therefore only those metadata) officially blessed by the > CDNI working group will be allowed. I would think that there should > be a way to include opaque and vendor defined metadata with the > capabilities advertisement as well. Agreed. Could you check with Kent to see if this is covered in the requirements = I-D and if not get it covered? >=20 >> I understand this to mean that dCDN selection by the uCDN is supped = to >> take into account things like whether a given resolution is deemed to = high >> by the CSP for delivery via a CDN. >=20 > The intent was to show that CP may have policies that they wish to > enforce. If a CP has a resolution policy, this is not to imply that > the CDN needs to know the resolution, only that the CP may be > motivated by something like resolution, to define a policy. So we are in line, and it sounds like a wording issue. >=20 >> Again, to me the whole point of that section is precisely to clarify = that >> CSPs may have fancy policies and that those can be enforced in a = multi-CDN >> environment without having to make these fancy policy understood by = the >> CDNs. >=20 > I agree with this statement. >=20 >> The current text is suggesting quite the opposite to me. Or maybe I >> am misreading it. >=20 > We will address this. Thanks Francois >=20 > thanx. >=20 > -- Kevin J. Ma >=20 >> -----Original Message----- >> From: Francois Le Faucheur [mailto:flefauch@cisco.com] >> Sent: Friday, May 04, 2012 11:28 AM >> To: Kevin J Ma >> Cc: Francois Le Faucheur; draft-ietf-cdni-use-cases@tools.ietf.org; >> cdni@ietf.org >> Subject: Tie between Request-Routing and policy Re: [CDNi] Document >> Shepherd review of draft-ietf-cdni-use-cases >>=20 >> Hi Kevin, >>=20 >> I think the discussion below touches on two topics: >> *A* delivery policies to be communicated and enforced by a dCDN >> *B* potential interactions between request-routing and the = ability >> of a CDN to enforce an aspect of policy >>=20 >> Regarding *A*, I expressed my thoughts in http://www.ietf.org/mail- >> archive/web/cdni/current/msg00988.html. Please let me know if that = makes >> sense to you. >>=20 >> Regarding *B*: So I think your concern is "how do we deal with = potential >> situations where an uCDN may redirect a request to a dCDN that is not >> capable to enforce all aspects of the distribution policy?". That is = a >> good point. >> My proposal would be: >> * let's settle on a small set of well-defined policies (as = discussed >> in http://www.ietf.org/mail-archive/web/cdni/current/msg00988.html.) = such >> as geoblocking + time-window + pre-authrization-enforcement (e.g. URI >> signing), then we may virtually eliminate the situation altogether in = the >> common cases (at least in the initial incarnation of the CDNI = solution) >> since all dCDNs could support that set of policies (i.e. they would = be >> mandatory) >> * to allow flexibility in the future (e.g. to allow introduction = of >> additional policies in subsequent versions of CDNI), let's rely on = the >> "Capabilities Advertisement" of the Request Routing interface. This = would >> allow the dCDN to advertise to the uCDN what sort of capabilities it >> supports in the area of distribution policy enforcement. The design = team >> will look into the details of those but they might come at different >> levels of granularity; for example, the dCDN may allow a dCDN to say = "I >> support the delivery policies defined in CDNI v1" or "I support the >> delivery policies defined in CDNI v1 and in CDNIv2" or, if needed, "I >> support the delivery policies defined in CDNI v1 and the 1st subset = of >> delivery policies defined in CDNIv2 but not the 2nd subset". This can = be >> factored by the uCDN Request Routing system (e.g. it can consider the >> metadata and based on those could decide to consider the dCDN = advertised >> policy capabilities). I am not sure we need that sort of things for = our >> initial CDNI solution, but arguably that depends on if we can settle = for a >> single set of delivery policies that we all make mandatory. >> * in any case, we have the "escape" mechanism discussed by Larry = in >> Paris: if a dCDN is explicitly told so, or if it is not capable of >> enforcing a particular policy aspect requested in the metadata, then = it >> can do a per-request authorization check into the uCDN. >>=20 >> Do you agree with the above? >>=20 >> To your specific question about my concern with the current text. I = just >> don't get the point it is trying to make. For example it says: >> " >> dCDN delegation and Surrogate selection decisions are influenced by >> these policies: >>=20 >> ... >> o dCDN delegation may fail if the content resolution has been >> specified by the CSP as being too high for distribution via the >> dCDN, >> " >> =03I understand this to mean that dCDN selection by the uCDN is = supped to >> take into account things like whether a given resolution is deemed to = high >> by the CSP for delivery via a CDN. >> I disagree with this. The uCDN should not have to be aware of that = sort of >> policies. All it would know is whether a content is to be delivered = or not >> (it really does not care whether this is because of excessively good >> resolution or any CSP-meaningful but CDN-meaningless reasons). >>=20 >> Again, to me the whole point of that section is precisely to clarify = that >> CSPs may have fancy policies and that those can be enforced in a = multi-CDN >> environment without having to make these fancy policy understood by = the >> CDNs. The current text is suggesting quite the opposite to me. Or = maybe I >> am misreading it. >>=20 >> Cheers >>=20 >> Francois >>=20 >>=20 >> On 26 Apr 2012, at 23:46, Kevin J Ma wrote: >>=20 >>> Hi Francois, >>>=20 >>>> * explain that the CDNs are only expected to enforce a few >> specific >>>> policy rules (e.g. geo-blocking, time window) and for enforcement = of >> all >>>> fancy CSP policy we propose that the responsibilities be divided = into >> (1) >>>> the CSP being responsible for the fancy policy decision and (ii) = the >> CDN >>>> for merely enforcing the CSP decision without having to understand = the >>>> policy (e.g. via URI signing). >>>> Do we not agree on that or not? >>>=20 >>> I agree that the CDN should enforce any policy that is defined in >> metadata. >>> If a supported metadata dictates a restriction, regardless of any >> individual >>> interpretation of the semantic fanciness, the restriction should be >> enforced. >>> If a dCDN does not support a given metadata, it can express that to = the >> uCDN, >>> which should influence the inter-CDN request routing. >>>=20 >>>> Also, the paragraph keeps talking about "dCDN selection or = Surrogate >>>> selection" may fail for some fancy policy reasons. I don't = understand >> what >>>> it means to "fail", but more importantly again, I don't think we = want >> CDN >>>> request routing decisions to be factoring very fancy CSP policy = rules. >>>> Do we agree or not? >>>=20 >>> The failure could probably be a more generic delivery failure, due = to >>> restrictions defined in the metadata, though, the framework document >>> shows the metadata checks as part of request routing decision making >>> which presumably influences dCDN/Surrogate selection? >>>=20 >>> The fanciness of the policy should not matter, as long as the >>> metadata which conveys the enforcement of that policy is clear and >>> succinct. The inter-CDN request routing should be aware of the >>> capabilities of each dCDN and not delegate to dCDNs that lack = support >>> for capabilities which are deemed mandatory. >>>=20 >>> The use cases do not dictate any specific implementations. They do = not >>> require request routing to implement fancy policy rules. A valid >>> implementation could wrap all the fancy policy rules into a nice = neat >>> boolean value. An equally valid implementation could implement = extra >>> super fancy policy rules. The use case does not mandate one or the >> other. >>>=20 >>> Is the concern that specific portions are not valid, or that the >> descriptions >>> are unclear, or is the concern about an assumed implementation's >> fanciness? >>>=20 >>> thanx. >>>=20 >>> -- Kevin J. Ma >>>=20 >>>> -----Original Message----- >>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On = Behalf Of >>>> Francois Le Faucheur >>>> Sent: Wednesday, April 25, 2012 12:46 PM >>>> To: draft-ietf-cdni-use-cases@tools.ietf.org >>>> Cc: cdni@ietf.org >>>> Subject: [CDNi] Document Sheperd review of = draft-ietf-cdni-use-cases >>>>=20 >>>> To use-cases authors, >>>>=20 >>>> Below are my shepherd review comments of cdni-uses-cases. >>>>=20 >>>> I think the document is in a good shape and captures well the key >> targeted >>>> use cases. >>>> I identified two remaining significant points to be addressed, and = also >>>> have included many suggestions to improve the document. >>>> I suggest we resolve the two significant points on the list and = leave >> it >>>> to editor/authors to decide how to dispose of the suggestions for >>>> improvement offline. >>>>=20 >>>> Cheers >>>>=20 >>>> Francois >>>>=20 >>>>=20 >>>> Significant points >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>> *** section 8 security considerations >>>> I have a few specific issues with the current text of the Security >>>> Considerations section. But I don't really see the need to have an >>>> expanded Security Considerations section in both the use-case = document >> and >>>> the problem-statement (particularly considering that the first IESG >> review >>>> comments on problem-statement suggest expanding the security >>>> considerations section there), in particular because the security >>>> considerations currently brought up in use-cases are not specific = to >>>> individual use cases bur rather generic to the whole CDN >> interconnection >>>> problem space. >>>> So my proposal would be to remove the whole discussion from = use-cases >>>> (i.e. the first 4 paragraphs) and refer to the Security = Considerations >>>> section of the Problem Statement e.g.. by replacing: >>>> " >>>> This document focuses on the motivational use cases for CDN >>>> Interconnection, and does not analyze these threats in detail. >>>> " >>>> with: >>>> " >>>> This document focuses on the motivational use cases for CDN >>>> Interconnection, and does not analyze the associated threats. Those = are >>>> discussed in [I-D.ietf-cdni-problem-statement]. >>>> " >>>>=20 >>>>=20 >>>> ***section A.1: >>>> I still have a problem with the text of that section. >>>> I thought we had converged on an agreement that the text would: >>>> * explain that CSPs may take into account very >>>> multiple/arbitrary/specific criteria in their policy >>>> * explain that the CDNs are only expected to enforce a few >> specific >>>> policy rules (e.g. geo-blocking, time window) and for enforcement = of >> all >>>> fancy CSP policy we propose that the responsibilities be divided = into >> (1) >>>> the CSP being responsible for the fancy policy decision and (ii) = the >> CDN >>>> for merely enforcing the CSP decision without having to understand = the >>>> policy (e.g. via URI signing). >>>> Do we not agree on that or not? >>>>=20 >>>> The current text says that CDN selection and surrogate selection = "are >>>> influenced by these policies" (referring to the fancy CSP = policies). I >> do >>>> not agree with that. I don;t think we want CDN Selection or = Surrogate >>>> selection to be influenced by whether a movie shoudl be available = 14 or >> 28 >>>> days after DVD release, or whether a given resolution is "too high" = for >> a >>>> particular user or terminal. >>>>=20 >>>> Also, the paragraph keeps talking about "dCDN selection or = Surrogate >>>> selection" may fail for some fancy policy reasons. I don't = understand >> what >>>> it means to "fail" , but more importantly again, I don't think we = want >> CDN >>>> request routing decisions to be factoring very fancy CSP policy = rules. >>>> Do we agree or not? >>>>=20 >>>> The last paragraphs gives examples of the CSP objectives of = supporting >>>> delivery policies in CDNs, and those are fine and can be achieved = with >> the >>>> set of mechanisms discussed above (i.e. goeblocking + time window + = URI >>>> signing). >>>>=20 >>>>=20 >>>> Suggestions for improvements >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >>>>=20 >>>> ***Abstract >>>> replace "CDNI" by "CDN Interconnection". >>>>=20 >>>> *** section 1: >>>> expand the first instance of CDNI into "CDN Interconnection = (CDNI)". >>>>=20 >>>> *** section 1: >>>> "Then, the document highlights the need for interoperability to >>>> exchange and enforce content delivery policies (Section 5)." >>>> I'd suggest replacing "for interoperability to exchange" by "for >>>> interoperability to allow exchange" or by "for interoperability in >> order >>>> to exchange" >>>>=20 >>>> *** section 1.1: >>>> Do you feel that the two additional terms are really specific to = the >> use- >>>> case document (in which case their definition should stay in this >>>> document) or are they likely useful in other documents (in which = case >>>> their definition should be migrated to the framework document)? >>>> Personally, I would say that those terms might be useful in other >>>> documents/discussions (eg I am pretty sure we'd need to refer to = the >>>> "Delivering CDN" in other context). >>>>=20 >>>> *** section 1.1: >>>> "Access CDN: >>>> A CDN that is directly connected to the End User's access." >>>> I think this definition needs to be a little more specific. = "Directly >>>> connected" does not mean "L2 connectivity" (because an on-net cache >> maybe >>>> a few L2 hops away), nor does it mean "L3 connectivity" (because an = OTT >>>> CDN cache has IP connectivity to an enduser). I think you mean >> something >>>> in between, more or less that the CDN and the access are within = the >> same >>>> IP administrative domain, or something close to that. Can you try >> refine >>>> that definition? >>>>=20 >>>> *** section 1.3: >>>> " o improve the experience for the End User; for instance delivery = has >>>> lower latency (decreased round-trip-time between the user and = the >>>> delivery server) and better robustness," >>>> To be more comprehensive in justifying the claims, how about: >>>> " o improve the experience for the End User; for instance delivery = has >>>> lower latency (decreased round-trip-time and higher throughput >>>> between the user and the >>>> delivery server) and better robustness (ability to use multiple >>>> delivery servers)," >>>>=20 >>>> *** section 1.3: >>>> "o reduce the Content Service Provider's (CSP) costs, such as >>>> datacenter capacity, space, and electricity consumption, as >>>> popular content is delivered through the CDN rather than through >>>> the CSP's servers." >>>> The current wording raises the question of "if it reduces the costs = by >>>> reducing expenses in the CSP datacenter, why does it not >> correspondingly >>>> increase the cost by increasing expenses in the CDN (which the CDN >>>> provider then charges back to the CSP)?" >>>> I think the gain is in the scale and effective pooling of CDN = resources >>>> across many CSPs. Could you refine the wording to explain why there = is >>>> indeed a net gain? >>>>=20 >>>> *** section 1.3: >>>> Replace: >>>> " >>>> An example is depicted in Figure 1. Two CDN Providers establish a = CDN >>>> Interconnection. >>>> " >>>> with: >>>> " >>>> An example is depicted in Figure 1 where two CDN Providers = establish a >> CDN >>>> Interconnection. >>>> " >>>> (this is to minimize the redundancy with the sentence coming below: >> "CDN >>>> Provider 'A' and CDN Provider 'B' agree to interconnect their = CDNs.") >>>>=20 >>>>=20 >>>> *** section 1.3: >>>> replace: >>>> " >>>> "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their >> CDNs." >>>> with: >>>> "Independently, CDN Provider 'A' and CDN Provider 'B' agree to >>>> interconnect their CDNs." >>>> this is to clarify that the A<->B agreement is not specific to the = 1<- >>> A >>>> agreement >>>>=20 >>>>=20 >>>> *** section 1.3: >>>> replace: >>>> " >>>> When a User Agent requests content from CSP-1, CDN-A considers that >>>> delivery by CDN-B is appropriate >>>> " >>>> with: >>>> " >>>> When a given User Agent requests content from CSP-1, CDN-A may = consider >>>> that delivery by CDN-B is appropriate >>>> " >>>>=20 >>>>=20 >>>> *** section 1.3: >>>> replace: >>>> " >>>> CDN-A has delegated the handling of requests for CSP-1's content >> through >>>> the CDN Interconnection agreement, thus, the content is actually >> delivered >>>> from CDN-B. >>>> " >>>> with: >>>> " >>>> Through the CDN Interconnection arrangements put in place between = CDN-A >>>> and CDN-B (as a result of the CDN Interconnection agreement = established >>>> between CDN Provider 'A' and CDN Provider 'B'), CDN-A can redirect = the >>>> request to CDN-B and the content is actually delivered to the User >> Agent >>>> by CDN-B. >>>> " >>>> (the current wording suggests that all deliveries of CSP1 content = would >> be >>>> handled by CDN-B, which is typically not the case i.e. only a = subset of >>>> the requests are redirected thy CDN-A to CDN-B) >>>>=20 >>>>=20 >>>> *** section 1.3: >>>> replace: >>>> " >>>> CSP-1 benefits because it only needs to make one business agreement = and >>>> one physical connection, with CDN Provider 'A' >>>> " >>>> with: >>>> " >>>> CSP-1 benefits because it only needs to make one business agreement = and >>>> one technical arrangement with CDN Provider 'A' >>>> " >>>> (this is because the interfacing between CSP and uCDN comprises = more >> than >>>> "physical connection"). >>>>=20 >>>>=20 >>>> *** section 1.3: >>>> replace: >>>> " >>>> CSP-1 had also gone to the trouble of making a business agreement = with >> CDN >>>> Provider 'B' >>>> " >>>> with: >>>> " >>>> CSP-1 had also gone to the trouble of making a business agreement = and >>>> technical arrangemement with CDN Provider 'B' >>>> " >>>>=20 >>>> *** section 1.3: >>>> replace: >>>> " >>>> But it does not want >>>> " >>>> with: >>>> " >>>> However, CSP-2 may not want >>>> " >>>>=20 >>>> *** section 2.1: >>>> after >>>> " >>>> o without incurring additional transit and other network costs = that >>>> would result from serving content from geographically or >>>> topologically remote Surrogates. >>>> " >>>> add: >>>> " >>>> o without incurring the cost of deploying and operating Surrogates = and >> the >>>> associated CDN infrastructure that may not be justified in the >>>> corresponding geographic region (e.g. because of relatively low >> delivery >>>> volume, or conversely because of the high investments that would be >> needed >>>> to satisfy the high volume) >>>> " >>>>=20 >>>>=20 >>>> *** section 2.2: >>>> replace: >>>> " >>>> A large CDN Provider may also operate CDNs from several = subsidiaries >>>> (which may rely on different CDN technologies, see Section 4.2). In >>>> certain circumstances, the CDN Provider needs to make its CDNs >>>> interoperate to provide a consistent service to its customers on = its >> whole >>>> footprint. >>>> " >>>> with: >>>> " >>>> A large CDN Provider may have several subsidiaries that also each >> operate >>>> their own CDN (which may rely on different CDN technologies, see >> Section >>>> 4.2). In certain circumstances, the CDN Provider needs to make = these >> CDNs >>>> interoperate to provide a consistent service to its customers on = the >> whole >>>> collective footprint. >>>> " >>>>=20 >>>>=20 >>>> *** section 2.3: >>>> replace: >>>> " >>>> injected into the access network >>>> " >>>> with: >>>> " >>>> injected into the ISP network >>>> " >>>>=20 >>>> *** section 2.3: >>>> replace: >>>> " >>>> There are mutual benefits to the Access CDN, >>>> " >>>> with: >>>> " >>>> There are mutual benefits to the ISP (acting as an Access CDN), >>>> " >>>>=20 >>>>=20 >>>> *** section 2.3: >>>> replace: >>>> " >>>> for example, QoS and reduced round trip time. >>>> " >>>> with: >>>> " >>>> for example, reduced content startup time or increased video = quality >> and >>>> resolution of adaptive streaming content. >>>> " >>>> (I don't think RTT is very meaningful to a CSP customer) >>>>=20 >>>>=20 >>>> *** section 2.4: >>>> The nomadic user is currently defined as "moving between CDNs" = which is >>>> sort of a self-serving definition to justify CDN interconnection. I >> think >>>> we should rather define the nomadic user as "moving between access >>>> networks" and then justify that leveraging local CDNs can bring a = lot >> of >>>> benefits. >>>> This requires the following text edits: >>>> s/who move between CDNs/who move between access networks/ >>>> s/moving between different CDN Providers/moving between different >> access >>>> networks/ >>>>=20 >>>> *** section 2.4: >>>> replace: >>>> " >>>> which may reside >>>> " >>>> with: >>>> " >>>> which may be located >>>> " >>>>=20 >>>> *** section 2.4:" >>>> I propose to remove the sentence: >>>> " >>>> The term "Nomadic" does not necessarily relate to geographic = roaming. >>>> " >>>> because this point has already been fully (and better) clarified in = the >>>> preceding paragraph. >>>>=20 >>>>=20 >>>>=20 >>>> *** section 2.4: >>>> replace: >>>> " >>>> the WiFi or mobile provider >>>> " >>>> with: >>>> " >>>> the WiFi or mobile provider (NSP B) >>>> " >>>>=20 >>>>=20 >>>> *** section 3.1: >>>> replace: >>>> " >>>> needs CDN capacities >>>> " >>>> with: >>>> " >>>> needs CDN capacity >>>> " >>>>=20 >>>> *** section 3.2.1: >>>> The text mentions two options (use OS, use another CDN). I think = the >>>> section shoudl probably also mention the most obvious option (i.e. = use >>>> other surrogates in the same CDN). Or alternatively, clarify that = the >>>> considered situation is where there is a partial failure of some >>>> surrogates resulting in the remaining surrogates being fully = loaded. >>>>=20 >>>>=20 >>>> *** section 3.2.1: >>>> replace: >>>> " >>>> to both distribute load between origin servers and attempt content >>>> acquisition from alternate origin servers when acquisition failures >> occur. >>>> When normal content acquisition fails, a CDN may need to try other >> origin >>>> server options, >>>> " >>>> with: >>>> " >>>> to both distribute load between content sources and attempt content >>>> acquisition from alternate content sources when acquisition = failures >>>> occur. When normal content acquisition fails, a CDN may need to = try >> other >>>> content source options, >>>> " >>>> (I believe everywhere else we use "origin server" to refer to the = OS of >>>> the CSP and "content source" as the generic term for getting = content >>>> including origin server and uCDN) >>>>=20 >>>> *** section 3.2.2: >>>> replace: >>>> " >>>> the selection of content acquisition sources should be considered. >>>> " >>>> with: >>>> " >>>> the selection of content acquisition sources should be considered = and >>>> facilitated. >>>> " >>>> (i.e. it is not just a matter of "thinking" about it: it must be >>>> explicitly allowed or at leads made easier). >>>>=20 >>>>=20 >>>> *** section 4.1: >>>> "to serve a proportion of its traffic that requires HTTPS." >>>> can you include a reference for HTTPS? >>>>=20 >>>>=20 >>>> *** section 5: >>>> replace: >>>> " >>>> An important aspect of the above use cases >>>> " >>>> with: >>>> " >>>> An important aspect common to all the above use cases >>>> " >>>>=20 >>>>=20 >>>> *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on = line >> 618, >>>> but no explicit reference was found in the text >>>> I'd suggest you add an explicit reference. For example, in "1. >>>> Introduction" you could replace: >>>> " >>>> The document can be used to guide the definition of the = requirements to >> be >>>> supported by the various CDNI interfaces defined in [I-D.ietf-cdni- >>>> problem-statement]. >>>> " >>>> by >>>> " >>>> The document can be used to guide the definition of the = requirements >> (as >>>> documented in [I-D.ietf-cdni-requirements]) to be supported by the = set >> of >>>> CDNI interfaces defined in [I-D.ietf-cdni-problem-statement]. >>>> " >>>> (BTW, independely of the reference issue, "the set of CDNI = interfaces" >>>> might read better than "the various CDNI interfaces"). >>>>=20 >>>>=20 >>>> *** The document has a disclaimer for pre-RFC5378 work, but was = first >>>> submitted on or after 10 November 2008. Does it really need the >>>> disclaimer? >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >=20 From ben@niven-jenkins.co.uk Sun May 13 20:19: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 4E40B21F849A for ; Sun, 13 May 2012 20:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=-3.400, BAYES_00=-2.599, GB_MUTUALBENEFIT=2, J_BACKHAIR_11=1, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+kahaLLIPGA for ; Sun, 13 May 2012 20:19:10 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6E721F8497 for ; Sun, 13 May 2012 20:19:09 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginmedia.com ([86.14.227.47] helo=[192.168.0.3]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1STloR-000124-Bi; Mon, 14 May 2012 04:19:08 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Ben Niven-Jenkins In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF035ED73B@ftrdmel0.rd.francetelecom.fr> Date: Mon, 14 May 2012 04:19:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <16153976-8E12-494D-908F-A4B90E037DA8@niven-jenkins.co.uk> References: <5388986F-034F-4E38-A5A3-78B6E30F56A5@cisco.com> <8E09C72DBC577D489F13A71228C0B7BF035ED73B@ftrdmel0.rd.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org Subject: Re: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss 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, 14 May 2012 03:19:11 -0000 On 9 May 2012, at 16:19, = wrote: > Hi Fran=E7ois, >=20 > Thanks for your review. We are integrating your comments.=20 >=20 > About your comments on Section 1.1, I definitely think the terms = "Access CDN" and "Delivering CDN" are useful more broadly than just in = the use cases document. Therefore, I would be in favor of moving them to = the framework document as you propose. >=20 > Access CDN: > A CDN that includes Surrogates in the same network (e.g., same = Autonomous System) as the End User. An Access CDN may have specific = information about > the End User and the network, for instance, End User's > profile and access capabilities. Is there really something special about an "access CDN" that means we = should define a specific term for it rather than just pointing out the = "special" bits in prose when they are relevant? I am slightly worried we start to introduce lots of quite specific terms = when in the majority of cases the "specifics" are not relevant. For = example, it seems to me that in the majority of cases we'll end up = talking about in our documents the fact an "Access CDN" may have some = more specific information won't be relevant at all. I worry that having too many specific terms for specific use cases = actually leads to more ambiguity, not less. To demonstrate possible = ambiguities: The examples of specific information makes me wonder, is a = CDN that isn't in the same network as an End User but is integrated with = an NSP's policy control (so it has awareness of profiles/access = capabilities) an access CDN? Or, is a CDN that is in the same network as = the End User but doesn't have any specific information on = profiles/access capabilities an access CDN? >=20 > Delivering CDN: > The CDN that delivers the requested piece of content to > the End User. In particular, the Delivering CDN can be an > Access CDN. I'd prefer "Terminating CDN" to "Delivering CDN" because I think = delivering CDN may get confusing when we're talking about end to end = flows. For example for a given content delivery, upstream CDN(s) may = also be delivering the content to downstream CDN(s). Having some CDNs = "delivering" content and other CDNs being called "Delivering CDNs" and = expecting readers to differentiate between the two (slightly different) = uses of the term "delivering" seems likely to cause confusion IMO. Ben >=20 >=20 > Best regards, >=20 > Gilles >=20 >=20 > -----Message d'origine----- > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part = de Francois Le Faucheur > Envoy=E9 : mercredi 25 avril 2012 18:46 > =C0 : draft-ietf-cdni-use-cases@tools.ietf.org > Cc : cdni@ietf.org > Objet : [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases >=20 > To use-cases authors, >=20 > Below are my shepherd review comments of cdni-uses-cases. >=20 > I think the document is in a good shape and captures well the key = targeted use cases. > I identified two remaining significant points to be addressed, and = also have included many suggestions to improve the document. > I suggest we resolve the two significant points on the list and leave = it to editor/authors to decide how to dispose of the suggestions for = improvement offline. >=20 > Cheers >=20 > Francois >=20 >=20 > Significant points > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > *** section 8 security considerations > I have a few specific issues with the current text of the Security = Considerations section. But I don't really see the need to have an = expanded Security Considerations section in both the use-case document = and the problem-statement (particularly considering that the first IESG = review comments on problem-statement suggest expanding the security = considerations section there), in particular because the security = considerations currently brought up in use-cases are not specific to = individual use cases bur rather generic to the whole CDN interconnection = problem space. > So my proposal would be to remove the whole discussion from use-cases = (i.e. the first 4 paragraphs) and refer to the Security Considerations = section of the Problem Statement e.g.. by replacing: > "=20 > This document focuses on the motivational use cases for CDN = Interconnection, and does not analyze these threats in detail. > " > with: > " > This document focuses on the motivational use cases for CDN = Interconnection, and does not analyze the associated threats. Those are = discussed in [I-D.ietf-cdni-problem-statement]. > " >=20 >=20 > ***section A.1: > I still have a problem with the text of that section. > I thought we had converged on an agreement that the text would: > * explain that CSPs may take into account very = multiple/arbitrary/specific criteria in their policy > * explain that the CDNs are only expected to enforce a few = specific policy rules (e.g. geo-blocking, time window) and for = enforcement of all fancy CSP policy we propose that the responsibilities = be divided into (1) the CSP being responsible for the fancy policy = decision and (ii) the CDN for merely enforcing the CSP decision without = having to understand the policy (e.g. via URI signing). > Do we not agree on that or not? >=20 > The current text says that CDN selection and surrogate selection "are = influenced by these policies" (referring to the fancy CSP policies). I = do not agree with that. I don;t think we want CDN Selection or Surrogate = selection to be influenced by whether a movie shoudl be available 14 or = 28 days after DVD release, or whether a given resolution is "too high" = for a particular user or terminal.=20 >=20 > Also, the paragraph keeps talking about "dCDN selection or Surrogate = selection" may fail for some fancy policy reasons. I don't understand = what it means to "fail" , but more importantly again, I don't think we = want CDN request routing decisions to be factoring very fancy CSP policy = rules. > Do we agree or not? >=20 > The last paragraphs gives examples of the CSP objectives of supporting = delivery policies in CDNs, and those are fine and can be achieved with = the set of mechanisms discussed above (i.e. goeblocking + time window + = URI signing). >=20 >=20 > Suggestions for improvements > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > ***Abstract > replace "CDNI" by "CDN Interconnection". >=20 > *** section 1: > expand the first instance of CDNI into "CDN Interconnection (CDNI)". >=20 > *** section 1: > "Then, the document highlights the need for interoperability to > exchange and enforce content delivery policies (Section 5)." > I'd suggest replacing "for interoperability to exchange" by "for = interoperability to allow exchange" or by "for interoperability in order = to exchange" >=20 > *** section 1.1: > Do you feel that the two additional terms are really specific to the = use-case document (in which case their definition should stay in this = document) or are they likely useful in other documents (in which case = their definition should be migrated to the framework document)? > Personally, I would say that those terms might be useful in other = documents/discussions (eg I am pretty sure we'd need to refer to the = "Delivering CDN" in other context). >=20 > *** section 1.1: > "Access CDN: > A CDN that is directly connected to the End User's access." > I think this definition needs to be a little more specific. "Directly = connected" does not mean "L2 connectivity" (because an on-net cache = maybe a few L2 hops away), nor does it mean "L3 connectivity" (because = an OTT CDN cache has IP connectivity to an enduser). I think you mean = something in between, more or less that the CDN and the access are = within the same IP administrative domain, or something close to that. = Can you try refine that definition? >=20 > *** section 1.3: > " o improve the experience for the End User; for instance delivery = has > lower latency (decreased round-trip-time between the user and the > delivery server) and better robustness," > To be more comprehensive in justifying the claims, how about: > " o improve the experience for the End User; for instance delivery = has > lower latency (decreased round-trip-time and higher throughput = between the user and the > delivery server) and better robustness (ability to use multiple = delivery servers)," >=20 > *** section 1.3: > "o reduce the Content Service Provider's (CSP) costs, such as > datacenter capacity, space, and electricity consumption, as > popular content is delivered through the CDN rather than through > the CSP's servers." > The current wording raises the question of "if it reduces the costs by = reducing expenses in the CSP datacenter, why does it not correspondingly = increase the cost by increasing expenses in the CDN (which the CDN = provider then charges back to the CSP)?" > I think the gain is in the scale and effective pooling of CDN = resources across many CSPs. Could you refine the wording to explain why = there is indeed a net gain? >=20 > *** section 1.3: > Replace: > " > An example is depicted in Figure 1. Two CDN Providers establish a CDN = Interconnection. > " > with: > " > An example is depicted in Figure 1 where two CDN Providers establish a = CDN Interconnection. > " > (this is to minimize the redundancy with the sentence coming below: = "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their = CDNs.") >=20 >=20 > *** section 1.3: > replace: > " > "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their = CDNs." > with: > "Independently, CDN Provider 'A' and CDN Provider 'B' agree to = interconnect their CDNs." > this is to clarify that the A<->B agreement is not specific to the = 1<->A agreement >=20 >=20 > *** section 1.3: > replace: > " > When a User Agent requests content from CSP-1, CDN-A considers that = delivery by CDN-B is appropriate " > with: > " > When a given User Agent requests content from CSP-1, CDN-A may = consider that delivery by CDN-B is appropriate " >=20 >=20 > *** section 1.3: > replace: > " > CDN-A has delegated the handling of requests for CSP-1's content = through the CDN Interconnection agreement, thus, the content is actually = delivered from CDN-B. > " > with: > " > Through the CDN Interconnection arrangements put in place between = CDN-A and CDN-B (as a result of the CDN Interconnection agreement = established between CDN Provider 'A' and CDN Provider 'B'), CDN-A can = redirect the request to CDN-B and the content is actually delivered to = the User Agent by CDN-B. > " > (the current wording suggests that all deliveries of CSP1 content = would be handled by CDN-B, which is typically not the case i.e. only a = subset of the requests are redirected thy CDN-A to CDN-B)=20 >=20 >=20 > *** section 1.3: > replace: > " > CSP-1 benefits because it only needs to make one business agreement = and one physical connection, with CDN Provider 'A' > " > with: > " > CSP-1 benefits because it only needs to make one business agreement = and one technical arrangement with CDN Provider 'A' > " > (this is because the interfacing between CSP and uCDN comprises more = than "physical connection"). >=20 >=20 > *** section 1.3: > replace: > " > CSP-1 had also gone to the trouble of making a business agreement with = CDN Provider 'B' > " > with: > " > CSP-1 had also gone to the trouble of making a business agreement and = technical arrangemement with CDN Provider 'B' > " >=20 > *** section 1.3: > replace: > " > But it does not want > " > with: > " > However, CSP-2 may not want > " >=20 > *** section 2.1: > after > " > o without incurring additional transit and other network costs that > would result from serving content from geographically or > topologically remote Surrogates. > " > add: > " > o without incurring the cost of deploying and operating Surrogates and = the associated CDN infrastructure that may not be justified in the = corresponding geographic region (e.g. because of relatively low delivery = volume, or conversely because of the high investments that would be = needed to satisfy the high volume) " >=20 >=20 > *** section 2.2: > replace: > " > A large CDN Provider may also operate CDNs from several subsidiaries = (which may rely on different CDN technologies, see Section 4.2). In = certain circumstances, the CDN Provider needs to make its CDNs = interoperate to provide a consistent service to its customers on its = whole footprint. > " > with: > " > A large CDN Provider may have several subsidiaries that also each = operate their own CDN (which may rely on different CDN technologies, see = Section 4.2). In certain circumstances, the CDN Provider needs to make = these CDNs interoperate to provide a consistent service to its customers = on the whole collective footprint.=20 > " >=20 >=20 > *** section 2.3: > replace: > " > injected into the access network > " > with: > " > injected into the ISP network > " >=20 > *** section 2.3: > replace: > " > There are mutual benefits to the Access CDN, > " > with: > " > There are mutual benefits to the ISP (acting as an Access CDN), > " >=20 >=20 > *** section 2.3: > replace: > " > for example, QoS and reduced round trip time. > " > with: > " > for example, reduced content startup time or increased video quality = and resolution of adaptive streaming content. > " > (I don't think RTT is very meaningful to a CSP customer) >=20 >=20 > *** section 2.4: > The nomadic user is currently defined as "moving between CDNs" which = is sort of a self-serving definition to justify CDN interconnection. I = think we should rather define the nomadic user as "moving between access = networks" and then justify that leveraging local CDNs can bring a lot of = benefits. > This requires the following text edits: > s/who move between CDNs/who move between access networks/ > s/moving between different CDN Providers/moving between different = access networks/ >=20 > *** section 2.4: > replace: > " > which may reside > " > with: > " > which may be located > " >=20 > *** section 2.4:" > I propose to remove the sentence: > " > The term "Nomadic" does not necessarily relate to geographic roaming. > " > because this point has already been fully (and better) clarified in = the preceding paragraph. >=20 >=20 >=20 > *** section 2.4: > replace: > " > the WiFi or mobile provider > " > with: > " > the WiFi or mobile provider (NSP B) > " >=20 >=20 > *** section 3.1: > replace: > " > needs CDN capacities > " > with: > " > needs CDN capacity > " >=20 > *** section 3.2.1: > The text mentions two options (use OS, use another CDN). I think the = section shoudl probably also mention the most obvious option (i.e. use = other surrogates in the same CDN). Or alternatively, clarify that the = considered situation is where there is a partial failure of some = surrogates resulting in the remaining surrogates being fully loaded. >=20 >=20 > *** section 3.2.1: > replace: > " > to both distribute load between origin servers and attempt content = acquisition from alternate origin servers when acquisition failures = occur. When normal content acquisition fails, a CDN may need to try = other origin server options, > " > with: > " > to both distribute load between content sources and attempt content = acquisition from alternate content sources when acquisition failures = occur. When normal content acquisition fails, a CDN may need to try = other content source options, > " > (I believe everywhere else we use "origin server" to refer to the OS = of the CSP and "content source" as the generic term for getting content = including origin server and uCDN) >=20 > *** section 3.2.2: > replace: > " > the selection of content acquisition sources should be considered. > " > with: > " > the selection of content acquisition sources should be considered and = facilitated. > " > (i.e. it is not just a matter of "thinking" about it: it must be = explicitly allowed or at leads made easier). >=20 >=20 > *** section 4.1: > "to serve a proportion of its traffic that requires HTTPS." > can you include a reference for HTTPS? >=20 >=20 > *** section 5: > replace: > " > An important aspect of the above use cases > " > with: > " > An important aspect common to all the above use cases > " >=20 >=20 > *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line = 618, but no explicit reference was found in the text > I'd suggest you add an explicit reference. For example, in "1. = Introduction" you could replace: > " > The document can be used to guide the definition of the requirements = to be supported by the various CDNI interfaces defined in = [I-D.ietf-cdni-problem-statement]. > " > by > " > The document can be used to guide the definition of the requirements = (as documented in [I-D.ietf-cdni-requirements]) to be supported by the = set of CDNI interfaces defined in [I-D.ietf-cdni-problem-statement]. > " > (BTW, independely of the reference issue, "the set of CDNI interfaces" = might read better than "the various CDNI interfaces"). >=20 >=20 > *** The document has a disclaimer for pre-RFC5378 work, but was first = submitted on or after 10 November 2008. Does it really need the = disclaimer? > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From gilles.bertrand@orange.com Mon May 14 05:55:32 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CABC21F8452 for ; Mon, 14 May 2012 05:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=-0.931, BAYES_00=-2.599, GB_MUTUALBENEFIT=2, HELO_EQ_FR=0.35, J_BACKHAIR_11=1, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gk1rIN4hrM5O for ; Mon, 14 May 2012 05:55:30 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id D35AB21F844F for ; Mon, 14 May 2012 05:55:29 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 69A915D8B18; Mon, 14 May 2012 14:55:26 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 59AF85D8B12; Mon, 14 May 2012 14:55:26 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 May 2012 14:55:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 May 2012 14:55:20 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF035EE117@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <16153976-8E12-494D-908F-A4B90E037DA8@niven-jenkins.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases Thread-Index: Ac0xgFPPYrnWUV8TSLe3taaJw/AapQAT8emQ References: <5388986F-034F-4E38-A5A3-78B6E30F56A5@cisco.com> <8E09C72DBC577D489F13A71228C0B7BF035ED73B@ftrdmel0.rd.francetelecom.fr> <16153976-8E12-494D-908F-A4B90E037DA8@niven-jenkins.co.uk> From: To: X-OriginalArrivalTime: 14 May 2012 12:55:26.0487 (UTC) FILETIME=[D5488270:01CD31D0] Cc: cdni@ietf.org Subject: Re: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss 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, 14 May 2012 12:55:32 -0000 Hi Ben, We can always avoid defining terms and concepts, at the price of = redundant explanations in the drafts.=20 IMO, the term "delivering CDN" is immediately understandable: = considering a given request, the delivering CDN is the one that delivers = the requested content to the end-user. By contrast, I find the term = terminating CDN more confusing (what does it terminate?).=20 Best regards, Gilles -----Message d'origine----- De=A0: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 Envoy=E9=A0: lundi 14 mai 2012 05:19 =C0=A0: BERTRAND Gilles RD-CORE-ISS Cc=A0: flefauch@cisco.com; lpeterson@verivue.com; cdni@ietf.org Objet=A0: Re: [CDNi] Document Sheperd review of = draft-ietf-cdni-use-cases On 9 May 2012, at 16:19, = wrote: > Hi Fran=E7ois, >=20 > Thanks for your review. We are integrating your comments.=20 >=20 > About your comments on Section 1.1, I definitely think the terms = "Access CDN" and "Delivering CDN" are useful more broadly than just in = the use cases document. Therefore, I would be in favor of moving them to = the framework document as you propose. >=20 > Access CDN: > A CDN that includes Surrogates in the same network (e.g., same = Autonomous System) as the End User. An Access CDN may have specific = information about > the End User and the network, for instance, End User's > profile and access capabilities. Is there really something special about an "access CDN" that means we = should define a specific term for it rather than just pointing out the = "special" bits in prose when they are relevant? I am slightly worried we start to introduce lots of quite specific terms = when in the majority of cases the "specifics" are not relevant. For = example, it seems to me that in the majority of cases we'll end up = talking about in our documents the fact an "Access CDN" may have some = more specific information won't be relevant at all. I worry that having too many specific terms for specific use cases = actually leads to more ambiguity, not less. To demonstrate possible = ambiguities: The examples of specific information makes me wonder, is a = CDN that isn't in the same network as an End User but is integrated with = an NSP's policy control (so it has awareness of profiles/access = capabilities) an access CDN? Or, is a CDN that is in the same network as = the End User but doesn't have any specific information on = profiles/access capabilities an access CDN? >=20 > Delivering CDN: > The CDN that delivers the requested piece of content to > the End User. In particular, the Delivering CDN can be an > Access CDN. I'd prefer "Terminating CDN" to "Delivering CDN" because I think = delivering CDN may get confusing when we're talking about end to end = flows. For example for a given content delivery, upstream CDN(s) may = also be delivering the content to downstream CDN(s). Having some CDNs = "delivering" content and other CDNs being called "Delivering CDNs" and = expecting readers to differentiate between the two (slightly different) = uses of the term "delivering" seems likely to cause confusion IMO. Ben >=20 >=20 > Best regards, >=20 > Gilles >=20 >=20 > -----Message d'origine----- > De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part=20 > de Francois Le Faucheur Envoy=E9 : mercredi 25 avril 2012 18:46 =C0 :=20 > draft-ietf-cdni-use-cases@tools.ietf.org > Cc : cdni@ietf.org > Objet : [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases >=20 > To use-cases authors, >=20 > Below are my shepherd review comments of cdni-uses-cases. >=20 > I think the document is in a good shape and captures well the key = targeted use cases. > I identified two remaining significant points to be addressed, and = also have included many suggestions to improve the document. > I suggest we resolve the two significant points on the list and leave = it to editor/authors to decide how to dispose of the suggestions for = improvement offline. >=20 > Cheers >=20 > Francois >=20 >=20 > Significant points > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > *** section 8 security considerations > I have a few specific issues with the current text of the Security = Considerations section. But I don't really see the need to have an = expanded Security Considerations section in both the use-case document = and the problem-statement (particularly considering that the first IESG = review comments on problem-statement suggest expanding the security = considerations section there), in particular because the security = considerations currently brought up in use-cases are not specific to = individual use cases bur rather generic to the whole CDN interconnection = problem space. > So my proposal would be to remove the whole discussion from use-cases = (i.e. the first 4 paragraphs) and refer to the Security Considerations = section of the Problem Statement e.g.. by replacing: > "=20 > This document focuses on the motivational use cases for CDN = Interconnection, and does not analyze these threats in detail. > " > with: > " > This document focuses on the motivational use cases for CDN = Interconnection, and does not analyze the associated threats. Those are = discussed in [I-D.ietf-cdni-problem-statement]. > " >=20 >=20 > ***section A.1: > I still have a problem with the text of that section. > I thought we had converged on an agreement that the text would: > * explain that CSPs may take into account very = multiple/arbitrary/specific criteria in their policy > * explain that the CDNs are only expected to enforce a few specific = policy rules (e.g. geo-blocking, time window) and for enforcement of all = fancy CSP policy we propose that the responsibilities be divided into = (1) the CSP being responsible for the fancy policy decision and (ii) the = CDN for merely enforcing the CSP decision without having to understand = the policy (e.g. via URI signing). > Do we not agree on that or not? >=20 > The current text says that CDN selection and surrogate selection "are = influenced by these policies" (referring to the fancy CSP policies). I = do not agree with that. I don;t think we want CDN Selection or Surrogate = selection to be influenced by whether a movie shoudl be available 14 or = 28 days after DVD release, or whether a given resolution is "too high" = for a particular user or terminal.=20 >=20 > Also, the paragraph keeps talking about "dCDN selection or Surrogate = selection" may fail for some fancy policy reasons. I don't understand = what it means to "fail" , but more importantly again, I don't think we = want CDN request routing decisions to be factoring very fancy CSP policy = rules. > Do we agree or not? >=20 > The last paragraphs gives examples of the CSP objectives of supporting = delivery policies in CDNs, and those are fine and can be achieved with = the set of mechanisms discussed above (i.e. goeblocking + time window + = URI signing). >=20 >=20 > Suggestions for improvements > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > ***Abstract > replace "CDNI" by "CDN Interconnection". >=20 > *** section 1: > expand the first instance of CDNI into "CDN Interconnection (CDNI)". >=20 > *** section 1: > "Then, the document highlights the need for interoperability to =20 > exchange and enforce content delivery policies (Section 5)." > I'd suggest replacing "for interoperability to exchange" by "for = interoperability to allow exchange" or by "for interoperability in order = to exchange" >=20 > *** section 1.1: > Do you feel that the two additional terms are really specific to the = use-case document (in which case their definition should stay in this = document) or are they likely useful in other documents (in which case = their definition should be migrated to the framework document)? > Personally, I would say that those terms might be useful in other = documents/discussions (eg I am pretty sure we'd need to refer to the = "Delivering CDN" in other context). >=20 > *** section 1.1: > "Access CDN: > A CDN that is directly connected to the End User's access." > I think this definition needs to be a little more specific. "Directly = connected" does not mean "L2 connectivity" (because an on-net cache = maybe a few L2 hops away), nor does it mean "L3 connectivity" (because = an OTT CDN cache has IP connectivity to an enduser). I think you mean = something in between, more or less that the CDN and the access are = within the same IP administrative domain, or something close to that. = Can you try refine that definition? >=20 > *** section 1.3: > " o improve the experience for the End User; for instance delivery = has > lower latency (decreased round-trip-time between the user and the > delivery server) and better robustness," > To be more comprehensive in justifying the claims, how about: > " o improve the experience for the End User; for instance delivery = has > lower latency (decreased round-trip-time and higher throughput = between the user and the > delivery server) and better robustness (ability to use multiple = delivery servers)," >=20 > *** section 1.3: > "o reduce the Content Service Provider's (CSP) costs, such as > datacenter capacity, space, and electricity consumption, as > popular content is delivered through the CDN rather than through > the CSP's servers." > The current wording raises the question of "if it reduces the costs by = reducing expenses in the CSP datacenter, why does it not correspondingly = increase the cost by increasing expenses in the CDN (which the CDN = provider then charges back to the CSP)?" > I think the gain is in the scale and effective pooling of CDN = resources across many CSPs. Could you refine the wording to explain why = there is indeed a net gain? >=20 > *** section 1.3: > Replace: > " > An example is depicted in Figure 1. Two CDN Providers establish a CDN = Interconnection. > " > with: > " > An example is depicted in Figure 1 where two CDN Providers establish a = CDN Interconnection. > " > (this is to minimize the redundancy with the sentence coming below:=20 > "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their=20 > CDNs.") >=20 >=20 > *** section 1.3: > replace: > " > "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their = CDNs." > with: > "Independently, CDN Provider 'A' and CDN Provider 'B' agree to = interconnect their CDNs." > this is to clarify that the A<->B agreement is not specific to the=20 > 1<->A agreement >=20 >=20 > *** section 1.3: > replace: > " > When a User Agent requests content from CSP-1, CDN-A considers that = delivery by CDN-B is appropriate " > with: > " > When a given User Agent requests content from CSP-1, CDN-A may = consider that delivery by CDN-B is appropriate " >=20 >=20 > *** section 1.3: > replace: > " > CDN-A has delegated the handling of requests for CSP-1's content = through the CDN Interconnection agreement, thus, the content is actually = delivered from CDN-B. > " > with: > " > Through the CDN Interconnection arrangements put in place between = CDN-A and CDN-B (as a result of the CDN Interconnection agreement = established between CDN Provider 'A' and CDN Provider 'B'), CDN-A can = redirect the request to CDN-B and the content is actually delivered to = the User Agent by CDN-B. > " > (the current wording suggests that all deliveries of CSP1 content=20 > would be handled by CDN-B, which is typically not the case i.e. only a = > subset of the requests are redirected thy CDN-A to CDN-B) >=20 >=20 > *** section 1.3: > replace: > " > CSP-1 benefits because it only needs to make one business agreement = and one physical connection, with CDN Provider 'A' > " > with: > " > CSP-1 benefits because it only needs to make one business agreement = and one technical arrangement with CDN Provider 'A' > " > (this is because the interfacing between CSP and uCDN comprises more = than "physical connection"). >=20 >=20 > *** section 1.3: > replace: > " > CSP-1 had also gone to the trouble of making a business agreement with = CDN Provider 'B' > " > with: > " > CSP-1 had also gone to the trouble of making a business agreement and = technical arrangemement with CDN Provider 'B' > " >=20 > *** section 1.3: > replace: > " > But it does not want > " > with: > " > However, CSP-2 may not want > " >=20 > *** section 2.1: > after > " > o without incurring additional transit and other network costs that > would result from serving content from geographically or > topologically remote Surrogates. > " > add: > " > o without incurring the cost of deploying and operating Surrogates and = the associated CDN infrastructure that may not be justified in the = corresponding geographic region (e.g. because of relatively low delivery = volume, or conversely because of the high investments that would be = needed to satisfy the high volume) " >=20 >=20 > *** section 2.2: > replace: > " > A large CDN Provider may also operate CDNs from several subsidiaries = (which may rely on different CDN technologies, see Section 4.2). In = certain circumstances, the CDN Provider needs to make its CDNs = interoperate to provide a consistent service to its customers on its = whole footprint. > " > with: > " > A large CDN Provider may have several subsidiaries that also each = operate their own CDN (which may rely on different CDN technologies, see = Section 4.2). In certain circumstances, the CDN Provider needs to make = these CDNs interoperate to provide a consistent service to its customers = on the whole collective footprint.=20 > " >=20 >=20 > *** section 2.3: > replace: > " > injected into the access network > " > with: > " > injected into the ISP network > " >=20 > *** section 2.3: > replace: > " > There are mutual benefits to the Access CDN, " > with: > " > There are mutual benefits to the ISP (acting as an Access CDN), " >=20 >=20 > *** section 2.3: > replace: > " > for example, QoS and reduced round trip time. > " > with: > " > for example, reduced content startup time or increased video quality = and resolution of adaptive streaming content. > " > (I don't think RTT is very meaningful to a CSP customer) >=20 >=20 > *** section 2.4: > The nomadic user is currently defined as "moving between CDNs" which = is sort of a self-serving definition to justify CDN interconnection. I = think we should rather define the nomadic user as "moving between access = networks" and then justify that leveraging local CDNs can bring a lot of = benefits. > This requires the following text edits: > s/who move between CDNs/who move between access networks/ s/moving=20 > between different CDN Providers/moving between different access=20 > networks/ >=20 > *** section 2.4: > replace: > " > which may reside > " > with: > " > which may be located > " >=20 > *** section 2.4:" > I propose to remove the sentence: > " > The term "Nomadic" does not necessarily relate to geographic roaming. > " > because this point has already been fully (and better) clarified in = the preceding paragraph. >=20 >=20 >=20 > *** section 2.4: > replace: > " > the WiFi or mobile provider > " > with: > " > the WiFi or mobile provider (NSP B) > " >=20 >=20 > *** section 3.1: > replace: > " > needs CDN capacities > " > with: > " > needs CDN capacity > " >=20 > *** section 3.2.1: > The text mentions two options (use OS, use another CDN). I think the = section shoudl probably also mention the most obvious option (i.e. use = other surrogates in the same CDN). Or alternatively, clarify that the = considered situation is where there is a partial failure of some = surrogates resulting in the remaining surrogates being fully loaded. >=20 >=20 > *** section 3.2.1: > replace: > " > to both distribute load between origin servers and attempt content=20 > acquisition from alternate origin servers when acquisition failures = occur. When normal content acquisition fails, a CDN may need to try = other origin server options, " > with: > " > to both distribute load between content sources and attempt content=20 > acquisition from alternate content sources when acquisition failures = occur. When normal content acquisition fails, a CDN may need to try = other content source options, " > (I believe everywhere else we use "origin server" to refer to the OS=20 > of the CSP and "content source" as the generic term for getting=20 > content including origin server and uCDN) >=20 > *** section 3.2.2: > replace: > " > the selection of content acquisition sources should be considered. > " > with: > " > the selection of content acquisition sources should be considered and = facilitated. > " > (i.e. it is not just a matter of "thinking" about it: it must be = explicitly allowed or at leads made easier). >=20 >=20 > *** section 4.1: > "to serve a proportion of its traffic that requires HTTPS." > can you include a reference for HTTPS? >=20 >=20 > *** section 5: > replace: > " > An important aspect of the above use cases " > with: > " > An important aspect common to all the above use cases " >=20 >=20 > *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line=20 > 618, but no explicit reference was found in the text I'd suggest you = add an explicit reference. For example, in "1. Introduction" you could = replace: > " > The document can be used to guide the definition of the requirements = to be supported by the various CDNI interfaces defined in = [I-D.ietf-cdni-problem-statement]. > " > by > " > The document can be used to guide the definition of the requirements = (as documented in [I-D.ietf-cdni-requirements]) to be supported by the = set of CDNI interfaces defined in [I-D.ietf-cdni-problem-statement]. > " > (BTW, independely of the reference issue, "the set of CDNI interfaces" = might read better than "the various CDNI interfaces"). >=20 >=20 > *** The document has a disclaimer for pre-RFC5378 work, but was first = submitted on or after 10 November 2008. Does it really need the = disclaimer? > _______________________________________________ > 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 oran@cisco.com Mon May 14 06:01:57 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB8221F8627 for ; Mon, 14 May 2012 06:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.999 X-Spam-Level: X-Spam-Status: No, score=-106.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_MUTUALBENEFIT=2, J_BACKHAIR_11=1, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTE8-iiRHoyi for ; Mon, 14 May 2012 06:01:52 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CFC3C21F8452 for ; Mon, 14 May 2012 06:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=oran@cisco.com; l=19496; q=dns/txt; s=iport; t=1337000512; x=1338210112; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8Y7iI/p6PsjYqmIRvovOgx6s5crSCrvQr0Ws/GtTzqA=; b=Oa26BteqifSrJGswB1EMH9laHqTA2SPa4Pey43Uoj3PeP3UKciGmuxVh XEkNNLpRhoqH5eRWJDZ3rgx51MTPVH3BMmekiQmDXLwQHuBihcHWJzwcW cuAK2ocOn5Vn9LSf10Zv5NT74G1hk7gJPMwqALwARe+GGMu275oi5YgCy s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHYBsU+tJXG//2dsb2JhbABEs3OBB4IVAQEBAwEBAQEPARRFAggDBQsCAQgYFRIHJwsUEQIEDgUih2cFC5pIn2gEhXKFKIJWgk9jBIgwjU2OV4Fpgmk X-IronPort-AV: E=Sophos;i="4.75,586,1330905600"; d="scan'208";a="83010706" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 14 May 2012 13:01:48 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4ED1m2h016703; Mon, 14 May 2012 13:01:48 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.235]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0283.003; Mon, 14 May 2012 08:01:48 -0500 From: "Dave Oran (oran)" To: " " Thread-Topic: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases Thread-Index: AQHNMYBg6gyptiV+T0ucllNCAIU1epbJknMAgAABzAA= Date: Mon, 14 May 2012 13:01:47 +0000 Message-ID: <485BBA53-61B6-4DD9-9C12-B0140BE520FE@cisco.com> References: <5388986F-034F-4E38-A5A3-78B6E30F56A5@cisco.com> <8E09C72DBC577D489F13A71228C0B7BF035ED73B@ftrdmel0.rd.francetelecom.fr> <16153976-8E12-494D-908F-A4B90E037DA8@niven-jenkins.co.uk> <8E09C72DBC577D489F13A71228C0B7BF035EE117@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF035EE117@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.12.73] x-tm-as-product-ver: SMEX-10.2.0.1135-6.800.1017-18904.004 x-tm-as-result: No--59.910800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss 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, 14 May 2012 13:01:58 -0000 On May 14, 2012, at 8:55 AM, wrote: > Hi Ben, >=20 > We can always avoid defining terms and concepts, at the price of redundan= t explanations in the drafts.=20 >=20 > IMO, the term "delivering CDN" is immediately understandable: considering= a given request, the delivering CDN is the one that delivers the requested= content to the end-user. By contrast, I find the term terminating CDN more= confusing (what does it terminate?).=20 >=20 Movies with Arnold Schwarzenegger. Sorry, couldn't resist... :-) > Best regards, >=20 > Gilles >=20 >=20 > -----Message d'origine----- > De : Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 > Envoy=E9 : lundi 14 mai 2012 05:19 > =C0 : BERTRAND Gilles RD-CORE-ISS > Cc : flefauch@cisco.com; lpeterson@verivue.com; cdni@ietf.org > Objet : Re: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases >=20 >=20 > On 9 May 2012, at 16:19, wrote: >=20 >> Hi Fran=E7ois, >>=20 >> Thanks for your review. We are integrating your comments.=20 >>=20 >> About your comments on Section 1.1, I definitely think the terms "Access= CDN" and "Delivering CDN" are useful more broadly than just in the use cas= es document. Therefore, I would be in favor of moving them to the framework= document as you propose. >>=20 >> Access CDN: >> A CDN that includes Surrogates in the same network (e.g., same Aut= onomous System) as the End User. An Access CDN may have specific informatio= n about >> the End User and the network, for instance, End User's >> profile and access capabilities. >=20 > Is there really something special about an "access CDN" that means we sho= uld define a specific term for it rather than just pointing out the "specia= l" bits in prose when they are relevant? >=20 > I am slightly worried we start to introduce lots of quite specific terms = when in the majority of cases the "specifics" are not relevant. For example= , it seems to me that in the majority of cases we'll end up talking about i= n our documents the fact an "Access CDN" may have some more specific inform= ation won't be relevant at all. >=20 > I worry that having too many specific terms for specific use cases actual= ly leads to more ambiguity, not less. To demonstrate possible ambiguities: = The examples of specific information makes me wonder, is a CDN that isn't i= n the same network as an End User but is integrated with an NSP's policy co= ntrol (so it has awareness of profiles/access capabilities) an access CDN? = Or, is a CDN that is in the same network as the End User but doesn't have a= ny specific information on profiles/access capabilities an access CDN? >=20 >>=20 >> Delivering CDN: >> The CDN that delivers the requested piece of content to >> the End User. In particular, the Delivering CDN can be an >> Access CDN. >=20 > I'd prefer "Terminating CDN" to "Delivering CDN" because I think deliveri= ng CDN may get confusing when we're talking about end to end flows. For exa= mple for a given content delivery, upstream CDN(s) may also be delivering t= he content to downstream CDN(s). Having some CDNs "delivering" content and = other CDNs being called "Delivering CDNs" and expecting readers to differen= tiate between the two (slightly different) uses of the term "delivering" se= ems likely to cause confusion IMO. >=20 > Ben >=20 >>=20 >>=20 >> Best regards, >>=20 >> Gilles >>=20 >>=20 >> -----Message d'origine----- >> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part=20 >> de Francois Le Faucheur Envoy=E9 : mercredi 25 avril 2012 18:46 =C0 :=20 >> draft-ietf-cdni-use-cases@tools.ietf.org >> Cc : cdni@ietf.org >> Objet : [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases >>=20 >> To use-cases authors, >>=20 >> Below are my shepherd review comments of cdni-uses-cases. >>=20 >> I think the document is in a good shape and captures well the key target= ed use cases. >> I identified two remaining significant points to be addressed, and also = have included many suggestions to improve the document. >> I suggest we resolve the two significant points on the list and leave it= to editor/authors to decide how to dispose of the suggestions for improvem= ent offline. >>=20 >> Cheers >>=20 >> Francois >>=20 >>=20 >> Significant points >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> *** section 8 security considerations >> I have a few specific issues with the current text of the Security Consi= derations section. But I don't really see the need to have an expanded Secu= rity Considerations section in both the use-case document and the problem-s= tatement (particularly considering that the first IESG review comments on p= roblem-statement suggest expanding the security considerations section ther= e), in particular because the security considerations currently brought up = in use-cases are not specific to individual use cases bur rather generic to= the whole CDN interconnection problem space. >> So my proposal would be to remove the whole discussion from use-cases (i= .e. the first 4 paragraphs) and refer to the Security Considerations sectio= n of the Problem Statement e.g.. by replacing: >> "=20 >> This document focuses on the motivational use cases for CDN Interconnect= ion, and does not analyze these threats in detail. >> " >> with: >> " >> This document focuses on the motivational use cases for CDN Interconnect= ion, and does not analyze the associated threats. Those are discussed in [I= -D.ietf-cdni-problem-statement]. >> " >>=20 >>=20 >> ***section A.1: >> I still have a problem with the text of that section. >> I thought we had converged on an agreement that the text would: >> * explain that CSPs may take into account very multiple/arbitrary/speci= fic criteria in their policy >> * explain that the CDNs are only expected to enforce a few specific pol= icy rules (e.g. geo-blocking, time window) and for enforcement of all fancy= CSP policy we propose that the responsibilities be divided into (1) the CS= P being responsible for the fancy policy decision and (ii) the CDN for mere= ly enforcing the CSP decision without having to understand the policy (e.g.= via URI signing). >> Do we not agree on that or not? >>=20 >> The current text says that CDN selection and surrogate selection "are in= fluenced by these policies" (referring to the fancy CSP policies). I do not= agree with that. I don;t think we want CDN Selection or Surrogate selectio= n to be influenced by whether a movie shoudl be available 14 or 28 days aft= er DVD release, or whether a given resolution is "too high" for a particula= r user or terminal.=20 >>=20 >> Also, the paragraph keeps talking about "dCDN selection or Surrogate sel= ection" may fail for some fancy policy reasons. I don't understand what it = means to "fail" , but more importantly again, I don't think we want CDN req= uest routing decisions to be factoring very fancy CSP policy rules. >> Do we agree or not? >>=20 >> The last paragraphs gives examples of the CSP objectives of supporting d= elivery policies in CDNs, and those are fine and can be achieved with the s= et of mechanisms discussed above (i.e. goeblocking + time window + URI sign= ing). >>=20 >>=20 >> Suggestions for improvements >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> ***Abstract >> replace "CDNI" by "CDN Interconnection". >>=20 >> *** section 1: >> expand the first instance of CDNI into "CDN Interconnection (CDNI)". >>=20 >> *** section 1: >> "Then, the document highlights the need for interoperability to =20 >> exchange and enforce content delivery policies (Section 5)." >> I'd suggest replacing "for interoperability to exchange" by "for interop= erability to allow exchange" or by "for interoperability in order to exchan= ge" >>=20 >> *** section 1.1: >> Do you feel that the two additional terms are really specific to the use= -case document (in which case their definition should stay in this document= ) or are they likely useful in other documents (in which case their definit= ion should be migrated to the framework document)? >> Personally, I would say that those terms might be useful in other docume= nts/discussions (eg I am pretty sure we'd need to refer to the "Delivering = CDN" in other context). >>=20 >> *** section 1.1: >> "Access CDN: >> A CDN that is directly connected to the End User's access." >> I think this definition needs to be a little more specific. "Directly co= nnected" does not mean "L2 connectivity" (because an on-net cache maybe a f= ew L2 hops away), nor does it mean "L3 connectivity" (because an OTT CDN ca= che has IP connectivity to an enduser). I think you mean something in betwe= en, more or less that the CDN and the access are within the same IP admini= strative domain, or something close to that. Can you try refine that defini= tion? >>=20 >> *** section 1.3: >> " o improve the experience for the End User; for instance delivery has >> lower latency (decreased round-trip-time between the user and the >> delivery server) and better robustness," >> To be more comprehensive in justifying the claims, how about: >> " o improve the experience for the End User; for instance delivery has >> lower latency (decreased round-trip-time and higher throughput betwee= n the user and the >> delivery server) and better robustness (ability to use multiple deliv= ery servers)," >>=20 >> *** section 1.3: >> "o reduce the Content Service Provider's (CSP) costs, such as >> datacenter capacity, space, and electricity consumption, as >> popular content is delivered through the CDN rather than through >> the CSP's servers." >> The current wording raises the question of "if it reduces the costs by r= educing expenses in the CSP datacenter, why does it not correspondingly inc= rease the cost by increasing expenses in the CDN (which the CDN provider th= en charges back to the CSP)?" >> I think the gain is in the scale and effective pooling of CDN resources = across many CSPs. Could you refine the wording to explain why there is inde= ed a net gain? >>=20 >> *** section 1.3: >> Replace: >> " >> An example is depicted in Figure 1. Two CDN Providers establish a CDN I= nterconnection. >> " >> with: >> " >> An example is depicted in Figure 1 where two CDN Providers establish a C= DN Interconnection. >> " >> (this is to minimize the redundancy with the sentence coming below:=20 >> "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their=20 >> CDNs.") >>=20 >>=20 >> *** section 1.3: >> replace: >> " >> "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs.= " >> with: >> "Independently, CDN Provider 'A' and CDN Provider 'B' agree to interconn= ect their CDNs." >> this is to clarify that the A<->B agreement is not specific to the=20 >> 1<->A agreement >>=20 >>=20 >> *** section 1.3: >> replace: >> " >> When a User Agent requests content from CSP-1, CDN-A considers that deli= very by CDN-B is appropriate " >> with: >> " >> When a given User Agent requests content from CSP-1, CDN-A may consider = that delivery by CDN-B is appropriate " >>=20 >>=20 >> *** section 1.3: >> replace: >> " >> CDN-A has delegated the handling of requests for CSP-1's content through= the CDN Interconnection agreement, thus, the content is actually delivered= from CDN-B. >> " >> with: >> " >> Through the CDN Interconnection arrangements put in place between CDN-A = and CDN-B (as a result of the CDN Interconnection agreement established bet= ween CDN Provider 'A' and CDN Provider 'B'), CDN-A can redirect the request= to CDN-B and the content is actually delivered to the User Agent by CDN-B. >> " >> (the current wording suggests that all deliveries of CSP1 content=20 >> would be handled by CDN-B, which is typically not the case i.e. only a=20 >> subset of the requests are redirected thy CDN-A to CDN-B) >>=20 >>=20 >> *** section 1.3: >> replace: >> " >> CSP-1 benefits because it only needs to make one business agreement and = one physical connection, with CDN Provider 'A' >> " >> with: >> " >> CSP-1 benefits because it only needs to make one business agreement and = one technical arrangement with CDN Provider 'A' >> " >> (this is because the interfacing between CSP and uCDN comprises more tha= n "physical connection"). >>=20 >>=20 >> *** section 1.3: >> replace: >> " >> CSP-1 had also gone to the trouble of making a business agreement with C= DN Provider 'B' >> " >> with: >> " >> CSP-1 had also gone to the trouble of making a business agreement and te= chnical arrangemement with CDN Provider 'B' >> " >>=20 >> *** section 1.3: >> replace: >> " >> But it does not want >> " >> with: >> " >> However, CSP-2 may not want >> " >>=20 >> *** section 2.1: >> after >> " >> o without incurring additional transit and other network costs that >> would result from serving content from geographically or >> topologically remote Surrogates. >> " >> add: >> " >> o without incurring the cost of deploying and operating Surrogates and t= he associated CDN infrastructure that may not be justified in the correspon= ding geographic region (e.g. because of relatively low delivery volume, or = conversely because of the high investments that would be needed to satisfy = the high volume) " >>=20 >>=20 >> *** section 2.2: >> replace: >> " >> A large CDN Provider may also operate CDNs from several subsidiaries (wh= ich may rely on different CDN technologies, see Section 4.2). In certain ci= rcumstances, the CDN Provider needs to make its CDNs interoperate to provid= e a consistent service to its customers on its whole footprint. >> " >> with: >> " >> A large CDN Provider may have several subsidiaries that also each operat= e their own CDN (which may rely on different CDN technologies, see Section = 4.2). In certain circumstances, the CDN Provider needs to make these CDNs i= nteroperate to provide a consistent service to its customers on the whole c= ollective footprint.=20 >> " >>=20 >>=20 >> *** section 2.3: >> replace: >> " >> injected into the access network >> " >> with: >> " >> injected into the ISP network >> " >>=20 >> *** section 2.3: >> replace: >> " >> There are mutual benefits to the Access CDN, " >> with: >> " >> There are mutual benefits to the ISP (acting as an Access CDN), " >>=20 >>=20 >> *** section 2.3: >> replace: >> " >> for example, QoS and reduced round trip time. >> " >> with: >> " >> for example, reduced content startup time or increased video quality and= resolution of adaptive streaming content. >> " >> (I don't think RTT is very meaningful to a CSP customer) >>=20 >>=20 >> *** section 2.4: >> The nomadic user is currently defined as "moving between CDNs" which is = sort of a self-serving definition to justify CDN interconnection. I think w= e should rather define the nomadic user as "moving between access networks"= and then justify that leveraging local CDNs can bring a lot of benefits. >> This requires the following text edits: >> s/who move between CDNs/who move between access networks/ s/moving=20 >> between different CDN Providers/moving between different access=20 >> networks/ >>=20 >> *** section 2.4: >> replace: >> " >> which may reside >> " >> with: >> " >> which may be located >> " >>=20 >> *** section 2.4:" >> I propose to remove the sentence: >> " >> The term "Nomadic" does not necessarily relate to geographic roaming. >> " >> because this point has already been fully (and better) clarified in the = preceding paragraph. >>=20 >>=20 >>=20 >> *** section 2.4: >> replace: >> " >> the WiFi or mobile provider >> " >> with: >> " >> the WiFi or mobile provider (NSP B) >> " >>=20 >>=20 >> *** section 3.1: >> replace: >> " >> needs CDN capacities >> " >> with: >> " >> needs CDN capacity >> " >>=20 >> *** section 3.2.1: >> The text mentions two options (use OS, use another CDN). I think the sec= tion shoudl probably also mention the most obvious option (i.e. use other s= urrogates in the same CDN). Or alternatively, clarify that the considered s= ituation is where there is a partial failure of some surrogates resulting i= n the remaining surrogates being fully loaded. >>=20 >>=20 >> *** section 3.2.1: >> replace: >> " >> to both distribute load between origin servers and attempt content=20 >> acquisition from alternate origin servers when acquisition failures occu= r. When normal content acquisition fails, a CDN may need to try other orig= in server options, " >> with: >> " >> to both distribute load between content sources and attempt content=20 >> acquisition from alternate content sources when acquisition failures occ= ur. When normal content acquisition fails, a CDN may need to try other con= tent source options, " >> (I believe everywhere else we use "origin server" to refer to the OS=20 >> of the CSP and "content source" as the generic term for getting=20 >> content including origin server and uCDN) >>=20 >> *** section 3.2.2: >> replace: >> " >> the selection of content acquisition sources should be considered. >> " >> with: >> " >> the selection of content acquisition sources should be considered and fa= cilitated. >> " >> (i.e. it is not just a matter of "thinking" about it: it must be explici= tly allowed or at leads made easier). >>=20 >>=20 >> *** section 4.1: >> "to serve a proportion of its traffic that requires HTTPS." >> can you include a reference for HTTPS? >>=20 >>=20 >> *** section 5: >> replace: >> " >> An important aspect of the above use cases " >> with: >> " >> An important aspect common to all the above use cases " >>=20 >>=20 >> *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line=20 >> 618, but no explicit reference was found in the text I'd suggest you add= an explicit reference. For example, in "1. Introduction" you could replac= e: >> " >> The document can be used to guide the definition of the requirements to = be supported by the various CDNI interfaces defined in [I-D.ietf-cdni-probl= em-statement]. >> " >> by >> " >> The document can be used to guide the definition of the requirements (as= documented in [I-D.ietf-cdni-requirements]) to be supported by the set of = CDNI interfaces defined in [I-D.ietf-cdni-problem-statement]. >> " >> (BTW, independely of the reference issue, "the set of CDNI interfaces" m= ight read better than "the various CDNI interfaces"). >>=20 >>=20 >> *** The document has a disclaimer for pre-RFC5378 work, but was first s= ubmitted on or after 10 November 2008. Does it really need the disclaimer? >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From ben@niven-jenkins.co.uk Mon May 14 17:37:08 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99D021F89C9 for ; Mon, 14 May 2012 17:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.982 X-Spam-Level: X-Spam-Status: No, score=-101.982 tagged_above=-999 required=5 tests=[AWL=-2.983, BAYES_00=-2.599, GB_MUTUALBENEFIT=2, J_BACKHAIR_11=1, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUwu6TiRSiZE for ; Mon, 14 May 2012 17:37:07 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB6C21F89BC for ; Mon, 14 May 2012 17:37:07 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginmedia.com ([86.14.227.47] helo=[192.168.0.3]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SU5lB-0000nx-Gd; Tue, 15 May 2012 01:37:06 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Ben Niven-Jenkins In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF035EE117@ftrdmel0.rd.francetelecom.fr> Date: Tue, 15 May 2012 01:37:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <71F8C195-23A8-40C4-B62C-498FAD3FA69B@niven-jenkins.co.uk> References: <5388986F-034F-4E38-A5A3-78B6E30F56A5@cisco.com> <8E09C72DBC577D489F13A71228C0B7BF035ED73B@ftrdmel0.rd.francetelecom.fr> <16153976-8E12-494D-908F-A4B90E037DA8@niven-jenkins.co.uk> <8E09C72DBC577D489F13A71228C0B7BF035EE117@ftrdmel0.rd.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org Subject: Re: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss 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, 15 May 2012 00:37:09 -0000 On 14 May 2012, at 13:55, = wrote: > Hi Ben, >=20 > We can always avoid defining terms and concepts, at the price of = redundant explanations in the drafts.=20 Indeed. I guess I'm not convinced we're going to need to refer to = "access CDNs" as a special case of a CDN very much. If we do decide we = need the term I think the definition needs to be more precise about what = exactly constitutes an access CDN versus some other kind of CDN. > IMO, the term "delivering CDN" is immediately understandable: = considering a given request, the delivering CDN is the one that delivers = the requested content to the end-user. By contrast, I find the term = terminating CDN more confusing (what does it terminate?).=20 I was thinking it terminated the chain of CDNs performing the delivery. = We can call it something else (final CDN, ultimate CDN, I'm sure others = can think of more) I just think using/overloading "delivering" when = we're going to be talking about delivering content in a number of = different contexts is likely to cause confusion. Ben >=20 > Best regards, >=20 > Gilles >=20 >=20 > -----Message d'origine----- > De : Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 > Envoy=E9 : lundi 14 mai 2012 05:19 > =C0 : BERTRAND Gilles RD-CORE-ISS > Cc : flefauch@cisco.com; lpeterson@verivue.com; cdni@ietf.org > Objet : Re: [CDNi] Document Sheperd review of = draft-ietf-cdni-use-cases >=20 >=20 > On 9 May 2012, at 16:19, = wrote: >=20 >> Hi Fran=E7ois, >>=20 >> Thanks for your review. We are integrating your comments.=20 >>=20 >> About your comments on Section 1.1, I definitely think the terms = "Access CDN" and "Delivering CDN" are useful more broadly than just in = the use cases document. Therefore, I would be in favor of moving them to = the framework document as you propose. >>=20 >> Access CDN: >> A CDN that includes Surrogates in the same network (e.g., same = Autonomous System) as the End User. An Access CDN may have specific = information about >> the End User and the network, for instance, End User's >> profile and access capabilities. >=20 > Is there really something special about an "access CDN" that means we = should define a specific term for it rather than just pointing out the = "special" bits in prose when they are relevant? >=20 > I am slightly worried we start to introduce lots of quite specific = terms when in the majority of cases the "specifics" are not relevant. = For example, it seems to me that in the majority of cases we'll end up = talking about in our documents the fact an "Access CDN" may have some = more specific information won't be relevant at all. >=20 > I worry that having too many specific terms for specific use cases = actually leads to more ambiguity, not less. To demonstrate possible = ambiguities: The examples of specific information makes me wonder, is a = CDN that isn't in the same network as an End User but is integrated with = an NSP's policy control (so it has awareness of profiles/access = capabilities) an access CDN? Or, is a CDN that is in the same network as = the End User but doesn't have any specific information on = profiles/access capabilities an access CDN? >=20 >>=20 >> Delivering CDN: >> The CDN that delivers the requested piece of content to >> the End User. In particular, the Delivering CDN can be an >> Access CDN. >=20 > I'd prefer "Terminating CDN" to "Delivering CDN" because I think = delivering CDN may get confusing when we're talking about end to end = flows. For example for a given content delivery, upstream CDN(s) may = also be delivering the content to downstream CDN(s). Having some CDNs = "delivering" content and other CDNs being called "Delivering CDNs" and = expecting readers to differentiate between the two (slightly different) = uses of the term "delivering" seems likely to cause confusion IMO. >=20 > Ben >=20 >>=20 >>=20 >> Best regards, >>=20 >> Gilles >>=20 >>=20 >> -----Message d'origine----- >> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part=20= >> de Francois Le Faucheur Envoy=E9 : mercredi 25 avril 2012 18:46 =C0 :=20= >> draft-ietf-cdni-use-cases@tools.ietf.org >> Cc : cdni@ietf.org >> Objet : [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases >>=20 >> To use-cases authors, >>=20 >> Below are my shepherd review comments of cdni-uses-cases. >>=20 >> I think the document is in a good shape and captures well the key = targeted use cases. >> I identified two remaining significant points to be addressed, and = also have included many suggestions to improve the document. >> I suggest we resolve the two significant points on the list and leave = it to editor/authors to decide how to dispose of the suggestions for = improvement offline. >>=20 >> Cheers >>=20 >> Francois >>=20 >>=20 >> Significant points >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> *** section 8 security considerations >> I have a few specific issues with the current text of the Security = Considerations section. But I don't really see the need to have an = expanded Security Considerations section in both the use-case document = and the problem-statement (particularly considering that the first IESG = review comments on problem-statement suggest expanding the security = considerations section there), in particular because the security = considerations currently brought up in use-cases are not specific to = individual use cases bur rather generic to the whole CDN interconnection = problem space. >> So my proposal would be to remove the whole discussion from use-cases = (i.e. the first 4 paragraphs) and refer to the Security Considerations = section of the Problem Statement e.g.. by replacing: >> "=20 >> This document focuses on the motivational use cases for CDN = Interconnection, and does not analyze these threats in detail. >> " >> with: >> " >> This document focuses on the motivational use cases for CDN = Interconnection, and does not analyze the associated threats. Those are = discussed in [I-D.ietf-cdni-problem-statement]. >> " >>=20 >>=20 >> ***section A.1: >> I still have a problem with the text of that section. >> I thought we had converged on an agreement that the text would: >> * explain that CSPs may take into account very = multiple/arbitrary/specific criteria in their policy >> * explain that the CDNs are only expected to enforce a few = specific policy rules (e.g. geo-blocking, time window) and for = enforcement of all fancy CSP policy we propose that the responsibilities = be divided into (1) the CSP being responsible for the fancy policy = decision and (ii) the CDN for merely enforcing the CSP decision without = having to understand the policy (e.g. via URI signing). >> Do we not agree on that or not? >>=20 >> The current text says that CDN selection and surrogate selection "are = influenced by these policies" (referring to the fancy CSP policies). I = do not agree with that. I don;t think we want CDN Selection or Surrogate = selection to be influenced by whether a movie shoudl be available 14 or = 28 days after DVD release, or whether a given resolution is "too high" = for a particular user or terminal.=20 >>=20 >> Also, the paragraph keeps talking about "dCDN selection or Surrogate = selection" may fail for some fancy policy reasons. I don't understand = what it means to "fail" , but more importantly again, I don't think we = want CDN request routing decisions to be factoring very fancy CSP policy = rules. >> Do we agree or not? >>=20 >> The last paragraphs gives examples of the CSP objectives of = supporting delivery policies in CDNs, and those are fine and can be = achieved with the set of mechanisms discussed above (i.e. goeblocking + = time window + URI signing). >>=20 >>=20 >> Suggestions for improvements >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> ***Abstract >> replace "CDNI" by "CDN Interconnection". >>=20 >> *** section 1: >> expand the first instance of CDNI into "CDN Interconnection (CDNI)". >>=20 >> *** section 1: >> "Then, the document highlights the need for interoperability to =20 >> exchange and enforce content delivery policies (Section 5)." >> I'd suggest replacing "for interoperability to exchange" by "for = interoperability to allow exchange" or by "for interoperability in order = to exchange" >>=20 >> *** section 1.1: >> Do you feel that the two additional terms are really specific to the = use-case document (in which case their definition should stay in this = document) or are they likely useful in other documents (in which case = their definition should be migrated to the framework document)? >> Personally, I would say that those terms might be useful in other = documents/discussions (eg I am pretty sure we'd need to refer to the = "Delivering CDN" in other context). >>=20 >> *** section 1.1: >> "Access CDN: >> A CDN that is directly connected to the End User's access." >> I think this definition needs to be a little more specific. "Directly = connected" does not mean "L2 connectivity" (because an on-net cache = maybe a few L2 hops away), nor does it mean "L3 connectivity" (because = an OTT CDN cache has IP connectivity to an enduser). I think you mean = something in between, more or less that the CDN and the access are = within the same IP administrative domain, or something close to that. = Can you try refine that definition? >>=20 >> *** section 1.3: >> " o improve the experience for the End User; for instance delivery = has >> lower latency (decreased round-trip-time between the user and the >> delivery server) and better robustness," >> To be more comprehensive in justifying the claims, how about: >> " o improve the experience for the End User; for instance delivery = has >> lower latency (decreased round-trip-time and higher throughput = between the user and the >> delivery server) and better robustness (ability to use multiple = delivery servers)," >>=20 >> *** section 1.3: >> "o reduce the Content Service Provider's (CSP) costs, such as >> datacenter capacity, space, and electricity consumption, as >> popular content is delivered through the CDN rather than through >> the CSP's servers." >> The current wording raises the question of "if it reduces the costs = by reducing expenses in the CSP datacenter, why does it not = correspondingly increase the cost by increasing expenses in the CDN = (which the CDN provider then charges back to the CSP)?" >> I think the gain is in the scale and effective pooling of CDN = resources across many CSPs. Could you refine the wording to explain why = there is indeed a net gain? >>=20 >> *** section 1.3: >> Replace: >> " >> An example is depicted in Figure 1. Two CDN Providers establish a = CDN Interconnection. >> " >> with: >> " >> An example is depicted in Figure 1 where two CDN Providers establish = a CDN Interconnection. >> " >> (this is to minimize the redundancy with the sentence coming below:=20= >> "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their=20 >> CDNs.") >>=20 >>=20 >> *** section 1.3: >> replace: >> " >> "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their = CDNs." >> with: >> "Independently, CDN Provider 'A' and CDN Provider 'B' agree to = interconnect their CDNs." >> this is to clarify that the A<->B agreement is not specific to the=20 >> 1<->A agreement >>=20 >>=20 >> *** section 1.3: >> replace: >> " >> When a User Agent requests content from CSP-1, CDN-A considers that = delivery by CDN-B is appropriate " >> with: >> " >> When a given User Agent requests content from CSP-1, CDN-A may = consider that delivery by CDN-B is appropriate " >>=20 >>=20 >> *** section 1.3: >> replace: >> " >> CDN-A has delegated the handling of requests for CSP-1's content = through the CDN Interconnection agreement, thus, the content is actually = delivered from CDN-B. >> " >> with: >> " >> Through the CDN Interconnection arrangements put in place between = CDN-A and CDN-B (as a result of the CDN Interconnection agreement = established between CDN Provider 'A' and CDN Provider 'B'), CDN-A can = redirect the request to CDN-B and the content is actually delivered to = the User Agent by CDN-B. >> " >> (the current wording suggests that all deliveries of CSP1 content=20 >> would be handled by CDN-B, which is typically not the case i.e. only = a=20 >> subset of the requests are redirected thy CDN-A to CDN-B) >>=20 >>=20 >> *** section 1.3: >> replace: >> " >> CSP-1 benefits because it only needs to make one business agreement = and one physical connection, with CDN Provider 'A' >> " >> with: >> " >> CSP-1 benefits because it only needs to make one business agreement = and one technical arrangement with CDN Provider 'A' >> " >> (this is because the interfacing between CSP and uCDN comprises more = than "physical connection"). >>=20 >>=20 >> *** section 1.3: >> replace: >> " >> CSP-1 had also gone to the trouble of making a business agreement = with CDN Provider 'B' >> " >> with: >> " >> CSP-1 had also gone to the trouble of making a business agreement and = technical arrangemement with CDN Provider 'B' >> " >>=20 >> *** section 1.3: >> replace: >> " >> But it does not want >> " >> with: >> " >> However, CSP-2 may not want >> " >>=20 >> *** section 2.1: >> after >> " >> o without incurring additional transit and other network costs that >> would result from serving content from geographically or >> topologically remote Surrogates. >> " >> add: >> " >> o without incurring the cost of deploying and operating Surrogates = and the associated CDN infrastructure that may not be justified in the = corresponding geographic region (e.g. because of relatively low delivery = volume, or conversely because of the high investments that would be = needed to satisfy the high volume) " >>=20 >>=20 >> *** section 2.2: >> replace: >> " >> A large CDN Provider may also operate CDNs from several subsidiaries = (which may rely on different CDN technologies, see Section 4.2). In = certain circumstances, the CDN Provider needs to make its CDNs = interoperate to provide a consistent service to its customers on its = whole footprint. >> " >> with: >> " >> A large CDN Provider may have several subsidiaries that also each = operate their own CDN (which may rely on different CDN technologies, see = Section 4.2). In certain circumstances, the CDN Provider needs to make = these CDNs interoperate to provide a consistent service to its customers = on the whole collective footprint.=20 >> " >>=20 >>=20 >> *** section 2.3: >> replace: >> " >> injected into the access network >> " >> with: >> " >> injected into the ISP network >> " >>=20 >> *** section 2.3: >> replace: >> " >> There are mutual benefits to the Access CDN, " >> with: >> " >> There are mutual benefits to the ISP (acting as an Access CDN), " >>=20 >>=20 >> *** section 2.3: >> replace: >> " >> for example, QoS and reduced round trip time. >> " >> with: >> " >> for example, reduced content startup time or increased video quality = and resolution of adaptive streaming content. >> " >> (I don't think RTT is very meaningful to a CSP customer) >>=20 >>=20 >> *** section 2.4: >> The nomadic user is currently defined as "moving between CDNs" which = is sort of a self-serving definition to justify CDN interconnection. I = think we should rather define the nomadic user as "moving between access = networks" and then justify that leveraging local CDNs can bring a lot of = benefits. >> This requires the following text edits: >> s/who move between CDNs/who move between access networks/ s/moving=20 >> between different CDN Providers/moving between different access=20 >> networks/ >>=20 >> *** section 2.4: >> replace: >> " >> which may reside >> " >> with: >> " >> which may be located >> " >>=20 >> *** section 2.4:" >> I propose to remove the sentence: >> " >> The term "Nomadic" does not necessarily relate to geographic roaming. >> " >> because this point has already been fully (and better) clarified in = the preceding paragraph. >>=20 >>=20 >>=20 >> *** section 2.4: >> replace: >> " >> the WiFi or mobile provider >> " >> with: >> " >> the WiFi or mobile provider (NSP B) >> " >>=20 >>=20 >> *** section 3.1: >> replace: >> " >> needs CDN capacities >> " >> with: >> " >> needs CDN capacity >> " >>=20 >> *** section 3.2.1: >> The text mentions two options (use OS, use another CDN). I think the = section shoudl probably also mention the most obvious option (i.e. use = other surrogates in the same CDN). Or alternatively, clarify that the = considered situation is where there is a partial failure of some = surrogates resulting in the remaining surrogates being fully loaded. >>=20 >>=20 >> *** section 3.2.1: >> replace: >> " >> to both distribute load between origin servers and attempt content=20 >> acquisition from alternate origin servers when acquisition failures = occur. When normal content acquisition fails, a CDN may need to try = other origin server options, " >> with: >> " >> to both distribute load between content sources and attempt content=20= >> acquisition from alternate content sources when acquisition failures = occur. When normal content acquisition fails, a CDN may need to try = other content source options, " >> (I believe everywhere else we use "origin server" to refer to the OS=20= >> of the CSP and "content source" as the generic term for getting=20 >> content including origin server and uCDN) >>=20 >> *** section 3.2.2: >> replace: >> " >> the selection of content acquisition sources should be considered. >> " >> with: >> " >> the selection of content acquisition sources should be considered and = facilitated. >> " >> (i.e. it is not just a matter of "thinking" about it: it must be = explicitly allowed or at leads made easier). >>=20 >>=20 >> *** section 4.1: >> "to serve a proportion of its traffic that requires HTTPS." >> can you include a reference for HTTPS? >>=20 >>=20 >> *** section 5: >> replace: >> " >> An important aspect of the above use cases " >> with: >> " >> An important aspect common to all the above use cases " >>=20 >>=20 >> *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line=20= >> 618, but no explicit reference was found in the text I'd suggest you = add an explicit reference. For example, in "1. Introduction" you could = replace: >> " >> The document can be used to guide the definition of the requirements = to be supported by the various CDNI interfaces defined in = [I-D.ietf-cdni-problem-statement]. >> " >> by >> " >> The document can be used to guide the definition of the requirements = (as documented in [I-D.ietf-cdni-requirements]) to be supported by the = set of CDNI interfaces defined in [I-D.ietf-cdni-problem-statement]. >> " >> (BTW, independely of the reference issue, "the set of CDNI = interfaces" might read better than "the various CDNI interfaces"). >>=20 >>=20 >> *** The document has a disclaimer for pre-RFC5378 work, but was first = submitted on or after 10 November 2008. Does it really need the = disclaimer? >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 From gilles.bertrand@orange.com Wed May 16 02:25:17 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAEFC21F8833 for ; Wed, 16 May 2012 02:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_MUTUALBENEFIT=2, HELO_EQ_FR=0.35, J_BACKHAIR_11=1, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwRh15tbRg1W for ; Wed, 16 May 2012 02:25:14 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD0A21F8834 for ; Wed, 16 May 2012 02:25:13 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2274F1074007; Wed, 16 May 2012 11:25:34 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 17F201074003; Wed, 16 May 2012 11:25:34 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 May 2012 11:25:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 May 2012 11:25:11 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF0362F63D@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <71F8C195-23A8-40C4-B62C-498FAD3FA69B@niven-jenkins.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases Thread-Index: Ac0yMtuMDKkRSQnOQQStiUrsTOr9gQBEXaxQ References: <5388986F-034F-4E38-A5A3-78B6E30F56A5@cisco.com> <8E09C72DBC577D489F13A71228C0B7BF035ED73B@ftrdmel0.rd.francetelecom.fr> <16153976-8E12-494D-908F-A4B90E037DA8@niven-jenkins.co.uk> <8E09C72DBC577D489F13A71228C0B7BF035EE117@ftrdmel0.rd.francetelecom.fr> <71F8C195-23A8-40C4-B62C-498FAD3FA69B@niven-jenkins.co.uk> From: To: X-OriginalArrivalTime: 16 May 2012 09:25:11.0870 (UTC) FILETIME=[CB3635E0:01CD3345] Cc: cdni@ietf.org Subject: Re: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss 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, 16 May 2012 09:25:17 -0000 Hi Ben, Maybe we should keep the term Access CDN in the use cases draft then, = and move only the definition of the "Delivering" CDN into the problem = statement. We will clarify the definition of Access CDN. Best regards, Gilles -----Message d'origine----- De=A0: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 Envoy=E9=A0: mardi 15 mai 2012 02:37 =C0=A0: BERTRAND Gilles RD-CORE-ISS Cc=A0: flefauch@cisco.com; lpeterson@verivue.com; cdni@ietf.org Objet=A0: Re: [CDNi] Document Sheperd review of = draft-ietf-cdni-use-cases On 14 May 2012, at 13:55, = wrote: > Hi Ben, >=20 > We can always avoid defining terms and concepts, at the price of = redundant explanations in the drafts.=20 Indeed. I guess I'm not convinced we're going to need to refer to = "access CDNs" as a special case of a CDN very much. If we do decide we = need the term I think the definition needs to be more precise about what = exactly constitutes an access CDN versus some other kind of CDN. > IMO, the term "delivering CDN" is immediately understandable: = considering a given request, the delivering CDN is the one that delivers = the requested content to the end-user. By contrast, I find the term = terminating CDN more confusing (what does it terminate?).=20 I was thinking it terminated the chain of CDNs performing the delivery. = We can call it something else (final CDN, ultimate CDN, I'm sure others = can think of more) I just think using/overloading "delivering" when = we're going to be talking about delivering content in a number of = different contexts is likely to cause confusion. Ben >=20 > Best regards, >=20 > Gilles >=20 >=20 > -----Message d'origine----- > De : Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] Envoy=E9 : = lundi=20 > 14 mai 2012 05:19 =C0 : BERTRAND Gilles RD-CORE-ISS Cc :=20 > flefauch@cisco.com; lpeterson@verivue.com; cdni@ietf.org Objet : Re:=20 > [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases >=20 >=20 > On 9 May 2012, at 16:19, = wrote: >=20 >> Hi Fran=E7ois, >>=20 >> Thanks for your review. We are integrating your comments.=20 >>=20 >> About your comments on Section 1.1, I definitely think the terms = "Access CDN" and "Delivering CDN" are useful more broadly than just in = the use cases document. Therefore, I would be in favor of moving them to = the framework document as you propose. >>=20 >> Access CDN: >> A CDN that includes Surrogates in the same network (e.g., same = Autonomous System) as the End User. An Access CDN may have specific = information about >> the End User and the network, for instance, End User's >> profile and access capabilities. >=20 > Is there really something special about an "access CDN" that means we = should define a specific term for it rather than just pointing out the = "special" bits in prose when they are relevant? >=20 > I am slightly worried we start to introduce lots of quite specific = terms when in the majority of cases the "specifics" are not relevant. = For example, it seems to me that in the majority of cases we'll end up = talking about in our documents the fact an "Access CDN" may have some = more specific information won't be relevant at all. >=20 > I worry that having too many specific terms for specific use cases = actually leads to more ambiguity, not less. To demonstrate possible = ambiguities: The examples of specific information makes me wonder, is a = CDN that isn't in the same network as an End User but is integrated with = an NSP's policy control (so it has awareness of profiles/access = capabilities) an access CDN? Or, is a CDN that is in the same network as = the End User but doesn't have any specific information on = profiles/access capabilities an access CDN? >=20 >>=20 >> Delivering CDN: >> The CDN that delivers the requested piece of content to >> the End User. In particular, the Delivering CDN can be an >> Access CDN. >=20 > I'd prefer "Terminating CDN" to "Delivering CDN" because I think = delivering CDN may get confusing when we're talking about end to end = flows. For example for a given content delivery, upstream CDN(s) may = also be delivering the content to downstream CDN(s). Having some CDNs = "delivering" content and other CDNs being called "Delivering CDNs" and = expecting readers to differentiate between the two (slightly different) = uses of the term "delivering" seems likely to cause confusion IMO. >=20 > Ben >=20 >>=20 >>=20 >> Best regards, >>=20 >> Gilles >>=20 >>=20 >> -----Message d'origine----- >> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part=20 >> de Francois Le Faucheur Envoy=E9 : mercredi 25 avril 2012 18:46 =C0 : >> draft-ietf-cdni-use-cases@tools.ietf.org >> Cc : cdni@ietf.org >> Objet : [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases >>=20 >> To use-cases authors, >>=20 >> Below are my shepherd review comments of cdni-uses-cases. >>=20 >> I think the document is in a good shape and captures well the key = targeted use cases. >> I identified two remaining significant points to be addressed, and = also have included many suggestions to improve the document. >> I suggest we resolve the two significant points on the list and leave = it to editor/authors to decide how to dispose of the suggestions for = improvement offline. >>=20 >> Cheers >>=20 >> Francois >>=20 >>=20 >> Significant points >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> *** section 8 security considerations I have a few specific issues=20 >> with the current text of the Security Considerations section. But I = don't really see the need to have an expanded Security Considerations = section in both the use-case document and the problem-statement = (particularly considering that the first IESG review comments on = problem-statement suggest expanding the security considerations section = there), in particular because the security considerations currently = brought up in use-cases are not specific to individual use cases bur = rather generic to the whole CDN interconnection problem space. >> So my proposal would be to remove the whole discussion from use-cases = (i.e. the first 4 paragraphs) and refer to the Security Considerations = section of the Problem Statement e.g.. by replacing: >> "=20 >> This document focuses on the motivational use cases for CDN = Interconnection, and does not analyze these threats in detail. >> " >> with: >> " >> This document focuses on the motivational use cases for CDN = Interconnection, and does not analyze the associated threats. Those are = discussed in [I-D.ietf-cdni-problem-statement]. >> " >>=20 >>=20 >> ***section A.1: >> I still have a problem with the text of that section. >> I thought we had converged on an agreement that the text would: >> * explain that CSPs may take into account very = multiple/arbitrary/specific criteria in their policy >> * explain that the CDNs are only expected to enforce a few specific = policy rules (e.g. geo-blocking, time window) and for enforcement of all = fancy CSP policy we propose that the responsibilities be divided into = (1) the CSP being responsible for the fancy policy decision and (ii) the = CDN for merely enforcing the CSP decision without having to understand = the policy (e.g. via URI signing). >> Do we not agree on that or not? >>=20 >> The current text says that CDN selection and surrogate selection "are = influenced by these policies" (referring to the fancy CSP policies). I = do not agree with that. I don;t think we want CDN Selection or Surrogate = selection to be influenced by whether a movie shoudl be available 14 or = 28 days after DVD release, or whether a given resolution is "too high" = for a particular user or terminal.=20 >>=20 >> Also, the paragraph keeps talking about "dCDN selection or Surrogate = selection" may fail for some fancy policy reasons. I don't understand = what it means to "fail" , but more importantly again, I don't think we = want CDN request routing decisions to be factoring very fancy CSP policy = rules. >> Do we agree or not? >>=20 >> The last paragraphs gives examples of the CSP objectives of = supporting delivery policies in CDNs, and those are fine and can be = achieved with the set of mechanisms discussed above (i.e. goeblocking + = time window + URI signing). >>=20 >>=20 >> Suggestions for improvements >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> ***Abstract >> replace "CDNI" by "CDN Interconnection". >>=20 >> *** section 1: >> expand the first instance of CDNI into "CDN Interconnection (CDNI)". >>=20 >> *** section 1: >> "Then, the document highlights the need for interoperability to=20 >> exchange and enforce content delivery policies (Section 5)." >> I'd suggest replacing "for interoperability to exchange" by "for = interoperability to allow exchange" or by "for interoperability in order = to exchange" >>=20 >> *** section 1.1: >> Do you feel that the two additional terms are really specific to the = use-case document (in which case their definition should stay in this = document) or are they likely useful in other documents (in which case = their definition should be migrated to the framework document)? >> Personally, I would say that those terms might be useful in other = documents/discussions (eg I am pretty sure we'd need to refer to the = "Delivering CDN" in other context). >>=20 >> *** section 1.1: >> "Access CDN: >> A CDN that is directly connected to the End User's access." >> I think this definition needs to be a little more specific. "Directly = connected" does not mean "L2 connectivity" (because an on-net cache = maybe a few L2 hops away), nor does it mean "L3 connectivity" (because = an OTT CDN cache has IP connectivity to an enduser). I think you mean = something in between, more or less that the CDN and the access are = within the same IP administrative domain, or something close to that. = Can you try refine that definition? >>=20 >> *** section 1.3: >> " o improve the experience for the End User; for instance delivery = has >> lower latency (decreased round-trip-time between the user and the >> delivery server) and better robustness," >> To be more comprehensive in justifying the claims, how about: >> " o improve the experience for the End User; for instance delivery = has >> lower latency (decreased round-trip-time and higher throughput = between the user and the >> delivery server) and better robustness (ability to use multiple = delivery servers)," >>=20 >> *** section 1.3: >> "o reduce the Content Service Provider's (CSP) costs, such as >> datacenter capacity, space, and electricity consumption, as >> popular content is delivered through the CDN rather than through >> the CSP's servers." >> The current wording raises the question of "if it reduces the costs = by reducing expenses in the CSP datacenter, why does it not = correspondingly increase the cost by increasing expenses in the CDN = (which the CDN provider then charges back to the CSP)?" >> I think the gain is in the scale and effective pooling of CDN = resources across many CSPs. Could you refine the wording to explain why = there is indeed a net gain? >>=20 >> *** section 1.3: >> Replace: >> " >> An example is depicted in Figure 1. Two CDN Providers establish a = CDN Interconnection. >> " >> with: >> " >> An example is depicted in Figure 1 where two CDN Providers establish = a CDN Interconnection. >> " >> (this is to minimize the redundancy with the sentence coming below:=20 >> "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their >> CDNs.") >>=20 >>=20 >> *** section 1.3: >> replace: >> " >> "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their = CDNs." >> with: >> "Independently, CDN Provider 'A' and CDN Provider 'B' agree to = interconnect their CDNs." >> this is to clarify that the A<->B agreement is not specific to the=20 >> 1<->A agreement >>=20 >>=20 >> *** section 1.3: >> replace: >> " >> When a User Agent requests content from CSP-1, CDN-A considers that = delivery by CDN-B is appropriate " >> with: >> " >> When a given User Agent requests content from CSP-1, CDN-A may = consider that delivery by CDN-B is appropriate " >>=20 >>=20 >> *** section 1.3: >> replace: >> " >> CDN-A has delegated the handling of requests for CSP-1's content = through the CDN Interconnection agreement, thus, the content is actually = delivered from CDN-B. >> " >> with: >> " >> Through the CDN Interconnection arrangements put in place between = CDN-A and CDN-B (as a result of the CDN Interconnection agreement = established between CDN Provider 'A' and CDN Provider 'B'), CDN-A can = redirect the request to CDN-B and the content is actually delivered to = the User Agent by CDN-B. >> " >> (the current wording suggests that all deliveries of CSP1 content=20 >> would be handled by CDN-B, which is typically not the case i.e. only=20 >> a subset of the requests are redirected thy CDN-A to CDN-B) >>=20 >>=20 >> *** section 1.3: >> replace: >> " >> CSP-1 benefits because it only needs to make one business agreement = and one physical connection, with CDN Provider 'A' >> " >> with: >> " >> CSP-1 benefits because it only needs to make one business agreement = and one technical arrangement with CDN Provider 'A' >> " >> (this is because the interfacing between CSP and uCDN comprises more = than "physical connection"). >>=20 >>=20 >> *** section 1.3: >> replace: >> " >> CSP-1 had also gone to the trouble of making a business agreement = with CDN Provider 'B' >> " >> with: >> " >> CSP-1 had also gone to the trouble of making a business agreement and = technical arrangemement with CDN Provider 'B' >> " >>=20 >> *** section 1.3: >> replace: >> " >> But it does not want >> " >> with: >> " >> However, CSP-2 may not want >> " >>=20 >> *** section 2.1: >> after >> " >> o without incurring additional transit and other network costs that >> would result from serving content from geographically or >> topologically remote Surrogates. >> " >> add: >> " >> o without incurring the cost of deploying and operating Surrogates = and the associated CDN infrastructure that may not be justified in the = corresponding geographic region (e.g. because of relatively low delivery = volume, or conversely because of the high investments that would be = needed to satisfy the high volume) " >>=20 >>=20 >> *** section 2.2: >> replace: >> " >> A large CDN Provider may also operate CDNs from several subsidiaries = (which may rely on different CDN technologies, see Section 4.2). In = certain circumstances, the CDN Provider needs to make its CDNs = interoperate to provide a consistent service to its customers on its = whole footprint. >> " >> with: >> " >> A large CDN Provider may have several subsidiaries that also each = operate their own CDN (which may rely on different CDN technologies, see = Section 4.2). In certain circumstances, the CDN Provider needs to make = these CDNs interoperate to provide a consistent service to its customers = on the whole collective footprint.=20 >> " >>=20 >>=20 >> *** section 2.3: >> replace: >> " >> injected into the access network >> " >> with: >> " >> injected into the ISP network >> " >>=20 >> *** section 2.3: >> replace: >> " >> There are mutual benefits to the Access CDN, " >> with: >> " >> There are mutual benefits to the ISP (acting as an Access CDN), " >>=20 >>=20 >> *** section 2.3: >> replace: >> " >> for example, QoS and reduced round trip time. >> " >> with: >> " >> for example, reduced content startup time or increased video quality = and resolution of adaptive streaming content. >> " >> (I don't think RTT is very meaningful to a CSP customer) >>=20 >>=20 >> *** section 2.4: >> The nomadic user is currently defined as "moving between CDNs" which = is sort of a self-serving definition to justify CDN interconnection. I = think we should rather define the nomadic user as "moving between access = networks" and then justify that leveraging local CDNs can bring a lot of = benefits. >> This requires the following text edits: >> s/who move between CDNs/who move between access networks/ s/moving=20 >> between different CDN Providers/moving between different access=20 >> networks/ >>=20 >> *** section 2.4: >> replace: >> " >> which may reside >> " >> with: >> " >> which may be located >> " >>=20 >> *** section 2.4:" >> I propose to remove the sentence: >> " >> The term "Nomadic" does not necessarily relate to geographic roaming. >> " >> because this point has already been fully (and better) clarified in = the preceding paragraph. >>=20 >>=20 >>=20 >> *** section 2.4: >> replace: >> " >> the WiFi or mobile provider >> " >> with: >> " >> the WiFi or mobile provider (NSP B) >> " >>=20 >>=20 >> *** section 3.1: >> replace: >> " >> needs CDN capacities >> " >> with: >> " >> needs CDN capacity >> " >>=20 >> *** section 3.2.1: >> The text mentions two options (use OS, use another CDN). I think the = section shoudl probably also mention the most obvious option (i.e. use = other surrogates in the same CDN). Or alternatively, clarify that the = considered situation is where there is a partial failure of some = surrogates resulting in the remaining surrogates being fully loaded. >>=20 >>=20 >> *** section 3.2.1: >> replace: >> " >> to both distribute load between origin servers and attempt content=20 >> acquisition from alternate origin servers when acquisition failures = occur. When normal content acquisition fails, a CDN may need to try = other origin server options, " >> with: >> " >> to both distribute load between content sources and attempt content=20 >> acquisition from alternate content sources when acquisition failures = occur. When normal content acquisition fails, a CDN may need to try = other content source options, " >> (I believe everywhere else we use "origin server" to refer to the OS=20 >> of the CSP and "content source" as the generic term for getting=20 >> content including origin server and uCDN) >>=20 >> *** section 3.2.2: >> replace: >> " >> the selection of content acquisition sources should be considered. >> " >> with: >> " >> the selection of content acquisition sources should be considered and = facilitated. >> " >> (i.e. it is not just a matter of "thinking" about it: it must be = explicitly allowed or at leads made easier). >>=20 >>=20 >> *** section 4.1: >> "to serve a proportion of its traffic that requires HTTPS." >> can you include a reference for HTTPS? >>=20 >>=20 >> *** section 5: >> replace: >> " >> An important aspect of the above use cases " >> with: >> " >> An important aspect common to all the above use cases " >>=20 >>=20 >> *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line = >> 618, but no explicit reference was found in the text I'd suggest you = add an explicit reference. For example, in "1. Introduction" you could = replace: >> " >> The document can be used to guide the definition of the requirements = to be supported by the various CDNI interfaces defined in = [I-D.ietf-cdni-problem-statement]. >> " >> by >> " >> The document can be used to guide the definition of the requirements = (as documented in [I-D.ietf-cdni-requirements]) to be supported by the = set of CDNI interfaces defined in [I-D.ietf-cdni-problem-statement]. >> " >> (BTW, independely of the reference issue, "the set of CDNI = interfaces" might read better than "the various CDNI interfaces"). >>=20 >>=20 >> *** The document has a disclaimer for pre-RFC5378 work, but was first = submitted on or after 10 November 2008. Does it really need the = disclaimer? >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 From flefauch@cisco.com Wed May 16 08:38:53 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745FD21F85DD for ; Wed, 16 May 2012 08:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_MUTUALBENEFIT=2, J_BACKHAIR_11=1, J_CHICKENPOX_31=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 Z2qJVK70m8AX for ; Wed, 16 May 2012 08:38:51 -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 5015D21F85D7 for ; Wed, 16 May 2012 08:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=21363; q=dns/txt; s=iport; t=1337182731; x=1338392331; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=eIFzEu7PM1NHs2SunrTXCaKx4XZEA6MmQS7hkCfvQzI=; b=UGkFc+ivDtsVQ41W9FYpoOjef0QsE32qWi+4I42jf85R8TNbWaGo2ue8 dDqZRm3CH/U1x5Xp8z/gugOE6DpIZ+hCGasvgCUzl/Z36JC6UcP7dT1oi 3IAnoqP7TAgzBLB+BenSxyglIAR2I5HaCSsvvUbwPmaLdn0DyjGHsClEo w=; X-IronPort-AV: E=Sophos;i="4.75,603,1330905600"; d="scan'208";a="83796580" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 16 May 2012 15:38:51 +0000 Received: from dhcp-64-100-116-89.cisco.com (dhcp-64-100-116-89.cisco.com [64.100.116.89]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q4GFco9e008604; Wed, 16 May 2012 15:38:50 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Francois Le Faucheur In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF0362F63D@ftrdmel0.rd.francetelecom.fr> Date: Wed, 16 May 2012 11:38:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <55997331-ACD6-4CD6-90B6-CDD3F87F518D@cisco.com> References: <5388986F-034F-4E38-A5A3-78B6E30F56A5@cisco.com> <8E09C72DBC577D489F13A71228C0B7BF035ED73B@ftrdmel0.rd.francetelecom.fr> <16153976-8E12-494D-908F-A4B90E037DA8@niven-jenkins.co.uk> <8E09C72DBC577D489F13A71228C0B7BF035EE117@ftrdmel0.rd.francetelecom.fr> <71F8C195-23A8-40C4-B62C-498FAD3FA69B@niven-jenkins.co.uk> <8E09C72DBC577D489F13A71228C0B7BF0362F63D@ftrdmel0.rd.francetelecom.fr> To: "" X-Mailer: Apple Mail (2.1278) Cc: cdni@ietf.org Subject: Re: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss 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, 16 May 2012 15:38:53 -0000 Gilles, Ben, Larry, On 16 May 2012, at 05:25, = wrote: > Hi Ben, >=20 > Maybe we should keep the term Access CDN in the use cases draft then, I support that. > and move only the definition of the "Delivering" CDN into the problem = statement. Actually, let's have this term included in the Framework I-D rather (the = problem statement has been posted already and does not actually need = that definition). Thanks Francois >=20 > We will clarify the definition of Access CDN. >=20 > Best regards, >=20 > Gilles >=20 >=20 > -----Message d'origine----- > De : Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 > Envoy=E9 : mardi 15 mai 2012 02:37 > =C0 : BERTRAND Gilles RD-CORE-ISS > Cc : flefauch@cisco.com; lpeterson@verivue.com; cdni@ietf.org > Objet : Re: [CDNi] Document Sheperd review of = draft-ietf-cdni-use-cases >=20 >=20 > On 14 May 2012, at 13:55, = wrote: >=20 >> Hi Ben, >>=20 >> We can always avoid defining terms and concepts, at the price of = redundant explanations in the drafts.=20 >=20 > Indeed. I guess I'm not convinced we're going to need to refer to = "access CDNs" as a special case of a CDN very much. If we do decide we = need the term I think the definition needs to be more precise about what = exactly constitutes an access CDN versus some other kind of CDN. >=20 >> IMO, the term "delivering CDN" is immediately understandable: = considering a given request, the delivering CDN is the one that delivers = the requested content to the end-user. By contrast, I find the term = terminating CDN more confusing (what does it terminate?).=20 >=20 > I was thinking it terminated the chain of CDNs performing the = delivery. We can call it something else (final CDN, ultimate CDN, I'm = sure others can think of more) I just think using/overloading = "delivering" when we're going to be talking about delivering content in = a number of different contexts is likely to cause confusion. >=20 > Ben >=20 >>=20 >> Best regards, >>=20 >> Gilles >>=20 >>=20 >> -----Message d'origine----- >> De : Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] Envoy=E9 : = lundi=20 >> 14 mai 2012 05:19 =C0 : BERTRAND Gilles RD-CORE-ISS Cc :=20 >> flefauch@cisco.com; lpeterson@verivue.com; cdni@ietf.org Objet : Re:=20= >> [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases >>=20 >>=20 >> On 9 May 2012, at 16:19, = wrote: >>=20 >>> Hi Fran=E7ois, >>>=20 >>> Thanks for your review. We are integrating your comments.=20 >>>=20 >>> About your comments on Section 1.1, I definitely think the terms = "Access CDN" and "Delivering CDN" are useful more broadly than just in = the use cases document. Therefore, I would be in favor of moving them to = the framework document as you propose. >>>=20 >>> Access CDN: >>> A CDN that includes Surrogates in the same network (e.g., same = Autonomous System) as the End User. An Access CDN may have specific = information about >>> the End User and the network, for instance, End User's >>> profile and access capabilities. >>=20 >> Is there really something special about an "access CDN" that means we = should define a specific term for it rather than just pointing out the = "special" bits in prose when they are relevant? >>=20 >> I am slightly worried we start to introduce lots of quite specific = terms when in the majority of cases the "specifics" are not relevant. = For example, it seems to me that in the majority of cases we'll end up = talking about in our documents the fact an "Access CDN" may have some = more specific information won't be relevant at all. >>=20 >> I worry that having too many specific terms for specific use cases = actually leads to more ambiguity, not less. To demonstrate possible = ambiguities: The examples of specific information makes me wonder, is a = CDN that isn't in the same network as an End User but is integrated with = an NSP's policy control (so it has awareness of profiles/access = capabilities) an access CDN? Or, is a CDN that is in the same network as = the End User but doesn't have any specific information on = profiles/access capabilities an access CDN? >>=20 >>>=20 >>> Delivering CDN: >>> The CDN that delivers the requested piece of content to >>> the End User. In particular, the Delivering CDN can be an >>> Access CDN. >>=20 >> I'd prefer "Terminating CDN" to "Delivering CDN" because I think = delivering CDN may get confusing when we're talking about end to end = flows. For example for a given content delivery, upstream CDN(s) may = also be delivering the content to downstream CDN(s). Having some CDNs = "delivering" content and other CDNs being called "Delivering CDNs" and = expecting readers to differentiate between the two (slightly different) = uses of the term "delivering" seems likely to cause confusion IMO. >>=20 >> Ben >>=20 >>>=20 >>>=20 >>> Best regards, >>>=20 >>> Gilles >>>=20 >>>=20 >>> -----Message d'origine----- >>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part=20= >>> de Francois Le Faucheur Envoy=E9 : mercredi 25 avril 2012 18:46 =C0 = : >>> draft-ietf-cdni-use-cases@tools.ietf.org >>> Cc : cdni@ietf.org >>> Objet : [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases >>>=20 >>> To use-cases authors, >>>=20 >>> Below are my shepherd review comments of cdni-uses-cases. >>>=20 >>> I think the document is in a good shape and captures well the key = targeted use cases. >>> I identified two remaining significant points to be addressed, and = also have included many suggestions to improve the document. >>> I suggest we resolve the two significant points on the list and = leave it to editor/authors to decide how to dispose of the suggestions = for improvement offline. >>>=20 >>> Cheers >>>=20 >>> Francois >>>=20 >>>=20 >>> Significant points >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> *** section 8 security considerations I have a few specific issues=20= >>> with the current text of the Security Considerations section. But I = don't really see the need to have an expanded Security Considerations = section in both the use-case document and the problem-statement = (particularly considering that the first IESG review comments on = problem-statement suggest expanding the security considerations section = there), in particular because the security considerations currently = brought up in use-cases are not specific to individual use cases bur = rather generic to the whole CDN interconnection problem space. >>> So my proposal would be to remove the whole discussion from = use-cases (i.e. the first 4 paragraphs) and refer to the Security = Considerations section of the Problem Statement e.g.. by replacing: >>> "=20 >>> This document focuses on the motivational use cases for CDN = Interconnection, and does not analyze these threats in detail. >>> " >>> with: >>> " >>> This document focuses on the motivational use cases for CDN = Interconnection, and does not analyze the associated threats. Those are = discussed in [I-D.ietf-cdni-problem-statement]. >>> " >>>=20 >>>=20 >>> ***section A.1: >>> I still have a problem with the text of that section. >>> I thought we had converged on an agreement that the text would: >>> * explain that CSPs may take into account very = multiple/arbitrary/specific criteria in their policy >>> * explain that the CDNs are only expected to enforce a few = specific policy rules (e.g. geo-blocking, time window) and for = enforcement of all fancy CSP policy we propose that the responsibilities = be divided into (1) the CSP being responsible for the fancy policy = decision and (ii) the CDN for merely enforcing the CSP decision without = having to understand the policy (e.g. via URI signing). >>> Do we not agree on that or not? >>>=20 >>> The current text says that CDN selection and surrogate selection = "are influenced by these policies" (referring to the fancy CSP = policies). I do not agree with that. I don;t think we want CDN Selection = or Surrogate selection to be influenced by whether a movie shoudl be = available 14 or 28 days after DVD release, or whether a given resolution = is "too high" for a particular user or terminal.=20 >>>=20 >>> Also, the paragraph keeps talking about "dCDN selection or Surrogate = selection" may fail for some fancy policy reasons. I don't understand = what it means to "fail" , but more importantly again, I don't think we = want CDN request routing decisions to be factoring very fancy CSP policy = rules. >>> Do we agree or not? >>>=20 >>> The last paragraphs gives examples of the CSP objectives of = supporting delivery policies in CDNs, and those are fine and can be = achieved with the set of mechanisms discussed above (i.e. goeblocking + = time window + URI signing). >>>=20 >>>=20 >>> Suggestions for improvements >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> ***Abstract >>> replace "CDNI" by "CDN Interconnection". >>>=20 >>> *** section 1: >>> expand the first instance of CDNI into "CDN Interconnection (CDNI)". >>>=20 >>> *** section 1: >>> "Then, the document highlights the need for interoperability to=20 >>> exchange and enforce content delivery policies (Section 5)." >>> I'd suggest replacing "for interoperability to exchange" by "for = interoperability to allow exchange" or by "for interoperability in order = to exchange" >>>=20 >>> *** section 1.1: >>> Do you feel that the two additional terms are really specific to the = use-case document (in which case their definition should stay in this = document) or are they likely useful in other documents (in which case = their definition should be migrated to the framework document)? >>> Personally, I would say that those terms might be useful in other = documents/discussions (eg I am pretty sure we'd need to refer to the = "Delivering CDN" in other context). >>>=20 >>> *** section 1.1: >>> "Access CDN: >>> A CDN that is directly connected to the End User's access." >>> I think this definition needs to be a little more specific. = "Directly connected" does not mean "L2 connectivity" (because an on-net = cache maybe a few L2 hops away), nor does it mean "L3 connectivity" = (because an OTT CDN cache has IP connectivity to an enduser). I think = you mean something in between, more or less that the CDN and the access = are within the same IP administrative domain, or something close to = that. Can you try refine that definition? >>>=20 >>> *** section 1.3: >>> " o improve the experience for the End User; for instance delivery = has >>> lower latency (decreased round-trip-time between the user and the >>> delivery server) and better robustness," >>> To be more comprehensive in justifying the claims, how about: >>> " o improve the experience for the End User; for instance delivery = has >>> lower latency (decreased round-trip-time and higher throughput = between the user and the >>> delivery server) and better robustness (ability to use multiple = delivery servers)," >>>=20 >>> *** section 1.3: >>> "o reduce the Content Service Provider's (CSP) costs, such as >>> datacenter capacity, space, and electricity consumption, as >>> popular content is delivered through the CDN rather than through >>> the CSP's servers." >>> The current wording raises the question of "if it reduces the costs = by reducing expenses in the CSP datacenter, why does it not = correspondingly increase the cost by increasing expenses in the CDN = (which the CDN provider then charges back to the CSP)?" >>> I think the gain is in the scale and effective pooling of CDN = resources across many CSPs. Could you refine the wording to explain why = there is indeed a net gain? >>>=20 >>> *** section 1.3: >>> Replace: >>> " >>> An example is depicted in Figure 1. Two CDN Providers establish a = CDN Interconnection. >>> " >>> with: >>> " >>> An example is depicted in Figure 1 where two CDN Providers establish = a CDN Interconnection. >>> " >>> (this is to minimize the redundancy with the sentence coming below:=20= >>> "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their >>> CDNs.") >>>=20 >>>=20 >>> *** section 1.3: >>> replace: >>> " >>> "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their = CDNs." >>> with: >>> "Independently, CDN Provider 'A' and CDN Provider 'B' agree to = interconnect their CDNs." >>> this is to clarify that the A<->B agreement is not specific to the=20= >>> 1<->A agreement >>>=20 >>>=20 >>> *** section 1.3: >>> replace: >>> " >>> When a User Agent requests content from CSP-1, CDN-A considers that = delivery by CDN-B is appropriate " >>> with: >>> " >>> When a given User Agent requests content from CSP-1, CDN-A may = consider that delivery by CDN-B is appropriate " >>>=20 >>>=20 >>> *** section 1.3: >>> replace: >>> " >>> CDN-A has delegated the handling of requests for CSP-1's content = through the CDN Interconnection agreement, thus, the content is actually = delivered from CDN-B. >>> " >>> with: >>> " >>> Through the CDN Interconnection arrangements put in place between = CDN-A and CDN-B (as a result of the CDN Interconnection agreement = established between CDN Provider 'A' and CDN Provider 'B'), CDN-A can = redirect the request to CDN-B and the content is actually delivered to = the User Agent by CDN-B. >>> " >>> (the current wording suggests that all deliveries of CSP1 content=20 >>> would be handled by CDN-B, which is typically not the case i.e. only=20= >>> a subset of the requests are redirected thy CDN-A to CDN-B) >>>=20 >>>=20 >>> *** section 1.3: >>> replace: >>> " >>> CSP-1 benefits because it only needs to make one business agreement = and one physical connection, with CDN Provider 'A' >>> " >>> with: >>> " >>> CSP-1 benefits because it only needs to make one business agreement = and one technical arrangement with CDN Provider 'A' >>> " >>> (this is because the interfacing between CSP and uCDN comprises more = than "physical connection"). >>>=20 >>>=20 >>> *** section 1.3: >>> replace: >>> " >>> CSP-1 had also gone to the trouble of making a business agreement = with CDN Provider 'B' >>> " >>> with: >>> " >>> CSP-1 had also gone to the trouble of making a business agreement = and technical arrangemement with CDN Provider 'B' >>> " >>>=20 >>> *** section 1.3: >>> replace: >>> " >>> But it does not want >>> " >>> with: >>> " >>> However, CSP-2 may not want >>> " >>>=20 >>> *** section 2.1: >>> after >>> " >>> o without incurring additional transit and other network costs that >>> would result from serving content from geographically or >>> topologically remote Surrogates. >>> " >>> add: >>> " >>> o without incurring the cost of deploying and operating Surrogates = and the associated CDN infrastructure that may not be justified in the = corresponding geographic region (e.g. because of relatively low delivery = volume, or conversely because of the high investments that would be = needed to satisfy the high volume) " >>>=20 >>>=20 >>> *** section 2.2: >>> replace: >>> " >>> A large CDN Provider may also operate CDNs from several subsidiaries = (which may rely on different CDN technologies, see Section 4.2). In = certain circumstances, the CDN Provider needs to make its CDNs = interoperate to provide a consistent service to its customers on its = whole footprint. >>> " >>> with: >>> " >>> A large CDN Provider may have several subsidiaries that also each = operate their own CDN (which may rely on different CDN technologies, see = Section 4.2). In certain circumstances, the CDN Provider needs to make = these CDNs interoperate to provide a consistent service to its customers = on the whole collective footprint.=20 >>> " >>>=20 >>>=20 >>> *** section 2.3: >>> replace: >>> " >>> injected into the access network >>> " >>> with: >>> " >>> injected into the ISP network >>> " >>>=20 >>> *** section 2.3: >>> replace: >>> " >>> There are mutual benefits to the Access CDN, " >>> with: >>> " >>> There are mutual benefits to the ISP (acting as an Access CDN), " >>>=20 >>>=20 >>> *** section 2.3: >>> replace: >>> " >>> for example, QoS and reduced round trip time. >>> " >>> with: >>> " >>> for example, reduced content startup time or increased video quality = and resolution of adaptive streaming content. >>> " >>> (I don't think RTT is very meaningful to a CSP customer) >>>=20 >>>=20 >>> *** section 2.4: >>> The nomadic user is currently defined as "moving between CDNs" which = is sort of a self-serving definition to justify CDN interconnection. I = think we should rather define the nomadic user as "moving between access = networks" and then justify that leveraging local CDNs can bring a lot of = benefits. >>> This requires the following text edits: >>> s/who move between CDNs/who move between access networks/ s/moving=20= >>> between different CDN Providers/moving between different access=20 >>> networks/ >>>=20 >>> *** section 2.4: >>> replace: >>> " >>> which may reside >>> " >>> with: >>> " >>> which may be located >>> " >>>=20 >>> *** section 2.4:" >>> I propose to remove the sentence: >>> " >>> The term "Nomadic" does not necessarily relate to geographic = roaming. >>> " >>> because this point has already been fully (and better) clarified in = the preceding paragraph. >>>=20 >>>=20 >>>=20 >>> *** section 2.4: >>> replace: >>> " >>> the WiFi or mobile provider >>> " >>> with: >>> " >>> the WiFi or mobile provider (NSP B) >>> " >>>=20 >>>=20 >>> *** section 3.1: >>> replace: >>> " >>> needs CDN capacities >>> " >>> with: >>> " >>> needs CDN capacity >>> " >>>=20 >>> *** section 3.2.1: >>> The text mentions two options (use OS, use another CDN). I think the = section shoudl probably also mention the most obvious option (i.e. use = other surrogates in the same CDN). Or alternatively, clarify that the = considered situation is where there is a partial failure of some = surrogates resulting in the remaining surrogates being fully loaded. >>>=20 >>>=20 >>> *** section 3.2.1: >>> replace: >>> " >>> to both distribute load between origin servers and attempt content=20= >>> acquisition from alternate origin servers when acquisition failures = occur. When normal content acquisition fails, a CDN may need to try = other origin server options, " >>> with: >>> " >>> to both distribute load between content sources and attempt content=20= >>> acquisition from alternate content sources when acquisition failures = occur. When normal content acquisition fails, a CDN may need to try = other content source options, " >>> (I believe everywhere else we use "origin server" to refer to the OS=20= >>> of the CSP and "content source" as the generic term for getting=20 >>> content including origin server and uCDN) >>>=20 >>> *** section 3.2.2: >>> replace: >>> " >>> the selection of content acquisition sources should be considered. >>> " >>> with: >>> " >>> the selection of content acquisition sources should be considered = and facilitated. >>> " >>> (i.e. it is not just a matter of "thinking" about it: it must be = explicitly allowed or at leads made easier). >>>=20 >>>=20 >>> *** section 4.1: >>> "to serve a proportion of its traffic that requires HTTPS." >>> can you include a reference for HTTPS? >>>=20 >>>=20 >>> *** section 5: >>> replace: >>> " >>> An important aspect of the above use cases " >>> with: >>> " >>> An important aspect common to all the above use cases " >>>=20 >>>=20 >>> *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on = line=20 >>> 618, but no explicit reference was found in the text I'd suggest you = add an explicit reference. For example, in "1. Introduction" you could = replace: >>> " >>> The document can be used to guide the definition of the requirements = to be supported by the various CDNI interfaces defined in = [I-D.ietf-cdni-problem-statement]. >>> " >>> by >>> " >>> The document can be used to guide the definition of the requirements = (as documented in [I-D.ietf-cdni-requirements]) to be supported by the = set of CDNI interfaces defined in [I-D.ietf-cdni-problem-statement]. >>> " >>> (BTW, independely of the reference issue, "the set of CDNI = interfaces" might read better than "the various CDNI interfaces"). >>>=20 >>>=20 >>> *** The document has a disclaimer for pre-RFC5378 work, but was = first submitted on or after 10 November 2008. Does it really need the = disclaimer? >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >=20 From vumip1@gmail.com Wed May 16 16:07:30 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B4621F8513 for ; Wed, 16 May 2012 16:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.34 X-Spam-Level: X-Spam-Status: No, score=-3.34 tagged_above=-999 required=5 tests=[AWL=0.258, 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 K1ZYlh8QfP6l for ; Wed, 16 May 2012 16:07:30 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B83A21F84E6 for ; Wed, 16 May 2012 16:07:30 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so1982155obb.31 for ; Wed, 16 May 2012 16:07:29 -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=JQ3/PMdhn0v2nDR011SbpvYQTWg9JLJTSWKN3JccpHk=; b=mgSZALs/Ve1TqI4O96DMgy3lk85ymNbI83N3aaL7LbX/yFamO9ktl5PNyg06XyLzEQ ikhM2VyFskobEt/4sGTQwQxDJjfGYRKu6syt3lFRkaQW96E7TxIvTokzZr98to+b9uPe ENZO37igNhK6jh6aEgbvyWimKAh910IWtvnIN8OC60X1fiMb8s3d6//TjtrBpaLQ2UUq 0fjOJ/SfcBCP6wEd7VAMIJpQFzJ5fMQNVCakhcGcGlw8fYF6L7ZB1mI+DM+FssJdNCaX wiOT+pMY3RqpJwX3pkIBGQX5pSkfZg/Fwr5yGCbs2sEXkkMdCiTo9Vr3Cm7GVLyRBIgR 5ebQ== MIME-Version: 1.0 Received: by 10.60.9.163 with SMTP id a3mr4403896oeb.71.1337209649736; Wed, 16 May 2012 16:07:29 -0700 (PDT) Received: by 10.182.32.42 with HTTP; Wed, 16 May 2012 16:07:29 -0700 (PDT) Date: Wed, 16 May 2012 19:07:29 -0400 Message-ID: From: Bhumip Khasnabish To: cdni@ietf.org Content-Type: multipart/alternative; boundary=e89a8fb1edec29ac9504c02f62a8 Subject: [CDNi] Content De-duplication Optimization in CDNI X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 23:07:30 -0000 --e89a8fb1edec29ac9504c02f62a8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable In some CDNI deployment, it is highly likely to have content repetition in the same dCDN. There is a need to develop an optimized mechanism to de-duplicate the content in CDNi network. In order to implement such optimization, enhancement to CDNI metadata model and interface may be required. Would anyone be interested in such works? Thanks Best. Bhumip Bhumip Khasnabish vumip1@gmail.com +1-781-752-8003 (mobile) http://tinyurl.com/bhumip __o _ `\ <, _ .......... ( =95 ) / ( =95 ) ...................... --e89a8fb1edec29ac9504c02f62a8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
In some CDNI= deployment, it is highly likely=A0 to have content repetition in the same = dCDN.=A0
=A0
There is a n= eed=A0to=A0 develop an optimized mechanism to de-duplicate the content in C= DNi network.=A0
In order to = implement such optimization, enhancement to CDNI =A0metadata model and inte= rface
may be requi= red.
Would anyone= be interested in such works?=A0 Thanks
Best.=
=A0
Bhumip


Bhumip Khasnabish
+1-781-752-8003 (mobile)
http://tinyurl.com/bhumip

=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 = ) ......................

--e89a8fb1edec29ac9504c02f62a8-- From flefauch@cisco.com Thu May 17 02:43:37 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E66E21F861B for ; Thu, 17 May 2012 02:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.93 X-Spam-Level: X-Spam-Status: No, score=-5.93 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, GB_MUTUALBENEFIT=2, J_BACKHAIR_11=1, J_CHICKENPOX_31=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 lUox+Rd1p4+e for ; Thu, 17 May 2012 02:43:36 -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 CBD2C21F8617 for ; Thu, 17 May 2012 02:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=18199; q=dns/txt; s=iport; t=1337247815; x=1338457415; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=WFzshpl1J3hVNziO9QOKNmpB3LQ3UgbcnXWZlbIRxDU=; b=RyhoqrFKkJMiIJO65VXxqDIt5yOG9RRaRCZ/9lzpTyu0VFeu+QQJSj3G amVzYl9/U6WacW/khLzLPWLfX+G5xmH0TouXIsMYqi/cAztPPm6xZlSBQ EdmTUWFlWReuzZeYmQNCBIOX3VV/CWtDXDYyKZRrsQsqRdYBLwokRCF4f E=; X-IronPort-AV: E=Sophos;i="4.75,608,1330905600"; d="scan'208";a="84052645" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 17 May 2012 09:43:35 +0000 Received: from rtp-vpn3-791.cisco.com (rtp-vpn3-791.cisco.com [10.82.219.27]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q4H9gkm6030598; Thu, 17 May 2012 09:43:33 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Francois Le Faucheur In-Reply-To: <3BE12F3B-51F6-4524-BBD2-C152C4F1F4C0@verivue.com> Date: Thu, 17 May 2012 02:16:22 +0200 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: "Peterson, Larry" 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: Thu, 17 May 2012 09:43:37 -0000 Larry and all, My understanding is that: * problem-statement includes a set of "core" definitions.=20 * framework will be cleaned up to refer to problem-statement for = all the "core" definitions (and not redefine them) * framework will include the additional definitions of general = interest to the working group. I believe there are a few already in = framework in that category.=20 * I think we are converging that: * "Delivering CDN" fits in the category of additional = definitions to be included in the framework * "Access CDN" does not fit that category and shoudl not = be introduced in framework. If folks (in particular authors of other documents) feel that they have = definitions that shoudl go into framework, please indicate so on the = list. Thanks Francois On 9 May 2012, at 19:05, Peterson, Larry wrote: > Yes... Generally, it would be good to do a survey of terminology > various docs have introduced recently, and converge on the core > definitions. >=20 > Larry >=20 > On May 9, 2012, at 11:47 AM, Francois Le Faucheur wrote: >=20 >> Hi Larry, >>=20 >> Can you confirm this can be done in next rev of cdni-framework? >>=20 >> Tx >>=20 >> Francois >>=20 >>=20 >> On 9 May 2012, at 17:19, wrote: >>=20 >>> Hi Fran=E7ois, >>>=20 >>> Thanks for your review. We are integrating your comments. >>>=20 >>> About your comments on Section 1.1, I definitely think the terms = "Access CDN" and "Delivering CDN" are useful more broadly than just in = the use cases document. Therefore, I would be in favor of moving them to = the framework document as you propose. >>>=20 >>> Access CDN: >>> A CDN that includes Surrogates in the same network (e.g., same = Autonomous System) as the End User. An Access CDN may have specific = information about >>> the End User and the network, for instance, End User's >>> profile and access capabilities. >>>=20 >>> Delivering CDN: >>> The CDN that delivers the requested piece of content to >>> the End User. In particular, the Delivering CDN can be an >>> Access CDN. >>>=20 >>>=20 >>> Best regards, >>>=20 >>> Gilles >>>=20 >>>=20 >>> -----Message d'origine----- >>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part = de Francois Le Faucheur >>> Envoy=E9 : mercredi 25 avril 2012 18:46 >>> =C0 : draft-ietf-cdni-use-cases@tools.ietf.org >>> Cc : cdni@ietf.org >>> Objet : [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases >>>=20 >>> To use-cases authors, >>>=20 >>> Below are my shepherd review comments of cdni-uses-cases. >>>=20 >>> I think the document is in a good shape and captures well the key = targeted use cases. >>> I identified two remaining significant points to be addressed, and = also have included many suggestions to improve the document. >>> I suggest we resolve the two significant points on the list and = leave it to editor/authors to decide how to dispose of the suggestions = for improvement offline. >>>=20 >>> Cheers >>>=20 >>> Francois >>>=20 >>>=20 >>> Significant points >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> *** section 8 security considerations >>> I have a few specific issues with the current text of the Security = Considerations section. But I don't really see the need to have an = expanded Security Considerations section in both the use-case document = and the problem-statement (particularly considering that the first IESG = review comments on problem-statement suggest expanding the security = considerations section there), in particular because the security = considerations currently brought up in use-cases are not specific to = individual use cases bur rather generic to the whole CDN interconnection = problem space. >>> So my proposal would be to remove the whole discussion from = use-cases (i.e. the first 4 paragraphs) and refer to the Security = Considerations section of the Problem Statement e.g.. by replacing: >>> " >>> This document focuses on the motivational use cases for CDN = Interconnection, and does not analyze these threats in detail. >>> " >>> with: >>> " >>> This document focuses on the motivational use cases for CDN = Interconnection, and does not analyze the associated threats. Those are = discussed in [I-D.ietf-cdni-problem-statement]. >>> " >>>=20 >>>=20 >>> ***section A.1: >>> I still have a problem with the text of that section. >>> I thought we had converged on an agreement that the text would: >>> * explain that CSPs may take into account very = multiple/arbitrary/specific criteria in their policy >>> * explain that the CDNs are only expected to enforce a few = specific policy rules (e.g. geo-blocking, time window) and for = enforcement of all fancy CSP policy we propose that the responsibilities = be divided into (1) the CSP being responsible for the fancy policy = decision and (ii) the CDN for merely enforcing the CSP decision without = having to understand the policy (e.g. via URI signing). >>> Do we not agree on that or not? >>>=20 >>> The current text says that CDN selection and surrogate selection = "are influenced by these policies" (referring to the fancy CSP = policies). I do not agree with that. I don;t think we want CDN Selection = or Surrogate selection to be influenced by whether a movie shoudl be = available 14 or 28 days after DVD release, or whether a given resolution = is "too high" for a particular user or terminal. >>>=20 >>> Also, the paragraph keeps talking about "dCDN selection or Surrogate = selection" may fail for some fancy policy reasons. I don't understand = what it means to "fail" , but more importantly again, I don't think we = want CDN request routing decisions to be factoring very fancy CSP policy = rules. >>> Do we agree or not? >>>=20 >>> The last paragraphs gives examples of the CSP objectives of = supporting delivery policies in CDNs, and those are fine and can be = achieved with the set of mechanisms discussed above (i.e. goeblocking + = time window + URI signing). >>>=20 >>>=20 >>> Suggestions for improvements >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> ***Abstract >>> replace "CDNI" by "CDN Interconnection". >>>=20 >>> *** section 1: >>> expand the first instance of CDNI into "CDN Interconnection (CDNI)". >>>=20 >>> *** section 1: >>> "Then, the document highlights the need for interoperability to >>> exchange and enforce content delivery policies (Section 5)." >>> I'd suggest replacing "for interoperability to exchange" by "for = interoperability to allow exchange" or by "for interoperability in order = to exchange" >>>=20 >>> *** section 1.1: >>> Do you feel that the two additional terms are really specific to the = use-case document (in which case their definition should stay in this = document) or are they likely useful in other documents (in which case = their definition should be migrated to the framework document)? >>> Personally, I would say that those terms might be useful in other = documents/discussions (eg I am pretty sure we'd need to refer to the = "Delivering CDN" in other context). >>>=20 >>> *** section 1.1: >>> "Access CDN: >>> A CDN that is directly connected to the End User's access." >>> I think this definition needs to be a little more specific. = "Directly connected" does not mean "L2 connectivity" (because an on-net = cache maybe a few L2 hops away), nor does it mean "L3 connectivity" = (because an OTT CDN cache has IP connectivity to an enduser). I think = you mean something in between, more or less that the CDN and the access = are within the same IP administrative domain, or something close to = that. Can you try refine that definition? >>>=20 >>> *** section 1.3: >>> " o improve the experience for the End User; for instance delivery = has >>> lower latency (decreased round-trip-time between the user and the >>> delivery server) and better robustness," >>> To be more comprehensive in justifying the claims, how about: >>> " o improve the experience for the End User; for instance delivery = has >>> lower latency (decreased round-trip-time and higher throughput = between the user and the >>> delivery server) and better robustness (ability to use multiple = delivery servers)," >>>=20 >>> *** section 1.3: >>> "o reduce the Content Service Provider's (CSP) costs, such as >>> datacenter capacity, space, and electricity consumption, as >>> popular content is delivered through the CDN rather than through >>> the CSP's servers." >>> The current wording raises the question of "if it reduces the costs = by reducing expenses in the CSP datacenter, why does it not = correspondingly increase the cost by increasing expenses in the CDN = (which the CDN provider then charges back to the CSP)?" >>> I think the gain is in the scale and effective pooling of CDN = resources across many CSPs. Could you refine the wording to explain why = there is indeed a net gain? >>>=20 >>> *** section 1.3: >>> Replace: >>> " >>> An example is depicted in Figure 1. Two CDN Providers establish a = CDN Interconnection. >>> " >>> with: >>> " >>> An example is depicted in Figure 1 where two CDN Providers establish = a CDN Interconnection. >>> " >>> (this is to minimize the redundancy with the sentence coming below: = "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their = CDNs.") >>>=20 >>>=20 >>> *** section 1.3: >>> replace: >>> " >>> "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their = CDNs." >>> with: >>> "Independently, CDN Provider 'A' and CDN Provider 'B' agree to = interconnect their CDNs." >>> this is to clarify that the A<->B agreement is not specific to the = 1<->A agreement >>>=20 >>>=20 >>> *** section 1.3: >>> replace: >>> " >>> When a User Agent requests content from CSP-1, CDN-A considers that = delivery by CDN-B is appropriate " >>> with: >>> " >>> When a given User Agent requests content from CSP-1, CDN-A may = consider that delivery by CDN-B is appropriate " >>>=20 >>>=20 >>> *** section 1.3: >>> replace: >>> " >>> CDN-A has delegated the handling of requests for CSP-1's content = through the CDN Interconnection agreement, thus, the content is actually = delivered from CDN-B. >>> " >>> with: >>> " >>> Through the CDN Interconnection arrangements put in place between = CDN-A and CDN-B (as a result of the CDN Interconnection agreement = established between CDN Provider 'A' and CDN Provider 'B'), CDN-A can = redirect the request to CDN-B and the content is actually delivered to = the User Agent by CDN-B. >>> " >>> (the current wording suggests that all deliveries of CSP1 content = would be handled by CDN-B, which is typically not the case i.e. only a = subset of the requests are redirected thy CDN-A to CDN-B) >>>=20 >>>=20 >>> *** section 1.3: >>> replace: >>> " >>> CSP-1 benefits because it only needs to make one business agreement = and one physical connection, with CDN Provider 'A' >>> " >>> with: >>> " >>> CSP-1 benefits because it only needs to make one business agreement = and one technical arrangement with CDN Provider 'A' >>> " >>> (this is because the interfacing between CSP and uCDN comprises more = than "physical connection"). >>>=20 >>>=20 >>> *** section 1.3: >>> replace: >>> " >>> CSP-1 had also gone to the trouble of making a business agreement = with CDN Provider 'B' >>> " >>> with: >>> " >>> CSP-1 had also gone to the trouble of making a business agreement = and technical arrangemement with CDN Provider 'B' >>> " >>>=20 >>> *** section 1.3: >>> replace: >>> " >>> But it does not want >>> " >>> with: >>> " >>> However, CSP-2 may not want >>> " >>>=20 >>> *** section 2.1: >>> after >>> " >>> o without incurring additional transit and other network costs that >>> would result from serving content from geographically or >>> topologically remote Surrogates. >>> " >>> add: >>> " >>> o without incurring the cost of deploying and operating Surrogates = and the associated CDN infrastructure that may not be justified in the = corresponding geographic region (e.g. because of relatively low delivery = volume, or conversely because of the high investments that would be = needed to satisfy the high volume) " >>>=20 >>>=20 >>> *** section 2.2: >>> replace: >>> " >>> A large CDN Provider may also operate CDNs from several subsidiaries = (which may rely on different CDN technologies, see Section 4.2). In = certain circumstances, the CDN Provider needs to make its CDNs = interoperate to provide a consistent service to its customers on its = whole footprint. >>> " >>> with: >>> " >>> A large CDN Provider may have several subsidiaries that also each = operate their own CDN (which may rely on different CDN technologies, see = Section 4.2). In certain circumstances, the CDN Provider needs to make = these CDNs interoperate to provide a consistent service to its customers = on the whole collective footprint. >>> " >>>=20 >>>=20 >>> *** section 2.3: >>> replace: >>> " >>> injected into the access network >>> " >>> with: >>> " >>> injected into the ISP network >>> " >>>=20 >>> *** section 2.3: >>> replace: >>> " >>> There are mutual benefits to the Access CDN, >>> " >>> with: >>> " >>> There are mutual benefits to the ISP (acting as an Access CDN), >>> " >>>=20 >>>=20 >>> *** section 2.3: >>> replace: >>> " >>> for example, QoS and reduced round trip time. >>> " >>> with: >>> " >>> for example, reduced content startup time or increased video quality = and resolution of adaptive streaming content. >>> " >>> (I don't think RTT is very meaningful to a CSP customer) >>>=20 >>>=20 >>> *** section 2.4: >>> The nomadic user is currently defined as "moving between CDNs" which = is sort of a self-serving definition to justify CDN interconnection. I = think we should rather define the nomadic user as "moving between access = networks" and then justify that leveraging local CDNs can bring a lot of = benefits. >>> This requires the following text edits: >>> s/who move between CDNs/who move between access networks/ >>> s/moving between different CDN Providers/moving between different = access networks/ >>>=20 >>> *** section 2.4: >>> replace: >>> " >>> which may reside >>> " >>> with: >>> " >>> which may be located >>> " >>>=20 >>> *** section 2.4:" >>> I propose to remove the sentence: >>> " >>> The term "Nomadic" does not necessarily relate to geographic = roaming. >>> " >>> because this point has already been fully (and better) clarified in = the preceding paragraph. >>>=20 >>>=20 >>>=20 >>> *** section 2.4: >>> replace: >>> " >>> the WiFi or mobile provider >>> " >>> with: >>> " >>> the WiFi or mobile provider (NSP B) >>> " >>>=20 >>>=20 >>> *** section 3.1: >>> replace: >>> " >>> needs CDN capacities >>> " >>> with: >>> " >>> needs CDN capacity >>> " >>>=20 >>> *** section 3.2.1: >>> The text mentions two options (use OS, use another CDN). I think the = section shoudl probably also mention the most obvious option (i.e. use = other surrogates in the same CDN). Or alternatively, clarify that the = considered situation is where there is a partial failure of some = surrogates resulting in the remaining surrogates being fully loaded. >>>=20 >>>=20 >>> *** section 3.2.1: >>> replace: >>> " >>> to both distribute load between origin servers and attempt content = acquisition from alternate origin servers when acquisition failures = occur. When normal content acquisition fails, a CDN may need to try = other origin server options, >>> " >>> with: >>> " >>> to both distribute load between content sources and attempt content = acquisition from alternate content sources when acquisition failures = occur. When normal content acquisition fails, a CDN may need to try = other content source options, >>> " >>> (I believe everywhere else we use "origin server" to refer to the OS = of the CSP and "content source" as the generic term for getting content = including origin server and uCDN) >>>=20 >>> *** section 3.2.2: >>> replace: >>> " >>> the selection of content acquisition sources should be considered. >>> " >>> with: >>> " >>> the selection of content acquisition sources should be considered = and facilitated. >>> " >>> (i.e. it is not just a matter of "thinking" about it: it must be = explicitly allowed or at leads made easier). >>>=20 >>>=20 >>> *** section 4.1: >>> "to serve a proportion of its traffic that requires HTTPS." >>> can you include a reference for HTTPS? >>>=20 >>>=20 >>> *** section 5: >>> replace: >>> " >>> An important aspect of the above use cases >>> " >>> with: >>> " >>> An important aspect common to all the above use cases >>> " >>>=20 >>>=20 >>> *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on = line 618, but no explicit reference was found in the text >>> I'd suggest you add an explicit reference. For example, in "1. = Introduction" you could replace: >>> " >>> The document can be used to guide the definition of the requirements = to be supported by the various CDNI interfaces defined in = [I-D.ietf-cdni-problem-statement]. >>> " >>> by >>> " >>> The document can be used to guide the definition of the requirements = (as documented in [I-D.ietf-cdni-requirements]) to be supported by the = set of CDNI interfaces defined in [I-D.ietf-cdni-problem-statement]. >>> " >>> (BTW, independely of the reference issue, "the set of CDNI = interfaces" might read better than "the various CDNI interfaces"). >>>=20 >>>=20 >>> *** The document has a disclaimer for pre-RFC5378 work, but was = first submitted on or after 10 November 2008. Does it really need the = disclaimer? >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >=20 From internet-drafts@ietf.org Sun May 20 01:42:25 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD51721F85B8; Sun, 20 May 2012 01:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.363 X-Spam-Level: X-Spam-Status: No, score=-102.363 tagged_above=-999 required=5 tests=[AWL=0.236, 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 pDQzYOS0xSlA; Sun, 20 May 2012 01:42:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2784221F85A2; Sun, 20 May 2012 01:42:25 -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: <20120520084225.13642.36903.idtracker@ietfa.amsl.com> Date: Sun, 20 May 2012 01:42:25 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-problem-statement-06.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 08:42:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnec= tion Working Group of the IETF. Title : Content Distribution Network Interconnection (CDNI) Prob= lem Statement Author(s) : Ben Niven-Jenkins Francois Le Faucheur Nabil Bitar Filename : draft-ietf-cdni-problem-statement-06.txt Pages : 40 Date : 2012-05-19 Content Delivery Networks (CDNs) provide numerous benefits: reduced delivery cost for cacheable content, improved quality of experience for End Users and increased robustness of delivery. For these reasons they are frequently used for large-scale content delivery. As a result, existing CDN Providers are scaling up their infrastructure and many Network Service Providers (NSPs) are deploying their own CDNs. It is generally desirable that a given content item can be delivered to an End User regardless of that End User's location or attachment network. This is the motivation for interconnecting standalone CDNs so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. However, no standards or open specifications currently exist to facilitate such CDN interconnection. The goal of this document is to outline the problem area of CDN interconnection for the IETF CDNI (CDN Interconnection) working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cdni-problem-statement-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cdni-problem-statement-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-problem-statement/ From ray.vanbrandenburg@tno.nl Wed May 23 04:36: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 B30FE21F85D5 for ; Wed, 23 May 2012 04:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.488 X-Spam-Level: * X-Spam-Status: No, score=1.488 tagged_above=-999 required=5 tests=[AWL=1.991, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppr1Ol8Hn2OR for ; Wed, 23 May 2012 04:36:59 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id C2E5A21F84FE for ; Wed, 23 May 2012 04:36:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,644,1330902000"; d="scan'208,217";a="69488353" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 23 May 2012 13:36:57 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.35]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0283.003; Wed, 23 May 2012 13:36:57 +0200 From: "Brandenburg, R. (Ray) van" To: "cdni@ietf.org" Thread-Topic: Status of Adaptive Streaming and CDNI draft Thread-Index: Ac0414J5VzCVuofZTcKanwrNrKyoTA== Date: Wed, 23 May 2012 11:36:57 +0000 Message-ID: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1581C5B6149EXCMBX03tsntnon_" MIME-Version: 1.0 Subject: [CDNi] Status of Adaptive Streaming and CDNI 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: Wed, 23 May 2012 11:36:59 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA1581C5B6149EXCMBX03tsntnon_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi all, Next Tuesday we have a planned interim meeting for discussing the combinati= on between HTTP Adaptive Streaming and CDNI. One of the expected inputs fo= r this meeting is a follow-up draft to draft-brandenburg-cdni-has-00. We are currently working hard at finishing this draft, but as you might hav= e seen, we have not yet uploaded a new version. Currently we are at a stage= where we have a first complete internal draft ready. However, Francois and= I have agreed that we rather spend some more time on it so that it fully c= overs all the areas of the CDNI-HAS combination than upload an incomplete v= ersion right now. We are currently planning to upload the draft this Friday= (25th of May) at the latest. I hope this gives you all enough time to read= the draft before the meeting on Tuesday. Sorry for the delay. Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_FCC100FC8D6B034CB88CD8173B2DA1581C5B6149EXCMBX03tsntnon_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
Hi all,
 
Next Tuesday we have a planned interim meeting for discussing the comb= ination between HTTP Adaptive Streaming and CDNI. One  of the expected= inputs for this meeting is a follow-up draft to draft-brandenburg-cdni-has= -00.
 
We are currently working hard at finishing this draft, but as you migh= t have seen, we have not yet uploaded a new version. Currently we are at a = stage where we have a first complete internal draft ready. However, Francoi= s and I have agreed that we rather spend some more time on it so that it fully covers all the areas of the CDN= I-HAS combination than upload an incomplete version right now. We are curre= ntly planning to upload the draft this Friday (25th of May) at the latest. I hope this gives you all enough time to read the dr= aft before the meeting on Tuesday.
 
Sorry for the delay.
 
Ray
 
 
 

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

--_000_FCC100FC8D6B034CB88CD8173B2DA1581C5B6149EXCMBX03tsntnon_-- From flefauch@cisco.com Wed May 23 05:26:36 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C2F21F86D5 for ; Wed, 23 May 2012 05:26:36 -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 22gmWxmIy5jB for ; Wed, 23 May 2012 05:26:35 -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 2E38F21F8701 for ; Wed, 23 May 2012 05:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=5129; q=dns/txt; s=iport; t=1337775995; x=1338985595; h=from:subject:date:references:to:message-id:mime-version; bh=79tTzyceESCINM9nYsWKZLQ6Wl8ZAnSWXZLFBZt91mM=; b=QEqACKvdTQv6Xc8YdBJ7pIeoAHflRqzGPnAVYq0ayCY6fM3BIgEKUXi7 Bjqxyfgumpbx2NtOiBDH6ci5V8i8g2+Ww5w53Y7z603kI2guIq+AvnZcV Iiapx1pFfD/BpIgdD/PXM709l5zVyTou6PeWAkeg62Yt0XO32oUh9Qs0O 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABnWvE+Q/khN/2dsb2JhbABDtDOBB4IVAQEBAwEBAQEPAVsQCxwDAQIvJyYCCBkJGYdnBQuaSKAFiw+CIoI8YgOVHIVPiD2BZIJs X-IronPort-AV: E=Sophos;i="4.75,645,1330905600"; d="scan'208,217";a="4865054" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 23 May 2012 12:26:34 +0000 Received: from [144.254.53.85] ([144.254.53.85]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4NCQXOf018400 for ; Wed, 23 May 2012 12:26:34 GMT From: Francois Le Faucheur Content-Type: multipart/alternative; boundary="Apple-Mail=_385E1156-AD09-4AEA-B8B2-F539186398A0" Date: Wed, 23 May 2012 14:26:40 +0200 References: <5339DEEB-766C-4523-B352-52BC07FA24F3@cisco.com> To: cdni@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [CDNi] Fwd: CDNI Virtual Interim Meetings on May 29 & 30, 2012 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss 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, 23 May 2012 12:26:36 -0000 --Apple-Mail=_385E1156-AD09-4AEA-B8B2-F539186398A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just a friendly reminder about our two virtual Interim Meetings next = week. Cheers Francois & Rich Begin forwarded message: > From: Francois Le Faucheur > Subject: [CDNi] CDNI Virtual Interim Meetings on May 29 & 30, 2012 > Date: 13 April 2012 14:58:34 CEST > To: cdni@ietf.org >=20 > Hello, >=20 > As discussed in Paris, the CDNI working group will hold: >=20 > * a (3-hour) virtual interim 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) virtual interim 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 >=20 > Please take note of these timeslots. >=20 > Looking forward to your participation. >=20 > Francois & Rich > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --Apple-Mail=_385E1156-AD09-4AEA-B8B2-F539186398A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Just = a friendly reminder about our two virtual Interim Meetings next = week.
Cheers
Francois & Rich

Begin = forwarded message:

From: Francois Le = Faucheur <flefauch@cisco.com>
Subject: = [CDNi] CDNI Virtual Interim Meetings on May 29 = & 30, 2012
Date: 13 April 2012 14:58:34 CEST

H= ello,

As discussed in Paris, the CDNI working group will = hold:

= * a (3-hour) virtual interim 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) virtual interim 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/agen= da-interim-2012-cdni-2.html

Please take note of these = timeslots.

Looking forward to your participation.

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

= --Apple-Mail=_385E1156-AD09-4AEA-B8B2-F539186398A0-- From internet-drafts@ietf.org Wed May 23 05:39: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 5ABC521F8710; Wed, 23 May 2012 05:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 5GOrDGMdV6l9; Wed, 23 May 2012 05:39:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6375D21F8673; Wed, 23 May 2012 05:39:03 -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: <20120523123903.26181.22284.idtracker@ietfa.amsl.com> Date: Wed, 23 May 2012 05:39:03 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-use-cases-05.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 12:39:05 -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-05.txt Pages : 16 Date : 2012-05-23 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-05.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-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-use-cases/ From iesg-secretary@ietf.org Wed May 23 06:54: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 166F721F871A; Wed, 23 May 2012 06:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.405 X-Spam-Level: X-Spam-Status: No, score=-102.405 tagged_above=-999 required=5 tests=[AWL=0.194, 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 CgGb3H4xPp+4; Wed, 23 May 2012 06:54:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B22D21F86C1; Wed, 23 May 2012 06:54:41 -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.02 Message-ID: <20120523135441.23235.12362.idtracker@ietfa.amsl.com> Date: Wed, 23 May 2012 06:54:41 -0700 Cc: cdni@ietf.org Subject: [CDNi] Last Call: (Content Distribution Network Interconnection (CDNI) Problem Statement) 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, 23 May 2012 13:54:42 -0000 The IESG has received a request from the Content Delivery Networks Interconnection WG (cdni) to consider the following document: - 'Content Distribution Network Interconnection (CDNI) Problem Statement' 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-06-06. 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) 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-cdni-problem-statement/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-cdni-problem-statement/ballot/ No IPR declarations have been submitted directly on this I-D. From internet-drafts@ietf.org Thu May 24 07:06:44 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C6021F84D6; Thu, 24 May 2012 07:06:44 -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 WUJ8dl1ZyE2T; Thu, 24 May 2012 07:06:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86EE21F84DE; Thu, 24 May 2012 07:06:43 -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: <20120524140643.8240.34311.idtracker@ietfa.amsl.com> Date: Thu, 24 May 2012 07:06:43 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-use-cases-06.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, 24 May 2012 14:06:44 -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-06.txt Pages : 16 Date : 2012-05-24 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-06.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-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-use-cases/ From flefauch@cisco.com Thu May 24 23:12:26 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BEF11E80AF for ; Thu, 24 May 2012 23:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOjbfMWgPPo4 for ; Thu, 24 May 2012 23:12:25 -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 6C45111E8073 for ; Thu, 24 May 2012 23:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=3383; q=dns/txt; s=iport; t=1337926345; x=1339135945; h=from:mime-version:subject:date:in-reply-to:to:references: message-id; bh=lCUgV+0kxy2k3IA6VQT86dsGCK1QSpHcANEL6mYdOyU=; b=XM7if1fZzd5dTFYd+1HAHYH5RT1KI0r2WUvr28lrU36eZTwVYl9TqAfg In8Hcy8m+gIlZ49gxIH6QBRZ5MsmZmKQ/efbKr2vtdL2zQSh0sGRetW09 1OVaCyrJ0UTOSDXMpunpHNJ+zVLsAdvqEikgF6M0QwCD7NJFKFj2jyqwn w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJ4hv0+Q/khL/2dsb2JhbABEtQSBB4IWAQEEEgF2D0JXIhmHawubUJ9pin+CMII2YAOVGI4MgWSCYg X-IronPort-AV: E=Sophos;i="4.75,655,1330905600"; d="scan'208,217";a="138530019" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 25 May 2012 06:12:24 +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 q4P6CNGD029256 for ; Fri, 25 May 2012 06:12:23 GMT From: Francois Le Faucheur Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_0D39A674-3DBB-4DE8-998C-1DBD5664E0DE" Date: Fri, 25 May 2012 08:12:22 +0200 In-Reply-To: To: cdni@ietf.org References: <5339DEEB-766C-4523-B352-52BC07FA24F3@cisco.com> Message-Id: X-Mailer: Apple Mail (2.1278) Subject: [CDNi] CDNI "Extended Design Team Meetings" on May 29 & 30, 2012 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss 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, 25 May 2012 06:12:26 -0000 --Apple-Mail=_0D39A674-3DBB-4DE8-998C-1DBD5664E0DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, 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 Cheers Francois & Rich * 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 * 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 --Apple-Mail=_0D39A674-3DBB-4DE8-998C-1DBD5664E0DE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii * 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
= --Apple-Mail=_0D39A674-3DBB-4DE8-998C-1DBD5664E0DE-- From ray.vanbrandenburg@tno.nl Fri May 25 07:18:40 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E3821F867C for ; Fri, 25 May 2012 07:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.99 X-Spam-Level: X-Spam-Status: No, score=0.99 tagged_above=-999 required=5 tests=[AWL=1.493, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykEsJcjY3c9K for ; Fri, 25 May 2012 07:18:39 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED9F21F8526 for ; Fri, 25 May 2012 07:18:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,656,1330902000"; d="scan'208,217";a="69632632" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 25 May 2012 16:18:37 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.35]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0283.003; Fri, 25 May 2012 16:18:37 +0200 From: "Brandenburg, R. (Ray) van" To: "cdni@ietf.org" Thread-Topic: Status of Adaptive Streaming and CDNI draft Thread-Index: Ac0414J5VzCVuofZTcKanwrNrKyoTABqTCnQ Date: Fri, 25 May 2012 14:18:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1581C5B7818EXCMBX03tsntnon_" MIME-Version: 1.0 Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI 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: Fri, 25 May 2012 14:18:40 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA1581C5B7818EXCMBX03tsntnon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I've just uploaded a new version of draft-brandenburg-cdni-has. You can find the document at: http://www.ietf.org/id/draft-brandenburg-cdni= -has-01.txt The draft is meant as an input document for the virtual meeting on Thursday= to discuss the impact of HTTP Adaptive Streaming on the CDNI Interfaces. I= n the draft a number of alternative solutions are presented for each area w= here the use of HAS might touch with the CDNI Interfaces (e.g. content acqu= isition, content purge, request routing, logging and URL signing). I'm looking forward to your comments. Have a nice weekend! Ray van Brandenburg From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Bra= ndenburg, R. (Ray) van Sent: woensdag 23 mei 2012 13:37 To: cdni@ietf.org Subject: [CDNi] Status of Adaptive Streaming and CDNI draft Hi all, Next Tuesday we have a planned interim meeting for discussing the combinati= on between HTTP Adaptive Streaming and CDNI. One of the expected inputs fo= r this meeting is a follow-up draft to draft-brandenburg-cdni-has-00. We are currently working hard at finishing this draft, but as you might hav= e seen, we have not yet uploaded a new version. Currently we are at a stage= where we have a first complete internal draft ready. However, Francois and= I have agreed that we rather spend some more time on it so that it fully c= overs all the areas of the CDNI-HAS combination than upload an incomplete v= ersion right now. We are currently planning to upload the draft this Friday= (25th of May) at the latest. I hope this gives you all enough time to read= the draft before the meeting on Tuesday. Sorry for the delay. Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_FCC100FC8D6B034CB88CD8173B2DA1581C5B7818EXCMBX03tsntnon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,=

 <= /p>

I’ve= just uploaded a new version of draft-brandenburg-cdni-has.

 = ;

You can fi= nd the document at: http://www.ietf.org/id/draft-brandenburg-cdni-has-01.= txt<= /p>

 = ;

The draft = is meant as an input document for the virtual meeting on Thursday to discus= s the impact of HTTP Adaptive Streaming on the CDNI Interfaces. In the draft a number of alternative solutions are presented for each area= where the use of HAS might touch with the CDNI Interfaces (e.g. content ac= quisition, content purge, request routing, logging and URL signing).

 = ;

I’m = looking forward to your comments.

 = ;

Have a nic= e weekend!

 = ;

Ray van Br= andenburg

 = ;

 = ;

 = ;

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van
Sent: woensdag 23 mei 2012 13:37
To: cdni@ietf.org
Subject: [CDNi] Status of Adaptive Streaming and CDNI draft

 

Hi all,

 

Next Tuesday we have a planned interim = meeting for discussing the combination between HTTP Adaptive Streaming and = CDNI. One  of the expected inputs for this meeting is a follow-up draft to draft-brandenburg-cdni-has-00.

 

We are currently working hard at finish= ing this draft, but as you might have seen, we have not yet uploaded a new = version. Currently we are at a stage where we have a first complete internal draft ready. However, Francois and I have agreed that we= rather spend some more time on it so that it fully covers all the areas of= the CDNI-HAS combination than upload an incomplete version right now. We a= re currently planning to upload the draft this Friday (25th of May) at the latest. I hope this gives you all enough time to read th= e draft before the meeting on Tuesday.

 

Sorry for the delay.<= /p>

 

Ray

 

 

 

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

--_000_FCC100FC8D6B034CB88CD8173B2DA1581C5B7818EXCMBX03tsntnon_-- From kevin.ma@azukisystems.com Sat May 26 16:37:16 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E54D21F84CF for ; Sat, 26 May 2012 16:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTPXoDOM91i6 for ; Sat, 26 May 2012 16:37:12 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD2F21F84CD for ; Sat, 26 May 2012 16:37:11 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 63CC78F64CE; Sat, 26 May 2012 19:20:03 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB028.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 6FDD1843FF0; Sat, 26 May 2012 19:20:00 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB028.mail.lan ([10.110.17.28]) with mapi; Sat, 26 May 2012 19:37:02 -0400 From: Kevin J Ma To: "Brandenburg, R. (Ray) van" , "cdni@ietf.org" Date: Sat, 26 May 2012 19:37:06 -0400 Thread-Topic: Status of Adaptive Streaming and CDNI draft Thread-Index: Ac0414J5VzCVuofZTcKanwrNrKyoTABqTCnQAEHKv5A= Message-ID: <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_291CC3F9E50E7641901A54E85D0977C653267F4D10MAILR002maill_" MIME-Version: 1.0 Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI 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: Sat, 26 May 2012 23:37:16 -0000 --_000_291CC3F9E50E7641901A54E85D0977C653267F4D10MAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ray, I read through the updated draft and had a number of comments ahead of the meeting. First, a general comment about manifest files. The document seems to assume that manifest files will be distributed through the CDN. There are many services where this is not the case, often to prevent modification. There is a large focus in the document on how to modify manifest files, in some cases where the manifest file itself is not necessarily relevant. I believe there are ways to optimize HAS delivery without modifying manifest files, and in imo, manifest manipulation falls under content adaptation which the wg declared to be out of scope for the initial phase? With respect section 2.2, I believe I commented on this in the initial draft, but I still feel that the relative vs absolute URL discussion is rather misleading. It seems to imply that: a) the HOST portion of a relative URL cannot point to a RR, that b) a RR must be accessed through some web service like API, and that c) absolute URLs can only point to specific surrogates. While these are all valid examples of how to use URLs, they do not seem to be typical cases. For us, a typical service has a DNS address which points to a base directory in one or more CDNs. The relative path from that base directory is the same in all CDNs. The hostname does not point to any one surrogate, and each CDN is still able to redirect requests as it sees fit. With respect to sections 3.1 and 3.2, while I agree that content storage and acquisition optimization is important, and that there should be metadata which can describe the format of the content, I do think the CDN needs to be fully HAS aware, nor do I think that the CDN necessarily needs access to the manifest file. I also do not see a "significant" impact to the MI. The metadata interface will have the ability to define metadata that applies to a set of content assets, per the META-10 requirement. Ultimately, the CDN needs to be able to respond to content requests from the client, even if that client got a manifest file directly from the content provider (not from the CDN) and is expecting the content to be in the format that was provided to the CDN by the content provider. How it got the content and how it stores it is out of scope? With respect to section 3.3, I think that a third case is missing, where the content provider does not provide the manifest file to the CDN (which can be a fairly common case). With respect to sections 3.3.2 and 3.3.3, would not DNS-based redirection solve the issue by simply directing manifest/chunk requests to the dCDN, rather than doing a manifest rewrite for every request (especially in the case of live streaming where the manifest might be changing on every chunk)? Also, presumably, the RR would only rewrite URLs which were within its own domain (i.e., not blackholing ad insertion segments, etc.)? With respect to section 3.5, the time component of URL signing is not mentioned until section 3.5.3. Expiration of URL tokens, in general, is an issue with HAS. Robust key management is an arguably more reliable approach to content access protection, though that would seem to be fairly well out of scope for CDNI. The proposed solution in section 3.5.3, seems to be managing session state? Depending on the complexity of the cookie, this could be troublesome if there is a failover and session state is not properly synchronized? And in the case of live streaming, the manifest is going to be requested every time? How is the state managed in that case? Is the cookie less susceptible to replay attacks than the URL token? Will the cookie work across all CDNs? Moving on to section 3.5.4 is even more concerning. What if the content is already encrypted? How is authentication being handled on the key server? Who is responsible for auditing the security of the solution? Is this intended to provide DRM? work with existing DRM? circumvent existing DRM? Does it only use the DRM/encryption support of the delivery protocol? or is the client expected to implement an alternate protocol? And how is this synchronized across CDNs? More generally, are we attempting to define security protocols for content delivery? If so, I would like to see a more formal definition of what those requirements are? With respect to section 3.6.2, it seems that we just want to be able to purge a set of content assets. Would a URI prefix not be sufficient? thanx. -- Kevin J. Ma From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Bra= ndenburg, R. (Ray) van Sent: Friday, May 25, 2012 10:19 AM To: cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft Hi all, I've just uploaded a new version of draft-brandenburg-cdni-has. You can find the document at: http://www.ietf.org/id/draft-brandenburg-cdni= -has-01.txt The draft is meant as an input document for the virtual meeting on Thursday= to discuss the impact of HTTP Adaptive Streaming on the CDNI Interfaces. I= n the draft a number of alternative solutions are presented for each area w= here the use of HAS might touch with the CDNI Interfaces (e.g. content acqu= isition, content purge, request routing, logging and URL signing). I'm looking forward to your comments. Have a nice weekend! Ray van Brandenburg From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Bra= ndenburg, R. (Ray) van Sent: woensdag 23 mei 2012 13:37 To: cdni@ietf.org Subject: [CDNi] Status of Adaptive Streaming and CDNI draft Hi all, Next Tuesday we have a planned interim meeting for discussing the combinati= on between HTTP Adaptive Streaming and CDNI. One of the expected inputs fo= r this meeting is a follow-up draft to draft-brandenburg-cdni-has-00. We are currently working hard at finishing this draft, but as you might hav= e seen, we have not yet uploaded a new version. Currently we are at a stage= where we have a first complete internal draft ready. However, Francois and= I have agreed that we rather spend some more time on it so that it fully c= overs all the areas of the CDNI-HAS combination than upload an incomplete v= ersion right now. We are currently planning to upload the draft this Friday= (25th of May) at the latest. I hope this gives you all enough time to read= the draft before the meeting on Tuesday. Sorry for the delay. Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_291CC3F9E50E7641901A54E85D0977C653267F4D10MAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ray,

  I read through the updated draft = and had a number of comments ahead of

  the = meeting.

 

  = First, a general comment about manifest files.  The document seems

  to assume that manifest files will be distrib= uted through the CDN.

  There are many servi= ces where this is not the case, often to prevent

=   modification.  There is a large focus in the document on how to= modify

  manifest files, in some cases wher= e the manifest file itself is not

  necessar= ily relevant.  I believe there are ways to optimize HAS

  delivery without modifying manifest files, and in imo, m= anifest

 manipulation falls under content a= daptation which the wg declared to

  be out = of scope for the initial phase?

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'> =

  With respect section 2.2, I believe I commented on t= his in the

  initial draft, but I still feel= that the relative vs absolute URL

  discuss= ion is rather misleading.  It seems to imply that:

    a) the HOST portion of a relative URL cannot poin= t to a RR, that

    b) a RR must b= e accessed through some web service like API, and that

    c) absolute URLs can only point to specific surrog= ates.

  While these are all valid examples o= f how to use URLs, they do not

  seem to be = typical cases.  For us, a typical service has a DNS<= /p>

  address which points to a base directory in one or more CDNs= .  The

  relative path from that base d= irectory is the same in all CDNs.  The

&nb= sp; hostname does not point to any one surrogate, and each CDN is still

  able to redirect requests as it sees fit.

 

  With respect= to sections 3.1 and 3.2, while I agree that content

<= p class=3DMsoNormal>  storage and acquisition optimization is important, and that ther= e

  should be metadata which can describe th= e format of the content, I

  do think the CD= N needs to be fully HAS aware, nor do I think that

  not see a "significant" imp= act to the MI.  The metadata interface

&nb= sp; will have the ability to define metadata that applies to a set of<= /o:p>

  content assets, per the META-10 requirement.&nb= sp; Ultimately, the CDN

  needs to be able t= o respond to content requests from the client,

&n= bsp; even if that client got a manifest file directly from the content=

  provider (not from the CDN) and is expecting t= he content to be in

  the format that was = provided to the CDN by the content provider.

&nb= sp; How it got the content and how it stores it is out of scope?=

 

  With respect to sec= tion 3.3, I think that a third case is missing,

=  where the content provider does not provide the manifest file to the<= o:p>

  CDN (which can be a fairly common case).

 

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>  With respe= ct to sections 3.3.2 and 3.3.3, would not DNS-based

  requests to the dCDN, rather than doing a ma= nifest rewrite for every

  request (especial= ly in the case of live streaming where the manifest

  only rewrite URLs which were within= its own domain (i.e., not

  blackholing ad = insertion segments, etc.)?

 

  With respect to section 3.5, the time component of URL si= gning is

  not mentioned until section 3.5.3= .  Expiration of URL tokens, in

  gener= al, is an issue with HAS.  Robust key management is an arguably

  more reliable approach to content access protect= ion, though that

  would seem to be fairly w= ell out of scope for CDNI.  The proposed

&nb= sp; solution in section 3.5.3, seems to be managing session state?

  Depending on the complexity of the cookie, this co= uld be troublesome

  if there is a failover = and session state is not properly synchronized?

=   And in the case of live streaming, the manifest is going to be<= o:p>

  requested every time?  How is the sta= te managed in that case?  Is

  the cook= ie less susceptible to replay attacks than the URL token?=

  Will the cookie work across all CDNs?  Moving on to se= ction 3.5.4

  is even more concerning. = What if the content is already encrypted?

 = How is authentication being handled on the key server?  Who is

  responsible for auditing the security of the sol= ution?  Is this

  intended to provide = DRM?  work with existing DRM?  circumvent

  delivery protocol?  or is the c= lient expected to implement an

  alternate p= rotocol?  And how is this synchronized across CDNs?<= /p>

  More generally, are we attempting to define security protoco= ls for

  content delivery?  If so, I wo= uld like to see a more formal

 definition o= f what those requirements are?

 <= /span>

  With respect to section 3.6.2, it seems that we just = want to be able

 to purge a set of content = assets.  Would a URI prefix not be sufficient?

thanx.

&= nbsp;

--  Kevin J. Ma

<= o:p> 

From: cd= ni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Bran= denburg, R. (Ray) van
Sent: Friday, May 25, 2012 10:19 AM
T= o: cdni@ietf.org
Subject: Re: [CDNi] Status of Adaptive Strea= ming and CDNI draft

<= o:p> 

Hi all,

 <= /p>

I’ve just uploaded a new version of dr= aft-brandenburg-cdni-has.

=  

You can find the do= cument at: http://www.ietf.org/id/draft= -brandenburg-cdni-has-01.txt

=

 

The draft is meant as an input document for the virtual meeting on= Thursday to discuss the impact of HTTP Adaptive Streaming on the CDNI Inte= rfaces. In the draft a number of alternative solutions are presented for ea= ch area where the use of HAS might touch with the CDNI Interfaces (e.g. con= tent acquisition, content purge, request routing, logging and URL signing).=

 =

I’m looking forward to your comments.=

 <= /p>

Have a nice weekend!

 

= Ray van Brandenburg

 

 <= /span>

 

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ie= tf.org] On Behalf Of Brandenburg, R. (Ray) van
Sent: woens= dag 23 mei 2012 13:37
To: cdni@ietf.org
Subject: [CDNi]= Status of Adaptive Streaming and CDNI draft

 

Hi all,

 

N= ext Tuesday we have a planned interim meeting for discussing the combinatio= n between HTTP Adaptive Streaming and CDNI. One  of the expected input= s for this meeting is a follow-up draft to draft-brandenburg-cdni-has-00. <= o:p>

 <= /span>

We are currently working hard = at finishing this draft, but as you might have seen, we have not yet upload= ed a new version. Currently we are at a stage where we have a first complet= e internal draft ready. However, Francois and I have agreed that we rather = spend some more time on it so that it fully covers all the areas of the CDN= I-HAS combination than upload an incomplete version right now. We are curre= ntly planning to upload the draft this Friday (25th of May) at the latest. I hope this gives you all enough time to read= the draft before the meeting on Tuesday.

=

 

Sorry for the delay.

 

Ray

 =

 

 

<= p>This e-mail and its contents are subject to the DISCLAIME= R at http://www.tno.nl/emaild= isclaimer

= --_000_291CC3F9E50E7641901A54E85D0977C653267F4D10MAILR002maill_-- From stef@jet-stream.com Sun May 27 06:03: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 49E6621F852B for ; Sun, 27 May 2012 06:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9t53q7KNsC5 for ; Sun, 27 May 2012 06:03:57 -0700 (PDT) Received: from monitor1.jet-stream.nl (smtp.jet-stream.nl [91.196.106.226]) by ietfa.amsl.com (Postfix) with ESMTP id 54C6F21F8514 for ; Sun, 27 May 2012 06:03:56 -0700 (PDT) Received: from [192.168.1.2] (5ED5ABD7.cm-7-6c.dynamic.ziggo.nl [94.213.171.215]) (authenticated bits=0) by monitor1.jet-stream.nl (8.13.7/8.13.7) with ESMTP id q4RD3GP4026984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 27 May 2012 15:03:55 +0200 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_8422F145-FF12-48B3-A0A2-DA5A9EBF67ED" From: Stef van der Ziel In-Reply-To: <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> Date: Sun, 27 May 2012 15:03:49 +0200 Message-Id: <76875F4E-5A68-417F-AD88-C21679F986A8@jet-stream.com> References: <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> To: Kevin J Ma X-Mailer: Apple Mail (2.1257) Cc: "cdni@ietf.org" Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI 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: Sun, 27 May 2012 13:03:59 -0000 --Apple-Mail=_8422F145-FF12-48B3-A0A2-DA5A9EBF67ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Kevin, Actually, many CDNs prefer to serve out both the segments and the = manifest files. Sure, dumb caching/DNS based CDNs can be used to deliver segments and = they wouldn't care about segments. They will just pump out the delivered = objects. But intelligent CDNs that are actually usable for = commercial/secure and manageable HAS, need the manifests. IMHO the role of a manifest file should not be confused with the role of = a referrer file.=20 A manifest is to represent the entire content, not just to the client = but in the entire chain of encoding, protection, CDN and clients.=20 A referrer file is the proper way to point to the (logical) content from = any remote location. We hardly ever see manifest files to be distributed outside of the CDN = in reality. It is not a fairly common scenario and should not be. In = more automated environments, it can actually be the CDN that creates the = manifest. The assumption that manifest files should or can be distributed offline = or outside the CDN is mostly wrong. The assumption that you can point = from a manifest to a CDN for the segments won't work since a proper CDN = would (should) block direct access to segments to prevent deep linking. = But we understand why people make these assumptions, we've heard other = statements from HAS enthusiasts that don't make sense in the real world. Serving out the manifests alongside the segments from the same CDN = account is done for multiple reasons, which do not at all adapt the = content: - Logical asset recognition (parsing the manifests so the CDN = understands that the segments are part of a logical entity) - Logical asset management (processing, copying, managing manifests and = subsequent segments as if they are one asset) - Logical asset reporting (reporting manifests and subsequent segments = via web interfaces and APIs as if they are one asset) - Request routing control (CDNs only produce URLs for manifest files and = will not accept requests for segments to prevent unnecessary request = routing overload by having to request route every individual segment = request) - Access control (CDNs will not allow direct access to segments but only = via the manifest file to prevent deep-linking, you don't want any third = party to publish a manifest file on an unlicensed portal and then point = users to the segments on the CDN without any access control) - Session control (http streaming is stateless and that is quite = dramatic for CDNs because you lose control over the session and over = session logging) There are additional reasons for CDNs to be able to adapt the manifest = files but do so without changing the actual content: - For instance, they could dynamically insert base URLs to point users = to a group of servers to improve the availability. - Or they could dynamically insert tokens into the manifest to control = access to segments. - Or they could dynamically insert session keys to be able to track a = unique user session over multiple federated CDNs. - Or they could dynamically remove higher or lower bit rates to better = control the actual QoE on a per request basis. Concluding:=20 To a CDN, the segments aren't actually that interesting. They are just = pieces of useless raw data that needs to be protected, managed and = served.=20 For a CDN, the manifest represents the content and is a critical = component so they need to be able to parse, alter and serve them.=20 I think the above by itself describes some interesting challenges. Just = one example: how are CDNs going to guarantee anti-deeplinking to = segments in a federated constellation where multiple nodes of multiple = CDNs and request routers need to be aware of each others sessions and = tokens, etc?=20 My 2 cents. Kind regards, Stef van der Ziel --=20 Owner Jet-Stream | StreamZilla GMT+1 Office: +31 50 5261820 | Mobile: +31 6 23406348 www.jet-stream.com | www.streamzillacdn.com this communication is confidential On 27 mei 2012, at 01:37, Kevin J Ma wrote: > Hi Ray, > =20 > I read through the updated draft and had a number of comments ahead = of > the meeting. > =20 > First, a general comment about manifest files. The document seems > to assume that manifest files will be distributed through the CDN. > There are many services where this is not the case, often to prevent > modification. There is a large focus in the document on how to = modify > manifest files, in some cases where the manifest file itself is not > necessarily relevant. I believe there are ways to optimize HAS > delivery without modifying manifest files, and in imo, manifest > manipulation falls under content adaptation which the wg declared to > be out of scope for the initial phase? > =20 > With respect section 2.2, I believe I commented on this in the > initial draft, but I still feel that the relative vs absolute URL > discussion is rather misleading. It seems to imply that: > a) the HOST portion of a relative URL cannot point to a RR, that > b) a RR must be accessed through some web service like API, and = that > c) absolute URLs can only point to specific surrogates. > While these are all valid examples of how to use URLs, they do not > seem to be typical cases. For us, a typical service has a DNS > address which points to a base directory in one or more CDNs. The > relative path from that base directory is the same in all CDNs. The > hostname does not point to any one surrogate, and each CDN is still > able to redirect requests as it sees fit. > =20 > With respect to sections 3.1 and 3.2, while I agree that content > storage and acquisition optimization is important, and that there > should be metadata which can describe the format of the content, I > do think the CDN needs to be fully HAS aware, nor do I think that > the CDN necessarily needs access to the manifest file. I also do > not see a "significant" impact to the MI. The metadata interface > will have the ability to define metadata that applies to a set of > content assets, per the META-10 requirement. Ultimately, the CDN > needs to be able to respond to content requests from the client, > even if that client got a manifest file directly from the content > provider (not from the CDN) and is expecting the content to be in > the format that was provided to the CDN by the content provider. > How it got the content and how it stores it is out of scope? > =20 > With respect to section 3.3, I think that a third case is missing, > where the content provider does not provide the manifest file to the > CDN (which can be a fairly common case). > =20 > With respect to sections 3.3.2 and 3.3.3, would not DNS-based > redirection solve the issue by simply directing manifest/chunk > requests to the dCDN, rather than doing a manifest rewrite for every > request (especially in the case of live streaming where the manifest > might be changing on every chunk)? Also, presumably, the RR would > only rewrite URLs which were within its own domain (i.e., not > blackholing ad insertion segments, etc.)? > =20 > With respect to section 3.5, the time component of URL signing is > not mentioned until section 3.5.3. Expiration of URL tokens, in > general, is an issue with HAS. Robust key management is an arguably > more reliable approach to content access protection, though that > would seem to be fairly well out of scope for CDNI. The proposed > solution in section 3.5.3, seems to be managing session state? > Depending on the complexity of the cookie, this could be troublesome > if there is a failover and session state is not properly = synchronized? > And in the case of live streaming, the manifest is going to be > requested every time? How is the state managed in that case? Is > the cookie less susceptible to replay attacks than the URL token? > Will the cookie work across all CDNs? Moving on to section 3.5.4 > is even more concerning. What if the content is already encrypted? > How is authentication being handled on the key server? Who is > responsible for auditing the security of the solution? Is this > intended to provide DRM? work with existing DRM? circumvent > existing DRM? Does it only use the DRM/encryption support of the > delivery protocol? or is the client expected to implement an > alternate protocol? And how is this synchronized across CDNs? > More generally, are we attempting to define security protocols for > content delivery? If so, I would like to see a more formal > definition of what those requirements are? > =20 > With respect to section 3.6.2, it seems that we just want to be able > to purge a set of content assets. Would a URI prefix not be = sufficient? > =20 > thanx. > =20 > -- Kevin J. Ma > =20 > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Brandenburg, R. (Ray) van > Sent: Friday, May 25, 2012 10:19 AM > To: cdni@ietf.org > Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft > =20 > Hi all, > =20 > I=92ve just uploaded a new version of draft-brandenburg-cdni-has. > =20 > You can find the document at: = http://www.ietf.org/id/draft-brandenburg-cdni-has-01.txt > =20 > The draft is meant as an input document for the virtual meeting on = Thursday to discuss the impact of HTTP Adaptive Streaming on the CDNI = Interfaces. In the draft a number of alternative solutions are presented = for each area where the use of HAS might touch with the CDNI Interfaces = (e.g. content acquisition, content purge, request routing, logging and = URL signing). > =20 > I=92m looking forward to your comments. > =20 > Have a nice weekend! > =20 > Ray van Brandenburg > =20 > =20 > =20 > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Brandenburg, R. (Ray) van > Sent: woensdag 23 mei 2012 13:37 > To: cdni@ietf.org > Subject: [CDNi] Status of Adaptive Streaming and CDNI draft > =20 > Hi all, > =20 > Next Tuesday we have a planned interim meeting for discussing the = combination between HTTP Adaptive Streaming and CDNI. One of the = expected inputs for this meeting is a follow-up draft to = draft-brandenburg-cdni-has-00. > =20 > We are currently working hard at finishing this draft, but as you = might have seen, we have not yet uploaded a new version. Currently we = are at a stage where we have a first complete internal draft ready. = However, Francois and I have agreed that we rather spend some more time = on it so that it fully covers all the areas of the CDNI-HAS combination = than upload an incomplete version right now. We are currently planning = to upload the draft this Friday (25th of May) at the latest. I hope this = gives you all enough time to read the draft before the meeting on = Tuesday. > =20 > Sorry for the delay. > =20 > Ray > =20 > =20 > =20 > This e-mail and its contents are subject to the DISCLAIMER at = http://www.tno.nl/emaildisclaimer >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --Apple-Mail=_8422F145-FF12-48B3-A0A2-DA5A9EBF67ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Kevin,

Actually, = many CDNs prefer to serve out both the segments and the manifest = files.
Sure, dumb caching/DNS based CDNs can be used to = deliver segments and they wouldn't care about segments. They will just = pump out the delivered objects. But intelligent CDNs that are = actually usable for commercial/secure and manageable HAS, need the = manifests.

IMHO the role of a manifest = file should not be confused with the role of a referrer = file. 
A manifest is to represent the entire = content, not just to the client but in the entire chain of encoding, = protection, CDN and clients. 
A referrer file is the = proper way to point to the (logical) content from any remote = location.

We hardly ever see manifest files to = be distributed outside of the CDN in reality. It is not a fairly common = scenario and should not be. In more automated environments, it can = actually be the CDN that creates the = manifest.

The assumption that manifest files = should or can be distributed offline or outside the CDN is mostly = wrong. The assumption that you can point from a manifest to a CDN = for the segments won't work since a proper CDN would (should) block = direct access to segments to prevent deep linking. But we understand why = people make these assumptions, we've heard other statements from HAS = enthusiasts that don't make sense in the real = world.

Serving out the manifests alongside the = segments from the same CDN account is done for multiple reasons, which = do not at all adapt the content:

- Logical = asset recognition (parsing the manifests so the CDN understands that the = segments are part of a logical entity)
- Logical asset = management (processing, copying, managing manifests and subsequent = segments as if they are one asset)
- Logical = asset reporting (reporting manifests and subsequent segments via web = interfaces and APIs as if they are one asset)
- = Request routing control (CDNs only produce URLs for manifest files and = will not accept requests for segments to prevent unnecessary request = routing overload by having to request route every individual segment = request)
- Access control (CDNs will not allow direct access = to segments but only via the manifest file to prevent deep-linking, you = don't want any third party to publish a manifest file on an unlicensed = portal and then point users to the segments on the CDN without any = access control)
- Session control (http streaming is stateless = and that is quite dramatic for CDNs because you lose control over the = session and over session logging)

There are = additional reasons for CDNs to be able to adapt the manifest files but = do so without changing the actual content:
- For instance, = they could dynamically insert base URLs to point users to a group of = servers to improve the availability.
- Or they could = dynamically insert tokens into the manifest to control access to = segments.
- Or they could dynamically insert session keys to = be able to track a unique user session over multiple federated = CDNs.
- Or they could dynamically remove higher or lower = bit rates to better control the actual QoE on a per request = basis.

Concluding: 
To a = CDN, the segments aren't actually that interesting. They are just pieces = of useless raw data that needs to be protected, managed and = served. 
For a CDN, the manifest represents the content = and is a critical component so they need to be able to parse, alter and = serve them. 

I think the above by itself = describes some interesting challenges. Just one example: how are CDNs = going to guarantee anti-deeplinking to segments in a federated = constellation where multiple nodes of multiple CDNs and request routers = need to be aware of each others sessions and tokens, = etc? 

My 2 = cents.

Kind = regards, Stef van der Ziel

-- 
Owner= Jet-Stream | = StreamZilla
<= /span>
Office: +31 50 5261820 | Mobile: +31 6 = 23406348
= www.jet-stream.com | www.streamzillacdn.com
this communication is = confidential




On 27 mei 2012, at 01:37, Kevin J Ma wrote:

Hi = Ray,
  I read = through the updated draft and had a number of comments ahead = of
  the = meeting.
  First, a = general comment about manifest files.  The document = seems
  to assume = that manifest files will be distributed through the = CDN.
  There are = many services where this is not the case, often to = prevent
  = modification.  There is a large focus in the document on how to = modify
  manifest = files, in some cases where the manifest file itself is = not
  necessarily relevant.  I = believe there are ways to optimize HAS
  be out of = scope for the initial phase?
  With = respect section 2.2, I believe I commented on this in = the
  initial draft, but I still feel = that the relative vs absolute URL
  While = these are all valid examples of how to use URLs, they do = not
  seem to be typical cases.  For = us, a typical service has a DNS
  relative = path from that base directory is the same in all CDNs.  = The
  hostname does not point to any one = surrogate, and each CDN is still
  With = respect to sections 3.1 and 3.2, while I agree that = content
  storage = and acquisition optimization is important, and that = there
  should be = metadata which can describe the format of the content, = I
  do think the CDN needs to be fully = HAS aware, nor do I think that
  not see a = "significant" impact to the MI.  The metadata = interface
  will have = the ability to define metadata that applies to a set = of
  content assets, per the META-10 = requirement.  Ultimately, the CDN
  even if = that client got a manifest file directly from the = content
  provider = (not from the CDN) and is expecting the content to be = in
  the format that was provided to the = CDN by the content provider.
  With = respect to section 3.3, I think that a third case is = missing,
 where the = content provider does not provide the manifest file to = the
  CDN (which can be a fairly common = case).
  With = respect to sections 3.3.2 and 3.3.3, would not = DNS-based
  = redirection solve the issue by simply directing = manifest/chunk
  requests = to the dCDN, rather than doing a manifest rewrite for = every
  request = (especially in the case of live streaming where the = manifest
  might be = changing on every chunk)?  Also, presumably, the RR = would
  only = rewrite URLs which were within its own domain (i.e., = not
  blackholing ad insertion segments, = etc.)?
  With = respect to section 3.5, the time component of URL signing = is
  not mentioned until section = 3.5.3.  Expiration of URL tokens, in
  more = reliable approach to content access protection, though = that
  would = seem to be fairly well out of scope for CDNI.  The = proposed
  solution = in section 3.5.3, seems to be managing session = state?
  Depending = on the complexity of the cookie, this could be = troublesome
  if there = is a failover and session state is not properly = synchronized?
  And = in the case of live streaming, the manifest is going to = be
  requested every time?  How is = the state managed in that case?  Is
  Will the = cookie work across all CDNs?  Moving on to section = 3.5.4
  is even = more concerning.  What if the content is already = encrypted?
  How is = authentication being handled on the key server?  Who = is
  responsible for auditing the = security of the solution?  Is this
  existing = DRM?  Does it only use the DRM/encryption support of = the
  delivery protocol?  or is the = client expected to implement an
  More = generally, are we attempting to define security protocols = for
  content delivery?  If so, I = would like to see a more formal
  With = respect to section 3.6.2, it seems that we just want to be = able
 to purge a = set of content assets.  Would a URI prefix not be = sufficient?
--  Kevin = J. Ma
 cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org= ] On Behalf Of Brandenburg, R. (Ray) = van
Sent: Friday, May 25, 2012 10:19 = AM
To: cdni@ietf.org
Subject: Re: [CDNi] Status of = Adaptive Streaming and CDNI = draft
Hi = all,
 
I=92ve just uploaded a new = version of draft-brandenburg-cdni-has.
The draft is meant as an input document for the = virtual meeting on Thursday to discuss the impact of HTTP Adaptive = Streaming on the CDNI Interfaces. In the draft a number of alternative = solutions are presented for each area where the use of HAS might touch = with the CDNI Interfaces (e.g. content acquisition, content purge, = request routing, logging and URL signing).
I=92m looking forward to your = comments.
 
Have a nice = weekend!
 
Ray van = Brandenburg
 
 
 cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org= ] On Behalf Of Brandenburg, R. (Ray) = van
Sent: woensdag 23 mei 2012 = 13:37
To: cdni@ietf.org
Subject: [CDNi] Status of Adaptive = Streaming and CDNI draft
 
Hi all,
 
Next Tuesday we have a planned interim meeting = for discussing the combination between HTTP Adaptive Streaming and CDNI. = One  of the expected inputs for this meeting is a follow-up draft = to draft-brandenburg-cdni-has-00.
 
We are currently working hard at finishing this = draft, but as you might have seen, we have not yet uploaded a new = version. Currently we are at a stage where we have a first complete = internal draft ready. However, Francois and I have agreed that we rather = spend some more time on it so that it fully covers all the areas of the = CDNI-HAS combination than upload an incomplete version right now. We are = currently planning to upload the draft this Friday (25 of May) at the latest. I = hope this gives you all enough time to read the draft before the meeting = on Tuesday.
Sorry for = the delay.
This e-mail and its contents are subject to = the DISCLAIMER at CDNi@ietf.org
Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI 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: Sun, 27 May 2012 16:00:57 -0000 --_000_291CC3F9E50E7641901A54E85D0977C653267F4D1FMAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stef, I was not arguing that a CDN would not prefer to have the manifest. I was more arguing that content providers may not trust CDNs with the manifest generation/modification. Securing content, preventing unauthorized access, and preventing piracy requires much more than simple auth tokens. DRM is explicitly listed as out-of-scope in the charter, so as I said, if the intent is to define a security protocol, then I would like to see more requirements. If, however, I have misunderstood, and section 3.5.4 is describing an existing feature that is widely supported across CDNs today, that just needs CDNI support, then I suppose that would be different. As for asset management, I agree the CDN needs to know what files go together, but I do not agree that a CDN should be allowed to modify a manifest file any way it wants, or generate any manifest it wants and present that to the end user. Manifest files may contain other information besides segment file locations, e.g., DRM info, targeted ad insertions, subscription-based customizations, etc., which the content provider may not trust the CDN with. I would like to know where the boundaries are of what the CDN may modify? Much of this requires subscriber-awareness. How subscriber-aware are we assuming the CDN to be? One might argue that the CDN should perform all these functions and be a one-stop intelligent content delivery shop, but that seems improbable in the short-run? Perhaps a more general question: Are we talking about making CDNs HAS aware, or making CDNI HAS aware? It feels more like the former, with the latter being an after-thought, and it is not clear to me how the former fits into the charter? Going straight from the uCDN routing every segment, to the uCDN supporting modification of a half dozen manifest formats feels disingenuous. Is there no BCP for how to configure DNS-RR to take the load off the uCDN RR, or a simple set of metadata to describe the source content structure which can facilitate more efficient content acquisition? thanx. -- Kevin J. Ma From: Stef van der Ziel [mailto:stef@jet-stream.nl] Sent: Sunday, May 27, 2012 9:03 AM To: Kevin J Ma Cc: Brandenburg, R. (Ray) van; cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft Hi Kevin, Actually, many CDNs prefer to serve out both the segments and the manifest = files. Sure, dumb caching/DNS based CDNs can be used to deliver segments and they = wouldn't care about segments. They will just pump out the delivered objects= . But intelligent CDNs that are actually usable for commercial/secure and m= anageable HAS, need the manifests. IMHO the role of a manifest file should not be confused with the role of a = referrer file. A manifest is to represent the entire content, not just to the client but i= n the entire chain of encoding, protection, CDN and clients. A referrer file is the proper way to point to the (logical) content from an= y remote location. We hardly ever see manifest files to be distributed outside of the CDN in r= eality. It is not a fairly common scenario and should not be. In more autom= ated environments, it can actually be the CDN that creates the manifest. The assumption that manifest files should or can be distributed offline or = outside the CDN is mostly wrong. The assumption that you can point from a m= anifest to a CDN for the segments won't work since a proper CDN would (shou= ld) block direct access to segments to prevent deep linking. But we underst= and why people make these assumptions, we've heard other statements from HA= S enthusiasts that don't make sense in the real world. Serving out the manifests alongside the segments from the same CDN account = is done for multiple reasons, which do not at all adapt the content: - Logical asset recognition (parsing the manifests so the CDN understands t= hat the segments are part of a logical entity) - Logical asset management (processing, copying, managing manifests and sub= sequent segments as if they are one asset) - Logical asset reporting (reporting manifests and subsequent segments via = web interfaces and APIs as if they are one asset) - Request routing control (CDNs only produce URLs for manifest files and wi= ll not accept requests for segments to prevent unnecessary request routing = overload by having to request route every individual segment request) - Access control (CDNs will not allow direct access to segments but only vi= a the manifest file to prevent deep-linking, you don't want any third party= to publish a manifest file on an unlicensed portal and then point users to= the segments on the CDN without any access control) - Session control (http streaming is stateless and that is quite dramatic f= or CDNs because you lose control over the session and over session logging) There are additional reasons for CDNs to be able to adapt the manifest file= s but do so without changing the actual content: - For instance, they could dynamically insert base URLs to point users to a= group of servers to improve the availability. - Or they could dynamically insert tokens into the manifest to control acce= ss to segments. - Or they could dynamically insert session keys to be able to track a uniqu= e user session over multiple federated CDNs. - Or they could dynamically remove higher or lower bit rates to better cont= rol the actual QoE on a per request basis. Concluding: To a CDN, the segments aren't actually that interesting. They are just piec= es of useless raw data that needs to be protected, managed and served. For a CDN, the manifest represents the content and is a critical component = so they need to be able to parse, alter and serve them. I think the above by itself describes some interesting challenges. Just one= example: how are CDNs going to guarantee anti-deeplinking to segments in a= federated constellation where multiple nodes of multiple CDNs and request = routers need to be aware of each others sessions and tokens, etc? My 2 cents. Kind regards, Stef van der Ziel -- Owner Jet-Stream | StreamZilla GMT+1 Office: +31 50 5261820 | Mobile: +31 6 23406348 www.jet-stream.com | www.streamzillacdn.com this communication is confidential On 27 mei 2012, at 01:37, Kevin J Ma wrote: Hi Ray, I read through the updated draft and had a number of comments ahead of the meeting. First, a general comment about manifest files. The document seems to assume that manifest files will be distributed through the CDN. There are many services where this is not the case, often to prevent modification. There is a large focus in the document on how to modify manifest files, in some cases where the manifest file itself is not necessarily relevant. I believe there are ways to optimize HAS delivery without modifying manifest files, and in imo, manifest manipulation falls under content adaptation which the wg declared to be out of scope for the initial phase? With respect section 2.2, I believe I commented on this in the initial draft, but I still feel that the relative vs absolute URL discussion is rather misleading. It seems to imply that: a) the HOST portion of a relative URL cannot point to a RR, that b) a RR must be accessed through some web service like API, and that c) absolute URLs can only point to specific surrogates. While these are all valid examples of how to use URLs, they do not seem to be typical cases. For us, a typical service has a DNS address which points to a base directory in one or more CDNs. The relative path from that base directory is the same in all CDNs. The hostname does not point to any one surrogate, and each CDN is still able to redirect requests as it sees fit. With respect to sections 3.1 and 3.2, while I agree that content storage and acquisition optimization is important, and that there should be metadata which can describe the format of the content, I do think the CDN needs to be fully HAS aware, nor do I think that the CDN necessarily needs access to the manifest file. I also do not see a "significant" impact to the MI. The metadata interface will have the ability to define metadata that applies to a set of content assets, per the META-10 requirement. Ultimately, the CDN needs to be able to respond to content requests from the client, even if that client got a manifest file directly from the content provider (not from the CDN) and is expecting the content to be in the format that was provided to the CDN by the content provider. How it got the content and how it stores it is out of scope? With respect to section 3.3, I think that a third case is missing, where the content provider does not provide the manifest file to the CDN (which can be a fairly common case). With respect to sections 3.3.2 and 3.3.3, would not DNS-based redirection solve the issue by simply directing manifest/chunk requests to the dCDN, rather than doing a manifest rewrite for every request (especially in the case of live streaming where the manifest might be changing on every chunk)? Also, presumably, the RR would only rewrite URLs which were within its own domain (i.e., not blackholing ad insertion segments, etc.)? With respect to section 3.5, the time component of URL signing is not mentioned until section 3.5.3. Expiration of URL tokens, in general, is an issue with HAS. Robust key management is an arguably more reliable approach to content access protection, though that would seem to be fairly well out of scope for CDNI. The proposed solution in section 3.5.3, seems to be managing session state? Depending on the complexity of the cookie, this could be troublesome if there is a failover and session state is not properly synchronized? And in the case of live streaming, the manifest is going to be requested every time? How is the state managed in that case? Is the cookie less susceptible to replay attacks than the URL token? Will the cookie work across all CDNs? Moving on to section 3.5.4 is even more concerning. What if the content is already encrypted? How is authentication being handled on the key server? Who is responsible for auditing the security of the solution? Is this intended to provide DRM? work with existing DRM? circumvent existing DRM? Does it only use the DRM/encryption support of the delivery protocol? or is the client expected to implement an alternate protocol? And how is this synchronized across CDNs? More generally, are we attempting to define security protocols for content delivery? If so, I would like to see a more formal definition of what those requirements are? With respect to section 3.6.2, it seems that we just want to be able to purge a set of content assets. Would a URI prefix not be sufficient? thanx. -- Kevin J. Ma From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: Friday, May 25, 2012 10:19 AM To: cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft Hi all, I've just uploaded a new version of draft-brandenburg-cdni-has. You can find the document at: http://www.ietf.org/id/draft-brandenburg-cdni= -has-01.txt The draft is meant as an input document for the virtual meeting on Thursday= to discuss the impact of HTTP Adaptive Streaming on the CDNI Interfaces. I= n the draft a number of alternative solutions are presented for each area w= here the use of HAS might touch with the CDNI Interfaces (e.g. content acqu= isition, content purge, request routing, logging and URL signing). I'm looking forward to your comments. Have a nice weekend! Ray van Brandenburg From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: woensdag 23 mei 2012 13:37 To: cdni@ietf.org Subject: [CDNi] Status of Adaptive Streaming and CDNI draft Hi all, Next Tuesday we have a planned interim meeting for discussing the combinati= on between HTTP Adaptive Streaming and CDNI. One of the expected inputs fo= r this meeting is a follow-up draft to draft-brandenburg-cdni-has-00. We are currently working hard at finishing this draft, but as you might hav= e seen, we have not yet uploaded a new version. Currently we are at a stage= where we have a first complete internal draft ready. However, Francois and= I have agreed that we rather spend some more time on it so that it fully c= overs all the areas of the CDNI-HAS combination than upload an incomplete v= ersion right now. We are currently planning to upload the draft this Friday= (25th of May) at the latest. I hope this gives you all enough time to read= the draft before the meeting on Tuesday. Sorry for the delay. Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_291CC3F9E50E7641901A54E85D0977C653267F4D1FMAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stef,

  I was not arguing that a CDN wou= ld not prefer to have the manifest.

  I was = more arguing that content providers may not trust CDNs with

  the manifest generation/modification.  Securing cont= ent, preventing

  unauthorized access, and p= reventing piracy requires much more than

  s= imple auth tokens.  DRM is explicitly listed as out-of-scope in

  the charter, so as I said, if the intent is to d= efine a security

  protocol, then I would li= ke to see more requirements.  If, however,

&= nbsp; I have misunderstood, and section 3.5.4 is describing an existing

  feature that is widely supported across CDNs = today, that just needs

  CDNI support, then = I suppose that would be different.

 

  As for asset management, I agree the CDN needs to= know what files go

  together, but I do n= ot agree that a CDN should be allowed to modify

&= nbsp; a manifest file any way it wants, or generate any manifest it wants

  and present that to the end user.  Man= ifest files may contain other

 information = besides segment file locations, e.g., DRM info, targeted<= /p>

  ad insertions, subscription-based customizations, etc., whic= h the

  content provider may not trust the C= DN with.  I would like to know

  where = the boundaries are of what the CDN may modify?  Much of this

  requires subscriber-awareness.  How subscriber= -aware are we assuming

 the CDN to be? = ; One might argue that the CDN should perform all these

 functions and be a one-stop intelligent content delivery shop= , but

 that seems improbable in the short-r= un?

 

  Perha= ps a more general question: Are we talking about making CDNs

  HAS aware, or making CDNI HAS aware?  It feels more= like the former,

  with the latter being an= after-thought, and it is not clear to me

  = how the former fits into the charter?  Going straight from the uCDN

  routing every segment, to the uCDN supportin= g modification of a half

  dozen manifest fo= rmats feels disingenuous.  Is there no BCP for how

  to configure DNS-RR to take the load off the uCDN RR, or a si= mple

  set of metadata to describe the sourc= e content structure which can

  facilitate m= ore efficient content acquisition?

 

thanx.

 

--  Kevin J. Ma

 <= /span>

From: Stef van der Ziel = [mailto:stef@jet-stream.nl]
Sent: Sunday, May 27, 2012 9:03 AMTo: Kevin J Ma
Cc: Brandenburg, R. (Ray) van; cdni@ietf.= org
Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI dra= ft

 <= /p>

Hi Kevin,

 

Actually, ma= ny CDNs prefer to serve out both the segments and the manifest files.<= /o:p>

Sure, dumb caching/DNS based CDNs = can be used to deliver segments and they wouldn't care about segments. They= will just pump out the delivered objects. But intelligent CDNs that a= re actually usable for commercial/secure and manageable HAS, need the manif= ests.

 

IMHO the role of a manifest file should = not be confused with the role of a referrer file. 

A manifest is to represent the entire cont= ent, not just to the client but in the entire chain of encoding, protection= , CDN and clients. 

A re= ferrer file is the proper way to point to the (logical) content from any re= mote location.

 

We hardly ever see manifest files to= be distributed outside of the CDN in reality. It is not a fairly common sc= enario and should not be. In more automated environments, it can actua= lly be the CDN that creates the manifest.

 

The assum= ption that manifest files should or can be distributed offline or outside t= he CDN is mostly wrong. The assumption that you can point from a manif= est to a CDN for the segments won't work since a proper CDN would (should) = block direct access to segments to prevent deep linking. But we understand = why people make these assumptions, we've heard other statements from HAS en= thusiasts that don't make sense in the real world.

 

= Serving out the manifests alongside the segments from the same CDN account = is done for multiple reasons, which do not at all adapt the content:

 

- Logical asset recognition (parsing the manifests so the= CDN understands that the segments are part of a logical entity)=

- Logical asset management (proces= sing, copying, managing manifests and subsequent segments as if they are on= e asset)

- Lo= gical asset reporting (reporting manifests and subsequent segments via web = interfaces and APIs as if they are one asset)

- Request routing control (CDNs only produce U= RLs for manifest files and will not accept requests for segments to prevent= unnecessary request routing overload by having to request route every indi= vidual segment request)

- Acc= ess control (CDNs will not allow direct access to segments but only via the= manifest file to prevent deep-linking, you don't want any third party to p= ublish a manifest file on an unlicensed portal and then point users to the = segments on the CDN without any access control)

- Session control (http streaming is stateless and that = is quite dramatic for CDNs because you lose control over the session and ov= er session logging)

&nbs= p;

There are additional reasons fo= r CDNs to be able to adapt the manifest files but do so without changing th= e actual content:

- For insta= nce, they could dynamically insert base URLs to point users to a group of s= ervers to improve the availability.

- Or they could dynamically insert tokens into the manifest to contr= ol access to segments.

- Or t= hey could dynamically insert session keys to be able to track a unique user= session over multiple federated CDNs.

- Or they could dynamically remove higher or lower bit rates= to better control the actual QoE on a per request basis.

 

Concluding: 

To a CDN, the segments aren't actually that interesting. They are just pi= eces of useless raw data that needs to be protected, managed and served.&nb= sp;

For a CDN, the manifest r= epresents the content and is a critical component so they need to be able t= o parse, alter and serve them. 

 

I think the ab= ove by itself describes some interesting challenges. Just one example: how = are CDNs going to guarantee anti-deeplinking to segments in a federated con= stellation where multiple nodes of multiple CDNs and request routers need t= o be aware of each others sessions and tokens, etc? 

 

My 2 cents.

 = ;

Kind regards, Stef van der Ziel=

 

--&n= bsp;

Owner Jet-S= tream | StreamZilla

<= /div>

GMT+1 Office: +31 50 5261820= | Mobile: +31 6 23406348

<= /div>

www.jet-str= eam.com | www.streamzillacdn.= com

this communi= cation is confidential

 

<= /div>
<= /div>



 

On 27 mei 2012, at 01:37, Kevin J Ma wrote:

<= /div>



Hi Ray,

 

  the meeting.<= /o:p>

 

 = First, a general comment about manifest files.  The document seems

  to assume that manifest files wil= l be distributed through the CDN.

&nb= sp; There are many services where this is not the case, often to prevent

  modification.  There is a la= rge focus in the document on how to modify

=

  manifest files, in some cases where the manifest file itself is= not

  necessarily relevant. = ; I believe there are ways to optimize HAS

=

  delivery without modifying manifest files, and in imo, manifest=

 manipulation falls under conten= t adaptation which the wg declared to

=   be out of scope for the initial phase?

 

  With respect sec= tion 2.2, I believe I commented on this in the

<= div>

  initial draft, but I still feel that the relative vs absolu= te URL

  discussion is rather mis= leading.  It seems to imply that:

    a) the HOST portion of a relative URL cannot point to a= RR, that

    b) a RR = must be accessed through some web service like API, and that

    c) absolute URLs can only point t= o specific surrogates.

  While th= ese are all valid examples of how to use URLs, they do not

  seem to be typical cases.  For us, a typic= al service has a DNS

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>  address wh= ich points to a base directory in one or more CDNs.  The

  relative path from that base directory is th= e same in all CDNs.  The

  h= ostname does not point to any one surrogate, and each CDN is still

  able to redirect requests as it sees fi= t.

 

<= div>

  With respect to sections 3.1 and 3.2, while I agree that co= ntent

  storage and acquisition o= ptimization is important, and that there

  do think the CDN needs to be = fully HAS aware, nor do I think that

&= nbsp; the CDN necessarily needs access to the manifest file.  I also d= o

  not see a "significant&q= uot; impact to the MI.  The metadata interface

  will have the ability to define metadata that applies = to a set of

  content assets, per= the META-10 requirement.  Ultimately, the CDN

  needs to be able to respond to content requests from t= he client,

  even if that client = got a manifest file directly from the content

  provider (not from the CDN) and is expecting the content to = be in

  the format that was provi= ded to the CDN by the content provider.

 

  With respect to section 3.3, I think that a third case is missing,<= /span>

 where the content provider does = not provide the manifest file to the

&= nbsp; CDN (which can be a fairly common case).

<= div>

 

  With respect to= sections 3.3.2 and 3.3.3, would not DNS-based

<= div>

  redirection solve the issue by simply directing manifest/ch= unk

  requests to the dCDN, rathe= r than doing a manifest rewrite for every

<= p class=3DMsoNormal>  request (especially in the case of live streaming where the mani= fest

  might be changing on every= chunk)?  Also, presumably, the RR would

  only rewrite URLs which were within its own domain (i.e., no= t

  blackholing ad insertion segm= ents, etc.)?

 <= /p>

  With respect to section 3.5, the time component o= f URL signing is

  not mentioned = until section 3.5.3.  Expiration of URL tokens, in

  general, is an issue with HAS.  Robust key ma= nagement is an arguably

  more re= liable approach to content access protection, though that=

  would seem to be fairly well out of scope for CD= NI.  The proposed

  solution= in section 3.5.3, seems to be managing session state?

  Depending on the complexity of the cookie, this cou= ld be troublesome

  if there is a= failover and session state is not properly synchronized?=

  And in the case of live streaming, the mani= fest is going to be

  requested e= very time?  How is the state managed in that case?  Is

  the cookie less susceptible to replay att= acks than the URL token?

  Will t= he cookie work across all CDNs?  Moving on to section 3.5.4

  is even more concerning.  What if th= e content is already encrypted?

 = How is authentication being handled on the key server?  Who is=

  responsible for auditing the security= of the solution?  Is this

 = intended to provide DRM?  work with existing DRM?  circumvent

  existing DRM?  Does it only = use the DRM/encryption support of the

=   delivery protocol?  or is the client expected to implement an

  alternate protocol?  And ho= w is this synchronized across CDNs?

&n= bsp; More generally, are we attempting to define security protocols for

  content delivery?  If so, I w= ould like to see a more formal

 d= efinition of what those requirements are?

<= p class=3DMsoNormal> 

  With respect to sect= ion 3.6.2, it seems that we just want to be able

 to purge a set of content assets.  Would a URI prefix= not be sufficient?

 =

thanx.

&nb= sp;

--  Kevin J. Ma

 

From: cdni-bounces@ietf.o= rg [mailto:cdni-bounces= @ietf.org] On Behalf Of<= span class=3Dapple-converted-space> Brandenburg, R. (Ray) v= an
Sent: Friday, = May 25, 2012 10:19 AM
To:&nbs= p;cdni@ietf.org
Subject:<= /b> Re: [CDNi] Status of Ad= aptive Streaming and CDNI draft

 

= Hi all,

 

I’ve just uploaded a new version of draft-brandenburg-cdn= i-has.

 

 

The dra= ft is meant as an input document for the virtual meeting on Thursday to dis= cuss the impact of HTTP Adaptive Streaming on the CDNI Interfaces. In the d= raft a number of alternative solutions are presented for each area where th= e use of HAS might touch with the CDNI Interfaces (e.g. content acquisition= , content purge, request routing, logging and URL signing).

 

I’m looking forward to your comm= ents.

 

Have a nice weeke= nd!

 

Ray van Brandenburg=

 <= o:p>

 

 

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van
Sent: woensdag 23 mei 2012 13:37
T= o: cdni@ietf.org
Subject: [CDNi] Status of Adaptive Streaming and CDNI draft

 

H= i all,

&= nbsp;

Ne= xt Tuesday we have a planned interim meeting for discussing the combination= between HTTP Adaptive Streaming and CDNI. One  of the expected inputs= for this meeting is a follow-up draft to draft-brandenburg-cdni-has-00.

 

We are curr= ently working hard at finishing this draft, but as you might have seen, we = have not yet uploaded a new version. Currently we are at a stage where we h= ave a first complete internal draft ready. However, Francois and I have agr= eed that we rather spend some more time on it so that it fully covers all t= he areas of the CDNI-HAS combination than upload an incomplete version righ= t now. We are currently planning to upload the draft this Friday (25= th <= /span>of May) at the latest. I hope this gives you all enough time to re= ad the draft before the meeting on Tuesday.

 

Sorry for the delay.

 

Ray

 

 

 

=

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

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

 

= --_000_291CC3F9E50E7641901A54E85D0977C653267F4D1FMAILR002maill_-- From ray.vanbrandenburg@tno.nl Mon May 28 02:17: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 A875221F853D for ; Mon, 28 May 2012 02:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.691 X-Spam-Level: X-Spam-Status: No, score=0.691 tagged_above=-999 required=5 tests=[AWL=1.194, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcWU4It0fPfY for ; Mon, 28 May 2012 02:17:16 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 07F9B21F8512 for ; Mon, 28 May 2012 02:17:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,670,1330902000"; d="scan'208,217";a="69704115" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 28 May 2012 11:17:11 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.96]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0283.003; Mon, 28 May 2012 11:17:10 +0200 From: "Brandenburg, R. (Ray) van" To: Kevin J Ma Thread-Topic: [CDNi] Status of Adaptive Streaming and CDNI draft Thread-Index: Ac0414J5VzCVuofZTcKanwrNrKyoTABqTCnQAEHKv5AAHBvSAAAGMhUAAChkn3U= Date: Mon, 28 May 2012 09:17:09 +0000 Message-ID: References: <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> <66050772-394A-4A28-92FE-6A0581D5A533@jet-stream.nl>, <291CC3F9E50E7641901A54E85D0977C653267F4D1F@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C653267F4D1F@MAILR002.mail.lan> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E2A69261962E4BD0BD9B2BC2713FB12Dtnonl_" MIME-Version: 1.0 Cc: "cdni@ietf.org" , Stef van der Ziel Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI 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: Mon, 28 May 2012 09:17:18 -0000 --_000_E2A69261962E4BD0BD9B2BC2713FB12Dtnonl_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, Kevin, if you want the ability to prevent CDNs from modifying the manifest = in some cases, wouldn't we be able to achieve this by adding a simple 'do n= ot change manifest'-boolean to the metadate interface? I think that solves = your concern and still leaves CDNs that do want to optimize their delivery = with the option of doing so. Ray On 27 mei 2012, at 18:00, "Kevin J Ma" > wrote: Hi Stef, I was not arguing that a CDN would not prefer to have the manifest. I was more arguing that content providers may not trust CDNs with the manifest generation/modification. Securing content, preventing unauthorized access, and preventing piracy requires much more than simple auth tokens. DRM is explicitly listed as out-of-scope in the charter, so as I said, if the intent is to define a security protocol, then I would like to see more requirements. If, however, I have misunderstood, and section 3.5.4 is describing an existing feature that is widely supported across CDNs today, that just needs CDNI support, then I suppose that would be different. As for asset management, I agree the CDN needs to know what files go together, but I do not agree that a CDN should be allowed to modify a manifest file any way it wants, or generate any manifest it wants and present that to the end user. Manifest files may contain other information besides segment file locations, e.g., DRM info, targeted ad insertions, subscription-based customizations, etc., which the content provider may not trust the CDN with. I would like to know where the boundaries are of what the CDN may modify? Much of this requires subscriber-awareness. How subscriber-aware are we assuming the CDN to be? One might argue that the CDN should perform all these functions and be a one-stop intelligent content delivery shop, but that seems improbable in the short-run? Perhaps a more general question: Are we talking about making CDNs HAS aware, or making CDNI HAS aware? It feels more like the former, with the latter being an after-thought, and it is not clear to me how the former fits into the charter? Going straight from the uCDN routing every segment, to the uCDN supporting modification of a half dozen manifest formats feels disingenuous. Is there no BCP for how to configure DNS-RR to take the load off the uCDN RR, or a simple set of metadata to describe the source content structure which can facilitate more efficient content acquisition? thanx. -- Kevin J. Ma From: Stef van der Ziel [mailto:stef@jet-stream.nl] Sent: Sunday, May 27, 2012 9:03 AM To: Kevin J Ma Cc: Brandenburg, R. (Ray) van; cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft Hi Kevin, Actually, many CDNs prefer to serve out both the segments and the manifest = files. Sure, dumb caching/DNS based CDNs can be used to deliver segments and they = wouldn't care about segments. They will just pump out the delivered objects= . But intelligent CDNs that are actually usable for commercial/secure and m= anageable HAS, need the manifests. IMHO the role of a manifest file should not be confused with the role of a = referrer file. A manifest is to represent the entire content, not just to the client but i= n the entire chain of encoding, protection, CDN and clients. A referrer file is the proper way to point to the (logical) content from an= y remote location. We hardly ever see manifest files to be distributed outside of the CDN in r= eality. It is not a fairly common scenario and should not be. In more autom= ated environments, it can actually be the CDN that creates the manifest. The assumption that manifest files should or can be distributed offline or = outside the CDN is mostly wrong. The assumption that you can point from a m= anifest to a CDN for the segments won't work since a proper CDN would (shou= ld) block direct access to segments to prevent deep linking. But we underst= and why people make these assumptions, we've heard other statements from HA= S enthusiasts that don't make sense in the real world. Serving out the manifests alongside the segments from the same CDN account = is done for multiple reasons, which do not at all adapt the content: - Logical asset recognition (parsing the manifests so the CDN understands t= hat the segments are part of a logical entity) - Logical asset management (processing, copying, managing manifests and sub= sequent segments as if they are one asset) - Logical asset reporting (reporting manifests and subsequent segments via = web interfaces and APIs as if they are one asset) - Request routing control (CDNs only produce URLs for manifest files and wi= ll not accept requests for segments to prevent unnecessary request routing = overload by having to request route every individual segment request) - Access control (CDNs will not allow direct access to segments but only vi= a the manifest file to prevent deep-linking, you don't want any third party= to publish a manifest file on an unlicensed portal and then point users to= the segments on the CDN without any access control) - Session control (http streaming is stateless and that is quite dramatic f= or CDNs because you lose control over the session and over session logging) There are additional reasons for CDNs to be able to adapt the manifest file= s but do so without changing the actual content: - For instance, they could dynamically insert base URLs to point users to a= group of servers to improve the availability. - Or they could dynamically insert tokens into the manifest to control acce= ss to segments. - Or they could dynamically insert session keys to be able to track a uniqu= e user session over multiple federated CDNs. - Or they could dynamically remove higher or lower bit rates to better cont= rol the actual QoE on a per request basis. Concluding: To a CDN, the segments aren't actually that interesting. They are just piec= es of useless raw data that needs to be protected, managed and served. For a CDN, the manifest represents the content and is a critical component = so they need to be able to parse, alter and serve them. I think the above by itself describes some interesting challenges. Just one= example: how are CDNs going to guarantee anti-deeplinking to segments in a= federated constellation where multiple nodes of multiple CDNs and request = routers need to be aware of each others sessions and tokens, etc? My 2 cents. Kind regards, Stef van der Ziel -- Owner Jet-Stream | StreamZilla GMT+1 Office: +31 50 5261820 | Mobile: +31 6 23406348 www.jet-stream.com | www.streamzillacdn.com this communication is confidential On 27 mei 2012, at 01:37, Kevin J Ma wrote: Hi Ray, I read through the updated draft and had a number of comments ahead of the meeting. First, a general comment about manifest files. The document seems to assume that manifest files will be distributed through the CDN. There are many services where this is not the case, often to prevent modification. There is a large focus in the document on how to modify manifest files, in some cases where the manifest file itself is not necessarily relevant. I believe there are ways to optimize HAS delivery without modifying manifest files, and in imo, manifest manipulation falls under content adaptation which the wg declared to be out of scope for the initial phase? With respect section 2.2, I believe I commented on this in the initial draft, but I still feel that the relative vs absolute URL discussion is rather misleading. It seems to imply that: a) the HOST portion of a relative URL cannot point to a RR, that b) a RR must be accessed through some web service like API, and that c) absolute URLs can only point to specific surrogates. While these are all valid examples of how to use URLs, they do not seem to be typical cases. For us, a typical service has a DNS address which points to a base directory in one or more CDNs. The relative path from that base directory is the same in all CDNs. The hostname does not point to any one surrogate, and each CDN is still able to redirect requests as it sees fit. With respect to sections 3.1 and 3.2, while I agree that content storage and acquisition optimization is important, and that there should be metadata which can describe the format of the content, I do think the CDN needs to be fully HAS aware, nor do I think that the CDN necessarily needs access to the manifest file. I also do not see a "significant" impact to the MI. The metadata interface will have the ability to define metadata that applies to a set of content assets, per the META-10 requirement. Ultimately, the CDN needs to be able to respond to content requests from the client, even if that client got a manifest file directly from the content provider (not from the CDN) and is expecting the content to be in the format that was provided to the CDN by the content provider. How it got the content and how it stores it is out of scope? With respect to section 3.3, I think that a third case is missing, where the content provider does not provide the manifest file to the CDN (which can be a fairly common case). With respect to sections 3.3.2 and 3.3.3, would not DNS-based redirection solve the issue by simply directing manifest/chunk requests to the dCDN, rather than doing a manifest rewrite for every request (especially in the case of live streaming where the manifest might be changing on every chunk)? Also, presumably, the RR would only rewrite URLs which were within its own domain (i.e., not blackholing ad insertion segments, etc.)? With respect to section 3.5, the time component of URL signing is not mentioned until section 3.5.3. Expiration of URL tokens, in general, is an issue with HAS. Robust key management is an arguably more reliable approach to content access protection, though that would seem to be fairly well out of scope for CDNI. The proposed solution in section 3.5.3, seems to be managing session state? Depending on the complexity of the cookie, this could be troublesome if there is a failover and session state is not properly synchronized? And in the case of live streaming, the manifest is going to be requested every time? How is the state managed in that case? Is the cookie less susceptible to replay attacks than the URL token? Will the cookie work across all CDNs? Moving on to section 3.5.4 is even more concerning. What if the content is already encrypted? How is authentication being handled on the key server? Who is responsible for auditing the security of the solution? Is this intended to provide DRM? work with existing DRM? circumvent existing DRM? Does it only use the DRM/encryption support of the delivery protocol? or is the client expected to implement an alternate protocol? And how is this synchronized across CDNs? More generally, are we attempting to define security protocols for content delivery? If so, I would like to see a more formal definition of what those requirements are? With respect to section 3.6.2, it seems that we just want to be able to purge a set of content assets. Would a URI prefix not be sufficient? thanx. -- Kevin J. Ma From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: Friday, May 25, 2012 10:19 AM To: cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft Hi all, I=92ve just uploaded a new version of draft-brandenburg-cdni-has. You can find the document at: http://www.ietf.org/id/draft-brandenburg-cdni= -has-01.txt The draft is meant as an input document for the virtual meeting on Thursday= to discuss the impact of HTTP Adaptive Streaming on the CDNI Interfaces. I= n the draft a number of alternative solutions are presented for each area w= here the use of HAS might touch with the CDNI Interfaces (e.g. content acqu= isition, content purge, request routing, logging and URL signing). I=92m looking forward to your comments. Have a nice weekend! Ray van Brandenburg From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: woensdag 23 mei 2012 13:37 To: cdni@ietf.org Subject: [CDNi] Status of Adaptive Streaming and CDNI draft Hi all, Next Tuesday we have a planned interim meeting for discussing the combinati= on between HTTP Adaptive Streaming and CDNI. One of the expected inputs fo= r this meeting is a follow-up draft to draft-brandenburg-cdni-has-00. We are currently working hard at finishing this draft, but as you might hav= e seen, we have not yet uploaded a new version. Currently we are at a stage= where we have a first complete internal draft ready. However, Francois and= I have agreed that we rather spend some more time on it so that it fully c= overs all the areas of the CDNI-HAS combination than upload an incomplete v= ersion right now. We are currently planning to upload the draft this Friday= (25th of May) at the latest. I hope this gives you all enough time to read= the draft before the meeting on Tuesday. Sorry for the delay. Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_E2A69261962E4BD0BD9B2BC2713FB12Dtnonl_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi all,

Kevin, if you want the ability to prevent CDNs from modifying the manifest in some cases, wouldn't we be = able to achieve this by adding a simple 'do not change manifest'-boolean to= the metadate interface? I think that solves your concern and still leaves = CDNs that do want to optimize their delivery with the option of doing so.

Ray


On 27 mei 2012, at 18:00, "Kevin J Ma" <kevin.ma@azukisystems.com> wrote:

Hi Stef,

 

  I was not arguing that a CDN would not prefer to ha= ve the manifest.

  I was more arguing that content providers may not t= rust CDNs with

  the manifest generation/modification.  Securin= g content, preventing

  unauthorized access, and preventing piracy requires= much more than

  simple auth tokens.  DRM is explicitly listed = as out-of-scope in

  the charter, so as I said, if the intent is to defi= ne a security

  protocol, then I would like to see more requirement= s.  If, however,

  I have misunderstood, and section 3.5.4 is describi= ng an existing

  feature that is widely supported across CDNs today,= that just needs

  CDNI support, then I suppose that would be differen= t.

  As for asset management, I agree the CDN needs to k= now what files go

  together, but I do not agree that a CDN should be a= llowed to modify

  a manifest file any way it wants, or generate any m= anifest it wants

  and present that to the end user.  Manifest fi= les may contain other

 information besides segment file locations, e.g., DR= M info, targeted

  ad insertions, subscription-based customizations, e= tc., which the

  content provider may not trust the CDN with.  = I would like to know

  where the boundaries are of what the CDN may modify= ?  Much of this

  requires subscriber-awareness.  How subscriber= -aware are we assuming

 the CDN to be?  One might argue that the CDN sh= ould perform all these

 functions and be a one-stop intelligent content deli= very shop, but

 that seems improbable in the short-run?

 

  Perhaps a more general question: Are we talking abo= ut making CDNs

  HAS aware, or making CDNI HAS aware?  It feels= more like the former,

  with the latter being an after-thought, and it is n= ot clear to me

  how the former fits into the charter?  Going s= traight from the uCDN

  routing every segment, to the uCDN supporting modif= ication of a half

  dozen manifest formats feels disingenuous.  Is= there no BCP for how

  to configure DNS-RR to take the load off the uCDN R= R, or a simple

  set of metadata to describe the source content stru= cture which can

  facilitate more efficient content acquisition?=

 

thanx.

 

--  Kevin J. Ma

 

From: Stef van= der Ziel [mailto:stef@jet-stream.nl]
Sent: Sunday, May 27, 2012 9:03 AM
To: Kevin J Ma
Cc: Brandenburg, R. (Ray) van; cdni= @ietf.org
Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft=

 

Hi Kevin,

 

Actually, many CDNs prefer to serve out both the seg= ments and the manifest files.

Sure, dumb caching/DNS based CDNs can be used to del= iver segments and they wouldn't care about segments. They will just pump ou= t the delivered objects. But intelligent CDNs that are actually usable= for commercial/secure and manageable HAS, need the manifests.

 

IMHO the role of a manifest file should not be confu= sed with the role of a referrer file. 

A manifest is to represent the entire content, not j= ust to the client but in the entire chain of encoding, protection, CDN and = clients. 

A referrer file is the proper way to point to the (l= ogical) content from any remote location.

 

We hardly ever see manifest files to be distributed = outside of the CDN in reality. It is not a fairly common scenario and shoul= d not be. In more automated environments, it can actually be the CDN t= hat creates the manifest.

 

The assumption that manifest files should or can be = distributed offline or outside the CDN is mostly wrong. The assumption= that you can point from a manifest to a CDN for the segments won't work si= nce a proper CDN would (should) block direct access to segments to prevent deep linking. But we understand why people m= ake these assumptions, we've heard other statements from HAS enthusiasts th= at don't make sense in the real world.

 

Serving out the manifests alongside the segments fro= m the same CDN account is done for multiple reasons, which do not at all ad= apt the content:

 

- Logical asset recognition (parsing the manifests s= o the CDN understands that the segments are part of a logical entity)<= /o:p>

- Logical asset management (processing, copying, man= aging manifests and subsequent segments as if they are one asset)

- Logical asset reporting (reporting manifests and s= ubsequent segments via web interfaces and APIs as if they are one asset)

- Request routing control (CDNs only produce URLs fo= r manifest files and will not accept requests for segments to prevent unnec= essary request routing overload by having to request route every individual= segment request)

- Access control (CDNs will not allow direct access = to segments but only via the manifest file to prevent deep-linking, you don= 't want any third party to publish a manifest file on an unlicensed portal = and then point users to the segments on the CDN without any access control)

- Session control (http streaming is stateless and t= hat is quite dramatic for CDNs because you lose control over the session an= d over session logging)

 

There are additional reasons for CDNs to be able to = adapt the manifest files but do so without changing the actual content:

- For instance, they could dynamically insert base U= RLs to point users to a group of servers to improve the availability.<= /o:p>

- Or they could dynamically insert tokens into the m= anifest to control access to segments.

- Or they could dynamically insert session keys to b= e able to track a unique user session over multiple federated CDNs.

- Or they could dynamically remove higher or lower b= it rates to better control the actual QoE on a per request basis.

 

Concluding: 

To a CDN, the segments aren't actually that interest= ing. They are just pieces of useless raw data that needs to be protected, m= anaged and served. 

For a CDN, the manifest represents the content and i= s a critical component so they need to be able to parse, alter and serve th= em. 

 

I think the above by itself describes some interesti= ng challenges. Just one example: how are CDNs going to guarantee anti-deepl= inking to segments in a federated constellation where multiple nodes of mul= tiple CDNs and request routers need to be aware of each others sessions and tokens, etc? 

 

My 2 cents.

 

Kind regards, Stef va= n der Ziel

 

-- =

Owner Jet-Stream | StreamZ= illa

GMT+1 Office: +31 50 5261820 | Mobile: +31 6 234063= 48

www.jet-stream.com | www.streamzillacdn.com=

this communication is conf= idential

 



 

On 27 mei 2012, at 01:37, Kevin J Ma wrote:



Hi Ray,

 

  I read through the updated draft and had a number o= f comments ahead of

  the meeting.

 

  First, a general comment about manifest files. = ; The document seems

  to assume that manifest files will be distributed t= hrough the CDN.

  There are many services where this is not the case,= often to prevent

  modification.  There is a large focus in the d= ocument on how to modify

  manifest files, in some cases where the manifest fi= le itself is not

  necessarily relevant.  I believe there are way= s to optimize HAS

  delivery without modifying manifest files, and in i= mo, manifest

 manipulation falls under content adaptation which th= e wg declared to

  be out of scope for the initial phase?<= /o:p>

 

  With respect section 2.2, I believe I commented on = this in the

  initial draft, but I still feel that the relative v= s absolute URL

  discussion is rather misleading.  It seems to = imply that:

    a) the HOST portion of a relative URL c= annot point to a RR, that

    b) a RR must be accessed through some w= eb service like API, and that

    c) absolute URLs can only point to spec= ific surrogates.

  While these are all valid examples of how to use UR= Ls, they do not

  seem to be typical cases.  For us, a typical s= ervice has a DNS

  address which points to a base directory in one or = more CDNs.  The

  relative path from that base directory is the same = in all CDNs.  The

  hostname does not point to any one surrogate, and e= ach CDN is still

  able to redirect requests as it sees fit.

 

  With respect to sections 3.1 and 3.2, while I agree= that content

  storage and acquisition optimization is important, = and that there

  should be metadata which can describe the format of= the content, I

  do think the CDN needs to be fully HAS aware, nor d= o I think that

  the CDN necessarily needs access to the manifest fi= le.  I also do

  not see a "significant" impact to the MI.=   The metadata interface

  will have the ability to define metadata that appli= es to a set of

  content assets, per the META-10 requirement.  = Ultimately, the CDN

  needs to be able to respond to content requests fro= m the client,

  even if that client got a manifest file directly fr= om the content

  provider (not from the CDN) and is expecting the co= ntent to be in

  the format that was provided to the CDN by the cont= ent provider.

  How it got the content and how it stores it is out = of scope?

 

  With respect to section 3.3, I think that a third c= ase is missing,

 where the content provider does not provide the mani= fest file to the

  CDN (which can be a fairly common case).

 

  With respect to sections 3.3.2 and 3.3.3, would not= DNS-based

  redirection solve the issue by simply directing man= ifest/chunk

  requests to the dCDN, rather than doing a manifest = rewrite for every

  request (especially in the case of live streaming w= here the manifest

  might be changing on every chunk)?  Also, pres= umably, the RR would

  only rewrite URLs which were within its own domain = (i.e., not

  blackholing ad insertion segments, etc.)?

 

  With respect to section 3.5, the time component of = URL signing is

  not mentioned until section 3.5.3.  Expiration= of URL tokens, in

  general, is an issue with HAS.  Robust key man= agement is an arguably

  more reliable approach to content access protection= , though that

  would seem to be fairly well out of scope for CDNI.=   The proposed

  solution in section 3.5.3, seems to be managing ses= sion state?

  Depending on the complexity of the cookie, this cou= ld be troublesome

  if there is a failover and session state is not pro= perly synchronized?

  And in the case of live streaming, the manifes= t is going to be

  requested every time?  How is the state manage= d in that case?  Is

  the cookie less susceptible to replay attacks than = the URL token?

  Will the cookie work across all CDNs?  Moving = on to section 3.5.4

  is even more concerning.  What if the content = is already encrypted?

  How is authentication being handled on the key serv= er?  Who is

  responsible for auditing the security of the soluti= on?  Is this

  intended to provide DRM?  work with existing D= RM?  circumvent

  existing DRM?  Does it only use the DRM/encryp= tion support of the

  delivery protocol?  or is the client expected = to implement an

  alternate protocol?  And how is this synchroni= zed across CDNs?

  More generally, are we attempting to define securit= y protocols for

  content delivery?  If so, I would like to see = a more formal

 definition of what those requirements are?

 

  With respect to section 3.6.2, it seems that we jus= t want to be able

 to purge a set of content assets.  Would a URI = prefix not be sufficient?

 

thanx.

 

--  Kevin J. Ma

 

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Brandenbur= g, R. (Ray) van
Sent: Friday, May = 25, 2012 10:19 AM
To: cdni@ietf.org
Subject: Re: [CDNi= ] Status of Adaptive Streaming and CDNI draft

 

Hi all,

 =

I=92ve just uploaded a ne= w version of draft-brandenburg-cdni-has.

 <= /p>

 <= /p>

The draft is meant as an = input document for the virtual meeting on Thursday to discuss the impact of= HTTP Adaptive Streaming on the CDNI Interfaces. In the draft a number of alternative solutions are presented for each area where = the use of HAS might touch with the CDNI Interfaces (e.g. content acquisiti= on, content purge, request routing, logging and URL signing).

 <= /p>

I=92m looking forward to = your comments.

 <= /p>

Have a nice weekend!

 <= /p>

Ray van Brandenburg

 <= /p>

 <= /p>

 <= /p>

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Brandenbur= g, R. (Ray) van
Sent: woensdag 23 = mei 2012 13:37
To: cdni@ietf.org
Subject: [CDNi] St= atus of Adaptive Streaming and CDNI draft

 

Hi all,

 

Next Tuesday we have a plan= ned interim meeting for discussing the combination between HTTP Adaptive St= reaming and CDNI. One  of the expected inputs for this meeting is a follow-up draft to draft-brandenburg-cdni-has-00.

 

We are currently working ha= rd at finishing this draft, but as you might have seen, we have not yet upl= oaded a new version. Currently we are at a stage where we have a first complete internal draft ready. However, Francois and I have a= greed that we rather spend some more time on it so that it fully covers all= the areas of the CDNI-HAS combination than upload an incomplete version ri= ght now. We are currently planning to upload the draft this Friday (25th<= /span> of May) at the latest. I hope this gives you all enough time to read the draf= t before the meeting on Tuesday.

 

Sorry for the delay.=

 

Ray

 

 

 

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

_____________________________________= __________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org= /mailman/listinfo/cdni

 

--_000_E2A69261962E4BD0BD9B2BC2713FB12Dtnonl_-- From ray.vanbrandenburg@tno.nl Mon May 28 02:37: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 60B1921F8549 for ; Mon, 28 May 2012 02:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.492 X-Spam-Level: X-Spam-Status: No, score=0.492 tagged_above=-999 required=5 tests=[AWL=0.995, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrGhDoLIEI5u for ; Mon, 28 May 2012 02:37:53 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id A344B21F8531 for ; Mon, 28 May 2012 02:37:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,670,1330902000"; d="scan'208,217";a="15345356" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1b.tno.nl with ESMTP; 28 May 2012 11:37:49 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.96]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.02.0283.003; Mon, 28 May 2012 11:37:49 +0200 From: "Brandenburg, R. (Ray) van" To: Kevin J Ma Thread-Topic: Status of Adaptive Streaming and CDNI draft Thread-Index: Ac0414J5VzCVuofZTcKanwrNrKyoTABqTCnQAEHKv5AAS2tZDw== Date: Mon, 28 May 2012 09:37:49 +0000 Message-ID: <3C0B3042-9BAB-4A7A-A952-737C92666E75@tno.nl> References: , <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3C0B30429BAB4A7AA952737C92666E75tnonl_" MIME-Version: 1.0 Cc: "cdni@ietf.org" , Stef van der Ziel Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI 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: Mon, 28 May 2012 09:37:55 -0000 --_000_3C0B30429BAB4A7AA952737C92666E75tnonl_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Kevin, Thanks for your review. See my comments inline. On 27 mei 2012, at 01:37, "Kevin J Ma" > wrote: Hi Ray, I read through the updated draft and had a number of comments ahead of the meeting. First, a general comment about manifest files. The document seems to assume that manifest files will be distributed through the CDN. There are many services where this is not the case, often to prevent modification. There is a large focus in the document on how to modify manifest files, in some cases where the manifest file itself is not necessarily relevant. I believe there are ways to optimize HAS delivery without modifying manifest files, and in imo, manifest manipulation falls under content adaptation which the wg declared to be out of scope for the initial phase? Sure, in some cases the CDN might not deliver the manifest, however in some= other cases it will. I think ruling out the latter is not what we want rig= ht? In my opinion, considering manifest manipulation to be content adaptation i= s stretching the definition of content adaption a little bit. I think Stef = already presented enough examples of why a CDN might want to modify the man= ifest file in a way that is not related to content adaptation at all. As I said in my other mail: wouldn't a simple 'do not change manifest'-bo= olean in the metadate interface solve your concerns in the cases where a Co= ntent Provider does not want the manifest to be modified? With respect section 2.2, I believe I commented on this in the initial draft, but I still feel that the relative vs absolute URL discussion is rather misleading. It seems to imply that: a) the HOST portion of a relative URL cannot point to a RR, that I'm not sure I understand you. The idea behind a Relative URL is that it do= esn't have a HOST portion. b) a RR must be accessed through some web service like API, and that The example presented is meant as just that, an example. The important part= here is in the HOST portion pointing to a RR function. However, if you fin= d this example to be confusing, I can change it. c) absolute URLs can only point to specific surrogates. Absolute URLs without Redirection point to surrogates, Absolute URLs with R= edirection explicitely do not. While these are all valid examples of how to use URLs, they do not seem to be typical cases. For us, a typical service has a DNS address which points to a base directory in one or more CDNs. The relative path from that base directory is the same in all CDNs. The hostname does not point to any one surrogate, and each CDN is still able to redirect requests as it sees fit. I agree that this is how some CDNs might do it. But I'm not sure how this = affects 2.2. Section 2.2 is meant as a general overview into the different = methods with which chunks might be addressed in a manifest file. Some CDNs = might use one option, some CDNs might use another. With respect to sections 3.1 and 3.2, while I agree that content storage and acquisition optimization is important, and that there should be metadata which can describe the format of the content, I do think the CDN needs to be fully HAS aware, nor do I think that the CDN necessarily needs access to the manifest file. I also do not see a "significant" impact to the MI. The metadata interface will have the ability to define metadata that applies to a set of content assets, per the META-10 requirement. Ultimately, the CDN needs to be able to respond to content requests from the client, even if that client got a manifest file directly from the content provider (not from the CDN) and is expecting the content to be in the format that was provided to the CDN by the content provider. How it got the content and how it stores it is out of scope? With respect to section 3.3, I think that a third case is missing, where the content provider does not provide the manifest file to the CDN (which can be a fairly common case). If you want, I can add this case. With respect to sections 3.3.2 and 3.3.3, would not DNS-based redirection solve the issue by simply directing manifest/chunk requests to the dCDN, rather than doing a manifest rewrite for every request (especially in the case of live streaming where the manifest might be changing on every chunk)? Also, presumably, the RR would only rewrite URLs which were within its own domain (i.e., not blackholing ad insertion segments, etc.)? I think we both agree that the CDNI interfaces should support both HTTP bas= ed and DNS based redirection, right? So even if DNS based redirection would= solve some issues regarding manifest files, we still need an HTTP based so= lution. With respect to section 3.5, the time component of URL signing is not mentioned until section 3.5.3. Expiration of URL tokens, in general, is an issue with HAS. Robust key management is an arguably more reliable approach to content access protection, though that would seem to be fairly well out of scope for CDNI. The proposed solution in section 3.5.3, seems to be managing session state? Depending on the complexity of the cookie, this could be troublesome if there is a failover and session state is not properly synchronized? And in the case of live streaming, the manifest is going to be requested every time? How is the state managed in that case? Is the cookie less susceptible to replay attacks than the URL token? Will the cookie work across all CDNs? Moving on to section 3.5.4 is even more concerning. What if the content is already encrypted? How is authentication being handled on the key server? Who is responsible for auditing the security of the solution? Is this intended to provide DRM? work with existing DRM? circumvent existing DRM? Does it only use the DRM/encryption support of the delivery protocol? or is the client expected to implement an alternate protocol? And how is this synchronized across CDNs? More generally, are we attempting to define security protocols for content delivery? If so, I would like to see a more formal definition of what those requirements are? I will defer this discussion to other. With respect to section 3.6.2, it seems that we just want to be able to purge a set of content assets. Would a URI prefix not be sufficient? thanx. -- Kevin J. Ma From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: Friday, May 25, 2012 10:19 AM To: cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft Hi all, I=92ve just uploaded a new version of draft-brandenburg-cdni-has. You can find the document at: http://www.ietf.org/id/draft-brandenburg-cdni= -has-01.txt The draft is meant as an input document for the virtual meeting on Thursday= to discuss the impact of HTTP Adaptive Streaming on the CDNI Interfaces. I= n the draft a number of alternative solutions are presented for each area w= here the use of HAS might touch with the CDNI Interfaces (e.g. content acqu= isition, content purge, request routing, logging and URL signing). I=92m looking forward to your comments. Have a nice weekend! Ray van Brandenburg From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: woensdag 23 mei 2012 13:37 To: cdni@ietf.org Subject: [CDNi] Status of Adaptive Streaming and CDNI draft Hi all, Next Tuesday we have a planned interim meeting for discussing the combinati= on between HTTP Adaptive Streaming and CDNI. One of the expected inputs fo= r this meeting is a follow-up draft to draft-brandenburg-cdni-has-00. We are currently working hard at finishing this draft, but as you might hav= e seen, we have not yet uploaded a new version. Currently we are at a stage= where we have a first complete internal draft ready. However, Francois and= I have agreed that we rather spend some more time on it so that it fully c= overs all the areas of the CDNI-HAS combination than upload an incomplete v= ersion right now. We are currently planning to upload the draft this Friday= (25th of May) at the latest. I hope this gives you all enough time to read= the draft before the meeting on Tuesday. Sorry for the delay. Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_3C0B30429BAB4A7AA952737C92666E75tnonl_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Kevin,

Thanks for your review. See my comments inline.

On 27 mei 2012, at 01:37, "Kevin J Ma" <kevin.ma@azukisystems.com> wrote:

Hi Ray,

 

  I read through the updated draft and had a number o= f comments ahead of

  the meeting.

 

  First, a general comment about manifest files. = ; The document seems

  to assume that manifest files will be distributed t= hrough the CDN.

  There are many services where this is not the case,= often to prevent

  modification.  There is a large focus in the d= ocument on how to modify

  manifest files, in some cases where the manifest fi= le itself is not

  necessarily relevant.  I believe there are way= s to optimize HAS

  delivery without modifying manifest files, and in i= mo, manifest

 manipulation falls under content adaptation which th= e wg declared to

  be out of scope for the initial phase?

 


Sure, in some cases the CDN might not deliver the manifest, however in= some other cases it will. I think ruling out the latter is not what we wan= t right?

In my opinion, considering manifest manipulation to be content adaptat= ion is stretching the definition of content adaption a little bit. I think = Stef already presented enough examples of why a CDN might want to modify th= e manifest file in a way that is not related to content adaptation at all.

 As I said in my other mail: wouldn't a simple  'do not change manifest'-boolean in the metadate interface solve your concerns= in the cases where a Content Provider does not want the manifest to be mod= ified?


  With respect section 2.2, I believe I commented on = this in the

  initial draft, but I still feel that the relative v= s absolute URL

  discussion is rather misleading.  It seems to = imply that:

    a) the HOST portion of a relative URL c= annot point to a RR, that


I'm not sure I understand you. The idea behind a Relative URL is that = it doesn't have a HOST portion. 

    b) a RR must be accessed through some w= eb service like API, and that


The example presented is meant as just that, an example. The important= part here is in the HOST portion pointing to a RR function. However, if yo= u find this example to be confusing, I can change it. 

    c) absolute URLs can only point to spec= ific surrogates.


Absolute URLs without Redirection point to surrogates, Absolute URLs w= ith Redirection explicitely do not. 

  While these are all valid examples of how to use UR= Ls, they do not

  seem to be typical cases.  For us, a typical s= ervice has a DNS

  address which points to a base directory in one or = more CDNs.  The

  relative path from that base directory is the same = in all CDNs.  The

  hostname does not point to any one surrogate, and e= ach CDN is still

  able to redirect requests as it sees fit.


I agree that this is how some CDNs might do it.  But I'm not sure= how this affects 2.2. Section 2.2 is meant as a general overview into the = different methods with which chunks might be addressed in a manifest file. = Some CDNs might use one option, some CDNs might use another. 

 

  With respect to sections 3.1 and 3.2, while I agree= that content

  storage and acquisition optimization is important, = and that there

  should be metadata which can describe the format of= the content, I

  do think the CDN needs to be fully HAS aware, nor d= o I think that

  the CDN necessarily needs access to the manifest fi= le.  I also do

  not see a "significant" impact to the MI.=   The metadata interface

  will have the ability to define metadata that appli= es to a set of

  content assets, per the META-10 requirement.  = Ultimately, the CDN

  needs to be able to respond to content requests fro= m the client,

  even if that client got a manifest file directly fr= om the content

  provider (not from the CDN) and is expecting the co= ntent to be in

  the format that was provided to the CDN by the cont= ent provider.

  How it got the content and how it stores it is out = of scope?

 

  With respect to section 3.3, I think that a third c= ase is missing,

 where the content provider does not provide the mani= fest file to the

  CDN (which can be a fairly common case).


If you want, I can add this case.

 

  With respect to sections 3.3.2 and 3.3.3, would not= DNS-based

  redirection solve the issue by simply directing man= ifest/chunk

  requests to the dCDN, rather than doing a manifest = rewrite for every

  request (especially in the case of live streaming w= here the manifest

  might be changing on every chunk)?  Also, pres= umably, the RR would

  only rewrite URLs which were within its own domain = (i.e., not

  blackholing ad insertion segments, etc.)?


I think we both agree that the CDNI interfaces should support both HTT= P based and DNS based redirection, right? So even if DNS based redirection = would solve some issues regarding manifest files, we still need an HTTP bas= ed solution.

 

  With respect to section 3.5, the time component of = URL signing is

  not mentioned until section 3.5.3.  Expiration= of URL tokens, in

  general, is an issue with HAS.  Robust key man= agement is an arguably

  more reliable approach to content access protection= , though that

  would seem to be fairly well out of scope for CDNI.=   The proposed

  solution in section 3.5.3, seems to be managing ses= sion state?

  Depending on the complexity of the cookie, this cou= ld be troublesome

  if there is a failover and session state is not pro= perly synchronized?

  And in the case of live streaming, the manifes= t is going to be

  requested every time?  How is the state manage= d in that case?  Is

  the cookie less susceptible to replay attacks than = the URL token?

  Will the cookie work across all CDNs?  Moving = on to section 3.5.4

  is even more concerning.  What if the content = is already encrypted?

  How is authentication being handled on the key serv= er?  Who is

  responsible for auditing the security of the soluti= on?  Is this

  intended to provide DRM?  work with existing D= RM?  circumvent

  existing DRM?  Does it only use the DRM/encryp= tion support of the

  delivery protocol?  or is the client expected = to implement an

  alternate protocol?  And how is this synchroni= zed across CDNs?

  More generally, are we attempting to define securit= y protocols for

  content delivery?  If so, I would like to see = a more formal

 definition of what those requirements are?

 


I will defer this discussion to other. 

  With respect to section 3.6.2, it seems that we jus= t want to be able

 to purge a set of content assets.  Would a URI = prefix not be sufficient?

 

thanx.

 

--  Kevin J. Ma

 

From: cdni-bounces@ietf.org [mailto:= cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van
Sent: Friday, May 25, 2012 10:19 AM
To: cdni@ietf.org
Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft=

 

Hi all,<= /o:p>

 

I=92ve just uploaded a ne= w version of draft-brandenburg-cdni-has.

 <= /p>

You can find the document= at: http://www.ietf.org/id/draft-brande= nburg-cdni-has-01.txt

 <= /p>

The draft is meant as an = input document for the virtual meeting on Thursday to discuss the impact of= HTTP Adaptive Streaming on the CDNI Interfaces. In the draft a number of alternative solutions are presented for each area where = the use of HAS might touch with the CDNI Interfaces (e.g. content acquisiti= on, content purge, request routing, logging and URL signing).

 <= /p>

I=92m looking forward to = your comments.

 <= /p>

Have a nice weekend!=

 <= /p>

Ray van Brandenburg<= /o:p>

 <= /p>

 <= /p>

 <= /p>

From: cdni-bounces@ietf.org [mailto:= cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van
Sent: woensdag 23 mei 2012 13:37
To: cdni@ietf.org
Subject: [CDNi] Status of Adaptive Streaming and CDNI draft

 

Hi all,

 

Next Tuesday we have a plan= ned interim meeting for discussing the combination between HTTP Adaptive St= reaming and CDNI. One  of the expected inputs for this meeting is a follow-up draft to draft-brandenburg-cdni-has-00. <= /p>

 

We are currently working ha= rd at finishing this draft, but as you might have seen, we have not yet upl= oaded a new version. Currently we are at a stage where we have a first complete internal draft ready. However, Francois and I have a= greed that we rather spend some more time on it so that it fully covers all= the areas of the CDNI-HAS combination than upload an incomplete version ri= ght now. We are currently planning to upload the draft this Friday (25th<= /span> of May) at the latest. I hope this gi= ves you all enough time to read the draft before the meeting on Tuesday.

 

Sorry for the delay.

 

Ray

 

 

 

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

--_000_3C0B30429BAB4A7AA952737C92666E75tnonl_-- From kevin.ma@azukisystems.com Mon May 28 07:49:50 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96DC821F843F for ; Mon, 28 May 2012 07:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coS6UPr53UtX for ; Mon, 28 May 2012 07:49:42 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 9005121F8622 for ; Mon, 28 May 2012 07:49:41 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id EA1248BE0B8; Mon, 28 May 2012 10:49:40 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 0954C8BE06B; Mon, 28 May 2012 10:49:37 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Mon, 28 May 2012 10:49:17 -0400 From: Kevin J Ma To: "Brandenburg, R. (Ray) van" Date: Mon, 28 May 2012 10:49:34 -0400 Thread-Topic: [CDNi] Status of Adaptive Streaming and CDNI draft Thread-Index: Ac0414J5VzCVuofZTcKanwrNrKyoTABqTCnQAEHKv5AAHBvSAAAGMhUAAChkn3UAC2CwsA== Message-ID: <291CC3F9E50E7641901A54E85D0977C653267F4D41@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> <66050772-394A-4A28-92FE-6A0581D5A533@jet-stream.nl>, <291CC3F9E50E7641901A54E85D0977C653267F4D1F@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_291CC3F9E50E7641901A54E85D0977C653267F4D41MAILR002maill_" MIME-Version: 1.0 Cc: "cdni@ietf.org" , Stef van der Ziel Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI 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: Mon, 28 May 2012 14:49:50 -0000 --_000_291CC3F9E50E7641901A54E85D0977C653267F4D41MAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ray, I was also wondering what the optimization options are if the manifest is= not provided to the CDN for delivery. Or would there also need be some kind = of "only use this manifest for optimizing, but do not provide this manifest t= o clients'-boolean? Theres also still a question in my mind of how this applies to live conte= nt? thanx. -- Kevin J. Ma From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] Sent: Monday, May 28, 2012 5:17 AM To: Kevin J Ma Cc: Stef van der Ziel; cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft Hi all, Kevin, if you want the ability to prevent CDNs from modifying the manifest = in some cases, wouldn't we be able to achieve this by adding a simple 'do n= ot change manifest'-boolean to the metadate interface? I think that solves = your concern and still leaves CDNs that do want to optimize their delivery = with the option of doing so. Ray On 27 mei 2012, at 18:00, "Kevin J Ma" > wrote: Hi Stef, I was not arguing that a CDN would not prefer to have the manifest. I was more arguing that content providers may not trust CDNs with the manifest generation/modification. Securing content, preventing unauthorized access, and preventing piracy requires much more than simple auth tokens. DRM is explicitly listed as out-of-scope in the charter, so as I said, if the intent is to define a security protocol, then I would like to see more requirements. If, however, I have misunderstood, and section 3.5.4 is describing an existing feature that is widely supported across CDNs today, that just needs CDNI support, then I suppose that would be different. As for asset management, I agree the CDN needs to know what files go together, but I do not agree that a CDN should be allowed to modify a manifest file any way it wants, or generate any manifest it wants and present that to the end user. Manifest files may contain other information besides segment file locations, e.g., DRM info, targeted ad insertions, subscription-based customizations, etc., which the content provider may not trust the CDN with. I would like to know where the boundaries are of what the CDN may modify? Much of this requires subscriber-awareness. How subscriber-aware are we assuming the CDN to be? One might argue that the CDN should perform all these functions and be a one-stop intelligent content delivery shop, but that seems improbable in the short-run? Perhaps a more general question: Are we talking about making CDNs HAS aware, or making CDNI HAS aware? It feels more like the former, with the latter being an after-thought, and it is not clear to me how the former fits into the charter? Going straight from the uCDN routing every segment, to the uCDN supporting modification of a half dozen manifest formats feels disingenuous. Is there no BCP for how to configure DNS-RR to take the load off the uCDN RR, or a simple set of metadata to describe the source content structure which can facilitate more efficient content acquisition? thanx. -- Kevin J. Ma From: Stef van der Ziel [mailto:stef@jet-stream.nl] Sent: Sunday, May 27, 2012 9:03 AM To: Kevin J Ma Cc: Brandenburg, R. (Ray) van; cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft Hi Kevin, Actually, many CDNs prefer to serve out both the segments and the manifest = files. Sure, dumb caching/DNS based CDNs can be used to deliver segments and they = wouldn't care about segments. They will just pump out the delivered objects= . But intelligent CDNs that are actually usable for commercial/secure and m= anageable HAS, need the manifests. IMHO the role of a manifest file should not be confused with the role of a = referrer file. A manifest is to represent the entire content, not just to the client but i= n the entire chain of encoding, protection, CDN and clients. A referrer file is the proper way to point to the (logical) content from an= y remote location. We hardly ever see manifest files to be distributed outside of the CDN in r= eality. It is not a fairly common scenario and should not be. In more autom= ated environments, it can actually be the CDN that creates the manifest. The assumption that manifest files should or can be distributed offline or = outside the CDN is mostly wrong. The assumption that you can point from a m= anifest to a CDN for the segments won't work since a proper CDN would (shou= ld) block direct access to segments to prevent deep linking. But we underst= and why people make these assumptions, we've heard other statements from HA= S enthusiasts that don't make sense in the real world. Serving out the manifests alongside the segments from the same CDN account = is done for multiple reasons, which do not at all adapt the content: - Logical asset recognition (parsing the manifests so the CDN understands t= hat the segments are part of a logical entity) - Logical asset management (processing, copying, managing manifests and sub= sequent segments as if they are one asset) - Logical asset reporting (reporting manifests and subsequent segments via = web interfaces and APIs as if they are one asset) - Request routing control (CDNs only produce URLs for manifest files and wi= ll not accept requests for segments to prevent unnecessary request routing = overload by having to request route every individual segment request) - Access control (CDNs will not allow direct access to segments but only vi= a the manifest file to prevent deep-linking, you don't want any third party= to publish a manifest file on an unlicensed portal and then point users to= the segments on the CDN without any access control) - Session control (http streaming is stateless and that is quite dramatic f= or CDNs because you lose control over the session and over session logging) There are additional reasons for CDNs to be able to adapt the manifest file= s but do so without changing the actual content: - For instance, they could dynamically insert base URLs to point users to a= group of servers to improve the availability. - Or they could dynamically insert tokens into the manifest to control acce= ss to segments. - Or they could dynamically insert session keys to be able to track a uniqu= e user session over multiple federated CDNs. - Or they could dynamically remove higher or lower bit rates to better cont= rol the actual QoE on a per request basis. Concluding: To a CDN, the segments aren't actually that interesting. They are just piec= es of useless raw data that needs to be protected, managed and served. For a CDN, the manifest represents the content and is a critical component = so they need to be able to parse, alter and serve them. I think the above by itself describes some interesting challenges. Just one= example: how are CDNs going to guarantee anti-deeplinking to segments in a= federated constellation where multiple nodes of multiple CDNs and request = routers need to be aware of each others sessions and tokens, etc? My 2 cents. Kind regards, Stef van der Ziel -- Owner Jet-Stream | StreamZilla GMT+1 Office: +31 50 5261820 | Mobile: +31 6 23406348 www.jet-stream.com | www.streamzillacdn.com this communication is confidential On 27 mei 2012, at 01:37, Kevin J Ma wrote: Hi Ray, I read through the updated draft and had a number of comments ahead of the meeting. First, a general comment about manifest files. The document seems to assume that manifest files will be distributed through the CDN. There are many services where this is not the case, often to prevent modification. There is a large focus in the document on how to modify manifest files, in some cases where the manifest file itself is not necessarily relevant. I believe there are ways to optimize HAS delivery without modifying manifest files, and in imo, manifest manipulation falls under content adaptation which the wg declared to be out of scope for the initial phase? With respect section 2.2, I believe I commented on this in the initial draft, but I still feel that the relative vs absolute URL discussion is rather misleading. It seems to imply that: a) the HOST portion of a relative URL cannot point to a RR, that b) a RR must be accessed through some web service like API, and that c) absolute URLs can only point to specific surrogates. While these are all valid examples of how to use URLs, they do not seem to be typical cases. For us, a typical service has a DNS address which points to a base directory in one or more CDNs. The relative path from that base directory is the same in all CDNs. The hostname does not point to any one surrogate, and each CDN is still able to redirect requests as it sees fit. With respect to sections 3.1 and 3.2, while I agree that content storage and acquisition optimization is important, and that there should be metadata which can describe the format of the content, I do think the CDN needs to be fully HAS aware, nor do I think that the CDN necessarily needs access to the manifest file. I also do not see a "significant" impact to the MI. The metadata interface will have the ability to define metadata that applies to a set of content assets, per the META-10 requirement. Ultimately, the CDN needs to be able to respond to content requests from the client, even if that client got a manifest file directly from the content provider (not from the CDN) and is expecting the content to be in the format that was provided to the CDN by the content provider. How it got the content and how it stores it is out of scope? With respect to section 3.3, I think that a third case is missing, where the content provider does not provide the manifest file to the CDN (which can be a fairly common case). With respect to sections 3.3.2 and 3.3.3, would not DNS-based redirection solve the issue by simply directing manifest/chunk requests to the dCDN, rather than doing a manifest rewrite for every request (especially in the case of live streaming where the manifest might be changing on every chunk)? Also, presumably, the RR would only rewrite URLs which were within its own domain (i.e., not blackholing ad insertion segments, etc.)? With respect to section 3.5, the time component of URL signing is not mentioned until section 3.5.3. Expiration of URL tokens, in general, is an issue with HAS. Robust key management is an arguably more reliable approach to content access protection, though that would seem to be fairly well out of scope for CDNI. The proposed solution in section 3.5.3, seems to be managing session state? Depending on the complexity of the cookie, this could be troublesome if there is a failover and session state is not properly synchronized? And in the case of live streaming, the manifest is going to be requested every time? How is the state managed in that case? Is the cookie less susceptible to replay attacks than the URL token? Will the cookie work across all CDNs? Moving on to section 3.5.4 is even more concerning. What if the content is already encrypted? How is authentication being handled on the key server? Who is responsible for auditing the security of the solution? Is this intended to provide DRM? work with existing DRM? circumvent existing DRM? Does it only use the DRM/encryption support of the delivery protocol? or is the client expected to implement an alternate protocol? And how is this synchronized across CDNs? More generally, are we attempting to define security protocols for content delivery? If so, I would like to see a more formal definition of what those requirements are? With respect to section 3.6.2, it seems that we just want to be able to purge a set of content assets. Would a URI prefix not be sufficient? thanx. -- Kevin J. Ma From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: Friday, May 25, 2012 10:19 AM To: cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft Hi all, I've just uploaded a new version of draft-brandenburg-cdni-has. You can find the document at: http://www.ietf.org/id/draft-brandenburg-cdni= -has-01.txt The draft is meant as an input document for the virtual meeting on Thursday= to discuss the impact of HTTP Adaptive Streaming on the CDNI Interfaces. I= n the draft a number of alternative solutions are presented for each area w= here the use of HAS might touch with the CDNI Interfaces (e.g. content acqu= isition, content purge, request routing, logging and URL signing). I'm looking forward to your comments. Have a nice weekend! Ray van Brandenburg From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: woensdag 23 mei 2012 13:37 To: cdni@ietf.org Subject: [CDNi] Status of Adaptive Streaming and CDNI draft Hi all, Next Tuesday we have a planned interim meeting for discussing the combinati= on between HTTP Adaptive Streaming and CDNI. One of the expected inputs fo= r this meeting is a follow-up draft to draft-brandenburg-cdni-has-00. We are currently working hard at finishing this draft, but as you might hav= e seen, we have not yet uploaded a new version. Currently we are at a stage= where we have a first complete internal draft ready. However, Francois and= I have agreed that we rather spend some more time on it so that it fully c= overs all the areas of the CDNI-HAS combination than upload an incomplete v= ersion right now. We are currently planning to upload the draft this Friday= (25th of May) at the latest. I hope this gives you all enough time to read= the draft before the meeting on Tuesday. Sorry for the delay. Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_291CC3F9E50E7641901A54E85D0977C653267F4D41MAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Ray,

 

  I was also wonder= ing what the optimization options are if the manifest is not

  provided to the CDN for delivery.  Or would there a= lso need be some kind of

 "only use th= is manifest for optimizing, but do not provide this manifest to<= /span>

 clients'-boolean?

&nbs= p;

  Theres also still a question in my mind of h= ow this applies to live content?

=  

thanx.

 <= /p>

--  Kevin J. Ma

 

From: Brandenburg, R. (Ray)= van [mailto:ray.vanbrandenburg@tno.nl]
Sent: Monday, May 28, 20= 12 5:17 AM
To: Kevin J Ma
Cc: Stef van der Ziel; cdni@i= etf.org
Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI= draft

 

Hi all,

 

Kevin, if you want the ability to prevent CDNs from m= odifying the manifest in some cases, wouldn't we be able to achieve this by= adding a simple 'do not change manifest'-boolean to the metadate interface= ? I think that solves your concern and still leaves CDNs that do want to op= timize their delivery with the option of doing so.



Ray



On 27 mei 2012= , at 18:00, "Kevin J Ma" <kevin.ma@azukisystems.com> wrote:

Hi Stef,

 

  I was not a= rguing that a CDN would not prefer to have the manifest.<= /p>

  I was more arguing that content providers may not trust CDNs= with

  the manifest generation/modification= .  Securing content, preventing

  unaut= horized access, and preventing piracy requires much more than

  simple auth tokens.  DRM is explicitly listed as o= ut-of-scope in

  the charter, so as I said, = if the intent is to define a security

  prot= ocol, then I would like to see more requirements.  If, however,=

  I have misunderstood, and section 3.5.4 is descr= ibing an existing

  feature that is widely s= upported across CDNs today, that just needs

&nb= sp; CDNI support, then I suppose that would be different.=

  As for asset management, I agree the CDN needs to k= now what files go

  together, but I do not a= gree that a CDN should be allowed to modify

&nb= sp; a manifest file any way it wants, or generate any manifest it wants

  and present that to the end user.  Manif= est files may contain other

 information bes= ides segment file locations, e.g., DRM info, targeted

=

  ad insertions, subscription-based customizations, etc., which t= he

  content provider may not trust the CDN = with.  I would like to know

=   where the= boundaries are of what the CDN may modify?  Much of this<= /o:p>

  requires subscriber-awareness.  How subscriber-aw= are are we assuming

 the CDN to be?  = One might argue that the CDN should perform all these

=

 functions and be a one-stop intelligent content delivery shop, b= ut

 that seems improbable in the short-run?<= /span>

 

  P= erhaps a more general question: Are we talking about making CDNs

  HAS aware, or making CDNI HAS aware?  It feels = more like the former,

  with the latter bein= g an after-thought, and it is not clear to me

&nb= sp; how the former fits into the charter?  Going straight from the uCD= N

  routing every segment, to the uCDN suppo= rting modification of a half

  dozen manifes= t formats feels disingenuous.  Is there no BCP for how

  to configure DNS-RR to take the load off the uCDN RR, or = a simple

  set of metadata to describe the s= ource content structure which can

  facilita= te more efficient content acquisition?

 

thanx.

 <= /o:p>

--  Kevin J. Ma

 <= o:p>

From: Stef van der Zi= el [mailto:stef@jet-stream.nl]
Sent: Sunday, May 27, 2012 9:03 A= M
To: Kevin J Ma
Cc: Brandenburg, R. (Ray) van; cdni@ietf.org
Subject: Re: [CDNi] S= tatus of Adaptive Streaming and CDNI draft

 

Hi Kev= in,

 

Actually, many CDNs prefer to serve out both th= e segments and the manifest files.

Sure, dumb caching/DNS based CDNs can be used to deliver segments and= they wouldn't care about segments. They will just pump out the delivered o= bjects. But intelligent CDNs that are actually usable for commercial/s= ecure and manageable HAS, need the manifests.

 

= IMHO the role of a manifest file should not be confused with the role of a = referrer file. 

A = manifest is to represent the entire content, not just to the client but in = the entire chain of encoding, protection, CDN and clients. =

A referrer file is the proper way to po= int to the (logical) content from any remote location.

=

 

We hardly ever see manifest files to be distributed outside of the CDN = in reality. It is not a fairly common scenario and should not be. In m= ore automated environments, it can actually be the CDN that creates the man= ifest.

 

<= /div>

The assumption that manifest files should or= can be distributed offline or outside the CDN is mostly wrong. The as= sumption that you can point from a manifest to a CDN for the segments won't= work since a proper CDN would (should) block direct access to segments to = prevent deep linking. But we understand why people make these assumptions, = we've heard other statements from HAS enthusiasts that don't make sense in = the real world.

 

Serving out the manifests alongside= the segments from the same CDN account is done for multiple reasons, which= do not at all adapt the content:

 

- Logical asset r= ecognition (parsing the manifests so the CDN understands that the segments = are part of a logical entity)

- Logical asset management (processing, copying, managing manifests a= nd subsequent segments as if they are one asset)

=

- Logical asset reporting (reporting ma= nifests and subsequent segments via web interfaces and APIs as if they are = one asset)

- Requ= est routing control (CDNs only produce URLs for manifest files and will not= accept requests for segments to prevent unnecessary request routing overlo= ad by having to request route every individual segment request)<= /p>

- Access control (CDNs will not allow di= rect access to segments but only via the manifest file to prevent deep-link= ing, you don't want any third party to publish a manifest file on an unlice= nsed portal and then point users to the segments on the CDN without any acc= ess control)

- Session contro= l (http streaming is stateless and that is quite dramatic for CDNs because = you lose control over the session and over session logging)

<= /div>

 

There are additional reasons for CDNs to be able to adapt the mani= fest files but do so without changing the actual content:

- For instance, they could dynamically insert = base URLs to point users to a group of servers to improve the availability.=

- Or they could dynamically = insert tokens into the manifest to control access to segments.

- Or they could dynamically insert sessio= n keys to be able to track a unique user session over multiple federated CD= Ns.

- Or they could dyna= mically remove higher or lower bit rates to better control the actual QoE o= n a per request basis.

=  

Concluding: =

To a CDN, the segments aren't act= ually that interesting. They are just pieces of useless raw data that needs= to be protected, managed and served. 

For a CDN, the manifest represents the content and is a crit= ical component so they need to be able to parse, alter and serve them. = ;

 

=

I think the above by itself describes some intere= sting challenges. Just one example: how are CDNs going to guarantee anti-de= eplinking to segments in a federated constellation where multiple nodes of = multiple CDNs and request routers need to be aware of each others sessions = and tokens, etc? 

 =

My 2 cents.

 

Kind regards, Stef van der Ziel

 

<= div>

-- 

Owner Jet-Stream | StreamZilla

=

GMT+1 Office: +31 50 5261820 | Mobile: +31 6 23406348

www.jet-stream.com | www.streamzillacdn.com

this communication is confidential

 




<= /p>

 

On 27 mei 2012, at 01:37, Kevin J Ma wrote:




= Hi Ray,

 

&n= bsp; I read through the updated draft and had a number of comments ahead of=

  the meeting.=

 

  Firs= t, a general comment about manifest files.  The document seems<= o:p>

  to assume that manifest files will be = distributed through the CDN.

  Th= ere are many services where this is not the case, often to prevent

  modification.  There is a large fo= cus in the document on how to modify

&= nbsp; manifest files, in some cases where the manifest file itself is not

  necessarily relevant.  I be= lieve there are ways to optimize HAS

&= nbsp; delivery without modifying manifest files, and in imo, manifest

 manipulation falls under content adap= tation which the wg declared to

 = be out of scope for the initial phase?

  With respect section= 2.2, I believe I commented on this in the

=

  initial draft, but I still feel that the relative vs absolute U= RL

  discussion is rather mislead= ing.  It seems to imply that:

&nb= sp;   a) the HOST portion of a relative URL cannot point to a RR,= that

    b) a RR must = be accessed through some web service like API, and that

    c) absolute URLs can only point to spe= cific surrogates.

  While these a= re all valid examples of how to use URLs, they do not

=

  seem to be typical cases.  For us, a typical se= rvice has a DNS

  address which p= oints to a base directory in one or more CDNs.  The<= /p>

  relative path from that base directory is the sam= e in all CDNs.  The

  hostna= me does not point to any one surrogate, and each CDN is still

  able to redirect requests as it sees fit.

 

<= p class=3DMsoNormal>  With respect to sections 3.1 and 3.2, while I agree that content=

  storage and acquisition optimi= zation is important, and that there

&n= bsp; should be metadata which can describe the format of the content, I

  do think the CDN needs to be fully= HAS aware, nor do I think that

 = the CDN necessarily needs access to the manifest file.  I also do

  not see a "significant" = impact to the MI.  The metadata interface

<= div>

  will have the ability to define metadata that applies to a = set of

  content assets, per the = META-10 requirement.  Ultimately, the CDN

<= div>

  needs to be able to respond to content requests from the cl= ient,

  even if that client got a= manifest file directly from the content

  the format that was provided t= o the CDN by the content provider.

&nb= sp; How it got the content and how it stores it is out of scope?

 

&nb= sp; With respect to section 3.3, I think that a third case is missing,

 where the content provider does not = provide the manifest file to the

&nb= sp; CDN (which can be a fairly common case).

 

  With respect to s= ections 3.3.2 and 3.3.3, would not DNS-based

  redirection solve the issue by simply directing manifest/chun= k

  requests to the dCDN, rather = than doing a manifest rewrite for every

  might be changing on every c= hunk)?  Also, presumably, the RR would

  only rewrite URLs which were within its own domain (i.e., not<= /span>

  blackholing ad insertion segmen= ts, etc.)?

 

  With respect to section 3.5, the time component of = URL signing is

  not mentioned un= til section 3.5.3.  Expiration of URL tokens, in

=

  general, is an issue with HAS.  Robust key mana= gement is an arguably

=   more reli= able approach to content access protection, though that

  would seem to be fairly well out of scope for CDNI= .  The proposed

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>  solution i= n section 3.5.3, seems to be managing session state?

<= /div>

  Depending on the complexity of the cookie, this could= be troublesome

  if there is a f= ailover and session state is not properly synchronized?

  And in the case of live streaming, the manife= st is going to be

  requested eve= ry time?  How is the state managed in that case?  Is<= /o:p>

  the cookie less susceptible to replay attac= ks than the URL token?

  Will the= cookie work across all CDNs?  Moving on to section 3.5.4<= /o:p>

  is even more concerning.  What if the = content is already encrypted?

  H= ow is authentication being handled on the key server?  Who is

  responsible for auditing the security o= f the solution?  Is this

  i= ntended to provide DRM?  work with existing DRM?  circumvent

  existing DRM?  Does it only us= e the DRM/encryption support of the

&n= bsp; delivery protocol?  or is the client expected to implement an

  alternate protocol?  And how = is this synchronized across CDNs?

&nb= sp; More generally, are we attempting to define security protocols for

  content delivery?  If so, I wo= uld like to see a more formal

 de= finition of what those requirements are?

  With respect to sect= ion 3.6.2, it seems that we just want to be able

 to purge a set of content assets.  Would a URI prefix= not be sufficient?

 =

thanx.

&nb= sp;

--  Kevin J. Ma

 

From: cdni-bounces@ietf.o= rg [mailto:cdni-bounces= @ietf.org] On Behalf Of<= span class=3Dapple-converted-space> Brandenburg, R. (Ray) v= an
Sent: Friday, = May 25, 2012 10:19 AM
To:&nbs= p;cdni@ietf.org
Subject:<= /b> Re: [CDNi] Status of Ad= aptive Streaming and CDNI draft

 

= Hi all,

 

I’ve just uploaded a new version of draft-brandenburg-cdn= i-has.

 

 

The dra= ft is meant as an input document for the virtual meeting on Thursday to dis= cuss the impact of HTTP Adaptive Streaming on the CDNI Interfaces. In the d= raft a number of alternative solutions are presented for each area where th= e use of HAS might touch with the CDNI Interfaces (e.g. content acquisition= , content purge, request routing, logging and URL signing).

 

I’m looking forward to your comm= ents.

 

Have a nice weeke= nd!

 

Ray van Brandenburg=

 <= o:p>

 

 

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van
Sent: woensdag 23 mei 2012 13:37
T= o: cdni@ietf.org
Subject: [CDNi] Status of Adaptive Streaming and CDNI draft

 

H= i all,

&= nbsp;

Ne= xt Tuesday we have a planned interim meeting for discussing the combination= between HTTP Adaptive Streaming and CDNI. One  of the expected inputs= for this meeting is a follow-up draft to draft-brandenburg-cdni-has-00.

 

We are curr= ently working hard at finishing this draft, but as you might have seen, we = have not yet uploaded a new version. Currently we are at a stage where we h= ave a first complete internal draft ready. However, Francois and I have agr= eed that we rather spend some more time on it so that it fully covers all t= he areas of the CDNI-HAS combination than upload an incomplete version righ= t now. We are currently planning to upload the draft this Friday (25= th <= /span>of May) at the latest. I hope this gives you all enough time to re= ad the draft before the meeting on Tuesday.

 

Sorry for the delay.

 

Ray

 

 

 

=

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

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

 

= --_000_291CC3F9E50E7641901A54E85D0977C653267F4D41MAILR002maill_-- From kevin.ma@azukisystems.com Mon May 28 09:10:14 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B0621F85C3 for ; Mon, 28 May 2012 09:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bzn2Qqx9hYAq for ; Mon, 28 May 2012 09:10:05 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 01C1A21F85A8 for ; Mon, 28 May 2012 09:10:04 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 5E84F8BE617; Mon, 28 May 2012 12:10:04 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 9EA4F8BE59D; Mon, 28 May 2012 12:10:00 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Mon, 28 May 2012 12:09:47 -0400 From: Kevin J Ma To: "Brandenburg, R. (Ray) van" Date: Mon, 28 May 2012 12:09:57 -0400 Thread-Topic: Status of Adaptive Streaming and CDNI draft Thread-Index: Ac0414J5VzCVuofZTcKanwrNrKyoTABqTCnQAEHKv5AAS2tZDwAMh8Bw Message-ID: <291CC3F9E50E7641901A54E85D0977C653267F4D48@MAILR002.mail.lan> References: , <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> <3C0B3042-9BAB-4A7A-A952-737C92666E75@tno.nl> In-Reply-To: <3C0B3042-9BAB-4A7A-A952-737C92666E75@tno.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_291CC3F9E50E7641901A54E85D0977C653267F4D48MAILR002maill_" MIME-Version: 1.0 Cc: "cdni@ietf.org" , Stef van der Ziel Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI 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: Mon, 28 May 2012 16:10:14 -0000 --_000_291CC3F9E50E7641901A54E85D0977C653267F4D48MAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ray, > Sure, in some cases the CDN might not deliver the manifest, however in so= me other cases it will. I think ruling out the latter is not what we want r= ight? I was more concerned that we may have tried to rule out the former. If we agree that there is a valid case where the CDN does not deliver the manifest, I think that it should be covered. > In my opinion, considering manifest manipulation to be content adaptation= is stretching the definition of content adaption a little bit. I think St= ef already presented enough examples of why a CDN might want to modify the = manifest file in a way that is not related to content adaptation at all. I think it's a slippery slope. Forbidding changes to data is pretty clear cut. When you start making exceptions, it raises concerns? What is it going to break? Who might stretch the boundaries of what would be reasonable to modify? How does it fit into the different distribution paradigms? There's no question that a CDN might want to modify a manifest. The question is should the CDN be allowed to, and if it is, what are the limits to what it is allowed to modify? There must be defined limits. > With respect to sections 3.3.2 and 3.3.3, would not DNS-based > redirection solve the issue by simply directing manifest/chunk > requests to the dCDN, rather than doing a manifest rewrite for every > request (especially in the case of live streaming where the manifest > might be changing on every chunk)? > > I think we both agree that the CDNI interfaces should support both HTTP b= ased and DNS based redirection, right? So even if DNS based redirection wou= ld solve some issues regarding manifest files, we still need an HTTP based = solution. Certainly, I agree that both DNS and HTTP redirects should be supported. I was trying to understand if there was "significant signalling overhead" in both cases? or if there are other factors involved, e.g., the redirection method. It might be helpful to expand the discussion of advantages and disadvantages for the different cases? > a) the HOST portion of a relative URL cannot point to a RR, that > > I'm not sure I understand you. The idea behind a Relative URL is that it = doesn't have a HOST portion. The manifest has a host from which it was retrieved. In your example, that host is a surrogate: http://surrogate.server.cdn.example.com/content_1/manifest.xml but that could have been a RR, that uses either DNS or HTTP redirects: http://rr.cdn.example.com/content_1/manifest.xml and that the relative paths could have been appended to the RR host, (as would be the case with HLS): http://rr.cdn.example.com/content_1/segments/segment1_1.ts I agree with the brittleness comments in section 3.3.1. Perhaps some text to that affect in section 2 would clarify it for the linear reader? though, the RR is going to need to be aware of the idiosyncrasies of each protocol and support all those brittle clients? > b) a RR must be accessed through some web service like API, and that > > The example presented is meant as just that, an example. The important pa= rt here is in the HOST portion pointing to a RR function. However, if you f= ind this example to be confusing, I can change it. It was not clear to me if the path was significant. Perhaps a second example with just the host name difference would clarify that? http://rr.cdn.example.com/content_1/segments/segment1_1.ts thanx. -- Kevin J. Ma From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] Sent: Monday, May 28, 2012 5:38 AM To: Kevin J Ma Cc: cdni@ietf.org; Stef van der Ziel Subject: Re: Status of Adaptive Streaming and CDNI draft Hi Kevin, Thanks for your review. See my comments inline. On 27 mei 2012, at 01:37, "Kevin J Ma" > wrote: Hi Ray, I read through the updated draft and had a number of comments ahead of the meeting. First, a general comment about manifest files. The document seems to assume that manifest files will be distributed through the CDN. There are many services where this is not the case, often to prevent modification. There is a large focus in the document on how to modify manifest files, in some cases where the manifest file itself is not necessarily relevant. I believe there are ways to optimize HAS delivery without modifying manifest files, and in imo, manifest manipulation falls under content adaptation which the wg declared to be out of scope for the initial phase? Sure, in some cases the CDN might not deliver the manifest, however in some= other cases it will. I think ruling out the latter is not what we want rig= ht? In my opinion, considering manifest manipulation to be content adaptation i= s stretching the definition of content adaption a little bit. I think Stef = already presented enough examples of why a CDN might want to modify the man= ifest file in a way that is not related to content adaptation at all. As I said in my other mail: wouldn't a simple 'do not change manifest'-bo= olean in the metadate interface solve your concerns in the cases where a Co= ntent Provider does not want the manifest to be modified? With respect section 2.2, I believe I commented on this in the initial draft, but I still feel that the relative vs absolute URL discussion is rather misleading. It seems to imply that: a) the HOST portion of a relative URL cannot point to a RR, that I'm not sure I understand you. The idea behind a Relative URL is that it do= esn't have a HOST portion. b) a RR must be accessed through some web service like API, and that The example presented is meant as just that, an example. The important part= here is in the HOST portion pointing to a RR function. However, if you fin= d this example to be confusing, I can change it. c) absolute URLs can only point to specific surrogates. Absolute URLs without Redirection point to surrogates, Absolute URLs with R= edirection explicitely do not. While these are all valid examples of how to use URLs, they do not seem to be typical cases. For us, a typical service has a DNS address which points to a base directory in one or more CDNs. The relative path from that base directory is the same in all CDNs. The hostname does not point to any one surrogate, and each CDN is still able to redirect requests as it sees fit. I agree that this is how some CDNs might do it. But I'm not sure how this = affects 2.2. Section 2.2 is meant as a general overview into the different = methods with which chunks might be addressed in a manifest file. Some CDNs = might use one option, some CDNs might use another. With respect to sections 3.1 and 3.2, while I agree that content storage and acquisition optimization is important, and that there should be metadata which can describe the format of the content, I do think the CDN needs to be fully HAS aware, nor do I think that the CDN necessarily needs access to the manifest file. I also do not see a "significant" impact to the MI. The metadata interface will have the ability to define metadata that applies to a set of content assets, per the META-10 requirement. Ultimately, the CDN needs to be able to respond to content requests from the client, even if that client got a manifest file directly from the content provider (not from the CDN) and is expecting the content to be in the format that was provided to the CDN by the content provider. How it got the content and how it stores it is out of scope? With respect to section 3.3, I think that a third case is missing, where the content provider does not provide the manifest file to the CDN (which can be a fairly common case). If you want, I can add this case. With respect to sections 3.3.2 and 3.3.3, would not DNS-based redirection solve the issue by simply directing manifest/chunk requests to the dCDN, rather than doing a manifest rewrite for every request (especially in the case of live streaming where the manifest might be changing on every chunk)? Also, presumably, the RR would only rewrite URLs which were within its own domain (i.e., not blackholing ad insertion segments, etc.)? I think we both agree that the CDNI interfaces should support both HTTP bas= ed and DNS based redirection, right? So even if DNS based redirection would= solve some issues regarding manifest files, we still need an HTTP based so= lution. With respect to section 3.5, the time component of URL signing is not mentioned until section 3.5.3. Expiration of URL tokens, in general, is an issue with HAS. Robust key management is an arguably more reliable approach to content access protection, though that would seem to be fairly well out of scope for CDNI. The proposed solution in section 3.5.3, seems to be managing session state? Depending on the complexity of the cookie, this could be troublesome if there is a failover and session state is not properly synchronized? And in the case of live streaming, the manifest is going to be requested every time? How is the state managed in that case? Is the cookie less susceptible to replay attacks than the URL token? Will the cookie work across all CDNs? Moving on to section 3.5.4 is even more concerning. What if the content is already encrypted? How is authentication being handled on the key server? Who is responsible for auditing the security of the solution? Is this intended to provide DRM? work with existing DRM? circumvent existing DRM? Does it only use the DRM/encryption support of the delivery protocol? or is the client expected to implement an alternate protocol? And how is this synchronized across CDNs? More generally, are we attempting to define security protocols for content delivery? If so, I would like to see a more formal definition of what those requirements are? I will defer this discussion to other. With respect to section 3.6.2, it seems that we just want to be able to purge a set of content assets. Would a URI prefix not be sufficient? thanx. -- Kevin J. Ma From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: Friday, May 25, 2012 10:19 AM To: cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft Hi all, I've just uploaded a new version of draft-brandenburg-cdni-has. You can find the document at: http://www.ietf.org/id/draft-brandenburg-cdni= -has-01.txt The draft is meant as an input document for the virtual meeting on Thursday= to discuss the impact of HTTP Adaptive Streaming on the CDNI Interfaces. I= n the draft a number of alternative solutions are presented for each area w= here the use of HAS might touch with the CDNI Interfaces (e.g. content acqu= isition, content purge, request routing, logging and URL signing). I'm looking forward to your comments. Have a nice weekend! Ray van Brandenburg From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: woensdag 23 mei 2012 13:37 To: cdni@ietf.org Subject: [CDNi] Status of Adaptive Streaming and CDNI draft Hi all, Next Tuesday we have a planned interim meeting for discussing the combinati= on between HTTP Adaptive Streaming and CDNI. One of the expected inputs fo= r this meeting is a follow-up draft to draft-brandenburg-cdni-has-00. We are currently working hard at finishing this draft, but as you might hav= e seen, we have not yet uploaded a new version. Currently we are at a stage= where we have a first complete internal draft ready. However, Francois and= I have agreed that we rather spend some more time on it so that it fully c= overs all the areas of the CDNI-HAS combination than upload an incomplete v= ersion right now. We are currently planning to upload the draft this Friday= (25th of May) at the latest. I hope this gives you all enough time to read= the draft before the meeting on Tuesday. Sorry for the delay. Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_291CC3F9E50E7641901A54E85D0977C653267F4D48MAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Ray,

 

> Sure, in some cases= the CDN might not deliver the manifest, however in some other cases it wil= l. I think ruling out the latter is not what we want right?

 

I was more concerned that we ma= y have tried to rule out the former.

If we agree = that there is a valid case where the CDN does not deliver=

the manifest, I think that it should be covered.=

 

> In my opinion, considering m= anifest manipulation to be content adaptation is stretching the definition = of content adaption a little bit.  I think Stef already presented enou= gh examples of why a CDN might want to modify the manifest file in a way th= at is not related to content adaptation at all.

<= o:p> 

I think it's a slippery slope.  Forbid= ding changes to data is pretty

clear cut.  W= hen you start making exceptions, it raises concerns?

<= p class=3DMsoNormal>What is it going to break?  Who might stretch the boundaries of wh= at

would be reasonable to modify?  How does = it fit into the different

distribution paradigms?=

 

There's no ques= tion that a CDN might want to modify a manifest.  The

question is should the CDN be allowed to, and if it is, what are = the

limits to what it is allowed to modify? = There must be defined limits.

 <= /span>

>  With respect to sections 3.3.2 and 3.3.3, would n= ot DNS-based

>  redirection solve the iss= ue by simply directing manifest/chunk

>  = requests to the dCDN, rather than doing a manifest rewrite for every

>  request (especially in the case of live stre= aming where the manifest

>  might be chan= ging on every chunk)?

> 

> I think we both agree that the CDNI interfaces should suppor= t both HTTP based and DNS based redirection, right? So even if DNS based re= direction would solve some issues regarding manifest files, we still need a= n HTTP based solution.

 

Certainly, I agree that both DNS and HTTP redirects should be

supported.  I was trying to understand if there wa= s "significant

signalling overhead" i= n both cases?  or if there are other factors

involved, e.g., the redirection method.  It might be helpful to expan= d

the discussion of advantages and disadvantages = for the different cases?

 =

> a) the HOST portion of a relative URL cannot point to a RR, t= hat

> 

> I'm= not sure I understand you. The idea behind a Relative URL is that it doesn= 't have a HOST portion.

 =

The manifest has a host from which it was retrieved.  In your= example,

that host is a surrogate:

 

  http://surrogate.ser= ver.cdn.example.com/content_1/manifest.xml

&= nbsp;

but that could have been a RR, that uses either = DNS or HTTP redirects:

 

  http://rr.cdn.example.com/content_1/manifest.xml

 

and that the relative paths= could have been appended to the RR host,

(as wou= ld be the case with HLS):

 

  http://rr.cdn.example.com/content_1/segments/segment1_1.ts=

 

I agree with th= e brittleness comments in section 3.3.1.  Perhaps some

text to that affect in section 2 would clarify it for the linear= reader?

 

though,= the RR is going to need to be aware of the idiosyncrasies of

each protocol and support all those brittle clients?

 

> b) a RR must be acce= ssed through some web service like API, and that

= > 

> The example presented is meant as= just that, an example. The important part here is in the HOST portion poin= ting to a RR function. However, if you find this example to be confusing, I= can change it.

 

It was not clear to me if the path was significant.  Perhaps a second=

example with just the host name difference would= clarify that?

 

&= nbsp; http://rr.cdn.example.com/content_1/segments/segment1_1.ts=

 

thanx.

 

--  Kevin J. Ma

 

From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] Sent: Monday, May 28, 2012 5:38 AM
To: Kevin J Ma
C= c: cdni@ietf.org; Stef van der Ziel
Subject: Re: Status of Ad= aptive Streaming and CDNI draft

 

Hi Kevin,<= /o:p>

 

Thanks for your review. S= ee my comments inline.

On 27 mei 2012, at 01:37, "Kevin J Ma&qu= ot; <kevin.ma@azukisystems.= com> wrote:

Hi Ray,

 

  I read through the updated draft and had a = number of comments ahead of

  the meeting.

 

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>  First, a g= eneral comment about manifest files.  The document seems

  to assume that manifest files will be distributed throu= gh the CDN.

  There are many services where = this is not the case, often to prevent

  mod= ification.  There is a large focus in the document on how to modify

  manifest files, in some cases where the mani= fest file itself is not

  necessarily releva= nt.  I believe there are ways to optimize HAS

 manipulation falls under content adaptation w= hich the wg declared to

  be out of scope fo= r the initial phase?

 

 

Sure, in some cases the CDN might not deliver the m= anifest, however in some other cases it will. I think ruling out the latter= is not what we want right?

<= o:p> 

In my opinion, consider= ing manifest manipulation to be content adaptation is stretching the defini= tion of content adaption a little bit. I think Stef already presented enoug= h examples of why a CDN might want to modify the manifest file in a way tha= t is not related to content adaptation at all.

 

&nbs= p;As I said in my other mail: wouldn't a simple  'do not change manifest'-boolean in the metadate interface s= olve your concerns in the cases where a Content Provider does not want the = manifest to be modified?

 



<= div>

  With respect section 2.2, I believe I commented on this in = the

  initial draft, but I still feel that t= he relative vs absolute URL

  discussion is = rather misleading.  It seems to imply that:

=     a) the HOST portion of a relative URL cannot point to a = RR, that

 

I'm not sure I understand you. The = idea behind a Relative URL is that it doesn't have a HOST portion. 



&nb= sp;   b) a RR must be accessed through some web service like API,= and that

 <= /o:p>

The example presented is meant as = just that, an example. The important part here is in the HOST portion point= ing to a RR function. However, if you find this example to be confusing, I = can change it. 



=

    c) absolute URLs can only point to s= pecific surrogates.

 

Absolute URLs without Re= direction point to surrogates, Absolute URLs with Redirection explicitely d= o not. 



  While these are all valid examples of how to use URLs, t= hey do not

  seem to be typical cases. = For us, a typical service has a DNS

  addre= ss which points to a base directory in one or more CDNs.  The

  relative path from that base directory is the same= in all CDNs.  The

  hostname does not = point to any one surrogate, and each CDN is still

  able to redirect requests as it sees fit.

 

I agree that this is how some CDNs might do it.  But I'm not sur= e how this affects 2.2. Section 2.2 is meant as a general overview into the= different methods with which chunks might be addressed in a manifest file.= Some CDNs might use one option, some CDNs might use another. 

 

 

  With respect to sections 3.1 and 3.2, while I agre= e that content

  storage and acquisition opt= imization is important, and that there

  sho= uld be metadata which can describe the format of the content, I=

  do think the CDN needs to be fully HAS aware, nor do = I think that

  the CDN necessarily needs acc= ess to the manifest file.  I also do

  = not see a "significant" impact to the MI.  The metadata inte= rface

  will have the ability to define meta= data that applies to a set of

  content asse= ts, per the META-10 requirement.  Ultimately, the CDN

  needs to be able to respond to content requests from the c= lient,

  even if that client got a manifest = file directly from the content

  provider (n= ot from the CDN) and is expecting the content to be in

  the format that was provided to the CDN by the content provide= r.

  How it got the content and how it store= s it is out of scope?

 <= /o:p>

  With respect to section 3.3, I think that a third case= is missing,

 where the content provider doe= s not provide the manifest file to the

  CDN= (which can be a fairly common case).

 

If you want, I can add this case.



 

&n= bsp; With respect to sections 3.3.2 and 3.3.3, would not DNS-based

  redirection solve the issue by simply directing ma= nifest/chunk

  requests to the dCDN, rather = than doing a manifest rewrite for every

  re= quest (especially in the case of live streaming where the manifest

  might be changing on every chunk)?  Also, pre= sumably, the RR would

  only rewrite URLs wh= ich were within its own domain (i.e., not

  = blackholing ad insertion segments, etc.)?

<= p class=3DMsoNormal> 

I = think we both agree that the CDNI interfaces should support both HTTP based= and DNS based redirection, right? So even if DNS based redirection would s= olve some issues regarding manifest files, we still need an HTTP based solu= tion.



=

 

  With respect to section 3.5, t= he time component of URL signing is

  not me= ntioned until section 3.5.3.  Expiration of URL tokens, in=

  general, is an issue with HAS.  Robust key manag= ement is an arguably

  more reliable approa= ch to content access protection, though that

&nb= sp; would seem to be fairly well out of scope for CDNI.  The proposed<= /span>

  solution in section 3.5.3, seems to be man= aging session state?

  Depending on the com= plexity of the cookie, this could be troublesome

=   if there is a failover and session state is not properly synchronize= d?

  And in the case of live streaming= , the manifest is going to be

  requested ev= ery time?  How is the state managed in that case?  Is=

  the cookie less susceptible to replay attacks than th= e URL token?

  Will the cookie work across a= ll CDNs?  Moving on to section 3.5.4

  = is even more concerning.  What if the content is already encrypted?

  How is authentication being handled on the k= ey server?  Who is

  responsible for au= diting the security of the solution?  Is this

  existing DRM?  Does it only use= the DRM/encryption support of the

  deliver= y protocol?  or is the client expected to implement an

  alternate protocol?  And how is this synchronized ac= ross CDNs?

  More generally, are we attempti= ng to define security protocols for

  conten= t delivery?  If so, I would like to see a more formal

 definition of what those requirements are?

 

=  

I will defer this discussio= n to other. 



  With respect to section 3.6.2, it seems that we jus= t want to be able

 to purge a set of content= assets.  Would a URI prefix not be sufficient?

<= p class=3DMsoNormal> 

thanx.

&nb= sp;

--  Kevin J. Ma

= From:= cdni-bounces@ietf.org [mailto= :cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van
Sent: Friday, May 25, 2012 10:19 AM
To: cdni@ietf.org
Subject: Re: [CDNi] Status of Adap= tive Streaming and CDNI draft

 

Hi all,=

 

I’ve just uploaded a new ver= sion of draft-brandenburg-cdni-has.

 

You can f= ind the document at: http://www.ietf.or= g/id/draft-brandenburg-cdni-has-01.txt

 

The draft is meant as an input document for the virtual meeting on Thu= rsday to discuss the impact of HTTP Adaptive Streaming on the CDNI Interfac= es. In the draft a number of alternative solutions are presented for each a= rea where the use of HAS might touch with the CDNI Interfaces (e.g. content= acquisition, content purge, request routing, logging and URL signing).

 

=

I’m looking forward to your comments.

 

<= p class=3DMsoNormal>Have a nice weekend!

 

Ray van Brandenburg

&nb= sp;

 

 

From: cdni-bou= nces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Brande= nburg, R. (Ray) van
Sent: woensdag 23 mei 2012 13:37
To: cdni@ietf.org
Subject: [CD= Ni] Status of Adaptive Streaming and CDNI draft

=

 

Hi all,

 

Next Tuesday we have a planned interim meeting for discussing the combi= nation between HTTP Adaptive Streaming and CDNI. One  of the expected = inputs for this meeting is a follow-up draft to draft-brandenburg-cdni-has-= 00.

 <= o:p>

We are currently working h= ard at finishing this draft, but as you might have seen, we have not yet up= loaded a new version. Currently we are at a stage where we have a first com= plete internal draft ready. However, Francois and I have agreed that we rat= her spend some more time on it so that it fully covers all the areas of the= CDNI-HAS combination than upload an incomplete version right now. We are c= urrently planning to upload the draft this Friday (25th of May) at the latest. I hope this gives you all enough time to = read the draft before the meeting on Tuesday.

<= div>

 

Sorry for the delay.

 

Ray

 <= /span>

 =

 

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

= --_000_291CC3F9E50E7641901A54E85D0977C653267F4D48MAILR002maill_-- From ben@niven-jenkins.co.uk Mon May 28 12:09:56 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9432A21F866A for ; Mon, 28 May 2012 12:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwQ9OhUls5-n for ; Mon, 28 May 2012 12:09:55 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id A7A5621F8669 for ; Mon, 28 May 2012 12:09:54 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginmedia.com ([86.14.227.47] helo=[192.168.0.4]) by mail4.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SZ5JN-0007tV-VX; Mon, 28 May 2012 20:09:02 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Ben Niven-Jenkins In-Reply-To: <76875F4E-5A68-417F-AD88-C21679F986A8@jet-stream.com> Date: Mon, 28 May 2012 20:09:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> <76875F4E-5A68-417F-AD88-C21679F986A8@jet-stream.com> To: Stef van der Ziel X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI 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: Mon, 28 May 2012 19:09:56 -0000 Stef, On 27 May 2012, at 14:03, Stef van der Ziel wrote: > Hi Kevin, >=20 > Actually, many CDNs prefer to serve out both the segments and the = manifest files. > IMHO the role of a manifest file should not be confused with the role = of a referrer file.=20 > A manifest is to represent the entire content, not just to the client = but in the entire chain of encoding, protection, CDN and clients.=20 > A referrer file is the proper way to point to the (logical) content = from any remote location. >=20 > We hardly ever see manifest files to be distributed outside of the CDN = in reality. It is not a fairly common scenario and should not be. In = more automated environments, it can actually be the CDN that creates the = manifest. >=20 > The assumption that manifest files should or can be distributed = offline or outside the CDN is mostly wrong. I'd disagree. I've seen live deployments of both cases of distributing = manifests through the CDN and out of band of the CDN so I don't think we = can make an assumption either way here. I think it would be useful for the group to consciously distinguish = between "core" CDNI capabilities and "value add" CDNI capabilities, = where I define "core" as being those things absolutely required for end = to end content delivery etc. to work across a set of interconnected CDNs = and "value add" as everything else (e.g. provides an = optimisation/efficiency gain or is a "nice to have" etc.). IMO HAS awareness, manifest awareness, manifest re-writing are all = "value add" as I believe we should be able to build a working CDNI = architecture that can deliver HAS at scale without requiring those = things. Having them provides benefits but is not absolutely required for = a scalable system. Ben > The assumption that you can point from a manifest to a CDN for the = segments won't work since a proper CDN would (should) block direct = access to segments to prevent deep linking. But we understand why people = make these assumptions, we've heard other statements from HAS = enthusiasts that don't make sense in the real world. >=20 > Serving out the manifests alongside the segments from the same CDN = account is done for multiple reasons, which do not at all adapt the = content: >=20 > - Logical asset recognition (parsing the manifests so the CDN = understands that the segments are part of a logical entity) > - Logical asset management (processing, copying, managing manifests = and subsequent segments as if they are one asset) > - Logical asset reporting (reporting manifests and subsequent segments = via web interfaces and APIs as if they are one asset) > - Request routing control (CDNs only produce URLs for manifest files = and will not accept requests for segments to prevent unnecessary request = routing overload by having to request route every individual segment = request) > - Access control (CDNs will not allow direct access to segments but = only via the manifest file to prevent deep-linking, you don't want any = third party to publish a manifest file on an unlicensed portal and then = point users to the segments on the CDN without any access control) > - Session control (http streaming is stateless and that is quite = dramatic for CDNs because you lose control over the session and over = session logging) >=20 > There are additional reasons for CDNs to be able to adapt the manifest = files but do so without changing the actual content: > - For instance, they could dynamically insert base URLs to point users = to a group of servers to improve the availability. > - Or they could dynamically insert tokens into the manifest to control = access to segments. > - Or they could dynamically insert session keys to be able to track a = unique user session over multiple federated CDNs. > - Or they could dynamically remove higher or lower bit rates to better = control the actual QoE on a per request basis. >=20 > Concluding:=20 > To a CDN, the segments aren't actually that interesting. They are just = pieces of useless raw data that needs to be protected, managed and = served.=20 > For a CDN, the manifest represents the content and is a critical = component so they need to be able to parse, alter and serve them.=20 >=20 > I think the above by itself describes some interesting challenges. = Just one example: how are CDNs going to guarantee anti-deeplinking to = segments in a federated constellation where multiple nodes of multiple = CDNs and request routers need to be aware of each others sessions and = tokens, etc?=20 >=20 > My 2 cents. >=20 > Kind regards, Stef van der Ziel >=20 > --=20 > Owner Jet-Stream | StreamZilla > GMT+1 Office: +31 50 5261820 | Mobile: +31 6 23406348 > www.jet-stream.com | www.streamzillacdn.com > this communication is confidential >=20 >=20 >=20 >=20 > On 27 mei 2012, at 01:37, Kevin J Ma wrote: >=20 >> Hi Ray, >> =20 >> I read through the updated draft and had a number of comments ahead = of >> the meeting. >> =20 >> First, a general comment about manifest files. The document seems >> to assume that manifest files will be distributed through the CDN. >> There are many services where this is not the case, often to = prevent >> modification. There is a large focus in the document on how to = modify >> manifest files, in some cases where the manifest file itself is not >> necessarily relevant. I believe there are ways to optimize HAS >> delivery without modifying manifest files, and in imo, manifest >> manipulation falls under content adaptation which the wg declared to >> be out of scope for the initial phase? >> =20 >> With respect section 2.2, I believe I commented on this in the >> initial draft, but I still feel that the relative vs absolute URL >> discussion is rather misleading. It seems to imply that: >> a) the HOST portion of a relative URL cannot point to a RR, that >> b) a RR must be accessed through some web service like API, and = that >> c) absolute URLs can only point to specific surrogates. >> While these are all valid examples of how to use URLs, they do not >> seem to be typical cases. For us, a typical service has a DNS >> address which points to a base directory in one or more CDNs. The >> relative path from that base directory is the same in all CDNs. = The >> hostname does not point to any one surrogate, and each CDN is still >> able to redirect requests as it sees fit. >> =20 >> With respect to sections 3.1 and 3.2, while I agree that content >> storage and acquisition optimization is important, and that there >> should be metadata which can describe the format of the content, I >> do think the CDN needs to be fully HAS aware, nor do I think that >> the CDN necessarily needs access to the manifest file. I also do >> not see a "significant" impact to the MI. The metadata interface >> will have the ability to define metadata that applies to a set of >> content assets, per the META-10 requirement. Ultimately, the CDN >> needs to be able to respond to content requests from the client, >> even if that client got a manifest file directly from the content >> provider (not from the CDN) and is expecting the content to be in >> the format that was provided to the CDN by the content provider. >> How it got the content and how it stores it is out of scope? >> =20 >> With respect to section 3.3, I think that a third case is missing, >> where the content provider does not provide the manifest file to the >> CDN (which can be a fairly common case). >> =20 >> With respect to sections 3.3.2 and 3.3.3, would not DNS-based >> redirection solve the issue by simply directing manifest/chunk >> requests to the dCDN, rather than doing a manifest rewrite for = every >> request (especially in the case of live streaming where the = manifest >> might be changing on every chunk)? Also, presumably, the RR would >> only rewrite URLs which were within its own domain (i.e., not >> blackholing ad insertion segments, etc.)? >> =20 >> With respect to section 3.5, the time component of URL signing is >> not mentioned until section 3.5.3. Expiration of URL tokens, in >> general, is an issue with HAS. Robust key management is an = arguably >> more reliable approach to content access protection, though that >> would seem to be fairly well out of scope for CDNI. The proposed >> solution in section 3.5.3, seems to be managing session state? >> Depending on the complexity of the cookie, this could be = troublesome >> if there is a failover and session state is not properly = synchronized? >> And in the case of live streaming, the manifest is going to be >> requested every time? How is the state managed in that case? Is >> the cookie less susceptible to replay attacks than the URL token? >> Will the cookie work across all CDNs? Moving on to section 3.5.4 >> is even more concerning. What if the content is already encrypted? >> How is authentication being handled on the key server? Who is >> responsible for auditing the security of the solution? Is this >> intended to provide DRM? work with existing DRM? circumvent >> existing DRM? Does it only use the DRM/encryption support of the >> delivery protocol? or is the client expected to implement an >> alternate protocol? And how is this synchronized across CDNs? >> More generally, are we attempting to define security protocols for >> content delivery? If so, I would like to see a more formal >> definition of what those requirements are? >> =20 >> With respect to section 3.6.2, it seems that we just want to be = able >> to purge a set of content assets. Would a URI prefix not be = sufficient? >> =20 >> thanx. >> =20 >> -- Kevin J. Ma >> =20 >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Brandenburg, R. (Ray) van >> Sent: Friday, May 25, 2012 10:19 AM >> To: cdni@ietf.org >> Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft >> =20 >> Hi all, >> =20 >> I=92ve just uploaded a new version of draft-brandenburg-cdni-has. >> =20 >> You can find the document at: = http://www.ietf.org/id/draft-brandenburg-cdni-has-01.txt >> =20 >> The draft is meant as an input document for the virtual meeting on = Thursday to discuss the impact of HTTP Adaptive Streaming on the CDNI = Interfaces. In the draft a number of alternative solutions are presented = for each area where the use of HAS might touch with the CDNI Interfaces = (e.g. content acquisition, content purge, request routing, logging and = URL signing). >> =20 >> I=92m looking forward to your comments. >> =20 >> Have a nice weekend! >> =20 >> Ray van Brandenburg >> =20 >> =20 >> =20 >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Brandenburg, R. (Ray) van >> Sent: woensdag 23 mei 2012 13:37 >> To: cdni@ietf.org >> Subject: [CDNi] Status of Adaptive Streaming and CDNI draft >> =20 >> Hi all, >> =20 >> Next Tuesday we have a planned interim meeting for discussing the = combination between HTTP Adaptive Streaming and CDNI. One of the = expected inputs for this meeting is a follow-up draft to = draft-brandenburg-cdni-has-00. >> =20 >> We are currently working hard at finishing this draft, but as you = might have seen, we have not yet uploaded a new version. Currently we = are at a stage where we have a first complete internal draft ready. = However, Francois and I have agreed that we rather spend some more time = on it so that it fully covers all the areas of the CDNI-HAS combination = than upload an incomplete version right now. We are currently planning = to upload the draft this Friday (25th of May) at the latest. I hope this = gives you all enough time to read the draft before the meeting on = Tuesday. >> =20 >> Sorry for the delay. >> =20 >> Ray >> =20 >> =20 >> =20 >> This e-mail and its contents are subject to the DISCLAIMER at = http://www.tno.nl/emaildisclaimer >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From stef@jet-stream.com Mon May 28 23:02: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 D9DC621F879B for ; Mon, 28 May 2012 23:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spKSwtBK3Jka for ; Mon, 28 May 2012 23:02:32 -0700 (PDT) Received: from monitor1.jet-stream.nl (smtp.jet-stream.nl [91.196.106.226]) by ietfa.amsl.com (Postfix) with ESMTP id B610E21F8790 for ; Mon, 28 May 2012 23:02:30 -0700 (PDT) Received: from [192.168.1.114] (5ED5ABD7.cm-7-6c.dynamic.ziggo.nl [94.213.171.215]) (authenticated bits=0) by monitor1.jet-stream.nl (8.13.7/8.13.7) with ESMTP id q4T62QeD000442 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 29 May 2012 08:02:27 +0200 References: <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> <76875F4E-5A68-417F-AD88-C21679F986A8@jet-stream.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <0DA7E356-6A2A-4948-B901-4A3A57411922@jet-stream.com> X-Mailer: iPad Mail (9B176) From: Stef van der Ziel Date: Tue, 29 May 2012 08:03:46 +0200 To: Ben Niven-Jenkins Cc: "cdni@ietf.org" Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI 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, 29 May 2012 06:02:34 -0000 Hi Ben, I know many CDNs that require manifests to be distributed via their CDN. It i= s mandatory. So if these CDNs would ever be used in federated scenarios, the= n federation must support this.=20 Verstuurd vanaf mijn iPad Op 28 mei 2012 om 21:09 heeft Ben Niven-Jenkins he= t volgende geschreven: > Stef, >=20 > On 27 May 2012, at 14:03, Stef van der Ziel wrote: >=20 >> Hi Kevin, >>=20 >> Actually, many CDNs prefer to serve out both the segments and the manifes= t files. > >> IMHO the role of a manifest file should not be confused with the role of a= referrer file.=20 >> A manifest is to represent the entire content, not just to the client but= in the entire chain of encoding, protection, CDN and clients.=20 >> A referrer file is the proper way to point to the (logical) content from a= ny remote location. >>=20 >> We hardly ever see manifest files to be distributed outside of the CDN in= reality. It is not a fairly common scenario and should not be. In more auto= mated environments, it can actually be the CDN that creates the manifest. >>=20 >> The assumption that manifest files should or can be distributed offline o= r outside the CDN is mostly wrong. >=20 > I'd disagree. I've seen live deployments of both cases of distributing man= ifests through the CDN and out of band of the CDN so I don't think we can ma= ke an assumption either way here. >=20 > I think it would be useful for the group to consciously distinguish betwee= n "core" CDNI capabilities and "value add" CDNI capabilities, where I define= "core" as being those things absolutely required for end to end content del= ivery etc. to work across a set of interconnected CDNs and "value add" as ev= erything else (e.g. provides an optimisation/efficiency gain or is a "nice t= o have" etc.). >=20 > IMO HAS awareness, manifest awareness, manifest re-writing are all "value a= dd" as I believe we should be able to build a working CDNI architecture that= can deliver HAS at scale without requiring those things. Having them provid= es benefits but is not absolutely required for a scalable system. >=20 > Ben >=20 >=20 >> The assumption that you can point from a manifest to a CDN for the segmen= ts won't work since a proper CDN would (should) block direct access to segme= nts to prevent deep linking. But we understand why people make these assumpt= ions, we've heard other statements from HAS enthusiasts that don't make sens= e in the real world. >>=20 >> Serving out the manifests alongside the segments from the same CDN accoun= t is done for multiple reasons, which do not at all adapt the content: >>=20 >> - Logical asset recognition (parsing the manifests so the CDN understands= that the segments are part of a logical entity) >> - Logical asset management (processing, copying, managing manifests and s= ubsequent segments as if they are one asset) >> - Logical asset reporting (reporting manifests and subsequent segments vi= a web interfaces and APIs as if they are one asset) >> - Request routing control (CDNs only produce URLs for manifest files and w= ill not accept requests for segments to prevent unnecessary request routing o= verload by having to request route every individual segment request) >> - Access control (CDNs will not allow direct access to segments but only v= ia the manifest file to prevent deep-linking, you don't want any third party= to publish a manifest file on an unlicensed portal and then point users to t= he segments on the CDN without any access control) >> - Session control (http streaming is stateless and that is quite dramatic= for CDNs because you lose control over the session and over session logging= ) >>=20 >> There are additional reasons for CDNs to be able to adapt the manifest fi= les but do so without changing the actual content: >> - For instance, they could dynamically insert base URLs to point users to= a group of servers to improve the availability. >> - Or they could dynamically insert tokens into the manifest to control ac= cess to segments. >> - Or they could dynamically insert session keys to be able to track a uni= que user session over multiple federated CDNs. >> - Or they could dynamically remove higher or lower bit rates to better co= ntrol the actual QoE on a per request basis. >>=20 >> Concluding:=20 >> To a CDN, the segments aren't actually that interesting. They are just pi= eces of useless raw data that needs to be protected, managed and served.=20 >> For a CDN, the manifest represents the content and is a critical componen= t so they need to be able to parse, alter and serve them.=20 >>=20 >> I think the above by itself describes some interesting challenges. Just o= ne example: how are CDNs going to guarantee anti-deeplinking to segments in a= federated constellation where multiple nodes of multiple CDNs and request r= outers need to be aware of each others sessions and tokens, etc?=20 >>=20 >> My 2 cents. >>=20 >> Kind regards, Stef van der Ziel >>=20 >> --=20 >> Owner Jet-Stream | StreamZilla >> GMT+1 Office: +31 50 5261820 | Mobile: +31 6 23406348 >> www.jet-stream.com | www.streamzillacdn.com >> this communication is confidential >>=20 >>=20 >>=20 >>=20 >> On 27 mei 2012, at 01:37, Kevin J Ma wrote: >>=20 >>> Hi Ray, >>>=20 >>> I read through the updated draft and had a number of comments ahead of >>> the meeting. >>>=20 >>> First, a general comment about manifest files. The document seems >>> to assume that manifest files will be distributed through the CDN. >>> There are many services where this is not the case, often to prevent >>> modification. There is a large focus in the document on how to modify >>> manifest files, in some cases where the manifest file itself is not >>> necessarily relevant. I believe there are ways to optimize HAS >>> delivery without modifying manifest files, and in imo, manifest >>> manipulation falls under content adaptation which the wg declared to >>> be out of scope for the initial phase? >>>=20 >>> With respect section 2.2, I believe I commented on this in the >>> initial draft, but I still feel that the relative vs absolute URL >>> discussion is rather misleading. It seems to imply that: >>> a) the HOST portion of a relative URL cannot point to a RR, that >>> b) a RR must be accessed through some web service like API, and that >>> c) absolute URLs can only point to specific surrogates. >>> While these are all valid examples of how to use URLs, they do not >>> seem to be typical cases. For us, a typical service has a DNS >>> address which points to a base directory in one or more CDNs. The >>> relative path from that base directory is the same in all CDNs. The >>> hostname does not point to any one surrogate, and each CDN is still >>> able to redirect requests as it sees fit. >>>=20 >>> With respect to sections 3.1 and 3.2, while I agree that content >>> storage and acquisition optimization is important, and that there >>> should be metadata which can describe the format of the content, I >>> do think the CDN needs to be fully HAS aware, nor do I think that >>> the CDN necessarily needs access to the manifest file. I also do >>> not see a "significant" impact to the MI. The metadata interface >>> will have the ability to define metadata that applies to a set of >>> content assets, per the META-10 requirement. Ultimately, the CDN >>> needs to be able to respond to content requests from the client, >>> even if that client got a manifest file directly from the content >>> provider (not from the CDN) and is expecting the content to be in >>> the format that was provided to the CDN by the content provider. >>> How it got the content and how it stores it is out of scope? >>>=20 >>> With respect to section 3.3, I think that a third case is missing, >>> where the content provider does not provide the manifest file to the >>> CDN (which can be a fairly common case). >>>=20 >>> With respect to sections 3.3.2 and 3.3.3, would not DNS-based >>> redirection solve the issue by simply directing manifest/chunk >>> requests to the dCDN, rather than doing a manifest rewrite for every >>> request (especially in the case of live streaming where the manifest >>> might be changing on every chunk)? Also, presumably, the RR would >>> only rewrite URLs which were within its own domain (i.e., not >>> blackholing ad insertion segments, etc.)? >>>=20 >>> With respect to section 3.5, the time component of URL signing is >>> not mentioned until section 3.5.3. Expiration of URL tokens, in >>> general, is an issue with HAS. Robust key management is an arguably >>> more reliable approach to content access protection, though that >>> would seem to be fairly well out of scope for CDNI. The proposed >>> solution in section 3.5.3, seems to be managing session state? >>> Depending on the complexity of the cookie, this could be troublesome >>> if there is a failover and session state is not properly synchronized? >>> And in the case of live streaming, the manifest is going to be >>> requested every time? How is the state managed in that case? Is >>> the cookie less susceptible to replay attacks than the URL token? >>> Will the cookie work across all CDNs? Moving on to section 3.5.4 >>> is even more concerning. What if the content is already encrypted? >>> How is authentication being handled on the key server? Who is >>> responsible for auditing the security of the solution? Is this >>> intended to provide DRM? work with existing DRM? circumvent >>> existing DRM? Does it only use the DRM/encryption support of the >>> delivery protocol? or is the client expected to implement an >>> alternate protocol? And how is this synchronized across CDNs? >>> More generally, are we attempting to define security protocols for >>> content delivery? If so, I would like to see a more formal >>> definition of what those requirements are? >>>=20 >>> With respect to section 3.6.2, it seems that we just want to be able >>> to purge a set of content assets. Would a URI prefix not be sufficient?= >>>=20 >>> thanx. >>>=20 >>> -- Kevin J. Ma >>>=20 >>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of B= randenburg, R. (Ray) van >>> Sent: Friday, May 25, 2012 10:19 AM >>> To: cdni@ietf.org >>> Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft >>>=20 >>> Hi all, >>>=20 >>> I=E2=80=99ve just uploaded a new version of draft-brandenburg-cdni-has. >>>=20 >>> You can find the document at: http://www.ietf.org/id/draft-brandenburg-c= dni-has-01.txt >>>=20 >>> The draft is meant as an input document for the virtual meeting on Thurs= day to discuss the impact of HTTP Adaptive Streaming on the CDNI Interfaces.= In the draft a number of alternative solutions are presented for each area w= here the use of HAS might touch with the CDNI Interfaces (e.g. content acqui= sition, content purge, request routing, logging and URL signing). >>>=20 >>> I=E2=80=99m looking forward to your comments. >>>=20 >>> Have a nice weekend! >>>=20 >>> Ray van Brandenburg >>>=20 >>>=20 >>>=20 >>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of B= randenburg, R. (Ray) van >>> Sent: woensdag 23 mei 2012 13:37 >>> To: cdni@ietf.org >>> Subject: [CDNi] Status of Adaptive Streaming and CDNI draft >>>=20 >>> Hi all, >>>=20 >>> Next Tuesday we have a planned interim meeting for discussing the combin= ation between HTTP Adaptive Streaming and CDNI. One of the expected inputs f= or this meeting is a follow-up draft to draft-brandenburg-cdni-has-00. >>>=20 >>> We are currently working hard at finishing this draft, but as you might h= ave seen, we have not yet uploaded a new version. Currently we are at a stag= e where we have a first complete internal draft ready. However, Francois and= I have agreed that we rather spend some more time on it so that it fully co= vers all the areas of the CDNI-HAS combination than upload an incomplete ver= sion right now. We are currently planning to upload the draft this Friday (2= 5th of May) at the latest. I hope this gives you all enough time to read the= draft before the meeting on Tuesday. >>>=20 >>> Sorry for the delay. >>>=20 >>> Ray >>>=20 >>>=20 >>>=20 >>> This e-mail and its contents are subject to the DISCLAIMER at http://www= .tno.nl/emaildisclaimer >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 From stef@jet-stream.com Tue May 29 00:05:49 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BC121F8711 for ; Tue, 29 May 2012 00:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.154 X-Spam-Level: X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQwhVt+vSIum for ; Tue, 29 May 2012 00:05:47 -0700 (PDT) Received: from monitor1.jet-stream.nl (smtp.jet-stream.nl [91.196.106.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7724021F870F for ; Tue, 29 May 2012 00:05:45 -0700 (PDT) Received: from [192.168.1.2] (5ED5ABD7.cm-7-6c.dynamic.ziggo.nl [94.213.171.215]) (authenticated bits=0) by monitor1.jet-stream.nl (8.13.7/8.13.7) with ESMTP id q4T75ht2012396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 29 May 2012 09:05:43 +0200 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_ACC28566-D8CA-4DA8-8894-6E2BA96366A6" From: Stef van der Ziel In-Reply-To: <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> Date: Tue, 29 May 2012 09:05:38 +0200 Message-Id: <77937918-F4BA-4D73-BD95-0F94FAD6E785@jet-stream.com> References: <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> To: Kevin J Ma X-Mailer: Apple Mail (2.1257) Cc: "cdni@ietf.org" Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI 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, 29 May 2012 07:05:49 -0000 --Apple-Mail=_ACC28566-D8CA-4DA8-8894-6E2BA96366A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Kevin, Actually, many CDNs prefer to serve out both the segments and the = manifest files. Sure, dumb caching/DNS based CDNs can be used to deliver segments and = they wouldn't care about segments. They will just pump out the delivered = objects. But intelligent CDNs that are actually usable for = commercial/secure and manageable HAS, need the manifests. IMHO the role of a manifest file should not be confused with the role of = a referrer file.=20 A manifest is to represent the entire content, not just to the client = but in the entire chain of encoding, protection, CDN and clients.=20 A referrer file is the proper way to point to the (logical) content from = any remote location. We hardly ever see manifest files to be distributed outside of the CDN = in reality. It is not a fairly common scenario and should not be. In = more automated environments, it can actually be the CDN that creates the = manifest. The assumption that manifest files should or can be distributed offline = or outside the CDN is mostly wrong. The assumption that you can point = from a manifest to a CDN for the segments won't work since a proper CDN = would (should) block direct access to segments to prevent deep linking. = But we understand why people make these assumptions, we've heard other = statements from HAS enthusiasts that don't make sense in the real world. Serving out the manifests alongside the segments from the same CDN = account is done for multiple reasons, which do not at all adapt the = content: - Logical asset recognition (parsing the manifests so the CDN = understands that the segments are part of a logical entity) - Logical asset management (processing, copying, managing manifests and = subsequent segments as if they are one asset) - Logical asset reporting (reporting manifests and subsequent segments = via web interfaces and APIs as if they are one asset) - Request routing control (CDNs only produce URLs for manifest files and = will not accept requests for segments to prevent unnecessary request = routing overload by having to request route every individual segment = request) - Access control (CDNs will not allow direct access to segments but only = via the manifest file to prevent deep-linking, you don't want any third = party to publish a manifest file on an unlicensed portal and then point = users to the segments on the CDN without any access control) - Session control (http streaming is stateless and that is quite = dramatic for CDNs because you lose control over the session and over = session logging) There are additional reasons for CDNs to be able to adapt the manifest = files but do so without changing the actual content: - For instance, they could dynamically insert base URLs to point users = to a group of servers to improve the availability. - Or they could dynamically insert tokens into the manifest to control = access to segments. - Or they could dynamically insert session keys to be able to track a = unique user session over multiple federated CDNs. - Or they could dynamically remove higher or lower bit rates to better = control the actual QoE on a per request basis. Concluding:=20 To a CDN, the segments aren't actually that interesting. They are just = pieces of useless raw data that needs to be protected, managed and = served.=20 For a CDN, the manifest represents the content and is a critical = component so they need to be able to parse, alter and serve them.=20 I think the above by itself describes some interesting challenges. Just = one example: how are CDNs going to guarantee anti-deeplinking to = segments in a federated constellation where multiple nodes of multiple = CDNs and request routers need to be aware of each others sessions and = tokens, etc?=20 My 2 cents. Kind regards, Stef van der Ziel --=20 Owner Jet-Stream | StreamZilla GMT+1 Office: +31 50 5261820 | Mobile: +31 6 23406348 www.jet-stream.com | www.streamzillacdn.com this communication is confidential On 27 mei 2012, at 01:37, Kevin J Ma wrote: > Hi Ray, > =20 > I read through the updated draft and had a number of comments ahead = of > the meeting. > =20 > First, a general comment about manifest files. The document seems > to assume that manifest files will be distributed through the CDN. > There are many services where this is not the case, often to prevent > modification. There is a large focus in the document on how to = modify > manifest files, in some cases where the manifest file itself is not > necessarily relevant. I believe there are ways to optimize HAS > delivery without modifying manifest files, and in imo, manifest > manipulation falls under content adaptation which the wg declared to > be out of scope for the initial phase? > =20 > With respect section 2.2, I believe I commented on this in the > initial draft, but I still feel that the relative vs absolute URL > discussion is rather misleading. It seems to imply that: > a) the HOST portion of a relative URL cannot point to a RR, that > b) a RR must be accessed through some web service like API, and = that > c) absolute URLs can only point to specific surrogates. > While these are all valid examples of how to use URLs, they do not > seem to be typical cases. For us, a typical service has a DNS > address which points to a base directory in one or more CDNs. The > relative path from that base directory is the same in all CDNs. The > hostname does not point to any one surrogate, and each CDN is still > able to redirect requests as it sees fit. > =20 > With respect to sections 3.1 and 3.2, while I agree that content > storage and acquisition optimization is important, and that there > should be metadata which can describe the format of the content, I > do think the CDN needs to be fully HAS aware, nor do I think that > the CDN necessarily needs access to the manifest file. I also do > not see a "significant" impact to the MI. The metadata interface > will have the ability to define metadata that applies to a set of > content assets, per the META-10 requirement. Ultimately, the CDN > needs to be able to respond to content requests from the client, > even if that client got a manifest file directly from the content > provider (not from the CDN) and is expecting the content to be in > the format that was provided to the CDN by the content provider. > How it got the content and how it stores it is out of scope? > =20 > With respect to section 3.3, I think that a third case is missing, > where the content provider does not provide the manifest file to the > CDN (which can be a fairly common case). > =20 > With respect to sections 3.3.2 and 3.3.3, would not DNS-based > redirection solve the issue by simply directing manifest/chunk > requests to the dCDN, rather than doing a manifest rewrite for every > request (especially in the case of live streaming where the manifest > might be changing on every chunk)? Also, presumably, the RR would > only rewrite URLs which were within its own domain (i.e., not > blackholing ad insertion segments, etc.)? > =20 > With respect to section 3.5, the time component of URL signing is > not mentioned until section 3.5.3. Expiration of URL tokens, in > general, is an issue with HAS. Robust key management is an arguably > more reliable approach to content access protection, though that > would seem to be fairly well out of scope for CDNI. The proposed > solution in section 3.5.3, seems to be managing session state? > Depending on the complexity of the cookie, this could be troublesome > if there is a failover and session state is not properly = synchronized? > And in the case of live streaming, the manifest is going to be > requested every time? How is the state managed in that case? Is > the cookie less susceptible to replay attacks than the URL token? > Will the cookie work across all CDNs? Moving on to section 3.5.4 > is even more concerning. What if the content is already encrypted? > How is authentication being handled on the key server? Who is > responsible for auditing the security of the solution? Is this > intended to provide DRM? work with existing DRM? circumvent > existing DRM? Does it only use the DRM/encryption support of the > delivery protocol? or is the client expected to implement an > alternate protocol? And how is this synchronized across CDNs? > More generally, are we attempting to define security protocols for > content delivery? If so, I would like to see a more formal > definition of what those requirements are? > =20 > With respect to section 3.6.2, it seems that we just want to be able > to purge a set of content assets. Would a URI prefix not be = sufficient? > =20 > thanx. > =20 > -- Kevin J. Ma > =20 > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Brandenburg, R. (Ray) van > Sent: Friday, May 25, 2012 10:19 AM > To: cdni@ietf.org > Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft > =20 > Hi all, > =20 > I=92ve just uploaded a new version of draft-brandenburg-cdni-has. > =20 > You can find the document at: = http://www.ietf.org/id/draft-brandenburg-cdni-has-01.txt > =20 > The draft is meant as an input document for the virtual meeting on = Thursday to discuss the impact of HTTP Adaptive Streaming on the CDNI = Interfaces. In the draft a number of alternative solutions are presented = for each area where the use of HAS might touch with the CDNI Interfaces = (e.g. content acquisition, content purge, request routing, logging and = URL signing). > =20 > I=92m looking forward to your comments. > =20 > Have a nice weekend! > =20 > Ray van Brandenburg > =20 > =20 > =20 > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Brandenburg, R. (Ray) van > Sent: woensdag 23 mei 2012 13:37 > To: cdni@ietf.org > Subject: [CDNi] Status of Adaptive Streaming and CDNI draft > =20 > Hi all, > =20 > Next Tuesday we have a planned interim meeting for discussing the = combination between HTTP Adaptive Streaming and CDNI. One of the = expected inputs for this meeting is a follow-up draft to = draft-brandenburg-cdni-has-00. > =20 > We are currently working hard at finishing this draft, but as you = might have seen, we have not yet uploaded a new version. Currently we = are at a stage where we have a first complete internal draft ready. = However, Francois and I have agreed that we rather spend some more time = on it so that it fully covers all the areas of the CDNI-HAS combination = than upload an incomplete version right now. We are currently planning = to upload the draft this Friday (25th of May) at the latest. I hope this = gives you all enough time to read the draft before the meeting on = Tuesday. > =20 > Sorry for the delay. > =20 > Ray > =20 > =20 > =20 > This e-mail and its contents are subject to the DISCLAIMER at = http://www.tno.nl/emaildisclaimer >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --Apple-Mail=_ACC28566-D8CA-4DA8-8894-6E2BA96366A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Kevin,

Actually, = many CDNs prefer to serve out both the segments and the manifest = files.
Sure, dumb caching/DNS based CDNs can be used to = deliver segments and they wouldn't care about segments. They will just = pump out the delivered objects. But intelligent CDNs that are = actually usable for commercial/secure and manageable HAS, need the = manifests.

IMHO the role of a manifest = file should not be confused with the role of a referrer = file. 
A manifest is to represent the entire = content, not just to the client but in the entire chain of encoding, = protection, CDN and clients. 
A referrer file is the = proper way to point to the (logical) content from any remote = location.

We hardly ever see manifest files to = be distributed outside of the CDN in reality. It is not a fairly common = scenario and should not be. In more automated environments, it can = actually be the CDN that creates the = manifest.

The assumption that manifest files = should or can be distributed offline or outside the CDN is mostly = wrong. The assumption that you can point from a manifest to a CDN = for the segments won't work since a proper CDN would (should) block = direct access to segments to prevent deep linking. But we understand why = people make these assumptions, we've heard other statements from HAS = enthusiasts that don't make sense in the real = world.

Serving out the manifests alongside the = segments from the same CDN account is done for multiple reasons, which = do not at all adapt the content:

- Logical = asset recognition (parsing the manifests so the CDN understands that the = segments are part of a logical entity)
- Logical asset = management (processing, copying, managing manifests and subsequent = segments as if they are one asset)
- Logical = asset reporting (reporting manifests and subsequent segments via web = interfaces and APIs as if they are one asset)
- = Request routing control (CDNs only produce URLs for manifest files and = will not accept requests for segments to prevent unnecessary request = routing overload by having to request route every individual segment = request)
- Access control (CDNs will not allow direct access = to segments but only via the manifest file to prevent deep-linking, you = don't want any third party to publish a manifest file on an unlicensed = portal and then point users to the segments on the CDN without any = access control)
- Session control (http streaming is stateless = and that is quite dramatic for CDNs because you lose control over the = session and over session logging)

There are = additional reasons for CDNs to be able to adapt the manifest files but = do so without changing the actual content:
- For instance, = they could dynamically insert base URLs to point users to a group of = servers to improve the availability.
- Or they could = dynamically insert tokens into the manifest to control access to = segments.
- Or they could dynamically insert session keys to = be able to track a unique user session over multiple federated = CDNs.
- Or they could dynamically remove higher or lower = bit rates to better control the actual QoE on a per request = basis.

Concluding: 
To a = CDN, the segments aren't actually that interesting. They are just pieces = of useless raw data that needs to be protected, managed and = served. 
For a CDN, the manifest represents the content = and is a critical component so they need to be able to parse, alter and = serve them. 

I think the above by itself = describes some interesting challenges. Just one example: how are CDNs = going to guarantee anti-deeplinking to segments in a federated = constellation where multiple nodes of multiple CDNs and request routers = need to be aware of each others sessions and tokens, = etc? 

My 2 = cents.

Kind = regards, Stef van der Ziel

-- 
Owner= Jet-Stream | = StreamZilla
<= /span>
Office: +31 50 5261820 | Mobile: +31 6 = 23406348
= www.jet-stream.com | www.streamzillacdn.com
this communication is = confidential




On 27 mei 2012, at 01:37, Kevin J Ma wrote:

Hi = Ray,
  I read = through the updated draft and had a number of comments ahead = of
  the = meeting.
  First, a = general comment about manifest files.  The document = seems
  to assume = that manifest files will be distributed through the = CDN.
  There are = many services where this is not the case, often to = prevent
  = modification.  There is a large focus in the document on how to = modify
  manifest = files, in some cases where the manifest file itself is = not
  necessarily relevant.  I = believe there are ways to optimize HAS
  be out of = scope for the initial phase?
  With = respect section 2.2, I believe I commented on this in = the
  initial draft, but I still feel = that the relative vs absolute URL
  While = these are all valid examples of how to use URLs, they do = not
  seem to be typical cases.  For = us, a typical service has a DNS
  relative = path from that base directory is the same in all CDNs.  = The
  hostname does not point to any one = surrogate, and each CDN is still
  With = respect to sections 3.1 and 3.2, while I agree that = content
  storage = and acquisition optimization is important, and that = there
  should be = metadata which can describe the format of the content, = I
  do think the CDN needs to be fully = HAS aware, nor do I think that
  not see a = "significant" impact to the MI.  The metadata = interface
  will have = the ability to define metadata that applies to a set = of
  content assets, per the META-10 = requirement.  Ultimately, the CDN
  even if = that client got a manifest file directly from the = content
  provider = (not from the CDN) and is expecting the content to be = in
  the format that was provided to the = CDN by the content provider.
  With = respect to section 3.3, I think that a third case is = missing,
 where the = content provider does not provide the manifest file to = the
  CDN (which can be a fairly common = case).
  With = respect to sections 3.3.2 and 3.3.3, would not = DNS-based
  = redirection solve the issue by simply directing = manifest/chunk
  requests = to the dCDN, rather than doing a manifest rewrite for = every
  request = (especially in the case of live streaming where the = manifest
  might be = changing on every chunk)?  Also, presumably, the RR = would
  only = rewrite URLs which were within its own domain (i.e., = not
  blackholing ad insertion segments, = etc.)?
  With = respect to section 3.5, the time component of URL signing = is
  not mentioned until section = 3.5.3.  Expiration of URL tokens, in
  more = reliable approach to content access protection, though = that
  would = seem to be fairly well out of scope for CDNI.  The = proposed
  solution = in section 3.5.3, seems to be managing session = state?
  Depending = on the complexity of the cookie, this could be = troublesome
  if there = is a failover and session state is not properly = synchronized?
  And = in the case of live streaming, the manifest is going to = be
  requested every time?  How is = the state managed in that case?  Is
  Will the = cookie work across all CDNs?  Moving on to section = 3.5.4
  is even = more concerning.  What if the content is already = encrypted?
  How is = authentication being handled on the key server?  Who = is
  responsible for auditing the = security of the solution?  Is this
  existing = DRM?  Does it only use the DRM/encryption support of = the
  delivery protocol?  or is the = client expected to implement an
  More = generally, are we attempting to define security protocols = for
  content delivery?  If so, I = would like to see a more formal
  With = respect to section 3.6.2, it seems that we just want to be = able
 to purge a = set of content assets.  Would a URI prefix not be = sufficient?
--  Kevin = J. Ma
 cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org= ] On Behalf Of Brandenburg, R. (Ray) = van
Sent: Friday, May 25, 2012 10:19 = AM
To: cdni@ietf.org
Subject: Re: [CDNi] Status of = Adaptive Streaming and CDNI = draft
Hi = all,
 
I=92ve just uploaded a new = version of draft-brandenburg-cdni-has.
The draft is meant as an input document for the = virtual meeting on Thursday to discuss the impact of HTTP Adaptive = Streaming on the CDNI Interfaces. In the draft a number of alternative = solutions are presented for each area where the use of HAS might touch = with the CDNI Interfaces (e.g. content acquisition, content purge, = request routing, logging and URL signing).
I=92m looking forward to your = comments.
 
Have a nice = weekend!
 
Ray van = Brandenburg
 
 
 cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org= ] On Behalf Of Brandenburg, R. (Ray) = van
Sent: woensdag 23 mei 2012 = 13:37
To: cdni@ietf.org
Subject: [CDNi] Status of Adaptive = Streaming and CDNI draft
 
Hi all,
 
Next Tuesday we have a planned interim meeting = for discussing the combination between HTTP Adaptive Streaming and CDNI. = One  of the expected inputs for this meeting is a follow-up draft = to draft-brandenburg-cdni-has-00.
 
We are currently working hard at finishing this = draft, but as you might have seen, we have not yet uploaded a new = version. Currently we are at a stage where we have a first complete = internal draft ready. However, Francois and I have agreed that we rather = spend some more time on it so that it fully covers all the areas of the = CDNI-HAS combination than upload an incomplete version right now. We are = currently planning to upload the draft this Friday (25 of May) at the latest. I = hope this gives you all enough time to read the draft before the meeting = on Tuesday.
Sorry for = the delay.
This e-mail and its contents are subject to = the DISCLAIMER at CDNi@ietf.org
In-Reply-To: <291CC3F9E50E7641901A54E85D0977C653267F4D1F@MAILR002.mail.lan> Date: Tue, 29 May 2012 09:06:30 +0200 Message-Id: References: <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> <66050772-394A-4A28-92FE-6A0581D5A533@jet-stream.nl> <291CC3F9E50E7641901A54E85D0977C653267F4D1F@MAILR002.mail.lan> To: Kevin J Ma X-Mailer: Apple Mail (2.1257) Cc: "cdni@ietf.org" Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI 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, 29 May 2012 07:06:41 -0000 --Apple-Mail=_F614E9A5-D002-45C3-8120-704C4C4709C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Kevin, Op 27 mei 2012 om 18:00 heeft Kevin J Ma het = volgende geschreven: > Hi Stef, > =20 > I was not arguing that a CDN would not prefer to have the manifest. > I was more arguing that content providers may not trust CDNs with > the manifest generation/modification. Securing content, preventing > unauthorized access, and preventing piracy requires much more than > simple auth tokens. DRM is explicitly listed as out-of-scope in > the charter, so as I said, if the intent is to define a security > protocol, then I would like to see more requirements. If, however, > I have misunderstood, and section 3.5.4 is describing an existing > feature that is widely supported across CDNs today, that just needs > CDNI support, then I suppose that would be different. > =20 In general CDNs must offer the ability to secure access to content.=20 Access restriction and DRM can complement each other and don't = necessarily overlap. Many CDNs use tokens between portals and request routers and between = request routers and delivery nodes to prevent unauthorized access to = content. However being a stateless and segmented technology, HAS introduces a new = massive gap in the security by having manifest files in between the = request router and the actual content. So it is a responsibility for the = CDN to close this gap.=20 I know that many platforms who call themselves CDNs are nothing more = than a managed caching environment. So you can pull anything through. So = coming from this angle it makes sense to assume that you can simply = distribute manifests besides the CDN. I'm trying to educate here that = this vision is too simple and that we foresee that content providers = will demand from CDNs that their content is protected by actively = managing the manifests.=20 Doing nothing about manifest control, these passive CDNs have a wide = open security problem. I see many possibilities for people to = reconstruct manifests and abuse federated CDNs by directly pulling off = objects from caches.=20 If these CDNs would allow direct access to segments, that would be a = blocking issue for other CDNs to actually federate with these CDNs. = Because it breaks the level of security they are offering to their = content publishing customers. > As for asset management, I agree the CDN needs to know what files go > together, but I do not agree that a CDN should be allowed to modify > a manifest file any way it wants, or generate any manifest it wants > and present that to the end user. Manifest files may contain other > information besides segment file locations, e.g., DRM info, targeted > ad insertions, subscription-based customizations, etc., which the > content provider may not trust the CDN with. I would like to know > where the boundaries are of what the CDN may modify? Much of this > requires subscriber-awareness. How subscriber-aware are we assuming > the CDN to be? One might argue that the CDN should perform all these > functions and be a one-stop intelligent content delivery shop, but > that seems improbable in the short-run? The real problem is that manifest files are quite open, not well = designed and immature so everyone in the value chain thinks they can = just use and abuse the manifest file for whatever purpose they have.=20 Content publishers may want to dynamically adjust the manifest files to = actually change the content on a per request basis.=20 At the same time CDNs must be able to adjust the manifest files to do = session tracking, access protection, management, etc. Without actually = changing the content by the way!=20 These requirements can't be supported at the same time today. In my view = the core role of a manifest is to instruct the client how to reconstruct = segments into a fluent stream. However there are secondary roles which = are in conflict: content adaptation (ad insertion for insance) and CDN = distribution management, asset management, session management, access = management. The solution would be to wait for manifest files to become more mature. = I prefer to have manifest files roles to be split into content = management manifests and distribution management manifests.=20 Anyway it is too easy to assume that CDNs don't change manifests so they = don't need to serve out manifests. They do, so CDNi should be aware of = it. It is not a matter of being an advanced feature, it is how many CDNs = simply work from a core philosophy around HAS. I'm not asking CDNi to make serving out manifests mandatory, because = that would be a similar mistake the other way around, what i propose is = that CDNi should be aware of which CDNs cannot control manifests, and = which CDNs make manifest control mandatory. > Perhaps a more general question: Are we talking about making CDNs > HAS aware, or making CDNI HAS aware? It feels more like the former, > with the latter being an after-thought, and it is not clear to me > how the former fits into the charter? Going straight from the uCDN > routing every segment, to the uCDN supporting modification of a half > dozen manifest formats feels disingenuous. Is there no BCP for how > to configure DNS-RR to take the load off the uCDN RR, or a simple > set of metadata to describe the source content structure which can > facilitate more efficient content acquisition? I think you hit a weak spot in CDNi. Some CDNs use passive DNS rr and = others use active HTTP rr. Some support both. Some also use redirect = instructional files which IMHO is the best technology since it is active = and guarantees much higher uptime and performance. If you want I can = share more details about this because it would be a great feature for = CDNi. You are right that active rr CDNs may not want to federate to DNS based = CDNs because their service level would drop below the SLA they offered = to their customer. And you are right that some scenarios may simply not = work, for instance when a uCDN manifest based anti-deeplinking and a = dCDN hasn't implemented this. Some CDNs don't care about manifests, = others need them to do their job. It isn't guaranteed that CDNs are = always interchangeable.=20 So that is why it is so important that CDNi doesn't rule out specific = technology visions, architecture designs or technology choices. It = should support these different flavors and definitely not rule out = specific ones. And this is a typical example of information that should = be shared between CDNs via a capabilities API, so CDNs can decide if = they want to federate with other CDNs that cannot support the features = they require. Best Stef > =20 > thanx. > =20 > -- Kevin J. Ma > =20 > From: Stef van der Ziel [mailto:stef@jet-stream.nl]=20 > Sent: Sunday, May 27, 2012 9:03 AM > To: Kevin J Ma > Cc: Brandenburg, R. (Ray) van; cdni@ietf.org > Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft > =20 > Hi Kevin, > =20 > Actually, many CDNs prefer to serve out both the segments and the = manifest files. > Sure, dumb caching/DNS based CDNs can be used to deliver segments and = they wouldn't care about segments. They will just pump out the delivered = objects. But intelligent CDNs that are actually usable for = commercial/secure and manageable HAS, need the manifests. > =20 > IMHO the role of a manifest file should not be confused with the role = of a referrer file.=20 > A manifest is to represent the entire content, not just to the client = but in the entire chain of encoding, protection, CDN and clients.=20 > A referrer file is the proper way to point to the (logical) content = from any remote location. > =20 > We hardly ever see manifest files to be distributed outside of the CDN = in reality. It is not a fairly common scenario and should not be. In = more automated environments, it can actually be the CDN that creates the = manifest. > =20 > The assumption that manifest files should or can be distributed = offline or outside the CDN is mostly wrong. The assumption that you can = point from a manifest to a CDN for the segments won't work since a = proper CDN would (should) block direct access to segments to prevent = deep linking. But we understand why people make these assumptions, we've = heard other statements from HAS enthusiasts that don't make sense in the = real world. > =20 > Serving out the manifests alongside the segments from the same CDN = account is done for multiple reasons, which do not at all adapt the = content: > =20 > - Logical asset recognition (parsing the manifests so the CDN = understands that the segments are part of a logical entity) > - Logical asset management (processing, copying, managing manifests = and subsequent segments as if they are one asset) > - Logical asset reporting (reporting manifests and subsequent segments = via web interfaces and APIs as if they are one asset) > - Request routing control (CDNs only produce URLs for manifest files = and will not accept requests for segments to prevent unnecessary request = routing overload by having to request route every individual segment = request) > - Access control (CDNs will not allow direct access to segments but = only via the manifest file to prevent deep-linking, you don't want any = third party to publish a manifest file on an unlicensed portal and then = point users to the segments on the CDN without any access control) > - Session control (http streaming is stateless and that is quite = dramatic for CDNs because you lose control over the session and over = session logging) > =20 > There are additional reasons for CDNs to be able to adapt the manifest = files but do so without changing the actual content: > - For instance, they could dynamically insert base URLs to point users = to a group of servers to improve the availability. > - Or they could dynamically insert tokens into the manifest to control = access to segments. > - Or they could dynamically insert session keys to be able to track a = unique user session over multiple federated CDNs. > - Or they could dynamically remove higher or lower bit rates to better = control the actual QoE on a per request basis. > =20 > Concluding:=20 > To a CDN, the segments aren't actually that interesting. They are just = pieces of useless raw data that needs to be protected, managed and = served.=20 > For a CDN, the manifest represents the content and is a critical = component so they need to be able to parse, alter and serve them.=20 > =20 > I think the above by itself describes some interesting challenges. = Just one example: how are CDNs going to guarantee anti-deeplinking to = segments in a federated constellation where multiple nodes of multiple = CDNs and request routers need to be aware of each others sessions and = tokens, etc?=20 > =20 > My 2 cents. > =20 > Kind regards, Stef van der Ziel > =20 > --=20 > Owner Jet-Stream | StreamZilla > GMT+1 Office: +31 50 5261820 | Mobile: +31 6 23406348 > www.jet-stream.com | www.streamzillacdn.com > this communication is confidential > =20 >=20 >=20 > =20 > On 27 mei 2012, at 01:37, Kevin J Ma wrote: >=20 >=20 > Hi Ray, > =20 > I read through the updated draft and had a number of comments ahead = of > the meeting. > =20 > First, a general comment about manifest files. The document seems > to assume that manifest files will be distributed through the CDN. > There are many services where this is not the case, often to prevent > modification. There is a large focus in the document on how to = modify > manifest files, in some cases where the manifest file itself is not > necessarily relevant. I believe there are ways to optimize HAS > delivery without modifying manifest files, and in imo, manifest > manipulation falls under content adaptation which the wg declared to > be out of scope for the initial phase? > =20 > With respect section 2.2, I believe I commented on this in the > initial draft, but I still feel that the relative vs absolute URL > discussion is rather misleading. It seems to imply that: > a) the HOST portion of a relative URL cannot point to a RR, that > b) a RR must be accessed through some web service like API, and = that > c) absolute URLs can only point to specific surrogates. > While these are all valid examples of how to use URLs, they do not > seem to be typical cases. For us, a typical service has a DNS > address which points to a base directory in one or more CDNs. The > relative path from that base directory is the same in all CDNs. The > hostname does not point to any one surrogate, and each CDN is still > able to redirect requests as it sees fit. > =20 > With respect to sections 3.1 and 3.2, while I agree that content > storage and acquisition optimization is important, and that there > should be metadata which can describe the format of the content, I > do think the CDN needs to be fully HAS aware, nor do I think that > the CDN necessarily needs access to the manifest file. I also do > not see a "significant" impact to the MI. The metadata interface > will have the ability to define metadata that applies to a set of > content assets, per the META-10 requirement. Ultimately, the CDN > needs to be able to respond to content requests from the client, > even if that client got a manifest file directly from the content > provider (not from the CDN) and is expecting the content to be in > the format that was provided to the CDN by the content provider. > How it got the content and how it stores it is out of scope? > =20 > With respect to section 3.3, I think that a third case is missing, > where the content provider does not provide the manifest file to the > CDN (which can be a fairly common case). > =20 > With respect to sections 3.3.2 and 3.3.3, would not DNS-based > redirection solve the issue by simply directing manifest/chunk > requests to the dCDN, rather than doing a manifest rewrite for every > request (especially in the case of live streaming where the manifest > might be changing on every chunk)? Also, presumably, the RR would > only rewrite URLs which were within its own domain (i.e., not > blackholing ad insertion segments, etc.)? > =20 > With respect to section 3.5, the time component of URL signing is > not mentioned until section 3.5.3. Expiration of URL tokens, in > general, is an issue with HAS. Robust key management is an arguably > more reliable approach to content access protection, though that > would seem to be fairly well out of scope for CDNI. The proposed > solution in section 3.5.3, seems to be managing session state? > Depending on the complexity of the cookie, this could be troublesome > if there is a failover and session state is not properly = synchronized? > And in the case of live streaming, the manifest is going to be > requested every time? How is the state managed in that case? Is > the cookie less susceptible to replay attacks than the URL token? > Will the cookie work across all CDNs? Moving on to section 3.5.4 > is even more concerning. What if the content is already encrypted? > How is authentication being handled on the key server? Who is > responsible for auditing the security of the solution? Is this > intended to provide DRM? work with existing DRM? circumvent > existing DRM? Does it only use the DRM/encryption support of the > delivery protocol? or is the client expected to implement an > alternate protocol? And how is this synchronized across CDNs? > More generally, are we attempting to define security protocols for > content delivery? If so, I would like to see a more formal > definition of what those requirements are? > =20 > With respect to section 3.6.2, it seems that we just want to be able > to purge a set of content assets. Would a URI prefix not be = sufficient? > =20 > thanx. > =20 > -- Kevin J. Ma > =20 > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Brandenburg, R. (Ray) van > Sent: Friday, May 25, 2012 10:19 AM > To: cdni@ietf.org > Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft > =20 > Hi all, > =20 > I=92ve just uploaded a new version of draft-brandenburg-cdni-has. > =20 > You can find the document at: = http://www.ietf.org/id/draft-brandenburg-cdni-has-01.txt > =20 > The draft is meant as an input document for the virtual meeting on = Thursday to discuss the impact of HTTP Adaptive Streaming on the CDNI = Interfaces. In the draft a number of alternative solutions are presented = for each area where the use of HAS might touch with the CDNI Interfaces = (e.g. content acquisition, content purge, request routing, logging and = URL signing). > =20 > I=92m looking forward to your comments. > =20 > Have a nice weekend! > =20 > Ray van Brandenburg > =20 > =20 > =20 > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Brandenburg, R. (Ray) van > Sent: woensdag 23 mei 2012 13:37 > To: cdni@ietf.org > Subject: [CDNi] Status of Adaptive Streaming and CDNI draft > =20 > Hi all, > =20 > Next Tuesday we have a planned interim meeting for discussing the = combination between HTTP Adaptive Streaming and CDNI. One of the = expected inputs for this meeting is a follow-up draft to = draft-brandenburg-cdni-has-00. > =20 > We are currently working hard at finishing this draft, but as you = might have seen, we have not yet uploaded a new version. Currently we = are at a stage where we have a first complete internal draft ready. = However, Francois and I have agreed that we rather spend some more time = on it so that it fully covers all the areas of the CDNI-HAS combination = than upload an incomplete version right now. We are currently planning = to upload the draft this Friday (25th of May) at the latest. I hope this = gives you all enough time to read the draft before the meeting on = Tuesday. > =20 > Sorry for the delay. > =20 > Ray > =20 > =20 > =20 > This e-mail and its contents are subject to the DISCLAIMER at = http://www.tno.nl/emaildisclaimer >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > =20 --Apple-Mail=_F614E9A5-D002-45C3-8120-704C4C4709C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Kevin,

Hi = Stef,

 

  I = was not arguing that a CDN would not prefer to have the = manifest.

  I = was more arguing that content providers may not trust CDNs = with

  = the manifest generation/modification.  Securing content, = preventing

  = unauthorized access, and preventing piracy requires much more = than

  = simple auth tokens.  DRM is explicitly listed as out-of-scope = in

  = the charter, so as I said, if the intent is to define a = security

  = protocol, then I would like to see more requirements.  If, = however,

  I = have misunderstood, and section 3.5.4 is describing an = existing

  = feature that is widely supported across CDNs today, that just = needs

  = CDNI support, then I suppose that would be = different.

 


<= /div>
In general CDNs must offer the ability to secure access to = content. 
Access restriction and DRM can complement each = other and don't necessarily overlap.
Many CDNs use tokens = between portals and request routers and between request routers and = delivery nodes to prevent unauthorized access to = content.

However being a stateless and = segmented technology, HAS introduces a new massive gap in the security = by having manifest files in between the request router and the actual = content. So it is a responsibility for the CDN to close this = gap. 

I know that many platforms who call = themselves CDNs are nothing more than a managed caching environment. So = you can pull anything through. So coming from this angle it makes sense = to assume that you can simply distribute manifests besides the CDN. I'm = trying to educate here that this vision is too simple and that we = foresee that content providers will demand from CDNs that their content = is protected by actively managing the = manifests. 

Doing nothing about manifest = control, these passive CDNs have a wide open security problem. I see = many possibilities for people to reconstruct manifests and abuse = federated CDNs by directly pulling off objects from = caches. 

If these CDNs would allow direct = access to segments, that would be a blocking issue for other CDNs to = actually federate with these CDNs. Because it breaks the level of = security they are offering to their content publishing = customers.


  As = for asset management, I agree the CDN needs to know what files = go

  = together, but I do not agree that a CDN should be allowed to = modify

  a = manifest file any way it wants, or generate any manifest it = wants

  = and present that to the end user.  Manifest files may contain = other

=  information besides segment file locations, e.g., DRM info, = targeted

  ad = insertions, subscription-based customizations, etc., which = the

  = content provider may not trust the CDN with.  I would like to = know

  = where the boundaries are of what the CDN may modify?  Much of = this

  = requires subscriber-awareness.  How subscriber-aware are we = assuming

=  the CDN to be?  One might argue that the CDN should perform = all these

=  functions and be a one-stop intelligent content delivery shop, = but

=  that seems improbable in the = short-run?


The real = problem is that manifest files are quite open, not well designed and = immature so everyone in the value chain thinks they can just use and = abuse the manifest file for whatever purpose they = have. 

Content publishers may want to = dynamically adjust the manifest files to actually change the content on = a per request basis. 

At the same time = CDNs must be able to adjust the manifest files to do session tracking, = access protection, management, etc. Without actually changing the = content by the way! 

These requirements = can't be supported at the same time today. In my view the core role of a = manifest is to instruct the client how to reconstruct segments into a = fluent stream. However there are secondary roles which are in conflict: = content adaptation (ad insertion for insance) and CDN distribution = management, asset management, session management, access = management.

The solution would be to wait for = manifest files to become more mature. I prefer to have manifest files = roles to be split into content management manifests and distribution = management manifests. 

Anyway it is too = easy to assume that CDNs don't change manifests so they don't need to = serve out manifests. They do, so CDNi should be aware of it. It is not a = matter of being an advanced feature, it is how many CDNs simply work = from a core philosophy around HAS.

I'm not = asking CDNi to make serving out manifests mandatory, because that would = be a similar mistake the other way around, what i propose is that CDNi = should be aware of which CDNs cannot control manifests, and which CDNs = make manifest control = mandatory.


  = Perhaps a more general question: Are we talking about making = CDNs

  = HAS aware, or making CDNI HAS aware?  It feels more like the = former,

  = with the latter being an after-thought, and it is not clear to = me

  = how the former fits into the charter?  Going straight from the = uCDN

  = routing every segment, to the uCDN supporting modification of a = half

  = dozen manifest formats feels disingenuous.  Is there no BCP for = how

  to = configure DNS-RR to take the load off the uCDN RR, or a = simple

  = set of metadata to describe the source content structure which = can

  = facilitate more efficient content = acquisition?


I = think you hit a weak spot in CDNi. Some CDNs use passive DNS rr and = others use active HTTP rr. Some support both. Some also use redirect = instructional files which IMHO is the best technology since it is active = and guarantees much higher uptime and performance. If you want I can = share more details about this because it would be a great feature for = CDNi.

You are = right that active rr CDNs may not want to federate to DNS based CDNs = because their service level would drop below the SLA they offered to = their customer. And you are right that some scenarios may simply not = work, for instance when a uCDN manifest based anti-deeplinking and a = dCDN hasn't implemented this. Some = CDNs don't care about manifests, others need them to do their = job. It = isn't guaranteed that CDNs are always = interchangeable. 

So that = is why it is so important that CDNi doesn't rule out specific technology = visions, architecture designs or technology choices. It should support = these different flavors and definitely not rule out specific ones. And = this is a typical example of information that should be shared between = CDNs via a capabilities API, so CDNs can decide if they want to federate = with other CDNs that cannot support the features they = require.
Best = Stef


 

thanx.

 

--  = Kevin J. Ma

 

From: Stef van der Ziel [mailto:stef@jet-stream.nl]
Sent: = Sunday, May 27, 2012 9:03 AM
To: Kevin J Ma
Cc: = Brandenburg, R. (Ray) van; cdni@ietf.org
Subject: Re: = [CDNi] Status of Adaptive Streaming and CDNI = draft

 

Hi = Kevin,

 

Actually, many CDNs prefer to serve out both the = segments and the manifest files.

Sure, dumb caching/DNS based CDNs can be used to = deliver segments and they wouldn't care about segments. They will just = pump out the delivered objects. But intelligent CDNs that are = actually usable for commercial/secure and manageable HAS, need the = manifests.

 

IMHO the role of a manifest file should not be = confused with the role of a referrer = file. 

A = manifest is to represent the entire content, not just to the client but = in the entire chain of encoding, protection, CDN and = clients. 

A = referrer file is the proper way to point to the (logical) content from = any remote location.

 

We hardly ever see manifest files to be distributed = outside of the CDN in reality. It is not a fairly common scenario and = should not be. In more automated environments, it can actually be = the CDN that creates the manifest.

 

The assumption that manifest files should or can be = distributed offline or outside the CDN is mostly wrong. The = assumption that you can point from a manifest to a CDN for the segments = won't work since a proper CDN would (should) block direct access to = segments to prevent deep linking. But we understand why people make = these assumptions, we've heard other statements from HAS enthusiasts = that don't make sense in the real world.

 

Serving out the manifests alongside the segments = from the same CDN account is done for multiple reasons, which do not at = all adapt the content:

 

- Logical asset recognition (parsing the manifests = so the CDN understands that the segments are part of a logical = entity)

- Logical = asset management (processing, copying, managing manifests and subsequent = segments as if they are one = asset)

- = Logical asset reporting (reporting manifests and subsequent segments via = web interfaces and APIs as if they are one = asset)

- = Request routing control (CDNs only produce URLs for manifest files and = will not accept requests for segments to prevent unnecessary request = routing overload by having to request route every individual segment = request)

- Access = control (CDNs will not allow direct access to segments but only via the = manifest file to prevent deep-linking, you don't want any third party to = publish a manifest file on an unlicensed portal and then point users to = the segments on the CDN without any access = control)

- Session = control (http streaming is stateless and that is quite dramatic for CDNs = because you lose control over the session and over session = logging)

 

There are additional reasons for CDNs to be able to = adapt the manifest files but do so without changing the actual = content:

- For instance, = they could dynamically insert base URLs to point users to a group of = servers to improve the availability.

- Or they could dynamically insert tokens into the = manifest to control access to segments.

- Or they could dynamically insert session keys to = be able to track a unique user session over multiple federated = CDNs.

- Or they = could dynamically remove higher or lower bit rates to better control the = actual QoE on a per request basis.

 

Concluding: 

To a CDN, the segments aren't actually that = interesting. They are just pieces of useless raw data that needs to be = protected, managed and served. 

For a CDN, the manifest represents the content and = is a critical component so they need to be able to parse, alter and = serve them. 

 

I think the above by itself describes some = interesting challenges. Just one example: how are CDNs going to = guarantee anti-deeplinking to segments in a federated constellation = where multiple nodes of multiple CDNs and request routers need to be = aware of each others sessions and tokens, = etc? 

 

My 2 cents.

 

<= div>

Kind regards, Stef van der = Ziel

 

-- 

Owner Jet-Stream | = StreamZilla

<= /div>

GMT+1 Office: +31 50 5261820 | Mobile: +31 6 = 23406348

www.jet-stream.com | www.streamzillacdn.com

this communication is confidential

 

<= /div>



 

On 27 mei 2012, at 01:37, Kevin J Ma = wrote:



Hi = Ray,

 

  I = read through the updated draft and had a number of comments ahead = of

  = the meeting.

 

  = First, a general comment about manifest files.  The document = seems

  to = assume that manifest files will be distributed through the = CDN.

  = There are many services where this is not the case, often to = prevent

  = modification.  There is a large focus in the document on how to = modify

  = manifest files, in some cases where the manifest file itself is = not

  = necessarily relevant.  I believe there are ways to optimize = HAS

  = delivery without modifying manifest files, and in imo, = manifest

 manipulation falls under content adaptation which the = wg declared to

  be = out of scope for the initial phase?

 

  = With respect section 2.2, I believe I commented on this in = the

  = initial draft, but I still feel that the relative vs absolute = URL

  = discussion is rather misleading.  It seems to imply = that:

    a) the HOST portion of a relative URL = cannot point to a RR, that

    b) a RR must be accessed through some web = service like API, and that

    c) absolute URLs can only point to = specific surrogates.

  = While these are all valid examples of how to use URLs, they do = not

  = seem to be typical cases.  For us, a typical service has a = DNS

  = address which points to a base directory in one or more CDNs.  = The

  = relative path from that base directory is the same in all CDNs.  = The

  = hostname does not point to any one surrogate, and each CDN is = still

  = able to redirect requests as it sees = fit.

 

  = With respect to sections 3.1 and 3.2, while I agree that = content

  = storage and acquisition optimization is important, and that = there

  = should be metadata which can describe the format of the content, = I

  do = think the CDN needs to be fully HAS aware, nor do I think = that

  = the CDN necessarily needs access to the manifest file.  I also = do

  = not see a "significant" impact to the MI.  The metadata = interface

  = will have the ability to define metadata that applies to a set = of

  = content assets, per the META-10 requirement.  Ultimately, the = CDN

  = needs to be able to respond to content requests from the = client,

  = even if that client got a manifest file directly from the = content

  = provider (not from the CDN) and is expecting the content to be = in

  = the format that was provided to the CDN by the content = provider.

  = How it got the content and how it stores it is out of = scope?

 

  = With respect to section 3.3, I think that a third case is = missing,

 where the content provider does not provide the = manifest file to the

  = CDN (which can be a fairly common = case).

 

  = With respect to sections 3.3.2 and 3.3.3, would not = DNS-based

  = redirection solve the issue by simply directing = manifest/chunk

  = requests to the dCDN, rather than doing a manifest rewrite for = every

  = request (especially in the case of live streaming where the = manifest

  = might be changing on every chunk)?  Also, presumably, the RR = would

  = only rewrite URLs which were within its own domain (i.e., = not

  = blackholing ad insertion segments, = etc.)?

 

  = With respect to section 3.5, the time component of URL signing = is

  = not mentioned until section 3.5.3.  Expiration of URL tokens, = in

  = general, is an issue with HAS.  Robust key management is an = arguably

  = more reliable approach to content access protection, though = that

  = would seem to be fairly well out of scope for CDNI.  The = proposed

  = solution in section 3.5.3, seems to be managing session = state?

  = Depending on the complexity of the cookie, this could be = troublesome

  if = there is a failover and session state is not properly = synchronized?

  And in the case of live streaming, the manifest = is going to be

  = requested every time?  How is the state managed in that case?  = Is

  = the cookie less susceptible to replay attacks than the URL = token?

  = Will the cookie work across all CDNs?  Moving on to section = 3.5.4

  is = even more concerning.  What if the content is already = encrypted?

  = How is authentication being handled on the key server?  Who = is

  = responsible for auditing the security of the solution?  Is = this

  = intended to provide DRM?  work with existing DRM?  = circumvent

  = existing DRM?  Does it only use the DRM/encryption support of = the

  = delivery protocol?  or is the client expected to implement = an

  = alternate protocol?  And how is this synchronized across = CDNs?

  = More generally, are we attempting to define security protocols = for

  = content delivery?  If so, I would like to see a more = formal

 definition of what those requirements = are?

 

  = With respect to section 3.6.2, it seems that we just want to be = able

 to = purge a set of content assets.  Would a URI prefix not be = sufficient?

 

thanx.

 

--  = Kevin J. Ma

 

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org= ] On Behalf Of Brandenburg, R. (Ray) = van
Sent: Friday, May 25, 2012 10:19 = AM
To: cdni@ietf.org
Subject: Re: [CDNi] Status of = Adaptive Streaming and CDNI = draft

 

Hi all,

 

I=92ve just uploaded a new version of = draft-brandenburg-cdni-has.

 

 

The draft is meant as an input document for the = virtual meeting on Thursday to discuss the impact of HTTP Adaptive = Streaming on the CDNI Interfaces. In the draft a number of alternative = solutions are presented for each area where the use of HAS might touch = with the CDNI Interfaces (e.g. content acquisition, content purge, = request routing, logging and URL = signing).

 

I=92m looking forward to your = comments.

 

Have a nice = weekend!

 

Ray van = Brandenburg

 

 

 

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org= ] On Behalf Of Brandenburg, R. (Ray) = van
Sent: woensdag 23 mei 2012 = 13:37
To: cdni@ietf.org
Subject: [CDNi] Status of Adaptive = Streaming and CDNI draft

 

Hi all,

 

Next Tuesday we have a planned interim meeting for discussing = the combination between HTTP Adaptive Streaming and CDNI. One  of = the expected inputs for this meeting is a follow-up draft to = draft-brandenburg-cdni-has-00.

=

 

We are currently working hard at finishing this draft, but as = you might have seen, we have not yet uploaded a new version. Currently = we are at a stage where we have a first complete internal draft ready. = However, Francois and I have agreed that we rather spend some more time = on it so that it fully covers all the areas of the CDNI-HAS combination = than upload an incomplete version right now. We are currently planning = to upload the draft this Friday (25th of May) at the latest. I hope this gives you all enough time to = read the draft before the meeting on = Tuesday.

 

Sorry for the = delay.

 

Ray

 

 

 

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

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

 

= --Apple-Mail=_F614E9A5-D002-45C3-8120-704C4C4709C3-- From ray.vanbrandenburg@tno.nl Tue May 29 01:00:38 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32A921F86EB for ; Tue, 29 May 2012 01:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[AWL=0.853, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZ12N+IIuWG6 for ; Tue, 29 May 2012 01:00:31 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 630E221F8460 for ; Tue, 29 May 2012 01:00:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,676,1330902000"; d="scan'208,217";a="15350324" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 29 May 2012 10:00:25 +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; Tue, 29 May 2012 10:00:25 +0200 From: "Brandenburg, R. (Ray) van" To: Kevin J Ma Thread-Topic: Status of Adaptive Streaming and CDNI draft Thread-Index: Ac0414J5VzCVuofZTcKanwrNrKyoTABqTCnQAEHKv5AAS2tZDwAMh8BwACHwwsA= Date: Tue, 29 May 2012 08:00:25 +0000 Message-ID: References: , <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> <3C0B3042-9BAB-4A7A-A952-737C92666E75@tno.nl> <291CC3F9E50E7641901A54E85D0977C653267F4D48@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C653267F4D48@MAILR002.mail.lan> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1581C5D18BEEXCMBX03tsntnon_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI 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, 29 May 2012 08:00:38 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA1581C5D18BEEXCMBX03tsntnon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kevin, Comments inline. Best regards, Ray From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] Sent: maandag 28 mei 2012 18:10 To: Brandenburg, R. (Ray) van Cc: cdni@ietf.org; Stef van der Ziel Subject: RE: Status of Adaptive Streaming and CDNI draft Hi Ray, > Sure, in some cases the CDN might not deliver the manifest, however in so= me other cases it will. I think ruling out the latter is not what we want r= ight? I was more concerned that we may have tried to rule out the former. If we agree that there is a valid case where the CDN does not deliver the manifest, I think that it should be covered. RvB: My goal was not to rule out anything (although I agree with Stef's com= ment that having the manifest file be delivered by the Content Provider doe= s present some problems). However, in the case where the manifest file is d= elivered by the Content Provider, wouldn't that force the manifest file to = use Absolute URLs? > In my opinion, considering manifest manipulation to be content adaptation= is stretching the definition of content adaption a little bit. I think St= ef already presented enough examples of why a CDN might want to modify the = manifest file in a way that is not related to content adaptation at all. I think it's a slippery slope. Forbidding changes to data is pretty clear cut. When you start making exceptions, it raises concerns? What is it going to break? Who might stretch the boundaries of what would be reasonable to modify? How does it fit into the different distribution paradigms? There's no question that a CDN might want to modify a manifest. The question is should the CDN be allowed to, and if it is, what are the limits to what it is allowed to modify? There must be defined limits. RvB: In the case of section 3.3.2, it is the uCDN who modifies the manifest= . I would guess that the uCDN has (should have) a pretty good idea of what = he discussed with the Content Provider about the possibilities of modifying= the manifest. Do you agree that we don't have a problem in that case? As for section 3.3.3, where the dCDN does some of the manifest manipulation= , I agree that we need to have some guidelines on what can en what can't be= modified. > With respect to sections 3.3.2 and 3.3.3, would not DNS-based > redirection solve the issue by simply directing manifest/chunk > requests to the dCDN, rather than doing a manifest rewrite for every > request (especially in the case of live streaming where the manifest > might be changing on every chunk)? > > I think we both agree that the CDNI interfaces should support both HTTP b= ased and DNS based redirection, right? So even if DNS based redirection wou= ld solve some issues regarding manifest files, we still need an HTTP based = solution. Certainly, I agree that both DNS and HTTP redirects should be supported. I was trying to understand if there was "significant signalling overhead" in both cases? or if there are other factors involved, e.g., the redirection method. It might be helpful to expand the discussion of advantages and disadvantages for the different cases? RvB: I'm not familiar enough with DNS CDNs to answer your question. If you = want, maybe you can write some text that details the DNS-redirection scenar= io better than the current draft? > a) the HOST portion of a relative URL cannot point to a RR, that > > I'm not sure I understand you. The idea behind a Relative URL is that it = doesn't have a HOST portion. The manifest has a host from which it was retrieved. In your example, that host is a surrogate: http://surrogate.server.cdn.example.com/content_1/manifest.xml but that could have been a RR, that uses either DNS or HTTP redirects: http://rr.cdn.example.com/content_1/manifest.xml and that the relative paths could have been appended to the RR host, (as would be the case with HLS): http://rr.cdn.example.com/content_1/segments/segment1_1.ts RvB: That would only be the case if the manifest were delivered by the RR f= unction, right? I agree with the brittleness comments in section 3.3.1. Perhaps some text to that affect in section 2 would clarify it for the linear reader? RvB: I can add this to the next version. though, the RR is going to need to be aware of the idiosyncrasies of each protocol and support all those brittle clients? > b) a RR must be accessed through some web service like API, and that > > The example presented is meant as just that, an example. The important pa= rt here is in the HOST portion pointing to a RR function. However, if you f= ind this example to be confusing, I can change it. It was not clear to me if the path was significant. Perhaps a second example with just the host name difference would clarify that? http://rr.cdn.example.com/content_1/segments/segment1_1.ts RvB: Yes, that's a good idea. I will add this to the next version. thanx. -- Kevin J. Ma From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] Sent: Monday, May 28, 2012 5:38 AM To: Kevin J Ma Cc: cdni@ietf.org; Stef van der Ziel Subject: Re: Status of Adaptive Streaming and CDNI draft Hi Kevin, Thanks for your review. See my comments inline. On 27 mei 2012, at 01:37, "Kevin J Ma" > wrote: Hi Ray, I read through the updated draft and had a number of comments ahead of the meeting. First, a general comment about manifest files. The document seems to assume that manifest files will be distributed through the CDN. There are many services where this is not the case, often to prevent modification. There is a large focus in the document on how to modify manifest files, in some cases where the manifest file itself is not necessarily relevant. I believe there are ways to optimize HAS delivery without modifying manifest files, and in imo, manifest manipulation falls under content adaptation which the wg declared to be out of scope for the initial phase? Sure, in some cases the CDN might not deliver the manifest, however in some= other cases it will. I think ruling out the latter is not what we want rig= ht? In my opinion, considering manifest manipulation to be content adaptation i= s stretching the definition of content adaption a little bit. I think Stef = already presented enough examples of why a CDN might want to modify the man= ifest file in a way that is not related to content adaptation at all. As I said in my other mail: wouldn't a simple 'do not change manifest'-bo= olean in the metadate interface solve your concerns in the cases where a Co= ntent Provider does not want the manifest to be modified? With respect section 2.2, I believe I commented on this in the initial draft, but I still feel that the relative vs absolute URL discussion is rather misleading. It seems to imply that: a) the HOST portion of a relative URL cannot point to a RR, that I'm not sure I understand you. The idea behind a Relative URL is that it do= esn't have a HOST portion. b) a RR must be accessed through some web service like API, and that The example presented is meant as just that, an example. The important part= here is in the HOST portion pointing to a RR function. However, if you fin= d this example to be confusing, I can change it. c) absolute URLs can only point to specific surrogates. Absolute URLs without Redirection point to surrogates, Absolute URLs with R= edirection explicitely do not. While these are all valid examples of how to use URLs, they do not seem to be typical cases. For us, a typical service has a DNS address which points to a base directory in one or more CDNs. The relative path from that base directory is the same in all CDNs. The hostname does not point to any one surrogate, and each CDN is still able to redirect requests as it sees fit. I agree that this is how some CDNs might do it. But I'm not sure how this = affects 2.2. Section 2.2 is meant as a general overview into the different = methods with which chunks might be addressed in a manifest file. Some CDNs = might use one option, some CDNs might use another. With respect to sections 3.1 and 3.2, while I agree that content storage and acquisition optimization is important, and that there should be metadata which can describe the format of the content, I do think the CDN needs to be fully HAS aware, nor do I think that the CDN necessarily needs access to the manifest file. I also do not see a "significant" impact to the MI. The metadata interface will have the ability to define metadata that applies to a set of content assets, per the META-10 requirement. Ultimately, the CDN needs to be able to respond to content requests from the client, even if that client got a manifest file directly from the content provider (not from the CDN) and is expecting the content to be in the format that was provided to the CDN by the content provider. How it got the content and how it stores it is out of scope? With respect to section 3.3, I think that a third case is missing, where the content provider does not provide the manifest file to the CDN (which can be a fairly common case). If you want, I can add this case. With respect to sections 3.3.2 and 3.3.3, would not DNS-based redirection solve the issue by simply directing manifest/chunk requests to the dCDN, rather than doing a manifest rewrite for every request (especially in the case of live streaming where the manifest might be changing on every chunk)? Also, presumably, the RR would only rewrite URLs which were within its own domain (i.e., not blackholing ad insertion segments, etc.)? I think we both agree that the CDNI interfaces should support both HTTP bas= ed and DNS based redirection, right? So even if DNS based redirection would= solve some issues regarding manifest files, we still need an HTTP based so= lution. With respect to section 3.5, the time component of URL signing is not mentioned until section 3.5.3. Expiration of URL tokens, in general, is an issue with HAS. Robust key management is an arguably more reliable approach to content access protection, though that would seem to be fairly well out of scope for CDNI. The proposed solution in section 3.5.3, seems to be managing session state? Depending on the complexity of the cookie, this could be troublesome if there is a failover and session state is not properly synchronized? And in the case of live streaming, the manifest is going to be requested every time? How is the state managed in that case? Is the cookie less susceptible to replay attacks than the URL token? Will the cookie work across all CDNs? Moving on to section 3.5.4 is even more concerning. What if the content is already encrypted? How is authentication being handled on the key server? Who is responsible for auditing the security of the solution? Is this intended to provide DRM? work with existing DRM? circumvent existing DRM? Does it only use the DRM/encryption support of the delivery protocol? or is the client expected to implement an alternate protocol? And how is this synchronized across CDNs? More generally, are we attempting to define security protocols for content delivery? If so, I would like to see a more formal definition of what those requirements are? I will defer this discussion to other. With respect to section 3.6.2, it seems that we just want to be able to purge a set of content assets. Would a URI prefix not be sufficient? thanx. -- Kevin J. Ma From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: Friday, May 25, 2012 10:19 AM To: cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft Hi all, I've just uploaded a new version of draft-brandenburg-cdni-has. You can find the document at: http://www.ietf.org/id/draft-brandenburg-cdni= -has-01.txt The draft is meant as an input document for the virtual meeting on Thursday= to discuss the impact of HTTP Adaptive Streaming on the CDNI Interfaces. I= n the draft a number of alternative solutions are presented for each area w= here the use of HAS might touch with the CDNI Interfaces (e.g. content acqu= isition, content purge, request routing, logging and URL signing). I'm looking forward to your comments. Have a nice weekend! Ray van Brandenburg From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: woensdag 23 mei 2012 13:37 To: cdni@ietf.org Subject: [CDNi] Status of Adaptive Streaming and CDNI draft Hi all, Next Tuesday we have a planned interim meeting for discussing the combinati= on between HTTP Adaptive Streaming and CDNI. One of the expected inputs fo= r this meeting is a follow-up draft to draft-brandenburg-cdni-has-00. We are currently working hard at finishing this draft, but as you might hav= e seen, we have not yet uploaded a new version. Currently we are at a stage= where we have a first complete internal draft ready. However, Francois and= I have agreed that we rather spend some more time on it so that it fully c= overs all the areas of the CDNI-HAS combination than upload an incomplete v= ersion right now. We are currently planning to upload the draft this Friday= (25th of May) at the latest. I hope this gives you all enough time to read= the draft before the meeting on Tuesday. Sorry for the delay. Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_FCC100FC8D6B034CB88CD8173B2DA1581C5D18BEEXCMBX03tsntnon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kevin,

 <= /p>

Comments inline.

 <= /p>

Best regards,<= /span>

 <= /p>

Ray

 <= /p>

From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]
Sent: maandag 28 mei 2012 18:10
To: Brandenburg, R. (Ray) van
Cc: cdni@ietf.org; Stef van der Ziel
Subject: RE: Status of Adaptive Streaming and CDNI draft<= /span>

 

Hi Ray,

 

> Sure, in some cases the CDN might not = deliver the manifest, however in some other cases it will. I think ruling o= ut the latter is not what we want right?

 

I was more concerned that we may have tried= to rule out the former.

If we agree that there is a valid case wher= e the CDN does not deliver

the manifest, I think that it should be cov= ered.

 = ;

RvB: My go= al was not to rule out anything (although I agree with Stef’s comment= that having the manifest file be delivered by the Content Provider does present some problems). However, in the case where the manifest file = is delivered by the Content Provider, wouldn’t that force the manifes= t file to use Absolute URLs?

 

> In my opinion, considering manifest ma= nipulation to be content adaptation is stretching the definition of content= adaption a little bit.  I think Stef already presented enough examples of why a CDN might want to modify the manifest file in a w= ay that is not related to content adaptation at all.

 

I think it's a slippery slope.  Forbid= ding changes to data is pretty

clear cut.  When you start making exce= ptions, it raises concerns?

What is it going to break?  Who might = stretch the boundaries of what

would be reasonable to modify?  How do= es it fit into the different

distribution paradigms?

 

There's no question that a CDN might want t= o modify a manifest.  The

question is should the CDN be allowed to, a= nd if it is, what are the

limits to what it is allowed to modify?&nbs= p; There must be defined limits.

 = ;

RvB: In th= e case of section 3.3.2, it is the uCDN who modifies the manifest. I would = guess that the uCDN has (should have) a pretty good idea of what he discussed with the Content Provider about the possibilities of mod= ifying the manifest. Do you agree that we don’t have a problem in tha= t case?

 = ;

As for sec= tion 3.3.3, where the dCDN does some of the manifest manipulation, I agree = that we need to have some guidelines on what can en what can’t be modified.

 

>  With respect to sections 3.3.2 a= nd 3.3.3, would not DNS-based

>  redirection solve the issue by s= imply directing manifest/chunk

>  requests to the dCDN, rather tha= n doing a manifest rewrite for every

>  request (especially in the case = of live streaming where the manifest

>  might be changing on every chunk= )?

> 

> I think we both agree that the CDNI in= terfaces should support both HTTP based and DNS based redirection, right? S= o even if DNS based redirection would solve some issues regarding manifest files, we still need an HTTP based solution.=

 

Certainly, I agree that both DNS and HTTP r= edirects should be

supported.  I was trying to understand= if there was "significant

signalling overhead" in both cases?&nb= sp; or if there are other factors

involved, e.g., the redirection method.&nbs= p; It might be helpful to expand

the discussion of advantages and disadvanta= ges for the different cases?

 = ;

RvB: IR= 17;m not familiar enough with DNS CDNs to answer your question. If you want= , maybe you can write some text that details the DNS-redirection scenario better than the current draft?

 

> a) the HOST portion of a relative URL = cannot point to a RR, that

> 

> I'm not sure I understand you. The ide= a behind a Relative URL is that it doesn't have a HOST portion.

 

The manifest has a host from which it was r= etrieved.  In your example,

that host is a surrogate:=

 

  = http://surrogate.server.cdn.example.com/content_1/manifest.xml

 

but that could have been a RR, that uses ei= ther DNS or HTTP redirects:

 

  http://rr.cdn.= example.com/content_1/manifest.xml

 = ;

and that the relative paths could have been= appended to the RR host,

(as would be the case with HLS):=

 

  http= ://rr.cdn.example.com/content_1/segments/segment1_1.ts

 = ;

RvB: That = would only be the case if the manifest were delivered by the RR function, r= ight?

 

I agree with the brittleness comments in se= ction 3.3.1.  Perhaps some

text to that affect in section 2 would clar= ify it for the linear reader?

 = ;

RvB: I can= add this to the next version.

 

though, the RR is going to need to be aware= of the idiosyncrasies of

each protocol and support all those brittle= clients?

 = ;

> b) a RR must be accessed through some = web service like API, and that

> 

> The example presented is meant as just= that, an example. The important part here is in the HOST portion pointing = to a RR function. However, if you find this example to be confusing, I can change it.

 

It was not clear to me if the path was sign= ificant.  Perhaps a second

example with just the host name difference = would clarify that?

 

  http= ://rr.cdn.example.com/content_1/segments/segment1_1.ts

 = ;

RvB: Yes, = that’s a good idea. I will add this to the next version.

 = ;

 

thanx.

 

--  Kevin J. Ma

 

From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl]
Sent: Monday, May 28, 2012 5:38 AM
To: Kevin J Ma
Cc: cdni@ietf.org; Stef van der= Ziel
Subject: Re: Status of Adaptive Streaming and CDNI draft<= /span>

 

Hi Kevin,

 

= Thanks for your review. See my comments inline.

On 27 mei 2012, at 01:37, "Kevin J Ma" <kevin.ma@azukisystems.com> wrote:<= /span>

Hi Ray,

 

  I read through the updated draft and= had a number of comments ahead of

  the meeting.

 

  First, a general comment about manif= est files.  The document seems<= /span>

  to assume that manifest files will b= e distributed through the CDN.

  There are many services where this i= s not the case, often to prevent

  modification.  There is a large= focus in the document on how to modify

  manifest files, in some cases where = the manifest file itself is not

  necessarily relevant.  I believ= e there are ways to optimize HAS

  delivery without modifying manifest = files, and in imo, manifest

 manipulation falls under content adap= tation which the wg declared to

  be out of scope for the initial phas= e?

 

 

Sure, in some cases the CDN mig= ht not deliver the manifest, however in some other cases it will. I think r= uling out the latter is not what we want right?

 

In my opinion, considering mani= fest manipulation to be content adaptation is stretching the definition of = content adaption a little bit. I think Stef already presented enough exampl= es of why a CDN might want to modify the manifest file in a way that is not related to content adaptation at al= l.

 

 As I said in my other mai= l: wouldn't a simple  'do not ch= ange manifest'-boolean in the metadate interface solve your concerns in the= cases where a Content Provider does not want the manifest to be modified?

 

=  

  With respect section 2.2, I believe = I commented on this in the

  initial draft, but I still feel that= the relative vs absolute URL=

  discussion is rather misleading.&nbs= p; It seems to imply that:

    a) the HOST portion of a= relative URL cannot point to a RR, that

 

I'm not sure I understand you. = The idea behind a Relative URL is that it doesn't have a HOST portion. = ;

=  

    b) a RR must be accessed= through some web service like API, and that

 

The example presented is meant = as just that, an example. The important part here is in the HOST portion po= inting to a RR function. However, if you find this example to be confusing,= I can change it. 

=  

    c) absolute URLs can onl= y point to specific surrogates.

 

Absolute URLs without Redirecti= on point to surrogates, Absolute URLs with Redirection explicitely do not.&= nbsp;

=  

  While these are all valid examples o= f how to use URLs, they do not

  seem to be typical cases.  For = us, a typical service has a DNS

  address which points to a base direc= tory in one or more CDNs.  The<= /span>

  relative path from that base directo= ry is the same in all CDNs.  The

  hostname does not point to any one s= urrogate, and each CDN is still

  able to redirect requests as it sees= fit.

 

I agree that this is how some C= DNs might do it.  But I'm not sure how this affects 2.2. Section 2.2 i= s meant as a general overview into the different methods with which chunks = might be addressed in a manifest file. Some CDNs might use one option, some CDNs might use another. 

 

 

  With respect to sections 3.1 and 3.2= , while I agree that content<= /p>

  storage and acquisition optimization= is important, and that there=

  should be metadata which can describ= e the format of the content, I

  do think the CDN needs to be fully H= AS aware, nor do I think that=

  the CDN necessarily needs access to = the manifest file.  I also do

  not see a "significant" im= pact to the MI.  The metadata interface

  will have the ability to define meta= data that applies to a set of=

  content assets, per the META-10 requ= irement.  Ultimately, the CDN

  needs to be able to respond to conte= nt requests from the client,<= /p>

  even if that client got a manifest f= ile directly from the content=

  provider (not from the CDN) and is e= xpecting the content to be in=

  the format that was provided to the = CDN by the content provider.<= /p>

  How it got the content and how it st= ores it is out of scope?

 

  With respect to section 3.3, I think= that a third case is missing,

 where the content provider does not p= rovide the manifest file to the

  CDN (which can be a fairly common ca= se).

 

If you want, I can add this cas= e.

=  

 

  With respect to sections 3.3.2 and 3= .3.3, would not DNS-based

  redirection solve the issue by simpl= y directing manifest/chunk

  requests to the dCDN, rather than do= ing a manifest rewrite for every

  request (especially in the case of l= ive streaming where the manifest

  might be changing on every chunk)?&n= bsp; Also, presumably, the RR would<= /span>

  only rewrite URLs which were within = its own domain (i.e., not

  blackholing ad insertion segments, e= tc.)?

 

I think we both agree that the = CDNI interfaces should support both HTTP based and DNS based redirection, r= ight? So even if DNS based redirection would solve some issues regarding ma= nifest files, we still need an HTTP based solution.

=  

 

  With respect to section 3.5, the tim= e component of URL signing is=

  not mentioned until section 3.5.3.&n= bsp; Expiration of URL tokens, in

  general, is an issue with HAS. = Robust key management is an arguably

  more reliable approach to content ac= cess protection, though that<= /p>

  would seem to be fairly well out of = scope for CDNI.  The proposed

  solution in section 3.5.3, seems to = be managing session state?

  Depending on the complexity of the c= ookie, this could be troublesome

  if there is a failover and session s= tate is not properly synchronized?

  And in the case of live streami= ng, the manifest is going to be

  requested every time?  How is t= he state managed in that case?  Is

  the cookie less susceptible to repla= y attacks than the URL token?=

  Will the cookie work across all CDNs= ?  Moving on to section 3.5.4

  is even more concerning.  What = if the content is already encrypted?=

  How is authentication being handled = on the key server?  Who is

  responsible for auditing the securit= y of the solution?  Is this

  intended to provide DRM?  work = with existing DRM?  circumvent<= /span>

  existing DRM?  Does it only use= the DRM/encryption support of the

  delivery protocol?  or is the c= lient expected to implement an

  alternate protocol?  And how is= this synchronized across CDNs?

  More generally, are we attempting to= define security protocols for

  content delivery?  If so, I wou= ld like to see a more formal<= /p>

 definition of what those requirements= are?

 

 

I will defer this discussion to= other. 

=  

  With respect to section 3.6.2, it se= ems that we just want to be able

 to purge a set of content assets.&nbs= p; Would a URI prefix not be sufficient?

 

thanx.

 

--  Kevin J. Ma

 

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van
Sent: Friday, May 25, 2012 10:19 AM
To: cdni@ietf.org
Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft

 

Hi all,

 

I’ve= just uploaded a new version of draft-brandenburg-cdni-has.

 

You can fi= nd the document at: http://www.ietf.org/id/draft-brandenburg-cdni-has-01.= txt

 

The draft = is meant as an input document for the virtual meeting on Thursday to discus= s the impact of HTTP Adaptive Streaming on the CDNI Interfaces. In the draft a number of alternative solutions are presented for each area= where the use of HAS might touch with the CDNI Interfaces (e.g. content ac= quisition, content purge, request routing, logging and URL signing).

 

I’m = looking forward to your comments.

 

Have a nic= e weekend!

 

Ray van Br= andenburg

 

 

 

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van
Sent: woensdag 23 mei 2012 13:37
To: cdni@ietf.org
Subject: [CDNi] Status of Adaptive Streaming and CDNI draft

 

Hi all,

 =

Next Tuesday we have a planned interim = meeting for discussing the combination between HTTP Adaptive Streaming and = CDNI. One  of the expected inputs for this meeting is a follow-up draft to draft-brandenburg-cdni-has-00.

 =

We are currently working hard at finish= ing this draft, but as you might have seen, we have not yet uploaded a new = version. Currently we are at a stage where we have a first complete internal draft ready. However, Francois and I have agreed that we= rather spend some more time on it so that it fully covers all the areas of= the CDNI-HAS combination than upload an incomplete version right now. We a= re currently planning to upload the draft this Friday (25th of May) at the latest. I hope this gives you all enough time to read th= e draft before the meeting on Tuesday.

 =

Sorry for the delay.

 =

Ray

 =

 =

 =

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

--_000_FCC100FC8D6B034CB88CD8173B2DA1581C5D18BEEXCMBX03tsntnon_-- From zahariad@synelixis.com Tue May 29 01:09:12 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0982A21F8726 for ; Tue, 29 May 2012 01:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.746 X-Spam-Level: X-Spam-Status: No, score=0.746 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vO8sIwzOyVyN for ; Tue, 29 May 2012 01:09:04 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 7825521F8737 for ; Tue, 29 May 2012 01:09:03 -0700 (PDT) Received: (qmail 25450 invoked by uid 0); 29 May 2012 08:09:02 -0000 Received: from unknown (HELO box521.bluehost.com) (74.220.219.121) by oproxy7.bluehost.com with SMTP; 29 May 2012 08:09:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=synelixis.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From:Reply-To; bh=66HcMzCRUKDRnR6z4gOtkMx+HQGbVryN/QcSutPls70=; b=Q9WADcSRyJvqscSNnxYz3oaMDqqlDGsIHoayj7JlZyWkhSoPPYkfYvr4ki0jG8E3TchdcZA26/vUPb9fzkQY35pjnX0sotx2/wPxvXVHebPlUMuvLZL8ncNk2icRMeb5; Received: from ppp-94-66-21-176.home.otenet.gr ([94.66.21.176] helo=acer) by box521.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1SZHUB-0005wR-L8; Tue, 29 May 2012 02:09:02 -0600 From: "Theodore Zahariadis" To: "'Brandenburg, R. \(Ray\) van'" , "'Kevin J Ma'" References: , <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> <3C0B3042-9BAB-4A7A-A952-737C92666E75@tno.nl> <291CC3F9E50E7641901A54E85D0977C653267F4D48@MAILR002.mail.lan> In-Reply-To: Date: Tue, 29 May 2012 11:08:57 +0300 Organization: Synelixis Solutions Ltd Message-ID: <004e01cd3d72$4da816c0$e8f84440$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004F_01CD3D8B.72F54EC0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0414J5VzCVuofZTcKanwrNrKyoTABqTCnQAEHKv5AAS2tZDwAMh8BwACHwwsAAAIrhAA== Content-Language: el X-Identified-User: {712:box521.bluehost.com:synelixi:synelixis.com} {sentby:smtp auth 94.66.21.176 authed with zahariad@synelixis.com} Cc: cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zahariad@synelixis.com List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 08:09:12 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_004F_01CD3D8B.72F54EC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, Just some additional (simplified?) thoughts/considerations to the discussion.. I fully agree that changing the manifest files can give some flexibility and good (short term) results. Yet, it is like hacking the application! Just like changing on the fly an HTTP page that is being downloaded. And finally, affecting the provided service; thus it could complicate the end-to-end business model. I think that drastically changing the manifest files would make CDNi too application specific (embed too much application specific intelligence), while on the other hand be prone to updates of the manifest files' structure (updating the standard structure of the manifest files to support a new video format will cause changes to CDNi!). With respect to the security, I guess that content chunks (or some of the chunks) could be encrypted following the CCN approach. Thus, only the users that have the relevant decryption keys could actually use them. Best regards, Theodore From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: Tuesday, May 29, 2012 11:00 AM To: Kevin J Ma Cc: cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft Hi Kevin, Comments inline. Best regards, Ray From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] Sent: maandag 28 mei 2012 18:10 To: Brandenburg, R. (Ray) van Cc: cdni@ietf.org; Stef van der Ziel Subject: RE: Status of Adaptive Streaming and CDNI draft Hi Ray, > Sure, in some cases the CDN might not deliver the manifest, however in some other cases it will. I think ruling out the latter is not what we want right? I was more concerned that we may have tried to rule out the former. If we agree that there is a valid case where the CDN does not deliver the manifest, I think that it should be covered. RvB: My goal was not to rule out anything (although I agree with Stef's comment that having the manifest file be delivered by the Content Provider does present some problems). However, in the case where the manifest file is delivered by the Content Provider, wouldn't that force the manifest file to use Absolute URLs? > In my opinion, considering manifest manipulation to be content adaptation is stretching the definition of content adaption a little bit. I think Stef already presented enough examples of why a CDN might want to modify the manifest file in a way that is not related to content adaptation at all. I think it's a slippery slope. Forbidding changes to data is pretty clear cut. When you start making exceptions, it raises concerns? What is it going to break? Who might stretch the boundaries of what would be reasonable to modify? How does it fit into the different distribution paradigms? There's no question that a CDN might want to modify a manifest. The question is should the CDN be allowed to, and if it is, what are the limits to what it is allowed to modify? There must be defined limits. RvB: In the case of section 3.3.2, it is the uCDN who modifies the manifest. I would guess that the uCDN has (should have) a pretty good idea of what he discussed with the Content Provider about the possibilities of modifying the manifest. Do you agree that we don't have a problem in that case? As for section 3.3.3, where the dCDN does some of the manifest manipulation, I agree that we need to have some guidelines on what can en what can't be modified. > With respect to sections 3.3.2 and 3.3.3, would not DNS-based > redirection solve the issue by simply directing manifest/chunk > requests to the dCDN, rather than doing a manifest rewrite for every > request (especially in the case of live streaming where the manifest > might be changing on every chunk)? > > I think we both agree that the CDNI interfaces should support both HTTP based and DNS based redirection, right? So even if DNS based redirection would solve some issues regarding manifest files, we still need an HTTP based solution. Certainly, I agree that both DNS and HTTP redirects should be supported. I was trying to understand if there was "significant signalling overhead" in both cases? or if there are other factors involved, e.g., the redirection method. It might be helpful to expand the discussion of advantages and disadvantages for the different cases? RvB: I'm not familiar enough with DNS CDNs to answer your question. If you want, maybe you can write some text that details the DNS-redirection scenario better than the current draft? > a) the HOST portion of a relative URL cannot point to a RR, that > > I'm not sure I understand you. The idea behind a Relative URL is that it doesn't have a HOST portion. The manifest has a host from which it was retrieved. In your example, that host is a surrogate: http://surrogate.server.cdn.example.com/content_1/manifest.xml but that could have been a RR, that uses either DNS or HTTP redirects: http://rr.cdn.example.com/content_1/manifest.xml and that the relative paths could have been appended to the RR host, (as would be the case with HLS): http://rr.cdn.example.com/content_1/segments/segment1_1.ts RvB: That would only be the case if the manifest were delivered by the RR function, right? I agree with the brittleness comments in section 3.3.1. Perhaps some text to that affect in section 2 would clarify it for the linear reader? RvB: I can add this to the next version. though, the RR is going to need to be aware of the idiosyncrasies of each protocol and support all those brittle clients? > b) a RR must be accessed through some web service like API, and that > > The example presented is meant as just that, an example. The important part here is in the HOST portion pointing to a RR function. However, if you find this example to be confusing, I can change it. It was not clear to me if the path was significant. Perhaps a second example with just the host name difference would clarify that? http://rr.cdn.example.com/content_1/segments/segment1_1.ts RvB: Yes, that's a good idea. I will add this to the next version. thanx. -- Kevin J. Ma From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] Sent: Monday, May 28, 2012 5:38 AM To: Kevin J Ma Cc: cdni@ietf.org; Stef van der Ziel Subject: Re: Status of Adaptive Streaming and CDNI draft Hi Kevin, Thanks for your review. See my comments inline. On 27 mei 2012, at 01:37, "Kevin J Ma" wrote: Hi Ray, I read through the updated draft and had a number of comments ahead of the meeting. First, a general comment about manifest files. The document seems to assume that manifest files will be distributed through the CDN. There are many services where this is not the case, often to prevent modification. There is a large focus in the document on how to modify manifest files, in some cases where the manifest file itself is not necessarily relevant. I believe there are ways to optimize HAS delivery without modifying manifest files, and in imo, manifest manipulation falls under content adaptation which the wg declared to be out of scope for the initial phase? Sure, in some cases the CDN might not deliver the manifest, however in some other cases it will. I think ruling out the latter is not what we want right? In my opinion, considering manifest manipulation to be content adaptation is stretching the definition of content adaption a little bit. I think Stef already presented enough examples of why a CDN might want to modify the manifest file in a way that is not related to content adaptation at all. As I said in my other mail: wouldn't a simple 'do not change manifest'-boolean in the metadate interface solve your concerns in the cases where a Content Provider does not want the manifest to be modified? With respect section 2.2, I believe I commented on this in the initial draft, but I still feel that the relative vs absolute URL discussion is rather misleading. It seems to imply that: a) the HOST portion of a relative URL cannot point to a RR, that I'm not sure I understand you. The idea behind a Relative URL is that it doesn't have a HOST portion. b) a RR must be accessed through some web service like API, and that The example presented is meant as just that, an example. The important part here is in the HOST portion pointing to a RR function. However, if you find this example to be confusing, I can change it. c) absolute URLs can only point to specific surrogates. Absolute URLs without Redirection point to surrogates, Absolute URLs with Redirection explicitely do not. While these are all valid examples of how to use URLs, they do not seem to be typical cases. For us, a typical service has a DNS address which points to a base directory in one or more CDNs. The relative path from that base directory is the same in all CDNs. The hostname does not point to any one surrogate, and each CDN is still able to redirect requests as it sees fit. I agree that this is how some CDNs might do it. But I'm not sure how this affects 2.2. Section 2.2 is meant as a general overview into the different methods with which chunks might be addressed in a manifest file. Some CDNs might use one option, some CDNs might use another. With respect to sections 3.1 and 3.2, while I agree that content storage and acquisition optimization is important, and that there should be metadata which can describe the format of the content, I do think the CDN needs to be fully HAS aware, nor do I think that the CDN necessarily needs access to the manifest file. I also do not see a "significant" impact to the MI. The metadata interface will have the ability to define metadata that applies to a set of content assets, per the META-10 requirement. Ultimately, the CDN needs to be able to respond to content requests from the client, even if that client got a manifest file directly from the content provider (not from the CDN) and is expecting the content to be in the format that was provided to the CDN by the content provider. How it got the content and how it stores it is out of scope? With respect to section 3.3, I think that a third case is missing, where the content provider does not provide the manifest file to the CDN (which can be a fairly common case). If you want, I can add this case. With respect to sections 3.3.2 and 3.3.3, would not DNS-based redirection solve the issue by simply directing manifest/chunk requests to the dCDN, rather than doing a manifest rewrite for every request (especially in the case of live streaming where the manifest might be changing on every chunk)? Also, presumably, the RR would only rewrite URLs which were within its own domain (i.e., not blackholing ad insertion segments, etc.)? I think we both agree that the CDNI interfaces should support both HTTP based and DNS based redirection, right? So even if DNS based redirection would solve some issues regarding manifest files, we still need an HTTP based solution. With respect to section 3.5, the time component of URL signing is not mentioned until section 3.5.3. Expiration of URL tokens, in general, is an issue with HAS. Robust key management is an arguably more reliable approach to content access protection, though that would seem to be fairly well out of scope for CDNI. The proposed solution in section 3.5.3, seems to be managing session state? Depending on the complexity of the cookie, this could be troublesome if there is a failover and session state is not properly synchronized? And in the case of live streaming, the manifest is going to be requested every time? How is the state managed in that case? Is the cookie less susceptible to replay attacks than the URL token? Will the cookie work across all CDNs? Moving on to section 3.5.4 is even more concerning. What if the content is already encrypted? How is authentication being handled on the key server? Who is responsible for auditing the security of the solution? Is this intended to provide DRM? work with existing DRM? circumvent existing DRM? Does it only use the DRM/encryption support of the delivery protocol? or is the client expected to implement an alternate protocol? And how is this synchronized across CDNs? More generally, are we attempting to define security protocols for content delivery? If so, I would like to see a more formal definition of what those requirements are? I will defer this discussion to other. With respect to section 3.6.2, it seems that we just want to be able to purge a set of content assets. Would a URI prefix not be sufficient? thanx. -- Kevin J. Ma From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: Friday, May 25, 2012 10:19 AM To: cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft Hi all, I've just uploaded a new version of draft-brandenburg-cdni-has. You can find the document at: http://www.ietf.org/id/draft-brandenburg-cdni-has-01.txt The draft is meant as an input document for the virtual meeting on Thursday to discuss the impact of HTTP Adaptive Streaming on the CDNI Interfaces. In the draft a number of alternative solutions are presented for each area where the use of HAS might touch with the CDNI Interfaces (e.g. content acquisition, content purge, request routing, logging and URL signing). I'm looking forward to your comments. Have a nice weekend! Ray van Brandenburg From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: woensdag 23 mei 2012 13:37 To: cdni@ietf.org Subject: [CDNi] Status of Adaptive Streaming and CDNI draft Hi all, Next Tuesday we have a planned interim meeting for discussing the combination between HTTP Adaptive Streaming and CDNI. One of the expected inputs for this meeting is a follow-up draft to draft-brandenburg-cdni-has-00. We are currently working hard at finishing this draft, but as you might have seen, we have not yet uploaded a new version. Currently we are at a stage where we have a first complete internal draft ready. However, Francois and I have agreed that we rather spend some more time on it so that it fully covers all the areas of the CDNI-HAS combination than upload an incomplete version right now. We are currently planning to upload the draft this Friday (25th of May) at the latest. I hope this gives you all enough time to read the draft before the meeting on Tuesday. Sorry for the delay. Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer ------=_NextPart_000_004F_01CD3D8B.72F54EC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Just some additional (simplified?) thoughts/considerations to the = discussion….

 

I fully agree that changing the manifest files can give some = flexibility and good (short term) results.

Yet, it is like hacking the application! Just like changing on the = fly an HTTP page that is being downloaded.

And finally, affecting the provided service; thus it could complicate = the end-to-end business model.

 

I think that drastically changing the manifest files would make CDNi = too application specific (embed too much application specific = intelligence), while on the other hand be prone to updates of the =  manifest files’ structure (updating the standard structure = of the manifest files to support a new video format will cause changes = to CDNi!).

 

With respect to the security, I guess that content chunks (or some of = the chunks) could be encrypted following the CCN approach. Thus, only = the users that have  the relevant decryption keys could actually = use them.

 

Best regards,

Theodore

 

 

 

From:= = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Brandenburg, R. (Ray) van
Sent: Tuesday, May 29, 2012 = 11:00 AM
To: Kevin J Ma
Cc: = cdni@ietf.org
Subject: Re: [CDNi] Status of Adaptive Streaming = and CDNI draft

 

Hi Kevin,

 

Comments inline.

 

Best regards,

 

Ray

 

From:= Kevin J Ma = [mailto:kevin.ma@azukisystems.co= m]
Sent: maandag 28 mei 2012 18:10
To: = Brandenburg, R. (Ray) van
Cc: cdni@ietf.org; Stef van der = Ziel
Subject: RE: Status of Adaptive Streaming and CDNI = draft

 

Hi = Ray,

 

> = Sure, in some cases the CDN might not deliver the manifest, however in = some other cases it will. I think ruling out the latter is not what we = want right?

 

I was = more concerned that we may have tried to rule out the = former.

If we agree that = there is a valid case where the CDN does not = deliver

the manifest, I = think that it should be covered.

 

RvB: My goal was not to rule out anything (although I agree with = Stef’s comment that having the manifest file be delivered by the = Content Provider does present some problems). However, in the case where = the manifest file is delivered by the Content Provider, wouldn’t = that force the manifest file to use Absolute URLs? =

 

> = In my opinion, considering manifest manipulation to be content = adaptation is stretching the definition of content adaption a little = bit.  I think Stef already presented enough examples of why a CDN = might want to modify the manifest file in a way that is not related to = content adaptation at all.

 

I = think it's a slippery slope.  Forbidding changes to data is = pretty

clear cut.  = When you start making exceptions, it raises = concerns?

What is it going to = break?  Who might stretch the boundaries of = what

would be reasonable = to modify?  How does it fit into the = different

distribution = paradigms?

 

There's no question that a CDN might want to modify a = manifest.  The

question is should the CDN be allowed to, and if it is, what are = the

limits to what it = is allowed to modify?  There must be defined = limits.

 

RvB: In the case of section 3.3.2, it is the uCDN who modifies the = manifest. I would guess that the uCDN has (should have) a pretty good = idea of what he discussed with the Content Provider about the = possibilities of modifying the manifest. Do you agree that we = don’t have a problem in that case?

 

As for section 3.3.3, where the dCDN does some of the manifest = manipulation, I agree that we need to have some guidelines on what can = en what can’t be modified.

 

>  With respect to sections 3.3.2 and 3.3.3, would not = DNS-based

>  = redirection solve the issue by simply directing = manifest/chunk

>  requests to the dCDN, rather than doing a manifest = rewrite for every

>  request (especially in the case of live streaming where = the manifest

>  might be changing on every = chunk)?

> 

> I = think we both agree that the CDNI interfaces should support both HTTP = based and DNS based redirection, right? So even if DNS based redirection = would solve some issues regarding manifest files, we still need an HTTP = based solution.

 

Certainly, I agree that both DNS and HTTP redirects should = be

supported.  I = was trying to understand if there was = "significant

signalling overhead" in both cases?  or if there are = other factors

involved, e.g., the redirection method.  It might be helpful = to expand

the discussion of = advantages and disadvantages for the different = cases?

 

RvB: I’m not familiar enough with DNS CDNs to answer your = question. If you want, maybe you can write some text that details the = DNS-redirection scenario better than the current = draft?

 

> = a) the HOST portion of a relative URL cannot point to a RR, = that

> 

> = I'm not sure I understand you. The idea behind a Relative URL is that it = doesn't have a HOST portion.

 

The = manifest has a host from which it was retrieved.  In your = example,

that host is a = surrogate:

 

  = h= ttp://surrogate.server.cdn.example.com/content_1/manifest.xml

 

but = that could have been a RR, that uses either DNS or HTTP = redirects:

 

  = http://rr.cdn.e= xample.com/content_1/manifest.xml

 

and that the = relative paths could have been appended to the RR = host,

(as would be the = case with HLS):

 

  = http:= //rr.cdn.example.com/content_1/segments/segment1_1.ts

 

RvB: That would only be the case if the manifest were delivered by = the RR function, right?

 

I = agree with the brittleness comments in section 3.3.1.  Perhaps = some

text to that affect = in section 2 would clarify it for the linear = reader?

 

RvB: I can add this to the next version.

 

though, the RR is going to need to be aware of the idiosyncrasies = of

each protocol and = support all those brittle clients?

 

> b) a RR must = be accessed through some web service like API, and = that

> 

> = The example presented is meant as just that, an example. The important = part here is in the HOST portion pointing to a RR function. However, if = you find this example to be confusing, I can change it. =

 

It was = not clear to me if the path was significant.  Perhaps a = second

example with just = the host name difference would clarify that?

 

  = http:= //rr.cdn.example.com/content_1/segments/segment1_1.ts

 

RvB: Yes, that’s a good idea. I will add this to the next = version.

 

 

thanx.

 

--  Kevin J. Ma

 

From:= = Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.n= l]
Sent: Monday, May 28, 2012 5:38 AM
To: Kevin = J Ma
Cc: cdni@ietf.org; = Stef van der Ziel
Subject: Re: Status of Adaptive Streaming = and CDNI draft

 

Hi = Kevin,

 

Thanks for your = review. See my comments inline.

On 27 mei 2012, at 01:37, = "Kevin J Ma" <kevin.ma@azukisystems.com&g= t; wrote:

Hi Ray,

 

  I read = through the updated draft and had a number of comments ahead = of

  the = meeting.

 

  = First, a general comment about manifest files.  The document = seems

  to assume = that manifest files will be distributed through the CDN.

  = There are many services where this is not the case, often to = prevent

  = modification.  There is a large focus in the document on how to = modify

  manifest = files, in some cases where the manifest file itself is not

  = necessarily relevant.  I believe there are ways to optimize = HAS

  delivery = without modifying manifest files, and in imo, manifest

 manipulation falls under content adaptation which the wg = declared to

  be out of = scope for the initial phase?

 

 

Sure, in some cases the CDN might = not deliver the manifest, however in some other cases it will. I think = ruling out the latter is not what we want = right?

 

In my opinion, considering manifest = manipulation to be content adaptation is stretching the definition of = content adaption a little bit. I think Stef already presented enough = examples of why a CDN might want to modify the manifest file in a way = that is not related to content adaptation at = all.

 

 As I said in my other mail: = wouldn't a simple  'do not = change manifest'-boolean in the metadate interface solve your concerns = in the cases where a Content Provider does not want the manifest to be = modified?

 

 

  = With respect section 2.2, I believe I commented on this in = the

  initial = draft, but I still feel that the relative vs absolute URL

  = discussion is rather misleading.  It seems to imply = that:

    = a) the HOST portion of a relative URL cannot point to a RR, = that

 

I'm not sure I understand you. The = idea behind a Relative URL is that it doesn't have a HOST = portion. 

 

    b) a RR must be accessed through some web = service like API, and that

 

The example presented is meant as = just that, an example. The important part here is in the HOST portion = pointing to a RR function. However, if you find this example to be = confusing, I can change it. 

 

    c) absolute URLs can only point to specific = surrogates.

 

Absolute URLs without Redirection = point to surrogates, Absolute URLs with Redirection explicitely do = not. 

 

  = While these are all valid examples of how to use URLs, they do = not

  seem to be = typical cases.  For us, a typical service has a DNS

  = address which points to a base directory in one or more CDNs.  = The

  relative = path from that base directory is the same in all CDNs.  = The

  hostname = does not point to any one surrogate, and each CDN is still

  = able to redirect requests as it sees fit.

 

I agree that this is how some CDNs = might do it.  But I'm not sure how this affects 2.2. Section 2.2 is = meant as a general overview into the different methods with which chunks = might be addressed in a manifest file. Some CDNs might use one option, = some CDNs might use another. 

 

 

  = With respect to sections 3.1 and 3.2, while I agree that = content

  storage and = acquisition optimization is important, and that there

  = should be metadata which can describe the format of the content, = I

  do think the = CDN needs to be fully HAS aware, nor do I think that

  = the CDN necessarily needs access to the manifest file.  I also = do

  not see a = "significant" impact to the MI.  The metadata = interface

  will have = the ability to define metadata that applies to a set of

  = content assets, per the META-10 requirement.  Ultimately, the = CDN

  needs to be = able to respond to content requests from the client,

  = even if that client got a manifest file directly from the = content

  provider = (not from the CDN) and is expecting the content to be in

  = the format that was provided to the CDN by the content = provider.

  How it got = the content and how it stores it is out of scope?

 

  = With respect to section 3.3, I think that a third case is = missing,

 where the = content provider does not provide the manifest file to the

  = CDN (which can be a fairly common case).

 

If you want, I can add this = case.

 

 

  With respect = to sections 3.3.2 and 3.3.3, would not DNS-based

  = redirection solve the issue by simply directing = manifest/chunk

  requests to = the dCDN, rather than doing a manifest rewrite for every

  = request (especially in the case of live streaming where the = manifest

  might be = changing on every chunk)?  Also, presumably, the RR = would

  only rewrite = URLs which were within its own domain (i.e., not

  = blackholing ad insertion segments, etc.)?

 

I think we both agree that the CDNI = interfaces should support both HTTP based and DNS based redirection, = right? So even if DNS based redirection would solve some issues = regarding manifest files, we still need an HTTP based = solution.

 

 

  With respect = to section 3.5, the time component of URL signing is

  = not mentioned until section 3.5.3.  Expiration of URL tokens, = in

  general, is = an issue with HAS.  Robust key management is an = arguably

  more = reliable approach to content access protection, though that

  = would seem to be fairly well out of scope for CDNI.  The = proposed

  solution in = section 3.5.3, seems to be managing session state?

  = Depending on the complexity of the cookie, this could be = troublesome

  if there is = a failover and session state is not properly synchronized?

  And in the case of live streaming, the manifest is = going to be

  requested = every time?  How is the state managed in that case?  = Is

  the cookie = less susceptible to replay attacks than the URL token?

  = Will the cookie work across all CDNs?  Moving on to section = 3.5.4

  is even more = concerning.  What if the content is already encrypted?

  = How is authentication being handled on the key server?  Who = is

  responsible = for auditing the security of the solution?  Is this

  = intended to provide DRM?  work with existing DRM?  = circumvent

  existing = DRM?  Does it only use the DRM/encryption support of = the

  delivery = protocol?  or is the client expected to implement an

  = alternate protocol?  And how is this synchronized across = CDNs?

  More = generally, are we attempting to define security protocols = for

  content = delivery?  If so, I would like to see a more formal

 definition of what those requirements are?

 

 

I will defer this discussion to = other. 

 

  = With respect to section 3.6.2, it seems that we just want to be = able

 to purge a = set of content assets.  Would a URI prefix not be = sufficient?

 

thanx.

 

--  Kevin J. Ma

 

From:= cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] = On Behalf Of Brandenburg, R. (Ray) van
Sent: Friday, = May 25, 2012 10:19 AM
To: cdni@ietf.org
Subject: Re: = [CDNi] Status of Adaptive Streaming and CDNI draft

 

Hi all,

 

I’ve just uploaded a new version of = draft-brandenburg-cdni-has.

 

You can find the document at: http://www.ietf.org/id/draft-brandenburg-cdni-has-01.txt

 

The draft is meant as an input document for the virtual meeting on = Thursday to discuss the impact of HTTP Adaptive Streaming on the CDNI = Interfaces. In the draft a number of alternative solutions are presented = for each area where the use of HAS might touch with the CDNI Interfaces = (e.g. content acquisition, content purge, request routing, logging and = URL signing).

 

I’m looking forward to your comments.

 

Have a nice weekend!

 

Ray van Brandenburg

 

 

 

From:= cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] = On Behalf Of Brandenburg, R. (Ray) van
Sent: woensdag = 23 mei 2012 13:37
To: cdni@ietf.org
Subject: = [CDNi] Status of Adaptive Streaming and CDNI draft

 

Hi = all,

 

Next = Tuesday we have a planned interim meeting for discussing the combination = between HTTP Adaptive Streaming and CDNI. One  of the expected = inputs for this meeting is a follow-up draft to = draft-brandenburg-cdni-has-00.

 

We are = currently working hard at finishing this draft, but as you might have = seen, we have not yet uploaded a new version. Currently we are at a = stage where we have a first complete internal draft ready. However, = Francois and I have agreed that we rather spend some more time on it so = that it fully covers all the areas of the CDNI-HAS combination than = upload an incomplete version right now. We are currently planning to = upload the draft this Friday (25th of May) = at the latest. I hope this gives you all enough time to read the draft = before the meeting on Tuesday.

 

Sorry for = the delay.

 

Ray<= span lang=3DEN-US>

 

 

 

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

------=_NextPart_000_004F_01CD3D8B.72F54EC0-- From flefauch@cisco.com Tue May 29 02:07:12 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B366621F8718 for ; Tue, 29 May 2012 02:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5OzFlv648VM for ; Tue, 29 May 2012 02:07:11 -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 A069121F870B for ; Tue, 29 May 2012 02:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=5390; q=dns/txt; s=iport; t=1338282430; x=1339492030; h=from:mime-version:subject:date:in-reply-to:to:references: message-id; bh=YLmP6HRMwCAUMjmwYUkMvJU+MdZGd8vwervxLVBFXyI=; b=ClW7AgQBo6LlSJ2H6ND68dPRxPxV3ZFt7K4nJ+g1/4CXz6cFwi59+zKP UFTYDeeZxLC5MVmcFn0Pl4gFybLhoLWBWzGiYzOKrqcXo/KKng063v+IJ P2GUPfOwA+lcheqfWnJhTNZJWbbcJwMpUuQoLzMxDi8AWc8R7n9B+I2Uf M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANiQxE+Q/khL/2dsb2JhbABEtWCBB4IXAQEBAgEBAQEBDwFbEAtRJzAZCRmHZAULmHKfS4sDghuCNmADlReODIFlgmI X-IronPort-AV: E=Sophos;i="4.75,677,1330905600"; d="scan'208,217";a="138718745" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 29 May 2012 09:07: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 q4T97113028118 for ; Tue, 29 May 2012 09:07:01 GMT From: Francois Le Faucheur Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_07ABE1B7-E27F-45C0-9B5F-A7035A70FCBA" Date: Tue, 29 May 2012 11:07:02 +0200 In-Reply-To: To: cdni@ietf.org References: <5339DEEB-766C-4523-B352-52BC07FA24F3@cisco.com> Message-Id: <31BDC4E6-A560-42CB-804F-A803CEF3D126@cisco.com> X-Mailer: Apple Mail (2.1278) Subject: [CDNi] Agenda & Slides for CDNI "Extended Design Team Meetings" on May 29 - "HTTP 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: Tue, 29 May 2012 09:07:12 -0000 --Apple-Mail=_07ABE1B7-E27F-45C0-9B5F-A7035A70FCBA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks, 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 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 Slides for the other discussions will be made available gradually. Cheers Francois & Rich On 25 May 2012, at 08:12, Francois Le Faucheur wrote: > 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 --Apple-Mail=_07ABE1B7-E27F-45C0-9B5F-A7035A70FCBA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://www.ietf.org/proceedings/interim/2012= /05/29/cdni/agenda/agenda-interim-2012-cdni-1.html

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/ma= ilman/listinfo/cdni


= --Apple-Mail=_07ABE1B7-E27F-45C0-9B5F-A7035A70FCBA-- From swainner@cisco.com Tue May 29 04:52: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 C9ABC11E8085 for ; Tue, 29 May 2012 04:52:30 -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 0QlPBKWsM0CX for ; Tue, 29 May 2012 04:52:27 -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 E7ACB21F881B for ; Tue, 29 May 2012 04:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=107718; q=dns/txt; s=iport; t=1338292338; x=1339501938; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=UfRpu75miM7g3iGRKCpqYYbK5hPQjdQaSeGRka+JqcM=; b=lVa/i2Hsk6irkL2n8tbL8q4nXdZCtnjHN4UGJTsXUKT2hGspxn87VhAl 6BV6rajmU3QGai4dxsokFOgl+TxwiB5REMfRrVsrvTHGj96FKGNeS+/oh Wfp9DTCvXpPG/+clFC8uVGOE6Cr7s4N3zBzo0Q6eTotPSBkU5JXkPNySS g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFABS4xE+tJV2a/2dsb2JhbABEgkWISKpOgQeCFwEBAQQBAQEPAQcBDAYcJQYEDwILEQEDAQEBCQQICgEBBgcJAwIBAgEEER8DBggTBgIBAQUSB4VvgXoLmGafUwSKfxoGgW+DIgOVF44MgWWCfIE7CA X-IronPort-AV: E=Sophos;i="4.75,677,1330905600"; d="scan'208,217";a="87466303" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 29 May 2012 11:52:16 +0000 Received: from rtp-swainner-8917.cisco.com (rtp-swainner-8917.cisco.com [10.116.109.200]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q4TBqFWe030689 for ; Tue, 29 May 2012 11:52:15 GMT Message-ID: <4FC4B86F.1040706@cisco.com> Date: Tue, 29 May 2012 07:52:15 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: cdni@ietf.org References: <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan><66050772-394A-4A28-92FE-6A0581D5A533@jet-stream.nl><291CC3F9E50E7641901A54E85D0977C653267F4D1F@MAILR002.mail.lan> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050202090002080104010109" Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI 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, 29 May 2012 11:52:30 -0000 This is a multi-part message in MIME format. --------------050202090002080104010109 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 5/29/12 3:06 AM, Stef van der Ziel wrote: > Hi Kevin, > > Op 27 mei 2012 om 18:00 heeft Kevin J Ma > het volgende geschreven: > >> Hi Stef, >> >> I was not arguing that a CDN would not prefer to have the manifest. >> >> I was more arguing that content providers may not trust CDNs with >> >> the manifest generation/modification. Securing content, preventing >> >> unauthorized access, and preventing piracy requires much more than >> >> simple auth tokens. DRM is explicitly listed as out-of-scope in >> >> the charter, so as I said, if the intent is to define a security >> >> protocol, then I would like to see more requirements. If, however, >> >> I have misunderstood, and section 3.5.4 is describing an existing >> >> feature that is widely supported across CDNs today, that just needs >> >> CDNI support, then I suppose that would be different. >> > > In general CDNs must offer the ability to secure access to content. > Access restriction and DRM can complement each other and don't > necessarily overlap. > Many CDNs use tokens between portals and request routers and between > request routers and delivery nodes to prevent unauthorized access to > content. > > However being a stateless and segmented technology, HAS introduces a > new massive gap in the security by having manifest files in between > the request router and the actual content. So it is a responsibility > for the CDN to close this gap. > > I know that many platforms who call themselves CDNs are nothing more > than a managed caching environment. So you can pull anything through. > So coming from this angle it makes sense to assume that you can simply > distribute manifests besides the CDN. I'm trying to educate here that > this vision is too simple and that we foresee that content providers > will demand from CDNs that their content is protected by actively > managing the manifests. > > Doing nothing about manifest control, these passive CDNs have a wide > open security problem. I see many possibilities for people to > reconstruct manifests and abuse federated CDNs by directly pulling off > objects from caches. > > If these CDNs would allow direct access to segments, that would be a > blocking issue for other CDNs to actually federate with these CDNs. > Because it breaks the level of security they are offering to their > content publishing customers. I think we need to address the security in several different context: a) CSP -> uCDN RR b) uCDN -> dCDN RR c) dCDN RR -> dCDN Delivery Node If I understand your 'deep-linking' comment, you're referring to hand-off (c) above where some external entity obtains the URL that the dCDN RR would have provided. I'm thinking the CDN-I may be focused specifically on the hand-off (b) above. While we define a security mechanism for (b), we need to understand there are various methods for (c) above and they should not interfere with one another. If we break the security problem in these three transactions, we can still allow the dCDN to choose a method of securing the HAS transactions between the client and dCDN using a method that does not override the security method using between the uCDN and dCDN. > > >> As for asset management, I agree the CDN needs to know what files go >> >> together, but I do not agree that a CDN should be allowed to modify >> >> a manifest file any way it wants, or generate any manifest it wants >> >> and present that to the end user. Manifest files may contain other >> >> information besides segment file locations, e.g., DRM info, targeted >> >> ad insertions, subscription-based customizations, etc., which the >> >> content provider may not trust the CDN with. I would like to know >> >> where the boundaries are of what the CDN may modify? Much of this >> >> requires subscriber-awareness. How subscriber-aware are we assuming >> >> the CDN to be? One might argue that the CDN should perform all these >> >> functions and be a one-stop intelligent content delivery shop, but >> >> that seems improbable in the short-run? >> > > The real problem is that manifest files are quite open, not well > designed and immature so everyone in the value chain thinks they can > just use and abuse the manifest file for whatever purpose they have. > > Content publishers may want to dynamically adjust the manifest files > to actually change the content on a per request basis. > > At the same time CDNs must be able to adjust the manifest files to do > session tracking, access protection, management, etc. Without actually > changing the content by the way! > > These requirements can't be supported at the same time today. In my > view the core role of a manifest is to instruct the client how to > reconstruct segments into a fluent stream. However there are secondary > roles which are in conflict: content adaptation (ad insertion for > insance) and CDN distribution management, asset management, session > management, access management. > > The solution would be to wait for manifest files to become more > mature. I prefer to have manifest files roles to be split into content > management manifests and distribution management manifests. I like this model, but as you say, the Manifest/MPD needs a BaseURL that is a Relative URL such that the client will refer back to the Delivery Node for each segment request. > > Anyway it is too easy to assume that CDNs don't change manifests so > they don't need to serve out manifests. They do, so CDNi should be > aware of it. It is not a matter of being an advanced feature, it is > how many CDNs simply work from a core philosophy around HAS. > > I'm not asking CDNi to make serving out manifests mandatory, because > that would be a similar mistake the other way around, what i propose > is that CDNi should be aware of which CDNs cannot control manifests, > and which CDNs make manifest control mandatory. Is this a binary option? Manifest may be modified / may not be modified? > > >> Perhaps a more general question: Are we talking about making CDNs >> >> HAS aware, or making CDNI HAS aware? It feels more like the former, >> >> with the latter being an after-thought, and it is not clear to me >> >> how the former fits into the charter? Going straight from the uCDN >> >> routing every segment, to the uCDN supporting modification of a half >> >> dozen manifest formats feels disingenuous. Is there no BCP for how >> >> to configure DNS-RR to take the load off the uCDN RR, or a simple >> >> set of metadata to describe the source content structure which can >> >> facilitate more efficient content acquisition? >> > > I think you hit a weak spot in CDNi. Some CDNs use passive DNS rr and > others use active HTTP rr. Some support both. Some also use redirect > instructional files which IMHO is the best technology since it is > active and guarantees much higher uptime and performance. If you want > I can share more details about this because it would be a great > feature for CDNi. > > Youare right that active rr CDNs may not want to federate to DNS based > CDNs because their service level would drop below the SLA they offered > to their customer. And you are right that some scenarios may simply > not work, for instance when a uCDN manifest based anti-deeplinking and > a dCDN hasn't implemented this. Some CDNs don't care about manifests, > others need them to do their job. It isn't guaranteed that CDNs are > always interchangeable. Sounds like a capability exchange that the dCDN must provide some means of manifest management in order to comply with the uCDN's SLA requirements. > > So that is why it is so important that CDNi doesn't rule out specific > technology visions, architecture designs or technology choices. It > should support these different flavors and definitely not rule out > specific ones. And this is a typical example of information that > should be shared between CDNs via a capabilities API, so CDNs can > decide if they want to federate with other CDNs that cannot support > the features they require. > > Best Stef > > >> thanx. >> >> -- Kevin J. Ma >> >> *From:*Stef van der Ziel [mailto:stef@jet-stream.nl] >> *Sent:* Sunday, May 27, 2012 9:03 AM >> *To:* Kevin J Ma >> *Cc:* Brandenburg, R. (Ray) van; cdni@ietf.org >> *Subject:* Re: [CDNi] Status of Adaptive Streaming and CDNI draft >> >> Hi Kevin, >> >> Actually, many CDNs prefer to serve out both the segments and the >> manifest files. >> >> Sure, dumb caching/DNS based CDNs can be used to deliver segments and >> they wouldn't care about segments. They will just pump out the >> delivered objects. But intelligent CDNs that are actually usable for >> commercial/secure and manageable HAS, need the manifests. >> >> IMHO the role of a manifest file should not be confused with the role >> of a referrer file. >> >> A manifest is to represent the entire content, not just to the client >> but in the entire chain of encoding, protection, CDN and clients. >> >> A referrer file is the proper way to point to the (logical) content >> from any remote location. >> >> We hardly ever see manifest files to be distributed outside of the >> CDN in reality. It is not a fairly common scenario and should not >> be. In more automated environments, it can actually be the CDN that >> creates the manifest. >> >> The assumption that manifest files should or can be distributed >> offline or outside the CDN is mostly wrong. The assumption that you >> can point from a manifest to a CDN for the segments won't work since >> a proper CDN would (should) block direct access to segments to >> prevent deep linking. But we understand why people make these >> assumptions, we've heard other statements from HAS enthusiasts that >> don't make sense in the real world. >> >> Serving out the manifests alongside the segments from the same CDN >> account is done for multiple reasons, which do not at all adapt the >> content: >> >> - Logical asset recognition (parsing the manifests so the CDN >> understands that the segments are part of a logical entity) >> >> - Logical asset management (processing, copying, managing manifests >> and subsequent segments as if they are one asset) >> >> - Logical asset reporting (reporting manifests and subsequent >> segments via web interfaces and APIs as if they are one asset) >> >> - Request routing control (CDNs only produce URLs for manifest files >> and will not accept requests for segments to prevent unnecessary >> request routing overload by having to request route every individual >> segment request) >> >> - Access control (CDNs will not allow direct access to segments but >> only via the manifest file to prevent deep-linking, you don't want >> any third party to publish a manifest file on an unlicensed portal >> and then point users to the segments on the CDN without any access >> control) >> >> - Session control (http streaming is stateless and that is quite >> dramatic for CDNs because you lose control over the session and over >> session logging) >> >> There are additional reasons for CDNs to be able to adapt the >> manifest files but do so without changing the actual content: >> >> - For instance, they could dynamically insert base URLs to point >> users to a group of servers to improve the availability. >> >> - Or they could dynamically insert tokens into the manifest to >> control access to segments. >> >> - Or they could dynamically insert session keys to be able to track a >> unique user session over multiple federated CDNs. >> >> - Or they could dynamically remove higher or lower bit rates to >> better control the actual QoE on a per request basis. >> >> Concluding: >> >> To a CDN, the segments aren't actually that interesting. They are >> just pieces of useless raw data that needs to be protected, managed >> and served. >> >> For a CDN, the manifest represents the content and is a critical >> component so they need to be able to parse, alter and serve them. >> >> I think the above by itself describes some interesting challenges. >> Just one example: how are CDNs going to guarantee anti-deeplinking to >> segments in a federated constellation where multiple nodes of >> multiple CDNs and request routers need to be aware of each others >> sessions and tokens, etc? >> >> My 2 cents. >> >> Kind regards, Stef van der Ziel >> >> -- >> >> Owner Jet-Stream | StreamZilla >> >> GMT+1 Office: +31 50 5261820 | Mobile: +31 6 23406348 >> >> www.jet-stream.com | >> www.streamzillacdn.com >> >> this communication is confidential >> >> >> >> On 27 mei 2012, at 01:37, Kevin J Ma wrote: >> >> >> >> Hi Ray, >> >> I read through the updated draft and had a number of comments ahead of >> >> the meeting. >> >> First, a general comment about manifest files. The document seems >> >> to assume that manifest files will be distributed through the CDN. >> >> There are many services where this is not the case, often to prevent >> >> modification. There is a large focus in the document on how to modify >> >> manifest files, in some cases where the manifest file itself is not >> >> necessarily relevant. I believe there are ways to optimize HAS >> >> delivery without modifying manifest files, and in imo, manifest >> >> manipulation falls under content adaptation which the wg declared to >> >> be out of scope for the initial phase? >> >> With respect section 2.2, I believe I commented on this in the >> >> initial draft, but I still feel that the relative vs absolute URL >> >> discussion is rather misleading. It seems to imply that: >> >> a) the HOST portion of a relative URL cannot point to a RR, that >> >> b) a RR must be accessed through some web service like API, and that >> >> c) absolute URLs can only point to specific surrogates. >> >> While these are all valid examples of how to use URLs, they do not >> >> seem to be typical cases. For us, a typical service has a DNS >> >> address which points to a base directory in one or more CDNs. The >> >> relative path from that base directory is the same in all CDNs. The >> >> hostname does not point to any one surrogate, and each CDN is still >> >> able to redirect requests as it sees fit. >> >> With respect to sections 3.1 and 3.2, while I agree that content >> >> storage and acquisition optimization is important, and that there >> >> should be metadata which can describe the format of the content, I >> >> do think the CDN needs to be fully HAS aware, nor do I think that >> >> the CDN necessarily needs access to the manifest file. I also do >> >> not see a "significant" impact to the MI. The metadata interface >> >> will have the ability to define metadata that applies to a set of >> >> content assets, per the META-10 requirement. Ultimately, the CDN >> >> needs to be able to respond to content requests from the client, >> >> even if that client got a manifest file directly from the content >> >> provider (not from the CDN) and is expecting the content to be in >> >> the format that was provided to the CDN by the content provider. >> >> How it got the content and how it stores it is out of scope? >> >> With respect to section 3.3, I think that a third case is missing, >> >> where the content provider does not provide the manifest file to the >> >> CDN (which can be a fairly common case). >> >> With respect to sections 3.3.2 and 3.3.3, would not DNS-based >> >> redirection solve the issue by simply directing manifest/chunk >> >> requests to the dCDN, rather than doing a manifest rewrite for every >> >> request (especially in the case of live streaming where the manifest >> >> might be changing on every chunk)? Also, presumably, the RR would >> >> only rewrite URLs which were within its own domain (i.e., not >> >> blackholing ad insertion segments, etc.)? >> >> With respect to section 3.5, the time component of URL signing is >> >> not mentioned until section 3.5.3. Expiration of URL tokens, in >> >> general, is an issue with HAS. Robust key management is an arguably >> >> more reliable approach to content access protection, though that >> >> would seem to be fairly well out of scope for CDNI. The proposed >> >> solution in section 3.5.3, seems to be managing session state? >> >> Depending on the complexity of the cookie, this could be troublesome >> >> if there is a failover and session state is not properly synchronized? >> >> And in the case of live streaming, the manifest is going to be >> >> requested every time? How is the state managed in that case? Is >> >> the cookie less susceptible to replay attacks than the URL token? >> >> Will the cookie work across all CDNs? Moving on to section 3.5.4 >> >> is even more concerning. What if the content is already encrypted? >> >> How is authentication being handled on the key server? Who is >> >> responsible for auditing the security of the solution? Is this >> >> intended to provide DRM? work with existing DRM? circumvent >> >> existing DRM? Does it only use the DRM/encryption support of the >> >> delivery protocol? or is the client expected to implement an >> >> alternate protocol? And how is this synchronized across CDNs? >> >> More generally, are we attempting to define security protocols for >> >> content delivery? If so, I would like to see a more formal >> >> definition of what those requirements are? >> >> With respect to section 3.6.2, it seems that we just want to be able >> >> to purge a set of content assets. Would a URI prefix not be sufficient? >> >> thanx. >> >> -- Kevin J. Ma >> >> *From:*cdni-bounces@ietf.org >> [mailto:cdni-bounces@ietf.org]*On >> Behalf Of*Brandenburg, R. (Ray) van >> *Sent:*Friday, May 25, 2012 10:19 AM >> *To:*cdni@ietf.org >> *Subject:*Re: [CDNi] Status of Adaptive Streaming and CDNI draft >> >> Hi all, >> >> I’ve just uploaded a new version of draft-brandenburg-cdni-has. >> >> You can find the document >> at:http://www.ietf.org/id/draft-brandenburg-cdni-has-01.txt >> >> The draft is meant as an input document for the virtual meeting on >> Thursday to discuss the impact of HTTP Adaptive Streaming on the CDNI >> Interfaces. In the draft a number of alternative solutions are >> presented for each area where the use of HAS might touch with the >> CDNI Interfaces (e.g. content acquisition, content purge, request >> routing, logging and URL signing). >> >> I’m looking forward to your comments. >> >> Have a nice weekend! >> >> Ray van Brandenburg >> >> *From:*cdni-bounces@ietf.org >> [mailto:cdni-bounces@ietf.org]*On >> Behalf Of*Brandenburg, R. (Ray) van >> *Sent:*woensdag 23 mei 2012 13:37 >> *To:*cdni@ietf.org >> *Subject:*[CDNi] Status of Adaptive Streaming and CDNI draft >> >> Hi all, >> >> Next Tuesday we have a planned interim meeting for discussing the >> combination between HTTP Adaptive Streaming and CDNI. One of the >> expected inputs for this meeting is a follow-up draft to >> draft-brandenburg-cdni-has-00. >> >> We are currently working hard at finishing this draft, but as you >> might have seen, we have not yet uploaded a new version. Currently we >> are at a stage where we have a first complete internal draft ready. >> However, Francois and I have agreed that we rather spend some more >> time on it so that it fully covers all the areas of the CDNI-HAS >> combination than upload an incomplete version right now. We are >> currently planning to upload the draft this Friday (25^th of May) at >> the latest. I hope this gives you all enough time to read the draft >> before the meeting on Tuesday. >> >> Sorry for the delay. >> >> Ray >> >> This e-mail and its contents are subject to the DISCLAIMER >> athttp://www.tno.nl/emaildisclaimer >> >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >> --------------050202090002080104010109 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 5/29/12 3:06 AM, Stef van der Ziel wrote:
Hi Kevin,

Op 27 mei 2012 om 18:00 heeft Kevin J Ma <kevin.ma@azukisystems.com> het volgende geschreven:

Hi Stef,

 

  I was not arguing that a CDN would not prefer to have the manifest.

  I was more arguing that content providers may not trust CDNs with

  the manifest generation/modification.  Securing content, preventing

  unauthorized access, and preventing piracy requires much more than

  simple auth tokens.  DRM is explicitly listed as out-of-scope in

  the charter, so as I said, if the intent is to define a security

  protocol, then I would like to see more requirements.  If, however,

  I have misunderstood, and section 3.5.4 is describing an existing

  feature that is widely supported across CDNs today, that just needs

  CDNI support, then I suppose that would be different.

 


In general CDNs must offer the ability to secure access to content. 
Access restriction and DRM can complement each other and don't necessarily overlap.
Many CDNs use tokens between portals and request routers and between request routers and delivery nodes to prevent unauthorized access to content.

However being a stateless and segmented technology, HAS introduces a new massive gap in the security by having manifest files in between the request router and the actual content. So it is a responsibility for the CDN to close this gap. 

I know that many platforms who call themselves CDNs are nothing more than a managed caching environment. So you can pull anything through. So coming from this angle it makes sense to assume that you can simply distribute manifests besides the CDN. I'm trying to educate here that this vision is too simple and that we foresee that content providers will demand from CDNs that their content is protected by actively managing the manifests. 

Doing nothing about manifest control, these passive CDNs have a wide open security problem. I see many possibilities for people to reconstruct manifests and abuse federated CDNs by directly pulling off objects from caches. 

If these CDNs would allow direct access to segments, that would be a blocking issue for other CDNs to actually federate with these CDNs. Because it breaks the level of security they are offering to their content publishing customers.
I think we need to address the security in several different context:

a) CSP -> uCDN RR
b) uCDN -> dCDN RR
c) dCDN RR -> dCDN Delivery Node

If I understand your 'deep-linking' comment, you're referring to hand-off (c) above where some external entity obtains the URL that the dCDN RR would have provided.  I'm thinking the CDN-I may be focused specifically on the hand-off (b) above.  While we define a security mechanism for (b), we need to understand there are various methods for (c) above and they should not interfere with one another.

If we break the security problem in these three transactions, we can still allow the dCDN to choose a method of securing the HAS transactions between the client and dCDN using a method that does not override the security method using between the uCDN and dCDN.


  As for asset management, I agree the CDN needs to know what files go

  together, but I do not agree that a CDN should be allowed to modify

  a manifest file any way it wants, or generate any manifest it wants

  and present that to the end user.  Manifest files may contain other

 information besides segment file locations, e.g., DRM info, targeted

  ad insertions, subscription-based customizations, etc., which the

  content provider may not trust the CDN with.  I would like to know

  where the boundaries are of what the CDN may modify?  Much of this

  requires subscriber-awareness.  How subscriber-aware are we assuming

 the CDN to be?  One might argue that the CDN should perform all these

 functions and be a one-stop intelligent content delivery shop, but

 that seems improbable in the short-run?


The real problem is that manifest files are quite open, not well designed and immature so everyone in the value chain thinks they can just use and abuse the manifest file for whatever purpose they have. 

Content publishers may want to dynamically adjust the manifest files to actually change the content on a per request basis. 

At the same time CDNs must be able to adjust the manifest files to do session tracking, access protection, management, etc. Without actually changing the content by the way! 

These requirements can't be supported at the same time today. In my view the core role of a manifest is to instruct the client how to reconstruct segments into a fluent stream. However there are secondary roles which are in conflict: content adaptation (ad insertion for insance) and CDN distribution management, asset management, session management, access management.

The solution would be to wait for manifest files to become more mature. I prefer to have manifest files roles to be split into content management manifests and distribution management manifests.
I like this model, but as you say, the Manifest/MPD needs a BaseURL that is a Relative URL such that the client will refer back to the Delivery Node for each segment request. 

Anyway it is too easy to assume that CDNs don't change manifests so they don't need to serve out manifests. They do, so CDNi should be aware of it. It is not a matter of being an advanced feature, it is how many CDNs simply work from a core philosophy around HAS.

I'm not asking CDNi to make serving out manifests mandatory, because that would be a similar mistake the other way around, what i propose is that CDNi should be aware of which CDNs cannot control manifests, and which CDNs make manifest control mandatory.
Is this a binary option?  Manifest may be modified / may not be modified?




  Perhaps a more general question: Are we talking about making CDNs

  HAS aware, or making CDNI HAS aware?  It feels more like the former,

  with the latter being an after-thought, and it is not clear to me

  how the former fits into the charter?  Going straight from the uCDN

  routing every segment, to the uCDN supporting modification of a half

  dozen manifest formats feels disingenuous.  Is there no BCP for how

  to configure DNS-RR to take the load off the uCDN RR, or a simple

  set of metadata to describe the source content structure which can

  facilitate more efficient content acquisition?


I think you hit a weak spot in CDNi. Some CDNs use passive DNS rr and others use active HTTP rr. Some support both. Some also use redirect instructional files which IMHO is the best technology since it is active and guarantees much higher uptime and performance. If you want I can share more details about this because it would be a great feature for CDNi.

You are right that active rr CDNs may not want to federate to DNS based CDNs because their service level would drop below the SLA they offered to their customer. And you are right that some scenarios may simply not work, for instance when a uCDN manifest based anti-deeplinking and a dCDN hasn't implemented this. Some CDNs don't care about manifests, others need them to do their job. It isn't guaranteed that CDNs are always interchangeable.
Sounds like a capability exchange that the dCDN must provide some means of manifest management in order to comply with the uCDN's SLA requirements.

So that is why it is so important that CDNi doesn't rule out specific technology visions, architecture designs or technology choices. It should support these different flavors and definitely not rule out specific ones. And this is a typical example of information that should be shared between CDNs via a capabilities API, so CDNs can decide if they want to federate with other CDNs that cannot support the features they require.

Best Stef


 

thanx.

 

--  Kevin J. Ma

 

From: Stef van der Ziel [mailto:stef@jet-stream.nl]
Sent: Sunday, May 27, 2012 9:03 AM
To: Kevin J Ma
Cc: Brandenburg, R. (Ray) van; cdni@ietf.org
Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft

 

Hi Kevin,

 

Actually, many CDNs prefer to serve out both the segments and the manifest files.

Sure, dumb caching/DNS based CDNs can be used to deliver segments and they wouldn't care about segments. They will just pump out the delivered objects. But intelligent CDNs that are actually usable for commercial/secure and manageable HAS, need the manifests.

 

IMHO the role of a manifest file should not be confused with the role of a referrer file. 

A manifest is to represent the entire content, not just to the client but in the entire chain of encoding, protection, CDN and clients. 

A referrer file is the proper way to point to the (logical) content from any remote location.

 

We hardly ever see manifest files to be distributed outside of the CDN in reality. It is not a fairly common scenario and should not be. In more automated environments, it can actually be the CDN that creates the manifest.

 

The assumption that manifest files should or can be distributed offline or outside the CDN is mostly wrong. The assumption that you can point from a manifest to a CDN for the segments won't work since a proper CDN would (should) block direct access to segments to prevent deep linking. But we understand why people make these assumptions, we've heard other statements from HAS enthusiasts that don't make sense in the real world.

 

Serving out the manifests alongside the segments from the same CDN account is done for multiple reasons, which do not at all adapt the content:

 

- Logical asset recognition (parsing the manifests so the CDN understands that the segments are part of a logical entity)

- Logical asset management (processing, copying, managing manifests and subsequent segments as if they are one asset)

- Logical asset reporting (reporting manifests and subsequent segments via web interfaces and APIs as if they are one asset)

- Request routing control (CDNs only produce URLs for manifest files and will not accept requests for segments to prevent unnecessary request routing overload by having to request route every individual segment request)

- Access control (CDNs will not allow direct access to segments but only via the manifest file to prevent deep-linking, you don't want any third party to publish a manifest file on an unlicensed portal and then point users to the segments on the CDN without any access control)

- Session control (http streaming is stateless and that is quite dramatic for CDNs because you lose control over the session and over session logging)

 

There are additional reasons for CDNs to be able to adapt the manifest files but do so without changing the actual content:

- For instance, they could dynamically insert base URLs to point users to a group of servers to improve the availability.

- Or they could dynamically insert tokens into the manifest to control access to segments.

- Or they could dynamically insert session keys to be able to track a unique user session over multiple federated CDNs.

- Or they could dynamically remove higher or lower bit rates to better control the actual QoE on a per request basis.

 

Concluding: 

To a CDN, the segments aren't actually that interesting. They are just pieces of useless raw data that needs to be protected, managed and served. 

For a CDN, the manifest represents the content and is a critical component so they need to be able to parse, alter and serve them. 

 

I think the above by itself describes some interesting challenges. Just one example: how are CDNs going to guarantee anti-deeplinking to segments in a federated constellation where multiple nodes of multiple CDNs and request routers need to be aware of each others sessions and tokens, etc? 

 

My 2 cents.

 

Kind regards, Stef van der Ziel

 

-- 

Owner Jet-Stream | StreamZilla

GMT+1 Office: +31 50 5261820 | Mobile: +31 6 23406348

www.jet-stream.com | www.streamzillacdn.com

this communication is confidential

 



 

On 27 mei 2012, at 01:37, Kevin J Ma wrote:



Hi Ray,

 

  I read through the updated draft and had a number of comments ahead of

  the meeting.

 

  First, a general comment about manifest files.  The document seems

  to assume that manifest files will be distributed through the CDN.

  There are many services where this is not the case, often to prevent

  modification.  There is a large focus in the document on how to modify

  manifest files, in some cases where the manifest file itself is not

  necessarily relevant.  I believe there are ways to optimize HAS

  delivery without modifying manifest files, and in imo, manifest

 manipulation falls under content adaptation which the wg declared to

  be out of scope for the initial phase?

 

  With respect section 2.2, I believe I commented on this in the

  initial draft, but I still feel that the relative vs absolute URL

  discussion is rather misleading.  It seems to imply that:

    a) the HOST portion of a relative URL cannot point to a RR, that

    b) a RR must be accessed through some web service like API, and that

    c) absolute URLs can only point to specific surrogates.

  While these are all valid examples of how to use URLs, they do not

  seem to be typical cases.  For us, a typical service has a DNS

  address which points to a base directory in one or more CDNs.  The

  relative path from that base directory is the same in all CDNs.  The

  hostname does not point to any one surrogate, and each CDN is still

  able to redirect requests as it sees fit.

 

  With respect to sections 3.1 and 3.2, while I agree that content

  storage and acquisition optimization is important, and that there

  should be metadata which can describe the format of the content, I

  do think the CDN needs to be fully HAS aware, nor do I think that

  the CDN necessarily needs access to the manifest file.  I also do

  not see a "significant" impact to the MI.  The metadata interface

  will have the ability to define metadata that applies to a set of

  content assets, per the META-10 requirement.  Ultimately, the CDN

  needs to be able to respond to content requests from the client,

  even if that client got a manifest file directly from the content

  provider (not from the CDN) and is expecting the content to be in

  the format that was provided to the CDN by the content provider.

  How it got the content and how it stores it is out of scope?

 

  With respect to section 3.3, I think that a third case is missing,

 where the content provider does not provide the manifest file to the

  CDN (which can be a fairly common case).

 

  With respect to sections 3.3.2 and 3.3.3, would not DNS-based

  redirection solve the issue by simply directing manifest/chunk

  requests to the dCDN, rather than doing a manifest rewrite for every

  request (especially in the case of live streaming where the manifest

  might be changing on every chunk)?  Also, presumably, the RR would

  only rewrite URLs which were within its own domain (i.e., not

  blackholing ad insertion segments, etc.)?

 

  With respect to section 3.5, the time component of URL signing is

  not mentioned until section 3.5.3.  Expiration of URL tokens, in

  general, is an issue with HAS.  Robust key management is an arguably

  more reliable approach to content access protection, though that

  would seem to be fairly well out of scope for CDNI.  The proposed

  solution in section 3.5.3, seems to be managing session state?

  Depending on the complexity of the cookie, this could be troublesome

  if there is a failover and session state is not properly synchronized?

  And in the case of live streaming, the manifest is going to be

  requested every time?  How is the state managed in that case?  Is

  the cookie less susceptible to replay attacks than the URL token?

  Will the cookie work across all CDNs?  Moving on to section 3.5.4

  is even more concerning.  What if the content is already encrypted?

  How is authentication being handled on the key server?  Who is

  responsible for auditing the security of the solution?  Is this

  intended to provide DRM?  work with existing DRM?  circumvent

  existing DRM?  Does it only use the DRM/encryption support of the

  delivery protocol?  or is the client expected to implement an

  alternate protocol?  And how is this synchronized across CDNs?

  More generally, are we attempting to define security protocols for

  content delivery?  If so, I would like to see a more formal

 definition of what those requirements are?

 

  With respect to section 3.6.2, it seems that we just want to be able

 to purge a set of content assets.  Would a URI prefix not be sufficient?

 

thanx.

 

--  Kevin J. Ma

 

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van
Sent: Friday, May 25, 2012 10:19 AM
To: cdni@ietf.org
Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft

 

Hi all,

 

I’ve just uploaded a new version of draft-brandenburg-cdni-has.

 

 

The draft is meant as an input document for the virtual meeting on Thursday to discuss the impact of HTTP Adaptive Streaming on the CDNI Interfaces. In the draft a number of alternative solutions are presented for each area where the use of HAS might touch with the CDNI Interfaces (e.g. content acquisition, content purge, request routing, logging and URL signing).

 

I’m looking forward to your comments.

 

Have a nice weekend!

 

Ray van Brandenburg

 

 

 

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van
Sent: woensdag 23 mei 2012 13:37
To: cdni@ietf.org
Subject: [CDNi] Status of Adaptive Streaming and CDNI draft

 

Hi all,

 

Next Tuesday we have a planned interim meeting for discussing the combination between HTTP Adaptive Streaming and CDNI. One  of the expected inputs for this meeting is a follow-up draft to draft-brandenburg-cdni-has-00.

 

We are currently working hard at finishing this draft, but as you might have seen, we have not yet uploaded a new version. Currently we are at a stage where we have a first complete internal draft ready. However, Francois and I have agreed that we rather spend some more time on it so that it fully covers all the areas of the CDNI-HAS combination than upload an incomplete version right now. We are currently planning to upload the draft this Friday (25th of May) at the latest. I hope this gives you all enough time to read the draft before the meeting on Tuesday.

 

Sorry for the delay.

 

Ray

 

 

 

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

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

 


--------------050202090002080104010109-- From flefauch@cisco.com Tue May 29 06:04:35 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEA521F8754 for ; Tue, 29 May 2012 06:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdH45Hkg7EtV for ; Tue, 29 May 2012 06:04:34 -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 0235721F869F for ; Tue, 29 May 2012 06:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=6813; q=dns/txt; s=iport; t=1338296674; x=1339506274; h=from:mime-version:subject:date:in-reply-to:to:references: message-id; bh=MQOiOP2N2OttISOmDhNP5QJCD8bDIuRjluIcgar/l90=; b=JMxerYwyR+ULWEJfWKkTibtzAV23TC6x8IhVaEHoBeF6dcdhCd2Wj7eE cIX0HQFzD0u5GS73JqCjoMvAZPZAKah8UdlWtO4Lc6xhagugkBiXGH1JU jvsToU3PgmFcJn75NlZlJWTjEGN/V0xcUHEMDNIWnL2ERoWgdhhByExu/ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOzHxE+Q/khN/2dsb2JhbABEtTWBB4IXAQEBAgEBAQEBDwFbEAsLGCMLJzAZCRmHZAULmF+fV4sDhFFgA5UXjgyBZYJi X-IronPort-AV: E=Sophos;i="4.75,677,1330905600"; d="scan'208,217";a="138737715" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 29 May 2012 13:04:32 +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 q4TD4WHL032086 for ; Tue, 29 May 2012 13:04:32 GMT From: Francois Le Faucheur Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_E3A28704-4062-4446-AA89-DF8CFC252941" Date: Tue, 29 May 2012 15:04:28 +0200 In-Reply-To: <31BDC4E6-A560-42CB-804F-A803CEF3D126@cisco.com> To: cdni@ietf.org References: <5339DEEB-766C-4523-B352-52BC07FA24F3@cisco.com> <31BDC4E6-A560-42CB-804F-A803CEF3D126@cisco.com> Message-Id: <4000A470-0FEC-4A6E-8FB0-BE346D97E120@cisco.com> X-Mailer: Apple Mail (2.1278) Subject: Re: [CDNi] Agenda & Slides for CDNI "Extended Design Team Meetings" on May 29 - "HTTP 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: Tue, 29 May 2012 13:04:35 -0000 --Apple-Mail=_E3A28704-4062-4446-AA89-DF8CFC252941 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Additional slidedecks have been uploaded. You can access them through the links included in the updated agenda at: = http://www.ietf.org/proceedings/interim/2012/05/29/cdni/agenda/agenda-inte= rim-2012-cdni-1.html On 29 May 2012, at 11:07, Francois Le Faucheur wrote: > 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 --Apple-Mail=_E3A28704-4062-4446-AA89-DF8CFC252941 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://www.ietf.org/proceedings/interim/2012= /05/29/cdni/agenda/agenda-interim-2012-cdni-1.html


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

http://www.ietf.org/proceedings/interim/2012= /05/29/cdni/agenda/agenda-interim-2012-cdni-1.html

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/ma= ilman/listinfo/cdni

= --Apple-Mail=_E3A28704-4062-4446-AA89-DF8CFC252941-- From stef@jet-stream.com Tue May 29 10:47:26 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF99411E80B5 for ; Tue, 29 May 2012 10:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.329 X-Spam-Level: X-Spam-Status: No, score=-0.329 tagged_above=-999 required=5 tests=[AWL=0.175, 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 v+g3VhtC9v-T for ; Tue, 29 May 2012 10:47:26 -0700 (PDT) Received: from monitor1.jet-stream.nl (smtp.jet-stream.nl [91.196.106.226]) by ietfa.amsl.com (Postfix) with ESMTP id D8D0611E80B2 for ; Tue, 29 May 2012 10:47:25 -0700 (PDT) Received: from [192.168.1.10] (5ED5ABD7.cm-7-6c.dynamic.ziggo.nl [94.213.171.215]) (authenticated bits=0) by monitor1.jet-stream.nl (8.13.7/8.13.7) with ESMTP id q4THlQmx022955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 29 May 2012 19:47:27 +0200 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Stef van der Ziel In-Reply-To: <4FC4B86F.1040706@cisco.com> Date: Tue, 29 May 2012 19:48:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan><66050772-394A-4A28-92FE-6A0581D5A533@jet-stream.nl><291CC3F9E50E7641901A54E85D0977C653267F4D1F@MAILR002.mail.lan> <4FC4B86F.1040706@cisco.com> To: Scott Wainner X-Mailer: Apple Mail (2.1257) Cc: cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI 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, 29 May 2012 17:47:26 -0000 Hi Scott, > I think we need to address the security in several different context: >=20 > a) CSP -> uCDN RR > b) uCDN -> dCDN RR > c) dCDN RR -> dCDN Delivery Node Actually it is: a) CSP -> uCDN RR b) uCDN -> dCDN RR c) dCDN RR -> dCDN Delivery Node Manifest file d) dCDN manifest file -> dCDN (segmented) data BTW, in our view a higher layered entity can either be a CSP or a uCDN. = They are inter-exchangable.=20 > If I understand your 'deep-linking' comment, you're referring to = hand-off (c) above where some external entity obtains the URL that the = dCDN RR would have provided. I'm thinking the CDN-I may be focused = specifically on the hand-off (b) above. While we define a security = mechanism for (b), we need to understand there are various methods for = (c) above and they should not interfere with one another. >=20 > If we break the security problem in these three transactions, we can = still allow the dCDN to choose a method of securing the HAS transactions = between the client and dCDN using a method that does not override the = security method using between the uCDN and dCDN. True. That is how we work today as well. The token between A and B does = not affect the token between B and C etc. We are not passing along = tokens, but are creating new ones in every step. Othewise you'll end up = integrating and exchanging tokens between many parties and that will = never work from an operational / SI point of view.=20 >>=20 > I like this model, Thanks. I would highly recommended to split content management and = adaption and CDN-client session management. With todays manifests that = is a blurred mess, unfortunately it is with all HAS technologies = including DASH.=20 > but as you say, the Manifest/MPD needs a BaseURL that is a Relative = URL such that the client will refer back to the Delivery Node for each = segment request. =20 Correct. You don't want clients to go through request routers for every = segment, that is highly inefficient.=20 >>=20 >> Anyway it is too easy to assume that CDNs don't change manifests so = they don't need to serve out manifests. They do, so CDNi should be aware = of it. It is not a matter of being an advanced feature, it is how many = CDNs simply work from a core philosophy around HAS. >>=20 >> I'm not asking CDNi to make serving out manifests mandatory, because = that would be a similar mistake the other way around, what i propose is = that CDNi should be aware of which CDNs cannot control manifests, and = which CDNs make manifest control mandatory. > Is this a binary option? Manifest may be modified / may not be = modified? Yes it is binary but in this way: CDN doesn't care about manifests / CDN = requires manifests to be modified Best Stef From kleung@cisco.com Tue May 29 15:17:38 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC0B11E8125 for ; Tue, 29 May 2012 15:17:38 -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 zp87KfoONJz6 for ; Tue, 29 May 2012 15:17:34 -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 5647111E8074 for ; Tue, 29 May 2012 15:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=33125; q=dns/txt; s=iport; t=1338329854; x=1339539454; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=hyjYTqQb7q1EY5BkDmqJylm1k+iNmdIBoO9X+3l8mYI=; b=mEJ0v9pD9fpW1H539scYxeyg3gEcSDm3qlpMLz+JVca+sZUQFpCdm17R QYXmVYiv3nxhiFbOGqK44BC2rWvblGM/5FXN70se8zgm2AcuKWZb4phgf C7s0M12c6Al9e6wh3ZFW75fvFwMrGBJxV4GeHDdsS7Am585CXcwI+/bol Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAMNJxU+rRDoI/2dsb2JhbAA6CoJFsnOBB4IXAQEBBBIBCREDRBUCARkEAQELBhABBgEGAUUJCAEBBAESCAESB4VvgXkBC5k6n3CLAxAEBoRIYAOIP5pkgWWDAIE2AgcZ X-IronPort-AV: E=Sophos;i="4.75,680,1330905600"; d="scan'208,217";a="44284313" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 29 May 2012 22:17:33 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q4TMHXfu020022; Tue, 29 May 2012 22:17:33 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 May 2012 15:17:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD3DE8.D7CB8FEE" Date: Tue, 29 May 2012 15:17:31 -0700 Message-ID: <7A2D6D1F6AC99243A77D32820D8ABBC20F18E20C@xmb-sjc-235.amer.cisco.com> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: URL Signing in Adaptive Streaming and CDNI draft Thread-Index: Ac0414J5VzCVuofZTcKanwrNrKyoTABqTCnQAEHKv5AAk6xvUA== References: <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> From: "Kent Leung (kleung)" To: "Kevin J Ma" , "Brandenburg, R. (Ray) van" , X-OriginalArrivalTime: 29 May 2012 22:17:32.0784 (UTC) FILETIME=[D7EB4700:01CD3DE8] Subject: [CDNi] URL Signing in Adaptive Streaming and CDNI 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, 29 May 2012 22:17:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD3DE8.D7CB8FEE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kevin. Thanks for your feedback. I've separated the URL Signing as a sub-topic of HAS draft. =20 Comments below. =20 From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kevin J Ma Sent: Saturday, May 26, 2012 4:37 PM To: Brandenburg, R. (Ray) van; cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft =20 =20 With respect to section 3.5, the time component of URL signing is not mentioned until section 3.5.3. Expiration of URL tokens, in general, is an issue with HAS. =20 =20 KL> The "time period" or freshness of the signed URL is mentioned in section 3.5. Perhaps it's a bit cursory as an example of potential authorization parameters in the embedded URL. I can dedicate a paragraph in this section for URL expiration. NTP can be used to sync the clocks on the entities that sign and validate the URL. Not sure if the logging interface requires some timestamp mediation? If so, maybe the same technique can be applied. =20 Robust key management is an arguably more reliable approach to content access protection, though that would seem to be fairly well out of scope for CDNI. =20 =20 KL> If the key management is out-of-band from the CDNI Interfaces, then it would be out of scope. =20 The proposed solution in section 3.5.3, seems to be managing session state? Depending on the complexity of the cookie, this could be troublesome if there is a failover and session state is not properly synchronized? =20 KL> Yes, this option is for per-HAS-session. There are various schemes to handle failover scenario, which is out of scope.=20 =20 And in the case of live streaming, the manifest is going to be requested every time? How is the state managed in that case? =20 =20 KL> For live streaming, this depends on the HAS technology. I don't think the draft needs to get into the details of each technology. The fundamental concept is there is a manifest file for a Content Item which needs to be signed. And subsequent request for related content (i.e. chunk and sub-level manifest file) is associated with the authorization. =20 Is the cookie less susceptible to replay attacks than the URL token? Will the cookie work across all CDNs? =20 =20 KL> I can add some more info on replay protection on the cookie. Cookie expiration time can be used. No time synchronization issue for the same surrogate case. Failover across surrogates in same CDN requires NTP or other clock synchronization. Cookie method is not intended to work across CDNs since redirection should happen in this case. =20 Moving on to section 3.5.4 is even more concerning. What if the content is already encrypted? =20 KL> CDN is not aware and don't care if the content is encrypted. The session-based encryption is only a technique to link to the authorized state of the Content Item. =20 =20 How is authentication being handled on the key server? Who is responsible for auditing the security of the solution? Is this intended to provide DRM? work with existing DRM? circumvent existing DRM? Does it only use the DRM/encryption support of the delivery protocol? =20 =20 KL> There is no intention for DRM. It is an independent matter. This is only for encryption for the HAS session after URL of the manifest file is validated. One way to look at sections 3.5.3 and 3.5.4 is that after the initial URL for the Content Item is validated via URL Signing, access to related Content Collection can use alternative methods such as authorization token or session-based encryption during the HAS session. The advantage is these techniques do not require URL to be rewritten which is the method used by URL Signing. I should probably add one more option where all content for the Content Item use URL Signing for authorization. =20 or is the client expected to implement an alternate protocol? =20 =20 KL> It's not the intent to come up with new protocol. For example, HLS already supports this method. The section points out various solution options that are applicable to URL Signing. This may be applicable to some of the HAS technology as I'm not clear if it's universally possible. =20 And how is this synchronized across CDNs? =20 KL> See earlier comment about across CDNs. Both methods are limited to same CDN. =20 More generally, are we attempting to define security protocols for content delivery? If so, I would like to see a more formal definition of what those requirements are? =20 KL> No, there is no attempt to define security protocols. The objective was to identify the options that are available when URL Signing is used for authorization of HAS content. Once the CDN is HAS-aware, then related content can be grouped. There are several techniques used to group the chunks and possibly sub-level manifest files for the HAS session. There are advantages and disadvantages of each technique. =20 Kent =20 =20 -- Kevin J. Ma =20 From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: Friday, May 25, 2012 10:19 AM To: cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft =20 Hi all, =20 I've just uploaded a new version of draft-brandenburg-cdni-has. =20 You can find the document at: http://www.ietf.org/id/draft-brandenburg-cdni-has-01.txt =20 =20 The draft is meant as an input document for the virtual meeting on Thursday to discuss the impact of HTTP Adaptive Streaming on the CDNI Interfaces. In the draft a number of alternative solutions are presented for each area where the use of HAS might touch with the CDNI Interfaces (e.g. content acquisition, content purge, request routing, logging and URL signing).=20 =20 I'm looking forward to your comments. =20 Have a nice weekend! =20 Ray van Brandenburg =20 =20 =20 From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: woensdag 23 mei 2012 13:37 To: cdni@ietf.org Subject: [CDNi] Status of Adaptive Streaming and CDNI draft =20 Hi all, =20 Next Tuesday we have a planned interim meeting for discussing the combination between HTTP Adaptive Streaming and CDNI. One of the expected inputs for this meeting is a follow-up draft to draft-brandenburg-cdni-has-00.=20 =20 We are currently working hard at finishing this draft, but as you might have seen, we have not yet uploaded a new version. Currently we are at a stage where we have a first complete internal draft ready. However, Francois and I have agreed that we rather spend some more time on it so that it fully covers all the areas of the CDNI-HAS combination than upload an incomplete version right now. We are currently planning to upload the draft this Friday (25th of May) at the latest. I hope this gives you all enough time to read the draft before the meeting on Tuesday.=20 =20 Sorry for the delay. =20 Ray =20 =20 =20 This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer ------_=_NextPart_001_01CD3DE8.D7CB8FEE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kevin. Thanks for your feedback. I’ve separated the URL = Signing as a sub-topic of HAS draft.

 

Comments below.

 

From:= = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Kevin J Ma
Sent: Saturday, May 26, 2012 4:37 = PM
To: Brandenburg, R. (Ray) van; = cdni@ietf.org
Subject: Re: [CDNi] Status of Adaptive Streaming = and CDNI draft

 

<snip>

 

  With = respect to section 3.5, the time component of URL signing = is

  not = mentioned until section 3.5.3.  Expiration of URL tokens, = in

  = general, is an issue with HAS. 

 

KL> The “time period” or freshness of the signed URL = is mentioned in section 3.5. Perhaps it’s a bit cursory as an = example of potential authorization parameters in the embedded URL. I can = dedicate a paragraph in this section for URL expiration. NTP can be used = to sync the clocks on the entities that sign and validate the URL. Not = sure if the logging interface requires some timestamp mediation? If so, = maybe the same technique can be applied.

 

  Robust key = management is an arguably

  more reliable approach to content access = protection, though that

  = would seem to be fairly well out of scope for CDNI. 

 

KL> If the key management is out-of-band from the CDNI Interfaces, = then it would be out of scope.

 

  The = proposed

  = solution in section 3.5.3, seems to be managing session = state?

  = Depending on the complexity of the cookie, this could be = troublesome

  if = there is a failover and session state is not properly synchronized? =

 

KL> Yes, this option is for per-HAS-session. There are various = schemes to handle failover scenario, which is out of scope. =

 

  And in the case of live streaming, the = manifest is going to be

  = requested every time?  How is the state managed in that case?  =

 

KL> For live streaming, this depends on the HAS technology. I = don’t think the draft needs to get into the details of each = technology. The fundamental concept is there is a manifest file for a = Content Item which needs to be signed. And subsequent request  for = related content (i.e. chunk and sub-level manifest file) is associated = with the authorization.

 

  Is

  the = cookie less susceptible to replay attacks than the URL = token?

  Will = the cookie work across all CDNs? 

 

KL> I can add some more info on replay protection on the cookie. = Cookie expiration time can be used. No time synchronization issue for = the same surrogate case. Failover across surrogates in same CDN requires = NTP or other clock synchronization. Cookie method is not intended to = work across CDNs since redirection should happen in this = case.

 

  Moving on = to section 3.5.4

  is = even more concerning.  What if the content is already = encrypted?

 

KL> CDN is not aware and don’t care if the content is = encrypted. The session-based encryption is only a technique to link to = the authorized state of the Content Item.  

 

  How = is authentication being handled on the key server?  Who = is

  = responsible for auditing the security of the solution?  Is = this

  = intended to provide DRM?  work with existing DRM?  = circumvent

  = existing DRM?  Does it only use the DRM/encryption support of = the

  = delivery protocol? 

 

KL> There is no intention for DRM. It is an independent matter. = This is only for encryption for the HAS session after URL of the = manifest file is validated. One way to look at sections 3.5.3 and 3.5.4 = is that after the initial URL for the Content Item is validated via URL = Signing, access to related Content Collection can use alternative = methods such as authorization token or session-based encryption during = the HAS session. The advantage is these techniques do not require URL to = be rewritten which is the method used by URL Signing. I should probably = add one more option where all content for the Content Item use URL = Signing for authorization.

 

or is the = client expected to implement an

  alternate protocol? 

 

KL> It’s not the intent to come up with new protocol. For = example, HLS  already supports this method. The section points out = various solution options that are applicable to URL Signing. This may be = applicable to some of the HAS technology as I’m not clear if = it’s universally possible.

 

And how is = this synchronized across CDNs?

 

KL> See earlier comment about across CDNs. Both methods are = limited to same CDN.

 

  More = generally, are we attempting to define security protocols = for

  = content delivery?  If so, I would like to see a more = formal

 definition of what those requirements = are?

 

KL> No, there is no attempt to define security protocols. The = objective was to identify the options that are available when URL = Signing is used for authorization of HAS content. Once the CDN is = HAS-aware, then related content can be grouped. There are several = techniques used to group the chunks and possibly sub-level manifest = files for the HAS session. There are advantages and disadvantages of = each technique.

 

Kent

 

<snip>

 

--  = Kevin J. Ma

 

From:= = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Brandenburg, R. (Ray) van
Sent: Friday, May 25, 2012 10:19 = AM
To: cdni@ietf.org
Subject: Re: [CDNi] Status of = Adaptive Streaming and CDNI draft

 

Hi all,

 

I’ve just uploaded a new version of = draft-brandenburg-cdni-has.

 

You can find the document at: http://www.ietf.org/id/draft-brandenburg-cdni-has-01.txt

 

The draft is meant as an input document for the virtual meeting on = Thursday to discuss the impact of HTTP Adaptive Streaming on the CDNI = Interfaces. In the draft a number of alternative solutions are presented = for each area where the use of HAS might touch with the CDNI Interfaces = (e.g. content acquisition, content purge, request routing, logging and = URL signing).

 

I’m looking forward to your comments.

 

Have a nice weekend!

 

Ray van Brandenburg

 

 

 

From:= = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Brandenburg, R. (Ray) van
Sent: woensdag 23 mei 2012 = 13:37
To: cdni@ietf.org
Subject: [CDNi] Status of = Adaptive Streaming and CDNI draft

 

Hi = all,

 =

Next = Tuesday we have a planned interim meeting for discussing the combination = between HTTP Adaptive Streaming and CDNI. One  of the expected = inputs for this meeting is a follow-up draft to = draft-brandenburg-cdni-has-00.

 =

We are = currently working hard at finishing this draft, but as you might have = seen, we have not yet uploaded a new version. Currently we are at a = stage where we have a first complete internal draft ready. However, = Francois and I have agreed that we rather spend some more time on it so = that it fully covers all the areas of the CDNI-HAS combination than = upload an incomplete version right now. We are currently planning to = upload the draft this Friday (25th of May) = at the latest. I hope this gives you all enough time to read the draft = before the meeting on Tuesday.

 =

Sorry for = the delay.

 =

Ray

 =

 =

 =

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

------_=_NextPart_001_01CD3DE8.D7CB8FEE-- From kevin.ma@azukisystems.com Tue May 29 21:14: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 04F2A11E80DB for ; Tue, 29 May 2012 21:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeBXWjm-Pj58 for ; Tue, 29 May 2012 21:14:36 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 9D82B11E80A5 for ; Tue, 29 May 2012 21:14:35 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 30DE88F6ACF; Tue, 29 May 2012 23:57:28 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB023.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 2D3828F6A7B; Tue, 29 May 2012 23:57:25 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Wed, 30 May 2012 00:14:11 -0400 From: Kevin J Ma To: "Kent Leung (kleung)" , "Brandenburg, R. (Ray) van" , "cdni@ietf.org" Date: Wed, 30 May 2012 00:14:29 -0400 Thread-Topic: URL Signing in Adaptive Streaming and CDNI draft Thread-Index: Ac0414J5VzCVuofZTcKanwrNrKyoTABqTCnQAEHKv5AAk6xvUAAOxjgQ Message-ID: <291CC3F9E50E7641901A54E85D0977C653267F5135@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> <7A2D6D1F6AC99243A77D32820D8ABBC20F18E20C@xmb-sjc-235.amer.cisco.com> In-Reply-To: <7A2D6D1F6AC99243A77D32820D8ABBC20F18E20C@xmb-sjc-235.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_291CC3F9E50E7641901A54E85D0977C653267F5135MAILR002maill_" MIME-Version: 1.0 Subject: Re: [CDNi] URL Signing in Adaptive Streaming and CDNI 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: Wed, 30 May 2012 04:14:42 -0000 --_000_291CC3F9E50E7641901A54E85D0977C653267F5135MAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent, With respect to token time periods, it is difficult to estimate when a segment is actually going to be requested. Web pages typically request everything immediately, but that's not the case with HAS. Maybe the player gets paused and its a while between manifest request and segment request, or maybe seeking causes segments to be played out of sequence. You often end up needing long time periods on all segments to prevent undue rejections, which limits the value of having URL tokens? To Scott's point, we may need to differentiate between URL tokens on inter-CDN acquisition vs dCDN-to-end-user tokens. Perhaps there is more value for the former than the latter? > What if the content is already encrypted? > > KL> CDN is not aware and don't care if the content is encrypted. I don't think this is true. Depending on how the encryption is being implemented, the CDN has to care if the content is already encrypted. You mention HLS supporting encryption. That is true, but you cannot double encrypt the content? If we are talking about reusing existing HAS protocol support, then I think you need to care what existing encryption and DRM are in use. Are you assuming this would only be performed on unencrypted content and that the CDN would have some business agreement with the CP to implement a DRM packaging function? If not, I don't think we can assume one way or the other if the content is already encrypted. The manifest may not be available, and even if it is, the manifest may not tell you if the content is encrypted, especially if it is using a third party DRM. Were you anticipating that the encryption keys would be session specific? Would they be client (subscriber) specific? I would be interested in more details on the security of the key exchange? If the keys are easily obtained, then there's little value in having segment encryption (as it pertains to authorization)? thanx. -- Kevin J. Ma From: Kent Leung (kleung) [mailto:kleung@cisco.com] Sent: Tuesday, May 29, 2012 6:18 PM To: Kevin J Ma; Brandenburg, R. (Ray) van; cdni@ietf.org Subject: URL Signing in Adaptive Streaming and CDNI draft Hi Kevin. Thanks for your feedback. I've separated the URL Signing as a sub= -topic of HAS draft. Comments below. From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kev= in J Ma Sent: Saturday, May 26, 2012 4:37 PM To: Brandenburg, R. (Ray) van; cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft With respect to section 3.5, the time component of URL signing is not mentioned until section 3.5.3. Expiration of URL tokens, in general, is an issue with HAS. KL> The "time period" or freshness of the signed URL is mentioned in sectio= n 3.5. Perhaps it's a bit cursory as an example of potential authorization = parameters in the embedded URL. I can dedicate a paragraph in this section = for URL expiration. NTP can be used to sync the clocks on the entities that= sign and validate the URL. Not sure if the logging interface requires some= timestamp mediation? If so, maybe the same technique can be applied. Robust key management is an arguably more reliable approach to content access protection, though that would seem to be fairly well out of scope for CDNI. KL> If the key management is out-of-band from the CDNI Interfaces, then it = would be out of scope. The proposed solution in section 3.5.3, seems to be managing session state? Depending on the complexity of the cookie, this could be troublesome if there is a failover and session state is not properly synchronized? KL> Yes, this option is for per-HAS-session. There are various schemes to h= andle failover scenario, which is out of scope. And in the case of live streaming, the manifest is going to be requested every time? How is the state managed in that case? KL> For live streaming, this depends on the HAS technology. I don't think t= he draft needs to get into the details of each technology. The fundamental = concept is there is a manifest file for a Content Item which needs to be si= gned. And subsequent request for related content (i.e. chunk and sub-level= manifest file) is associated with the authorization. Is the cookie less susceptible to replay attacks than the URL token? Will the cookie work across all CDNs? KL> I can add some more info on replay protection on the cookie. Cookie exp= iration time can be used. No time synchronization issue for the same surrog= ate case. Failover across surrogates in same CDN requires NTP or other cloc= k synchronization. Cookie method is not intended to work across CDNs since = redirection should happen in this case. Moving on to section 3.5.4 is even more concerning. What if the content is already encrypted? KL> CDN is not aware and don't care if the content is encrypted. The sessio= n-based encryption is only a technique to link to the authorized state of t= he Content Item. How is authentication being handled on the key server? Who is responsible for auditing the security of the solution? Is this intended to provide DRM? work with existing DRM? circumvent existing DRM? Does it only use the DRM/encryption support of the delivery protocol? KL> There is no intention for DRM. It is an independent matter. This is onl= y for encryption for the HAS session after URL of the manifest file is vali= dated. One way to look at sections 3.5.3 and 3.5.4 is that after the initia= l URL for the Content Item is validated via URL Signing, access to related = Content Collection can use alternative methods such as authorization token = or session-based encryption during the HAS session. The advantage is these = techniques do not require URL to be rewritten which is the method used by U= RL Signing. I should probably add one more option where all content for the= Content Item use URL Signing for authorization. or is the client expected to implement an alternate protocol? KL> It's not the intent to come up with new protocol. For example, HLS alr= eady supports this method. The section points out various solution options = that are applicable to URL Signing. This may be applicable to some of the H= AS technology as I'm not clear if it's universally possible. And how is this synchronized across CDNs? KL> See earlier comment about across CDNs. Both methods are limited to same= CDN. More generally, are we attempting to define security protocols for content delivery? If so, I would like to see a more formal definition of what those requirements are? KL> No, there is no attempt to define security protocols. The objective was= to identify the options that are available when URL Signing is used for au= thorization of HAS content. Once the CDN is HAS-aware, then related content= can be grouped. There are several techniques used to group the chunks and = possibly sub-level manifest files for the HAS session. There are advantages= and disadvantages of each technique. Kent -- Kevin J. Ma From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Bra= ndenburg, R. (Ray) van Sent: Friday, May 25, 2012 10:19 AM To: cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft Hi all, I've just uploaded a new version of draft-brandenburg-cdni-has. You can find the document at: http://www.ietf.org/id/draft-brandenburg-cdni= -has-01.txt The draft is meant as an input document for the virtual meeting on Thursday= to discuss the impact of HTTP Adaptive Streaming on the CDNI Interfaces. I= n the draft a number of alternative solutions are presented for each area w= here the use of HAS might touch with the CDNI Interfaces (e.g. content acqu= isition, content purge, request routing, logging and URL signing). I'm looking forward to your comments. Have a nice weekend! Ray van Brandenburg From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Bra= ndenburg, R. (Ray) van Sent: woensdag 23 mei 2012 13:37 To: cdni@ietf.org Subject: [CDNi] Status of Adaptive Streaming and CDNI draft Hi all, Next Tuesday we have a planned interim meeting for discussing the combinati= on between HTTP Adaptive Streaming and CDNI. One of the expected inputs fo= r this meeting is a follow-up draft to draft-brandenburg-cdni-has-00. We are currently working hard at finishing this draft, but as you might hav= e seen, we have not yet uploaded a new version. Currently we are at a stage= where we have a first complete internal draft ready. However, Francois and= I have agreed that we rather spend some more time on it so that it fully c= overs all the areas of the CDNI-HAS combination than upload an incomplete v= ersion right now. We are currently planning to upload the draft this Friday= (25th of May) at the latest. I hope this gives you all enough time to read= the draft before the meeting on Tuesday. Sorry for the delay. Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_291CC3F9E50E7641901A54E85D0977C653267F5135MAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kent,

  With respect to token time perio= ds, it is difficult to estimate when

  a seg= ment is actually going to be requested.  Web pages typically

  request everything immediately, but that's not the = case with HAS.

  Maybe the player gets pause= d and its a while between manifest request

 = ;and segment request, or maybe seeking causes segments to be played

 out of sequence.  You often end up needing l= ong time periods on all

 segments to preven= t undue rejections, which limits the value of

&nb= sp; having URL tokens?

 

  To Scott's point, we may need to differentiate between URL to= kens on

  inter-CDN acquisition vs dCDN-to-e= nd-user tokens.  Perhaps there is

  mor= e value for the former than the latter?

&nbs= p;

> What if the content is already encrypted?=

> 

= > KL> CDN = is not aware and don’t care if the content is encrypted.

 

  I don't think this i= s true.  Depending on how the encryption is

=   being implemented, the CDN has to care if the content is already

  encrypted.  You mention HLS supporting e= ncryption.  That is true,

  but you can= not double encrypt the content?  If we are talking about

  reusing existing HAS protocol support, then I think you= need to care

  what existing encryption and= DRM are in use.

 

  Are you assuming this would only be performed on unencrypted conten= t

  and that the CDN would have some busines= s agreement with the CP to

  implement a DRM= packaging function?  If not, I don't think we can

  assume one way or the other if the content is already encrypt= ed.

  The manifest may not be available, and= even if it is, the manifest

  may not tell = you if the content is encrypted, especially if it is

<= p class=3DMsoNormal>  using a third party DRM.

 

  Were you anticipating that the encryption keys w= ould be session

  specific?  Would they= be client (subscriber) specific?  I would be

  the keys are easily obtained, then = there's little value in having

  segment enc= ryption (as it pertains to authorization)?

&= nbsp;

thanx.

 

--  Kevin J. Ma

 = ;

 

<= p class=3DMsoNormal>From: Kent Leung (kleung) [mailto:kleung@cisco.com]
<= b>Sent: Tuesday, May 29, 2012 6:18 PM
To: Kevin J Ma; Branden= burg, R. (Ray) van; cdni@ietf.org
Subject: URL Signing in Adaptiv= e Streaming and CDNI draft

 

Hi Kevin. Thanks for= your feedback. I’ve separated the URL Signing as a sub-topic of HAS = draft.

 

Comments below.

<= p class=3DMsoNormal> 

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] = On Behalf Of Kevin J Ma
Sent: Saturday, May 26, 2012 4:37 PM<= br>To: Brandenburg, R. (Ray) van; cdni@ietf.org
Subject: R= e: [CDNi] Status of Adaptive Streaming and CDNI draft

=

 

= &l= t;snip>

 

  With re= spect to section 3.5, the time component of URL signing is

  not mentioned until section 3.5.3.  Expiration of URL= tokens, in

  general, is an issue with HAS.=  

 

KL> The “time period” or freshness of the signed URL is men= tioned in section 3.5. Perhaps it’s a bit cursory as an example of po= tential authorization parameters in the embedded URL. I can dedicate a para= graph in this section for URL expiration. NTP can be used to sync the clock= s on the entities that sign and validate the URL. Not sure if the logging i= nterface requires some timestamp mediation? If so, maybe the same technique= can be applied.

&nbs= p;

  Robust key management is an arguably

  more reliable approach to content access pro= tection, though that

  would seem to be fai= rly well out of scope for CDNI. 

 <= /p>

KL> If the key management is out-of-band = from the CDNI Interfaces, then it would be out of scope.<= /p>

 

  The proposed

  solution in section 3.5.3, s= eems to be managing session state?

  Dependi= ng on the complexity of the cookie, this could be troublesome

  if there is a failover and session state is not properl= y synchronized?

&nbs= p;

KL> Yes, this option is f= or per-HAS-session. There are various schemes to handle failover scenario, = which is out of scope.

 

  And in the case of live streamin= g, the manifest is going to be

  requested e= very time?  How is the state managed in that case? 

 

KL> For live st= reaming, this depends on the HAS technology. I don’t think the draft = needs to get into the details of each technology. The fundamental concept i= s there is a manifest file for a Content Item which needs to be signed. And= subsequent request  for related content (i.e. chunk and sub-level man= ifest file) is associated with the authorization.

 

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:#1F497D'>&nb= sp; = Is

  the cookie less susceptible to replay a= ttacks than the URL token?

  Will the cookie= work across all CDNs? 

 

KL> I can add some more info on replay protection = on the cookie. Cookie expiration time can be used. No time synchronization = issue for the same surrogate case. Failover across surrogates in same CDN r= equires NTP or other clock synchronization. Cookie method is not intended t= o work across CDNs since redirection should happen in this case.=

 

  Moving on to section 3.5.4

  is eve= n more concerning.  What if the content is already encrypted?

 

KL> CDN is not aware and don’t care if the c= ontent is encrypted. The session-based encryption is only a technique to li= nk to the authorized state of the Content Item.  

 

  How is= authentication being handled on the key server?  Who is

  responsible for auditing the security of the solution?&= nbsp; Is this

  intended to provide DRM?&nbs= p; work with existing DRM?  circumvent

&nb= sp; existing DRM?  Does it only use the DRM/encryption support of the<= o:p>

  delivery protocol? 

 

KL> There is no inte= ntion for DRM. It is an independent matter. This is only for encryption for= the HAS session after URL of the manifest file is validated. One way to lo= ok at sections 3.5.3 and 3.5.4 is that after the initial URL for the Conten= t Item is validated via URL Signing, access to related Content Collection c= an use alternative methods such as authorization token or session-based enc= ryption during the HAS session. The advantage is these techniques do not re= quire URL to be rewritten which is the method used by URL Signing. I should= probably add one more option where all content for the Content Item use UR= L Signing for authorization.

 

or is the client expected to implement = an

  alternate protocol? 

 

KL> It’s = not the intent to come up with new protocol. For example, HLS  already= supports this method. The section points out various solution options that= are applicable to URL Signing. This may be applicable to some of the HAS t= echnology as I’m not clear if it’s universally possible.

 

And how is this synchronized across CDNs?

 

KL= > See earlier comment about across CDNs. Both methods are limited to sam= e CDN.

 

  More generally, are we attempting to define security p= rotocols for

  content delivery?  If so= , I would like to see a more formal

 definit= ion of what those requirements are?

 

KL> No, there i= s no attempt to define security protocols. The objective was to identify th= e options that are available when URL Signing is used for authorization of = HAS content. Once the CDN is HAS-aware, then related content can be grouped= . There are several techniques used to group the chunks and possibly sub-le= vel manifest files for the HAS session. There are advantages and disadvanta= ges of each technique.

 

Kent=

 

<snip>

 

-- = Kevin J. Ma

 

<= div>

From: cdni-bounces@ietf.org [mailto:cdni-bo= unces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van
Sent: Friday, May 25, 2012 10:19 AM
To: cdni@ietf.org
Subject:= Re: [CDNi] Status of Adaptive Streaming and CDNI draft

 

Hi all,

 

I= 217;ve just uploaded a new version of draft-brandenburg-cdni-has.

 

You can find the document at: <= a href=3D"http://www.ietf.org/id/draft-brandenburg-cdni-has-01.txt">http://www.ietf.org/id/draft-brandenburg-cdni-has-01.txt=

&n= bsp;

The draft is meant as an i= nput document for the virtual meeting on Thursday to discuss the impact of = HTTP Adaptive Streaming on the CDNI Interfaces. In the draft a number of al= ternative solutions are presented for each area where the use of HAS might = touch with the CDNI Interfaces (e.g. content acquisition, content purge, re= quest routing, logging and URL signing).

 

I&#= 8217;m looking forward to your comments.

 

Have= a nice weekend!

&nbs= p;

Ray van Brandenburg

 

 

 

From: cdni-= bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Branden= burg, R. (Ray) van
Sent: woensdag 23 mei 2012 13:37
To:= cdni@ietf.org
Subject: [CDNi] Status of Adaptive Streaming and C= DNI draft

 

Hi all,=

 

Next Tuesday we have a planned inte= rim meeting for discussing the combination between HTTP Adaptive Streaming = and CDNI. One  of the expected inputs for this meeting is a follow-up = draft to draft-brandenburg-cdni-has-00.

 

We are currently working hard at finishing this draft, but as you= might have seen, we have not yet uploaded a new version. Currently we are = at a stage where we have a first complete internal draft ready. However, Fr= ancois and I have agreed that we rather spend some more time on it so that = it fully covers all the areas of the CDNI-HAS combination than upload an in= complete version right now. We are currently planning to upload the draft t= his Friday (25th of May) at the latest. I hop= e this gives you all enough time to read the draft before the meeting on Tu= esday.

 =

Sorry for the delay.

 

Ray

 

 

 

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

<= /div>
= --_000_291CC3F9E50E7641901A54E85D0977C653267F5135MAILR002maill_-- From kleung@cisco.com Tue May 29 23:31: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 2D28F21F86E4 for ; Tue, 29 May 2012 23:31:16 -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 3zJneUQLb00l for ; Tue, 29 May 2012 23:31:09 -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 66B0921F86E3 for ; Tue, 29 May 2012 23:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=56762; q=dns/txt; s=iport; t=1338359468; x=1339569068; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=3kUWBFaXtcqFZumPttMSsMNxksr3g2AHPuJGEDF5K14=; b=f/iPnOmLzSR6V8wULTDr5l61zi44gEbjjtpjej+GJX8eVU2nqaR+vcsM oMlcAeJpNc/0JRKYZzKahT/cZDeh2TWRTC8mNPgqqieH03gDZQz9j4iwG naWQmCyf80ANe1RcpyDPsI18zlpOVWOhewA98nIJs/wIdPwyeytqeOFOG 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAD6+xU+tJV2Z/2dsb2JhbAA6CoJFsVyBB4IXAQEBAwESAQcCEQNECgsCAQgRBAEBCwYQAQYBBgFFCQgBAQQBEggBEgeFb4F1BAELmS+gCYsFEAQGhEhgA4hAmmSBZoMAgTYCBxk X-IronPort-AV: E=Sophos;i="4.75,681,1330905600"; d="scan'208,217";a="87590042" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 30 May 2012 06:31:07 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q4U6V6Rj019905; Wed, 30 May 2012 06:31:06 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 May 2012 23:31:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD3E2D.C94A9EC0" Date: Tue, 29 May 2012 23:31:01 -0700 Message-ID: <7A2D6D1F6AC99243A77D32820D8ABBC20F18E349@xmb-sjc-235.amer.cisco.com> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C653267F5135@MAILR002.mail.lan> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: URL Signing in Adaptive Streaming and CDNI draft Thread-Index: Ac0414J5VzCVuofZTcKanwrNrKyoTABqTCnQAEHKv5AAk6xvUAAOxjgQAAPCBkA= References: <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> <7A2D6D1F6AC99243A77D32820D8ABBC20F18E20C@xmb-sjc-235.amer.cisco.com> <291CC3F9E50E7641901A54E85D0977C653267F5135@MAILR002.mail.lan> From: "Kent Leung (kleung)" To: "Kevin J Ma" , "Brandenburg, R. (Ray) van" , X-OriginalArrivalTime: 30 May 2012 06:31:04.0331 (UTC) FILETIME=[C9C6C5B0:01CD3E2D] Subject: Re: [CDNi] URL Signing in Adaptive Streaming and CDNI 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: Wed, 30 May 2012 06:31:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD3E2D.C94A9EC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kevin. Comments below. =20 From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]=20 Sent: Tuesday, May 29, 2012 9:14 PM To: Kent Leung (kleung); Brandenburg, R. (Ray) van; cdni@ietf.org Subject: RE: URL Signing in Adaptive Streaming and CDNI draft =20 Hi Kent, =20 With respect to token time periods, it is difficult to estimate when a segment is actually going to be requested. Web pages typically request everything immediately, but that's not the case with HAS. Maybe the player gets paused and its a while between manifest request and segment request, or maybe seeking causes segments to be played out of sequence. You often end up needing long time periods on all segments to prevent undue rejections, which limits the value of having URL tokens? =20 KL> I'm not clear what you mean by "URL tokens". Are you talking about Option 5.1 or 5.2? If the latter, then the authorization token is for the HAS session. This is not per chunk basis. The cookie can be refreshed periodically during the session. So any chunk can be requested during the HAS session as long as the cookie has not expired. This is an issue for the former case. =20 To Scott's point, we may need to differentiate between URL tokens on inter-CDN acquisition vs dCDN-to-end-user tokens. Perhaps there is more value for the former than the latter? =20 KL> I agree that there is a difference between the tokens. But URL Signing is about delivery authorization (or content access control) and not content acquisition. The scheme used for acquisition does not have to be the same as for delivery. We should not be figuring out how token is used for different interfaces (e.g. between CDNs or between dCDN and end user). Instead, we should be figuring out how to support HAS with URL Signing. I think there are quite a few methods. Some of them may depend on the capabilities of the HAS technology. If your point is that this is not CDNI issue, I don't have a problem with that. CDNI does need to be aware that URL Signing is used for delivery to end user. This impacts some of the CDNI Interfaces. As for how URL Signing is optimized when CDN is HAS-aware, that may not need to be defined. So using Authorization token, session-based encryption, or some other methods don't need to be described in detail. Maybe just the concept that the manifest URL of the Content Item is protected by URL Signing and the related content is associated for the HAS session is sufficient? =20 > What if the content is already encrypted? >=20 > KL> CDN is not aware and don't care if the content is encrypted. =20 I don't think this is true. Depending on how the encryption is being implemented, the CDN has to care if the content is already encrypted. You mention HLS supporting encryption. That is true, but you cannot double encrypt the content? If we are talking about reusing existing HAS protocol support, then I think you need to care what existing encryption and DRM are in use. =20 Are you assuming this would only be performed on unencrypted content and that the CDN would have some business agreement with the CP to implement a DRM packaging function? If not, I don't think we can assume one way or the other if the content is already encrypted. The manifest may not be available, and even if it is, the manifest may not tell you if the content is encrypted, especially if it is using a third party DRM. =20 KL> Maybe I'm missing your point. Double encryption happens all the time. For example, I have an HTTPS session to a web server over the business IPSec VPN. In this case, the content is encrypted with DRM. The content may be transported over VPN between CSP and uCDN or between uCDN and dCDN. The content may be delivered from dCDN to end user with session-based encryption. =20 Were you anticipating that the encryption keys would be session specific? Would they be client (subscriber) specific? I would be interested in more details on the security of the key exchange? If the keys are easily obtained, then there's little value in having segment encryption (as it pertains to authorization)? =20 KL> So far, we've been talking in the context of the HAS session. But the keying method can be flexible. Anyways, I offered the Session-Based Encryption as an option to bind the HAS session with the authorized manifest file for dCDN that is HAS-aware. The intent was to give an example and not get into the detailed implementation. =20 Maybe we should step back and look at the following to see if we are on the right track? =20 1. URL Signing is a method to authorize content delivery (or content access control) 2. CDNI needs URL Signing support on Request Routing (mandatory), Metadata (mandatory), and Logging (optional) Interfaces 3. When URL Signing is used in CDN without HAS-awareness, everything works fine with some caveats a. Relative URL is signed for invariant portion of URL b. Request for signed URL needs to be within the expiration period (this can be an issue) 4. When URL Signing is used in CDN with HAS-awareness, validation of the URL for manifest of Original Content assumes that access to the Content Collection is authorized for the HAS session (Details of the methods are not CDNI related) =20 Kent =20 thanx. =20 -- Kevin J. Ma =20 =20 From: Kent Leung (kleung) [mailto:kleung@cisco.com]=20 Sent: Tuesday, May 29, 2012 6:18 PM To: Kevin J Ma; Brandenburg, R. (Ray) van; cdni@ietf.org Subject: URL Signing in Adaptive Streaming and CDNI draft =20 Hi Kevin. Thanks for your feedback. I've separated the URL Signing as a sub-topic of HAS draft. =20 Comments below. =20 From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kevin J Ma Sent: Saturday, May 26, 2012 4:37 PM To: Brandenburg, R. (Ray) van; cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft =20 =20 With respect to section 3.5, the time component of URL signing is not mentioned until section 3.5.3. Expiration of URL tokens, in general, is an issue with HAS. =20 =20 KL> The "time period" or freshness of the signed URL is mentioned in section 3.5. Perhaps it's a bit cursory as an example of potential authorization parameters in the embedded URL. I can dedicate a paragraph in this section for URL expiration. NTP can be used to sync the clocks on the entities that sign and validate the URL. Not sure if the logging interface requires some timestamp mediation? If so, maybe the same technique can be applied. =20 Robust key management is an arguably more reliable approach to content access protection, though that would seem to be fairly well out of scope for CDNI. =20 =20 KL> If the key management is out-of-band from the CDNI Interfaces, then it would be out of scope. =20 The proposed solution in section 3.5.3, seems to be managing session state? Depending on the complexity of the cookie, this could be troublesome if there is a failover and session state is not properly synchronized? =20 KL> Yes, this option is for per-HAS-session. There are various schemes to handle failover scenario, which is out of scope.=20 =20 And in the case of live streaming, the manifest is going to be requested every time? How is the state managed in that case? =20 =20 KL> For live streaming, this depends on the HAS technology. I don't think the draft needs to get into the details of each technology. The fundamental concept is there is a manifest file for a Content Item which needs to be signed. And subsequent request for related content (i.e. chunk and sub-level manifest file) is associated with the authorization. =20 Is the cookie less susceptible to replay attacks than the URL token? Will the cookie work across all CDNs? =20 =20 KL> I can add some more info on replay protection on the cookie. Cookie expiration time can be used. No time synchronization issue for the same surrogate case. Failover across surrogates in same CDN requires NTP or other clock synchronization. Cookie method is not intended to work across CDNs since redirection should happen in this case. =20 Moving on to section 3.5.4 is even more concerning. What if the content is already encrypted? =20 KL> CDN is not aware and don't care if the content is encrypted. The session-based encryption is only a technique to link to the authorized state of the Content Item. =20 =20 How is authentication being handled on the key server? Who is responsible for auditing the security of the solution? Is this intended to provide DRM? work with existing DRM? circumvent existing DRM? Does it only use the DRM/encryption support of the delivery protocol? =20 =20 KL> There is no intention for DRM. It is an independent matter. This is only for encryption for the HAS session after URL of the manifest file is validated. One way to look at sections 3.5.3 and 3.5.4 is that after the initial URL for the Content Item is validated via URL Signing, access to related Content Collection can use alternative methods such as authorization token or session-based encryption during the HAS session. The advantage is these techniques do not require URL to be rewritten which is the method used by URL Signing. I should probably add one more option where all content for the Content Item use URL Signing for authorization. =20 or is the client expected to implement an alternate protocol? =20 =20 KL> It's not the intent to come up with new protocol. For example, HLS already supports this method. The section points out various solution options that are applicable to URL Signing. This may be applicable to some of the HAS technology as I'm not clear if it's universally possible. =20 And how is this synchronized across CDNs? =20 KL> See earlier comment about across CDNs. Both methods are limited to same CDN. =20 More generally, are we attempting to define security protocols for content delivery? If so, I would like to see a more formal definition of what those requirements are? =20 KL> No, there is no attempt to define security protocols. The objective was to identify the options that are available when URL Signing is used for authorization of HAS content. Once the CDN is HAS-aware, then related content can be grouped. There are several techniques used to group the chunks and possibly sub-level manifest files for the HAS session. There are advantages and disadvantages of each technique. =20 Kent =20 =20 -- Kevin J. Ma =20 From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: Friday, May 25, 2012 10:19 AM To: cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft =20 Hi all, =20 I've just uploaded a new version of draft-brandenburg-cdni-has. =20 You can find the document at: http://www.ietf.org/id/draft-brandenburg-cdni-has-01.txt =20 =20 The draft is meant as an input document for the virtual meeting on Thursday to discuss the impact of HTTP Adaptive Streaming on the CDNI Interfaces. In the draft a number of alternative solutions are presented for each area where the use of HAS might touch with the CDNI Interfaces (e.g. content acquisition, content purge, request routing, logging and URL signing).=20 =20 I'm looking forward to your comments. =20 Have a nice weekend! =20 Ray van Brandenburg =20 =20 =20 From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: woensdag 23 mei 2012 13:37 To: cdni@ietf.org Subject: [CDNi] Status of Adaptive Streaming and CDNI draft =20 Hi all, =20 Next Tuesday we have a planned interim meeting for discussing the combination between HTTP Adaptive Streaming and CDNI. One of the expected inputs for this meeting is a follow-up draft to draft-brandenburg-cdni-has-00.=20 =20 We are currently working hard at finishing this draft, but as you might have seen, we have not yet uploaded a new version. Currently we are at a stage where we have a first complete internal draft ready. However, Francois and I have agreed that we rather spend some more time on it so that it fully covers all the areas of the CDNI-HAS combination than upload an incomplete version right now. We are currently planning to upload the draft this Friday (25th of May) at the latest. I hope this gives you all enough time to read the draft before the meeting on Tuesday.=20 =20 Sorry for the delay. =20 Ray =20 =20 =20 This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer ------_=_NextPart_001_01CD3E2D.C94A9EC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kevin. Comments below.

 

From:= = Kevin J Ma [mailto:kevin.ma@azukisystems.com]
Sent: Tuesday, = May 29, 2012 9:14 PM
To: Kent Leung (kleung); Brandenburg, R. = (Ray) van; cdni@ietf.org
Subject: RE: URL Signing in Adaptive = Streaming and CDNI draft

 

Hi = Kent,

 

  With = respect to token time periods, it is difficult to estimate = when

  a = segment is actually going to be requested.  Web pages = typically

  = request everything immediately, but that's not the case with = HAS.

  = Maybe the player gets paused and its a while between manifest = request

 and = segment request, or maybe seeking causes segments to be = played

 out = of sequence.  You often end up needing long time periods on = all

 segments to prevent undue rejections, which limits = the value of

  = having URL tokens?

 

KL> I’m not clear what you mean by “URL tokens”. = Are you talking about Option 5.1 or 5.2?  If the latter, then the = authorization token is for the HAS session. This is not per chunk basis. = The cookie can be refreshed periodically during the session. So any = chunk can be requested during the HAS session as long as the cookie has = not expired. This is an issue for the former = case.

 

  To = Scott's point, we may need to differentiate between URL tokens = on

  = inter-CDN acquisition vs dCDN-to-end-user tokens.  Perhaps there = is

  more = value for the former than the latter?

 

KL> I agree that there is a difference between the tokens. But URL = Signing is about delivery authorization (or content access control) and = not content acquisition. The scheme used for acquisition does not have = to be the same as for delivery. We should not be figuring out how token = is used for different interfaces (e.g. between CDNs or between dCDN and = end user). Instead, we should be figuring out how to support HAS with = URL Signing. I think there are quite a few methods. Some of them may = depend on the capabilities of the HAS technology. If your point is that = this is not CDNI issue, I don’t have a problem with that. CDNI = does need to be aware that URL Signing is used for delivery to end user. = This impacts some of the CDNI Interfaces. As for how URL Signing is = optimized when CDN is HAS-aware, that may not need to be defined. So = using Authorization token, session-based encryption, or some other = methods don’t need to be described in detail. Maybe just the = concept that the manifest URL of the Content Item is protected by URL = Signing and the related content is associated for the HAS session is = sufficient?

 

> What = if the content is already encrypted?

> 

> KL> = CDN is not aware and don’t care if the content is = encrypted.

 

  I = don't think this is true.  Depending on how the encryption = is

  = being implemented, the CDN has to care if the content is = already

  = encrypted.  You mention HLS supporting encryption.  That is = true,

  but = you cannot double encrypt the content?  If we are talking = about

  = reusing existing HAS protocol support, then I think you need to = care

  what = existing encryption and DRM are in use.

 

  Are = you assuming this would only be performed on unencrypted = content

  and = that the CDN would have some business agreement with the CP = to

  = implement a DRM packaging function?  If not, I don't think we = can

  = assume one way or the other if the content is already = encrypted.

  The = manifest may not be available, and even if it is, the = manifest

  may = not tell you if the content is encrypted, especially if it = is

  = using a third party DRM.

 

KL> Maybe I’m missing your point. Double encryption happens = all the time. For example, I have an HTTPS session to a web server over = the business IPSec VPN. In this case, the content is encrypted with DRM. = The content may be transported over VPN between CSP and uCDN or between = uCDN and dCDN. The content may be delivered from dCDN to end user with = session-based encryption.

 

  Were = you anticipating that the encryption keys would be = session

  = specific?  Would they be client (subscriber) specific?  I = would be

  = interested in more details on the security of the key exchange?  = If

  the = keys are easily obtained, then there's little value in = having

  = segment encryption (as it pertains to = authorization)?

 

KL> So far, we’ve been talking in the context of the HAS = session. But the keying method can be flexible. Anyways, I offered the = Session-Based Encryption as an option to bind the HAS session with the = authorized manifest file for dCDN that is HAS-aware. The intent was to = give an example and not get into the detailed = implementation.

 

Maybe we should step back and look at the following to see if we are = on the right track?

 

1.       = URL Signing is a method to authorize content delivery (or content = access control)

2.       = CDNI needs URL Signing support on Request Routing (mandatory), = Metadata (mandatory), and Logging (optional) = Interfaces

3.       =  When URL Signing is used in CDN without HAS-awareness, = everything works fine with some caveats

a.       = Relative URL is signed for invariant portion of = URL

b.      = Request for signed URL needs to be within the expiration period (this = can be an issue)

4.       = When URL Signing is used in CDN with HAS-awareness, validation of the = URL for manifest of Original Content assumes that access to the Content = Collection is authorized for the HAS session (Details of the methods are = not CDNI related)

 

Kent

 

thanx.

 

--  = Kevin J. Ma

 

 

From:= = Kent Leung (kleung) [mailto:kleung@cisco.com]
Sent: Tuesday, = May 29, 2012 6:18 PM
To: Kevin J Ma; Brandenburg, R. (Ray) = van; cdni@ietf.org
Subject: URL Signing in Adaptive Streaming = and CDNI draft

 

Hi Kevin. Thanks for your feedback. I’ve separated the URL = Signing as a sub-topic of HAS draft.

 

Comments below.

 

From:= = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Kevin J Ma
Sent: Saturday, May 26, 2012 4:37 = PM
To: Brandenburg, R. (Ray) van; = cdni@ietf.org
Subject: Re: [CDNi] Status of Adaptive Streaming = and CDNI draft

 

<snip>

 

  With = respect to section 3.5, the time component of URL signing = is

  not = mentioned until section 3.5.3.  Expiration of URL tokens, = in

  = general, is an issue with HAS. 

 

KL> The “time period” or freshness of the signed URL = is mentioned in section 3.5. Perhaps it’s a bit cursory as an = example of potential authorization parameters in the embedded URL. I can = dedicate a paragraph in this section for URL expiration. NTP can be used = to sync the clocks on the entities that sign and validate the URL. Not = sure if the logging interface requires some timestamp mediation? If so, = maybe the same technique can be applied.

 

  Robust key = management is an arguably

  more reliable approach to content access = protection, though that

  = would seem to be fairly well out of scope for CDNI. 

 

KL> If the key management is out-of-band from the CDNI Interfaces, = then it would be out of scope.

 

  The = proposed

  = solution in section 3.5.3, seems to be managing session = state?

  = Depending on the complexity of the cookie, this could be = troublesome

  if = there is a failover and session state is not properly synchronized? =

 

KL> Yes, this option is for per-HAS-session. There are various = schemes to handle failover scenario, which is out of scope. =

 

  And in the case of live streaming, the = manifest is going to be

  = requested every time?  How is the state managed in that case?  =

 

KL> For live streaming, this depends on the HAS technology. I = don’t think the draft needs to get into the details of each = technology. The fundamental concept is there is a manifest file for a = Content Item which needs to be signed. And subsequent request  for = related content (i.e. chunk and sub-level manifest file) is associated = with the authorization.

 

  Is

  the = cookie less susceptible to replay attacks than the URL = token?

  Will = the cookie work across all CDNs? 

 

KL> I can add some more info on replay protection on the cookie. = Cookie expiration time can be used. No time synchronization issue for = the same surrogate case. Failover across surrogates in same CDN requires = NTP or other clock synchronization. Cookie method is not intended to = work across CDNs since redirection should happen in this = case.

 

  Moving on = to section 3.5.4

  is = even more concerning.  What if the content is already = encrypted?

 

KL> CDN is not aware and don’t care if the content is = encrypted. The session-based encryption is only a technique to link to = the authorized state of the Content Item.  

 

  How = is authentication being handled on the key server?  Who = is

  = responsible for auditing the security of the solution?  Is = this

  = intended to provide DRM?  work with existing DRM?  = circumvent

  = existing DRM?  Does it only use the DRM/encryption support of = the

  = delivery protocol? 

 

KL> There is no intention for DRM. It is an independent matter. = This is only for encryption for the HAS session after URL of the = manifest file is validated. One way to look at sections 3.5.3 and 3.5.4 = is that after the initial URL for the Content Item is validated via URL = Signing, access to related Content Collection can use alternative = methods such as authorization token or session-based encryption during = the HAS session. The advantage is these techniques do not require URL to = be rewritten which is the method used by URL Signing. I should probably = add one more option where all content for the Content Item use URL = Signing for authorization.

 

or is the = client expected to implement an

  alternate protocol? 

 

KL> It’s not the intent to come up with new protocol. For = example, HLS  already supports this method. The section points out = various solution options that are applicable to URL Signing. This may be = applicable to some of the HAS technology as I’m not clear if = it’s universally possible.

 

And how is = this synchronized across CDNs?

 

KL> See earlier comment about across CDNs. Both methods are = limited to same CDN.

 

  More = generally, are we attempting to define security protocols = for

  = content delivery?  If so, I would like to see a more = formal

 definition of what those requirements = are?

 

KL> No, there is no attempt to define security protocols. The = objective was to identify the options that are available when URL = Signing is used for authorization of HAS content. Once the CDN is = HAS-aware, then related content can be grouped. There are several = techniques used to group the chunks and possibly sub-level manifest = files for the HAS session. There are advantages and disadvantages of = each technique.

 

Kent

 

<snip>

 

--  = Kevin J. Ma

 

From:= = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Brandenburg, R. (Ray) van
Sent: Friday, May 25, 2012 10:19 = AM
To: cdni@ietf.org
Subject: Re: [CDNi] Status of = Adaptive Streaming and CDNI draft

 

Hi all,

 

I’ve just uploaded a new version of = draft-brandenburg-cdni-has.

 

You can find the document at: http://www.ietf.org/id/draft-brandenburg-cdni-has-01.txt

 

The draft is meant as an input document for the virtual meeting on = Thursday to discuss the impact of HTTP Adaptive Streaming on the CDNI = Interfaces. In the draft a number of alternative solutions are presented = for each area where the use of HAS might touch with the CDNI Interfaces = (e.g. content acquisition, content purge, request routing, logging and = URL signing).

 

I’m looking forward to your comments.

 

Have a nice weekend!

 

Ray van Brandenburg

 

 

 

From:= = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Brandenburg, R. (Ray) van
Sent: woensdag 23 mei 2012 = 13:37
To: cdni@ietf.org
Subject: [CDNi] Status of = Adaptive Streaming and CDNI draft

 

Hi = all,

 =

Next = Tuesday we have a planned interim meeting for discussing the combination = between HTTP Adaptive Streaming and CDNI. One  of the expected = inputs for this meeting is a follow-up draft to = draft-brandenburg-cdni-has-00.

 =

We are = currently working hard at finishing this draft, but as you might have = seen, we have not yet uploaded a new version. Currently we are at a = stage where we have a first complete internal draft ready. However, = Francois and I have agreed that we rather spend some more time on it so = that it fully covers all the areas of the CDNI-HAS combination than = upload an incomplete version right now. We are currently planning to = upload the draft this Friday (25th of May) = at the latest. I hope this gives you all enough time to read the draft = before the meeting on Tuesday.

 =

Sorry for = the delay.

 =

Ray

 =

 =

 =

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

------_=_NextPart_001_01CD3E2D.C94A9EC0-- From flefauch@cisco.com Tue May 29 23:50: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 CDD1421F86C9 for ; Tue, 29 May 2012 23:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.888 X-Spam-Level: X-Spam-Status: No, score=-9.888 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWk6H+GX3xHu for ; Tue, 29 May 2012 23:50:30 -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 77DAF21F86AF for ; Tue, 29 May 2012 23:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=31380; q=dns/txt; s=iport; t=1338360629; x=1339570229; h=from:mime-version:subject:date:in-reply-to:to:references: message-id; bh=OZpsp4JO6XZgjROdNbehjwBDm3Z4v3f/UO02xiMcN9U=; b=U+kGuOtENvFcvL184FoT0TReYMG3cU7q6h54PQ7JrKsYnL38ArRi8hng +6mpG4JobMZF+pso2mxSbShjRDwwCRUMWFlBvEsFnDKVu8+19FJcAS/Uh GZjAGrpfoTG2pDpWMfDyzs8jkD6lU/ofGcY0Zm2UPpvzm3AxX9iNKegUa E=; X-Files: image001.jpg, green.gif : 11041, 87 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABfCxU+Q/khM/2dsb2JhbABEgkWxXIEHghcBAQECAQEBAQECAQYGARIJNgoQCQIjBQEBAQocAhUECQIBMBgBCRmHZAULmSygDASLARWETWADj1NPhHaBD4Ihgh+IPYFmgmKBVQg X-IronPort-AV: E=Sophos;i="4.75,683,1330905600"; d="gif'147?jpg'147,145?scan'147,145,208,145,147,217";a="5130294" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 30 May 2012 06:50:28 +0000 Received: from [144.254.53.99] ([144.254.53.99]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q4U6oRgg017170 for ; Wed, 30 May 2012 06:50:28 GMT From: Francois Le Faucheur Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_D9D9088F-9F21-4401-86F2-1B45E55C2E53" Date: Wed, 30 May 2012 08:50:31 +0200 In-Reply-To: <31BDC4E6-A560-42CB-804F-A803CEF3D126@cisco.com> 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: [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, 30 May 2012 06:50:31 -0000 --Apple-Mail=_D9D9088F-9F21-4401-86F2-1B45E55C2E53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Folks, 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. 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 Looking forward to continuing our discussion (Notes from Yesterday's = discussion will come shortly). Cheers Francois & Rich 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. On 29 May 2012, at 11:07, Francois Le Faucheur wrote: > 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 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 Cisco Systems France Greenside 400 Ave de Roumanille 06410 Sophia Antipolis France Cisco.com =20 Think before you print. 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. 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. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --Apple-Mail=_D9D9088F-9F21-4401-86F2-1B45E55C2E53 Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_42F85008-E150-401C-B812-CDC86939C363" --Apple-Mail=_42F85008-E150-401C-B812-CDC86939C363 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

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/ma= ilman/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

 


 Think before you = print.
/9j/4AAQSkZJRgABAQEAYABgAAD/4QBmRXhpZgAASUkqAAgAAAAEABoBBQABAAAAPgAAABsBBQAB AAAARgAAACgBAwABAAAAAgAAADEBAgAQAAAATgAAAAAAAABgAAAAAQAAAGAAAAABAAAAUGFpbnQu TkVUIHYzLjM1AP/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/AABEIAGQAmgMBIgACEQEDEQH/xAAf AAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEF EiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJ SlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEB AAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIy gQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI ycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP7+KKKKACiiigAoor49 /wCCgOv634Y/Yu/aP1vw7qt9omsWnwy1mO01TTLmSzv7Rb57bT7prW6hZJraWSzuriETwuk0QkLx SJIFdenBYaWNxmEwcZqEsXiaGGjOSbjCVerCkptKzai53aTu0rI4syxscty7H5jOEqsMBgsVjZUo tRlUjhaFSvKEZNNRlNU3FNppN3asfX6SRyqWjdJFDyRlkZXUSQyNFKhKkgPFKjxyL95JEZGAZSA+ v54/+Df/AFzWLvwf+0zoF1qd7caJpHiL4YappelzXEkllYajrun+OoNZvLSBmKQT6nFomkJevGAZ xp9rvyYwa/ocr0eIcneQ5xjcpeIWKeElRSrqm6PtI1sPRxEW6bnU5Go1lGS9pJXi2m00ePwfxFHi zhzLOII4R4FZhDEN4R1liHRlhsZiMHNKsqVH2kZTw8pxl7KD5ZJOKaYUUUV4p9KFFFFABTGliR44 mkjWSXf5UbOqvL5Y3P5aEhn2KQz7QdoOTgU+v5DP+CqnjnxjYf8ABS23uLHxNrdlP4BX4NL4MmtN RureTwz52l6Hr8zaM0UimwebWNRvL+Z7fY0087tIX4A+k4X4elxNmFbARxUcG6OBr4z2sqLrKXsZ 0qcafIqlK3POtG8+Z8sVJqMnaL+M454whwVlGHzWeAnmKxGaYTLVQhiFhnH6zCvVlWdR0a1/Z08P Plp8i55yjFzhG8l/XnRRRXzZ9mFFFFABRRRQAUUUUAFVry4FnZ3V2UMgtbae4KA7S4gieUoGIIUs FwDg4znB6V/OT+zV+3z+0t4+/wCCpWtfB3xR43Oo/CXXviR8ZvANv4AOmaTDpOg6L4F0zxvd+Frn SLmCwj1GLV7Sfwxp/wDaWozXUsmsx3GoJeL+9tGsf6LNa/5A2rf9gy//APSWWvczrIcXkGJweGxs 6FSeMwWGx8HQlOUY0sRKpD2c3KEGqkJ0pqXKnFq0oyd9Pl+GOLMv4twWY43LaWKo08uzTGZTUWLh ThOdfCQo1HVpqnVqp0alOvTlDncZp80ZwVk3+C3/AASz/wCCiX7Rf7U/7RvxG+HPxg1Pw7rHha68 A698QPDVppnhzStDm8GXOkeJvC2lQ6Fpl5pltb3WraLNY+IrgTP4km1fWPtNpaTR6skf2mC4/SP/ AIKPf8mNftL/APZNr7/04adX8+H/AAQo/wCTyPFn/ZAfGv8A6m3w1r+g/wD4KPf8mNftL/8AZNr7 /wBOGnV9nxPgMFl3H+VYfAYWjhKH1jI5+xw9ONKmpvE04ykoRSipSUU5NK8pXlK8m2/zbgTNcyzn wmz7GZrjsTmGL+q8T03icXVlWrOnHB1Zxg6k25OMHOShFtqEbQgowjGK/Kf/AIN9/wDkDftVf9hP 4Nf+kvxOr9Sf+Cjn7QHj39mf9lDx18UPhjNYWfje31Pwr4f0TVNSsLbVLfR5PEOvWdhd6ommXsct jfXdtYtciyhvoZ7JbuSGe6truGF7Wb8tv+Dff/kDftVf9hP4Nf8ApL8Tq+2P+Cz/APyYj42/7Hf4 b/8AqT21PiChRxPiksPiKcK1CtmmR06tKpFSp1KcsHl6lCcXpKEldSi01JNppptE8JYvE4HwJljM HWqYbFYbIuJquHxFKThVo1YZjm7hVpTVpQqQlaUJxalCSUotNJnd/wDBLX9pj4n/ALVH7Mk3j34v Xum6t4z8PfEbxH4FuNd07SrLRTrtlpWjeGNbtNS1DTdLhtdJttR/4qOWymGlWNhZSRWcEq2kczzM /wCj1fi//wAEKP8AkzfxZ/2X7xr/AOoT8Nau/wDBZD9qn4zfs2/DT4R6b8GPFM3gjVviN4p8SR63 4m0+1sbjWodK8KadpNxHpenTaha3kVimo3mtwz3l5bRR3+zTo7WG5jtrq8in8PM8ieYcbY7I8shh 8Kq2Y4inh4NOlhqEKdKVedo04ycYQhCbjCELbQikrW+oyTipZR4Y5VxTndTGY94fJ8JWxdSLVfG4 qpVrQwtNudapBVKs6lSmp1KtRN+9UnKTu3+ydfhd/wAFbP28f2g/2VPiB8HfBfwR1zRfDFtrvhy/ 8Z+Jb+/8NaL4jutcFvrjaXa6BKmvWl9BYaT5VlcSXc2lx2WsTNdgW+qWggXf+gv/AAT3+Mvjj9oD 9jz4L/Fn4kXtvqfjfxJp3iyy1/VLazttPTVLjwn4/wDFfg231OWzsooLK3vNRsfD1reX6Wdvb2hv p7hra2t4GjhT8Lf+C+v/ACXb4G/9kl1L/wBTHVK6+C8nof66f2TmmHw2Mjg55nh69GpCNfDTr4SF ak5KNSPLUjGpBypuUFqoyspJW4PEriLErw0fEGRYzG5dLMKWR4zC4ijUlhcbTw2YVsLXjBzozcqV SVGooVVTqNWc6fPKDd/6avht4nuvG3w78A+M722gs73xd4L8LeJ7u0tTIbW1utf0Ox1W4trYzM8p gglu3ihMrvIY1UuzNkn+RX/gq9/yko8Tf90V/wDUS8K1/WJ8Av8AkhPwV/7JL8OP/UO0av5O/wDg q9/yko8Tf90V/wDUS8K16XhpGMOKc0hFWjDKsxjFLZRjjcGkvkkkeJ41znV4DyKpUk5TqZ9ks5yd rynPLswlKTtZXbbeisf2PV/Pl4W/4KQftF6z/wAFR7z9na61Dw6vwUj+MPi34Ox+DI/DulLcJb+H 31nSbXxSPExtT4kOuTajpkWpXFu+pvohgllsItLjPl3af0G1/Hr8P/8AlNbf/wDZ43xL/wDUl8V1 5fA+X4LHUuKJYzC0MS8NkGKq4d1qcansKqjNqrS5k/Z1YuK5asbThryyV3f3PFDN8zyvE8Cwy7HY nBRxvFuBoYxYarKksVh+empYevyte1w81OXtKM+alU054S5Y2/sKoor+bT/gmD+37+0z+0L+2N4g 8G/FDxz/AMJD4G8b+FvGfiK38JzaTpVtp3hG80aSzvdGj8LS2VnbX1jb2Vm0ulS29xd3cWoW8zXm ord6skWoR/O5ZkOMzXAZzmGHqUIUckw9LE4mNWU41KkavtnGNFRpzUpKGHqyfPKCuoxveV19jnvF mXZBmvDeUYyliqmJ4nxtbBYGdCFOVKjUovDRlPEynVhKMHUxeHgvZxqStKcmkoa/0l0UUV4h9QFF FFAH46/Bj/glXP8ACj9unV/2sZfivb6v4VXxd8R/HPhzwXH4fmttdTV/iLZ6/ZSaXrGqtfSWL6do aeKdSkgvbOAXOpSWOn+daWST3Sp+wlxBHdW89tKCYriGWCQKdrGOZGjcBhyCVY4PY81NRXp5nm+Y ZxVw9fMK/t6uGwtHB0ZKFOny0KDnKnG1KME5c1ScpTac5OWrskl4mR8O5Rw5h8Xhcnwv1WhjcdiM yxMHWrVufF4mNOFWadapUlCLhSpwjTg4wjGC5Yptt/kN+wN/wS6uP2L/AI1ePfivqPxVt/HVtqvh XV/Avg7SbPw/LpNxb6Fq3iHRtak1XxHcTXtxE2sRweHdOs0s9Njax33V/ObhgltGv1D/AMFHQT+w 3+0vgE/8W1vzxzwL/TyT9AASfQDNfbFYviTw5oPjDQNa8K+KdI0/X/DfiLTL3Rdd0TVbaK903VdK 1G3ktb6wvrWZWintrm3lkiljdSCrHGDgjqq5/jcbnWDzrNKjxdfDYjBVJuMKVJzpYOpCcacY04wg nJQfvcuspNs4KHCeWZXw1mPDWRUY4DC43CZnRpqdSviFTr5jRq05VZzrVKlWUYynH3VPSEFGNrH8 9P8Awb7g/wBjftUnBwdU+DYB7Ei0+J2Rn1GRn0yPWv2E/bU/ZpP7Wv7PPjH4KweJl8IanrVzoWsa Jr01i2pWNrq/h3VrbVbWHUrKOa3nl0+/WCWxuJLaZbizFyt9FFdm2+xXPe/Av9m74I/s0+H9W8Mf BD4f6Z4C0fXdVbWtZis73WdWvNT1ExmKOW91fxFqer6vcQ2sRaKwspL82OnRSSx2FtbJNKr+3115 9xD9f4oxHEOWqrhn9YweIwnt40nVpzweHw9KE6kFKrSbc6HO4c1SFnytyVzg4U4Q/srgbCcH53LD 46P1PMMJmH1WdeNCtTzHF4zEVIUaso0K6UaeK9mqnJSnzR54qLtb4p/YI/ZJuP2MfgQfhPqHjCDx vrOp+M9d8ca3rFlpsmlaZFqGs2Oi6Smn6ZbT3FzdNaWun6BYlrm6dZri8lupRDbwmKFOA/4KLfsK XP7cPgXwHo2ieObPwJ4q+HfiHU9V0q91bS7nVtF1LTtfs7Sy1nTryKyura6s7gNp+m3tjfxJeKrW k9jJaBb/AO22X6K0V50M9zOnnDz6GItmbr1MQ8R7KlZ1KsZQqfuuT2XJKnOVNwUElF2VnZnsVeFs jrcOLhSpg3LI1hKWDWE9vXUlRoThVpf7Qqnt/aQq04VVUdRyc43k2m0/nT9kv4Awfsu/s8fDX4Ew +IX8Vt4E0/WVvPED2Q05dT1TxJ4n1vxdrEtvY+fdNa2Meq6/eW+nwyXM8y2MNv58rzeYx+Lf+Cin /BNrU/23fFnwy8ZeHvidp/gHUvBmkX/hbWbXWdAutbs7/Q73UhqsF9prWV/Yyw6pYTy3sb2dzutd Riubci801rJ/tv6u0UYTPc0wOazzrDYnkzKrVxNapXdKjNTqYvneIlKlODpfvHUm7KCUW04KNlYz DhbI8zyClwzjMG6mS0KGCw1HCxr4inKnRy/2SwkY4inVjiL0lRpx5nVcpxTVRy5pX5rwX4ZtfBXg 7wn4Nsbie7svCXhrQvDNpdXIQXNza6DpdrpVvcXAiCxieaK0SSURqqCRmCALgV/IP/wVfVh/wUn8 SkggMPgsykggMv8AwinhdcqT1G5WXI43KR1Br+x2vnH4jfsi/s3fFv4m+F/jH8RvhL4c8VfEjwct gmheJL+XVomVNKunvNLXVtKstStdD8SDTbmR5bD/AISTTNW+xnatt5aIir6/CHEVDh7NsTmOMo18 THEYDFYZxoez9p7atUo1ozl7SUI8jnR5ZtO8VPmjGbjyP57xD4OxXF/D+CyfLcRhcFPCZtgMapYr 23svq+FpYjDzpxdKnVm6ip4jmppxUZypqE6lNS9pH6Or8edB/wCCVsmift93f7X4+K1vN4Rm+IGv /FWLwMPD86eIR4r8QJfTz6TJrJv3046FBrOpXOpJepZi9eyjh0Y2SSM2sL+w1FeHl2b5hlSxscDX 9iswwlTBYpezp1PaYer8cV7SEuSVrpVIcs4pu0lc+ozjh7KM+lls81wv1mWUZhRzPAP2tal7HGUH enN+yqQ9rC9nKlV56U3GPNB2QV+Nv7Ev/BKS4/ZG/aN1/wCNFx8WbTxb4etdE8SaB4H8O2nh2403 VEtPEVxCq3HiW/udRu7fzdL0yD7KsOnRyjUbyf7c9xYRW32K7/ZKings3zDLsLmODwlf2WHzWjCh joezpz9tTpupypSnCUqbSq1Y81NxfLUkr3s0s04dyjOcdk2ZZjhfb4zIMTUxeV1fbVqaw9er7Fzk 4UqkIVU5YehNRqxnFTpRaVnJSKKKK8w9sKKKKACuS8eeO/CHww8G+I/iB4916w8MeDvCWl3Gs+IN d1J2S10+wtgNzlY0knubiaRo7aysbSGe+1C9mt7Gxt7i8uIIJOtr8G/+C9PxE1zQvgl8Gvhvp1xc W2kfELx7rmteIfIMiR31v4C0rT207TLx1+R7V9S8UQaqttJkSXmj2dyoLWYK+bnGYf2XlmMx/Iqj w9LmhBtqMqk5xpUlJrXldScea2vLezTPtvDjhB8ecccOcJfWJYWnnGOdPE4mCjKrRwWFw9bHY6dF TTg66weFr+wU04e25OdON0/BvjR/wXr8VL4g1Cw/Z9+DnhdfDdpPJBp/iP4sz61qOpazEkmFvn8M eFdY8Px6LHMgJitH8SapOFKSzSwuXtU+3v8Agmv/AMFIfiD+2p4y8d+BvH3w88G+Fbzwb4QtvFMe teELzW0tr9p9Zs9JaxfR9audVltwBdG4FwusTH5BEYOTIPnv/gj1+xN8BfFH7P8AH8f/AIneAPCX xQ8Y+NfE3iPTtEg8baNpnijRPCWgeF9U/seOGw8PatHf6VHr19q+nXupT61dWX9pw2T6dbaa1lbm 7m1P9qfBfwF+Cvw38U6l41+Hfwq8BeAvE+s6Qug6xq3gvwvpPhaXVtLS7gvkttSg0O1sbO/eO5to Hjurq3lvI1jWFJ1hzGfmciocTYuWCzbGZtTeFxKVeeAjSik8PUhJ0knGmowk7wmkm5ctuao5XR+2 +KuaeCHD1Hibw94a8P8AGRz/ACWcsrw/F1XHVp1IZxgsTRjjp1IVsZKriKN6eKw05TjGj7Xmlh8H Gj7OS/PH/gqN+3j8Xv2JP+FGf8Kq8OfDfxB/ws3/AIWb/b3/AAsHSPE+q/ZP+EM/4V9/Zf8AZH/C OeMPCf2f7R/wleo/b/tn2/zfJsvs/wBl8uf7T9afsMfHnxf+03+yz8Lvjf4803w3pHizxt/wm39q 6f4Rs9UsPD1v/wAI38RfF3hGx/s+01nWNf1KLzdN0Cznu/tOrXfmX0tzLD5Fu8VtD+Of/BwV/wA2 kf8Ade//AHi9fpB/wSO/5R6/s+/91X/9Xd8Sq3wWPxlTjPN8vniKksHQy+lVo4dtezp1HTyxucVa 9261V7/bkeZxNwnw5hPo0eHvF2GyjCUeJc04wxuAzDOIRmsZi8HTxfHEIYerJzcHTjDLcDFJQTth qeujv8yftzf8Fg9O/Zy+JesfBn4OeA9I+IfjPwlPFaeNfEvifUb228J6Jq7RLNceG9P07SGg1HWt SsUlij1W7OqaZa6ZfCbTlhv7mG5Nr5N+xJ/wWB+Nn7Qv7Qfw8+CXxI+GHwttrT4galqmnx+IfBA8 W6DcaN/Z/h7VtcWZ9O17xD4vj1PzW0v7MY1u9O2ifzQ7GLy5Pze/bs+Evxi/ZC/bi8T/AByvvCUG u+GvEPxp1L4zfDjxJ4l0eXxD4C8Sy6t4jl8ZHwvrJJgie70W7uptG1TRZrmx1QWtpHqOnyi0uLDU n/Y39jj/AIK9fCn9pLxp4P8Ahb8X/AMHww+KWs38em+Ddat54tf8C634iu2SCz0vTr28gh1rwjrW sO6Wel2d2mpWN7cItmfEKX13YWFx4eFzfMMRn1ahmGdyymdHMI06GWzwSdDE4dVUlR+sNxUJVqaU YVKim5uanSlrGK/VM78O+D8m8JsszbhLwvw/iHQzPhGrjM140w3E1WnmuSZvUwDlLMFlFOlWqYmj l2LlKriMFg5YeOFWFnhsdRvGtWl+zep6np2i6bqGsavfWml6TpNjd6nqmp6hcRWlhp2nWEEl1e31 7dzvHBa2lpbRS3FzcTOkUMMbySOqKSP56/2if+C7WnaB4m1Lw3+zX8MtK8ZaTpdzNar8RPiJd6tZ 6VrkkTGNp9E8H6S+l6sulMymS0v9V16wvruJlMuiWBAMn2N/wWZ+I2veAP2JtfsNBuZ7J/iT478J /DnVrq2kaKZdB1CDWvEmq2wdeRBqlv4W/si9jyFnsdQurd8pMyn84P8Agi/+xj8FvjN4b+Ivx1+L /hPQviPL4a8ZL4A8JeD/ABTZ22r+GNOuLXQdK17Wde1bw9dtNYa7PeQ+INPsNLh1mxuNOsvseo3E UFzfPDPpvsZ5mWa184wvD+T1qeEq1KDxGJxc4qThC05ckOaM+VKELtxhzznOEVKEVNv858K+CeAM r8Oc88XfEjLsXxBgMFmscmyXh7C1qlKGIxN8NTeIxDpV8N7SVTEYl04wr144bD4fDYmvOhi6tXDU 4fVX/BPX/gqr8Wf2svjjY/Bj4j/Db4d6Mb/wx4j19fEvgmXxLpohk0G3iuBbNo2u6v4l85LoS7DI NWiaEruCy52j9jPix8VfAvwR+Hnin4p/ErXIfD3gvwfpx1HWdTljlnkCvNFaWdlZWkCvcX2panf3 Frp2m2Nujz3l9dW9vGu6QEc/4d/Z2+Avg7xdpvj3wb8G/hp4O8ZaRYX2l2PiTwh4L0Dwvqsem6lC ILywnutBsdPa9s5YxhLa9+0QwNmS3SKRi5/DL/gvp8S/EVnYfAD4R2N7c2nhnW28Y+OvEVpFKyQa xqWjPoujeGluURl8yPSI9Q1+ZYpVeN59QgmAEtrGw662JzHh7IMZicwxUczxdCf7iq4OCl7aVKjQ hUSUW1TqylOfvOUoJpTu0l83l+S8H+MXi1w5knB2Q1uCMgzShH+1sCsQsTOl/ZtLH5hmmIwVSc60 I1MXgaFLD4VOlGlSxTU54aVOM5VPN/ip/wAF7/iVca5eRfBL4KeBdI8NwzvHp998UrnxB4k1vUbd XXy7u70zwnrvhSx0eaaMNu0+HVtbS3dlxqVwEO/6I/ZS/wCC3nhv4leNNG+H/wC0V4E0j4ZTeIr6 10vSPiH4W1O+uvB1vqd7MYLW38TaTrBn1Lw9p0szQQf29HrGr2dtLN52qQaXpsNxqMPrP/BMj9gn 9nXRv2Zvh58VvHPw48FfFT4hfFrw9D4t1LWPHfh/R/GFjoOl6pJO2keHvDela3b6jpej/Y9LaNNY vre2XWNQ1G41CC9vP7PistNsfzZ/4LNfse/CP9n/AMSfDD4pfB7QNM8DaZ8T5/E2jeJvA2iRx2Ph 201vw7DpF5Z654b0eNhBpFvqNnqc1pqumaZDa6NZz2Gn3FpaQ3GpXjS/N1qvF+X5fS4grZlRxFJq hXr5fKnBRjh68oKEbRpRin+8gpqk4zhdtVJ8rv8AtmXZf9HXi/i/G+EGW8E5nlOPp1M0yrK+LqWM xLxFbNspo4ieKq3q42tVlB/U8TPDSx9KvhsS4KE8Jhva01H+r6ivhL/gmd8S/EXxZ/Yg+A/izxZe 3OpeIYND13wlf6leStcXWoQ+BfF3iDwdpN5dXMjNNd3k+iaJpr311cE3FzfG5mmeV3M0n3bX6Ng8 THGYTC4uCcYYrD0cRCMvijGtTjUUX5pSs/NH8Y8RZLiOHM/zzh7FVIVcTkWb5lk+Iq001Tq1stxl bB1KtNO7VOpOi5wTd+WSvqFFFFdB44UUUUAFfmP/AMFWP2TvEf7Uv7OSf8K+sH1X4mfCnXH8b+Ft FhGbvxNpj2E9h4p8LWALBTqV/Yta6rpUQV5r/VNCstIh2NqRkT9OKwPEviG08M6VPql2rSCPCQwI QJJ5nOEjTPc9Seygk8AkceYYShj8FicHib+wr0nCo07Sjs4zi3dKUJqM43TXNFXTWj+j4R4hzXhT ibJeIsk5XmmU4+lisLTqRc6Vd606uFrRjKEnQxVCdXDV1GcJ+xqz5KkJWmv43f2LP+Ckfxf/AGEr XxP8LdX+H8PjzwPJr97qN74B8TajqXgzxL4R8VgW9hq66bq0ulaxJpCXQskj1jQtS8O3ipqMC3dt /Z91JqY1H93f2BP+ClGu/twfFbx74Qk+E2k/DLw54O8BW3iWFU8W3njLW77VJ9fsNKKy6mdC8LWM Onrb3Mri2TRZLkzCNjfbFaOTpfjP8FfhF+0d4iOvfEL4B/D3xZraLFGusf2BqEHiue0tlMVtb6p4 k8O6hpOtanbWyMyW9teXMlpbhsQwocGvb/2UfgR8I/gzc+JF+H/wY8HfDTVb2xtLW81bRdH1KDXN T02OfzRY3+ra7f6rqtxaLcrHcfZxdpbtPGkskTyxxunx+TZdnmAxeGwsc4hXyfD1JctGVDlrVKXL Jxp80qM5U4qUk1BYlwSVkkrJf0Z4mcZ+FfFuQZ3ns/DrE5V4j5thcM62Z0c19tl2Fxbr4WNfFujS zHD0MVVqUY1KbxE8kWInKfPUqOd6j/I//g4K/wCbSP8Auvf/ALxev0g/4JHf8o9f2ff+6r/+ru+J Ve6/tG+FvA3ivUPC0Pj34QfB/wCKtpptnqkuiH4o/DzRfHU+g3F/PZpq40Z9aWZNMi1OOw0j7ctp FE92+n2xuZJhb2yw+zfCrRPDHhv4c+GtI8FeEPC3gPw/a2NzLY+FPBeg6d4a8L6TdXt9d3+qf2Vo Wkw21hYRX2sXN9qU6Qxh5ru8uLi4kmuZpp5PWwmVSpcT5lm/t4ShicHDDqhySU4OMMBHnc37jT+r N2Wvvx7M+Az/AI+oY/wL4K8O1lleliMk4jxWbzzZ4mjPDYiFavxTWVCGGivb06kVnkIuU24t4ao1 pOB+QXxM/wCCzf7OWheLfir8Hfix8BfH+vQeDPGnjTwHqFpaW3gXxl4a8SyeEfEOo6JDdXdh4l1T QEhtNSn01Lt7aay1BrASBVN88IaT8L/Bfh6D9rD9u7RG/Zm+FEnw28MeJvif4Z8TaL4M0qSOWw+H fhTQb3RJvEXie/ntYo7DRtMtWs73xJcWNkhstMub+Hw3oKXrjS4Lr+j7x7+xJ8FfiV4q13xd4q/Z b+HGq6/q2ralqes6vp+m+J/DTaxqd/dPcahqt7B4e8XaPBd3uo3LSXlzdzQyXFxczT3MkjzTzSSf Qn7PHhj4S/BNp/B3gn4NeCvha2qXIivr7whoq6fd6hcBsxQ69eXj3ut34iOBbyXuq3UcAISGGGPF eHismzbN8Xh45vj8J9SoYn2tKVHCOnipxUvdo+1dGmoKUW4tqpKClabhUlGNv1LIfErw+8O+H83x Hh7wpxA+J80yP+z8dRzDiGGK4fw9epSp+2zBYCOZYqeJlTrwVSmpYSliXS58LTxGGpV63NN+3z+z ZeftV/sw+PvhZoRtk8aL/Z/izwDJeSxW9q3i/wAM3BvLKwnuZiIbSPXrB9S8ONezOkNiNY+2TN5U Dg/ywfso/tkfHv8A4JwfETx14P1bwDNeadqd3b23xB+EfjpdT8M39rrWlxTJp2saVe/ZrifQtV8i 4Ecl6dM1TTtb0d4A9rceVpOoWX9q+r6raaLp9zqV6xW3tYy77Rl3P8KIO7ueAK+Avjn4M+Fv7R1z awfEj4F+APHqabG1to9/4i0a8uvFdjZtL50tvZeJNFvtJ1zT7O4lAmmsLK+jtmkG6UTMAw9PiHJp 4nF4bNMvxrwOa4eHs6cuRzp1aacrKaUZ8rXtJxbcKkakZezlBpJr4jwf8S8NkvD2d8CcYcLw4r4B zjFfXcVh1iI4bGYDGOOH554SVSrRjWjOWFwtaFOnicDWwmJp/W6OLhOcoVPm39jP/grFrf7Yf7Q/ h/4PWvwR0r4a6HdeF/Fev6rqlx48u/G+q3E2h2cc9nb6eY/Cng6zsInllH2lrm21N5I1KxeQzB16 L/gsL+yH4k/aL+Cnh/4i/DrTbzXPiJ8D59b1OPw1pts11qPinwV4hTTB4nsdMtYVNxe61o8uj6br mmWcW+W6s7fW7GytrrU76xgf2r9nT9nv4PfBjx5Y6n8NfgB8P/h/rd5Bc6dP4nt9I8RXniG2026A a9trDWPEuu6veWSXYjSOdLaaJZoVMMgaLKV+gGtazY6Dp8+p6hIUt4FyQgDSyufuxRISN8j4wq5A 7kgAkdOFwGKzDJcXgc9xccXUxE5qdelBUo0opUp0eSKpUI81GpBVf4ajKWkuZN38TOuL8i4R8TeH +KvCnh+vw/gcooYV4fKcfi6uPq4+rUnjaGZQxVWWPzOsqWZYPFSwUksZOpSp+/RdOUYOP8g37GP/ AAVu+J/7J3w7g+EfiT4eaf8AGHwLoU92/hC3vPFV34N8SeF4r65nvLzR01v+wfFVtf6Gl9PNdWNh caLFd6fJcXNvFqLWH2OzsvF/2g/2jP2hP+Cnnx38B+HdM8HRi7SSfw58Mvhl4Va9v7DQIdXuLafX Nb1fVrpFae4mjs7S68TeJrq30vS7HSNHtpXtNPtLGV3/AKNPi38Af2bvjh4lvPEnib9l/wCG2ta7 eXD3V9rg03VdK8Q6xOd6/btd1DwVqHhq51S6kjYCR9Tm1CQbY1NxIIISvo/wQ8P/AAu/Z9eTTfh3 8Dfh78PLW/EVrrV94S0F9O8S31okokjTVNc1Ge/1vWYrZ8ywWup6jLHG+5ojEzFj8x/YGb16VHK8 bnyqZNSnBRhToTVadOlKLp025Uk0kkuRTxFanRai4wkoRR+6f8Rd8Osqx2P474b8J6mE8S8ww+Jq VMRi81w08tw+NxtKUMTiqapY+dN1KrnUeJq4TKMtxeYRqVqdXE0Xiasz6E/Zj+B+mfs3fAT4Y/BL Sr0anD4C8OrY32qLF5Eeq6/qd9ea94n1WCDAa3ttS8Sarqt9bW8heWC3uIoppZpUeV/d6r2l1BfW 0F3bOJILiJJYnHdHAIz6EZwQeQQQelWK/SaNKnQo0qNGKjSo04UqUVqo06cVCEU+yikl5I/ijMsf jM0zHH5nmNWWIzDMcbisfjq80lOtjMXXqYjFVZqKSUqlepOckkknJpJLQKKKK0OIKKKKACvLfibY y39vpcQBMKzTyOv8PmBEWMkdztaTHpz68epVn6jYRX8HlSDlWDocZ2sARnHcEEg+xz2qKkOeEo97 fg0/xsdWDxH1XE0q/wDz7k35q8XG681e5yfw+0mz07RFaKFBczTym5kKgvuRsRrnkhRHtYDgZZiB zk93tUEsFAYjBOBkj0J64rm7TTLqxLfZZDGHxuUBWRsdCUYFc9ecA4PWta1S7WR2uZS6lMKuFVQd wJOFAGcdzzjjpSprlhGPK1ZW0tb1363u9N76DxU/bVqtd1VN1JOVm25atWjta0bpLW1lsrWPMfif pf8AaE2jvt3eXFer0zjL2xrtfBkH2XwzpVuRjyo51x6f6XcEfoavatpo1BoCRnyhIOf9sp/8TV6w tvstnFb9PLDj/vqR29/71TGnatOpb4o2v6KHl5dzWri/aZdh8Jf+DVlO19rurrbz5/8Ah9TiPEXi y+t55bLSYV3xEpLdSqXAfAysUZwMochmcMCchV4DHh9H8Hapq+txaxqCuq/akuri5mURvKYyMLEh AJztCghdiqMAkgKfVH0TbeNdRqpfzjOpYAjeW3nIPX5iensQRWzEb3egkESxj72xGBx+LsB+A/Lq JdJzmpVG2oyvGKS5Vqrf8HyT13N6ePWFoOnhIU4TqUuWrWbvVd0nJeeuqV+VNfDozjviNay3mhxQ Jko95F5qjugV2XPsHVfxNZ/w30SysbO8uDDGb17gIzsql0hCKUC55VWYvnGMle+K9EvbSO9t3gkG VYAjjOGBBVh7gj8Rkd6w7bSLiykL2sjRsRglcbWH+0jAq3qNynB6U3T/AHyqW5tLenTTTz7rdmVP F/8ACfPBc/s71HNvZSu4u0mt07Wfay3V0dKUQsGKKWX7rFQWH0JGR+Bryz4mWc1+mmQDcYFM8jKM 7WkGwDcOh2jBHHGT616HAl8JlaeUtGAcqFRQSeATtAPv6UupafFqEIRx80bbkb0OMEe4I7eoB6ir qR9pTlG1ua29tbNPz3tbUwwlb6piqNa6lyNu8bvl5ouN9baq938+pzngbR7DTNEtmt4YxcThnuZs AyNJuIKluoCfdC5AAHTNcz8SdCsrwafcpDGt4XlSRkUBpIgqkGTHXaxIDEZOcZOOO3tNNu7IMLaQ xq3JTCsmfUKwKgnuQATgZNRT6NNeSiS6dpGOAWbnao7Ko4A5JwABk+9RKHNSVPk2UV0srW1Xn8ur vszppYqVPHvG+3u3Kc73blJTTXI+nKrrS70irJNe7X8CwS23hy0gl3fu5LhU3ZyIxM4QDPYAYHtX YVBbQR20McEY2pGoUD6D9T6nueanrWK5Yxj/ACxS+5WOCvV9tWq1bW9pUlO3bmbf66hRRRVGQUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2Q== --Apple-Mail=_42F85008-E150-401C-B812-CDC86939C363 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=green.gif Content-Type: image/gif; name="green.gif" Content-Id: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --Apple-Mail=_42F85008-E150-401C-B812-CDC86939C363-- --Apple-Mail=_D9D9088F-9F21-4401-86F2-1B45E55C2E53-- From kevin.ma@azukisystems.com Wed May 30 05:28:39 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407D421F86E3 for ; Wed, 30 May 2012 05:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siErqdx3+Nwd for ; Wed, 30 May 2012 05:28:30 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 0C67921F86DE for ; Wed, 30 May 2012 05:28:29 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 1E8288BEC6A; Wed, 30 May 2012 08:28:29 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 18BC08BE559; Wed, 30 May 2012 08:28:24 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Wed, 30 May 2012 08:28:09 -0400 From: Kevin J Ma To: "Kent Leung (kleung)" , "Brandenburg, R. (Ray) van" , "cdni@ietf.org" Date: Wed, 30 May 2012 08:28:21 -0400 Thread-Topic: URL Signing in Adaptive Streaming and CDNI draft Thread-Index: Ac0414J5VzCVuofZTcKanwrNrKyoTABqTCnQAEHKv5AAk6xvUAAOxjgQAAPCBkAADrrj8A== Message-ID: <291CC3F9E50E7641901A54E85D0977C653267F5152@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> <7A2D6D1F6AC99243A77D32820D8ABBC20F18E20C@xmb-sjc-235.amer.cisco.com> <291CC3F9E50E7641901A54E85D0977C653267F5135@MAILR002.mail.lan> <7A2D6D1F6AC99243A77D32820D8ABBC20F18E349@xmb-sjc-235.amer.cisco.com> In-Reply-To: <7A2D6D1F6AC99243A77D32820D8ABBC20F18E349@xmb-sjc-235.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_291CC3F9E50E7641901A54E85D0977C653267F5152MAILR002maill_" MIME-Version: 1.0 Subject: Re: [CDNi] URL Signing in Adaptive Streaming and CDNI 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: Wed, 30 May 2012 12:28:39 -0000 --_000_291CC3F9E50E7641901A54E85D0977C653267F5152MAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent, KL> Maybe I'm missing your point. Double encryption happens all the time. F= or example, I have an HTTPS session to a web server over the business IPSec= VPN. This is true, but the termination of those tunnels is in different levels. L3 for IPSec. L5+ for HTTPS. L7+ for HLS. The order is well defined. If we are talking about using the encryption support of HLS or some other HAS protocol, and the encryption has already taken place, the client is not equipped to recognize that the content is encrypted multiple times. If we are just talking about using HTTPS, then thats different, since the transport is terminated at a lower layer than the HAS client decryption? In another example, if the CP and the client are using a third party DRM, layering on an additional encryption scheme which the client is forced to recognize and deal with may not work, e.g., a CP wants to deliver HLS to iPad, but has a corporate mandate to use Playready DRM and the segments are encrypted with Playready. That client is unlikedly to be able to handle some unexpected extra HLS encryption that a CDN may have added. In general, the order of the crypto operations is not well defined here. > Maybe we should step back and look at the following to see if we are on t= he right track? > 1. URL Signing is a method to authorize content delivery (or content acc= ess control) > 2. CDNI needs URL Signing support on Request Routing (mandatory), Metada= ta (mandatory), and Logging (optional) Interfaces > 3. When URL Signing is used in CDN without HAS-awareness, everything wor= ks fine with some caveats > a. Relative URL is signed for invariant portion of URL > b. Request for signed URL needs to be within the expiration period= (this can be an issue) > 4. When URL Signing is used in CDN with HAS-awareness, validation of the= URL for manifest of Original Content assumes that access to the Content Co= llection is authorized for the HAS session (Details of the methods are not = CDNI related) I agree with 1 and 2. I agree with 3, but think that b is a big issue. I have a fundamental problem with 4, however, in that: if content security matters, I dont think manifests should be delivered through the CDN, and without details of the exact (non-CDNI related) methods, I am unable to assess how secure they are or what they might break in the process? thanx. -- Kevin J. Ma From: Kent Leung (kleung) [mailto:kleung@cisco.com] Sent: Wednesday, May 30, 2012 2:31 AM To: Kevin J Ma; Brandenburg, R. (Ray) van; cdni@ietf.org Subject: RE: URL Signing in Adaptive Streaming and CDNI draft Hi Kevin. Comments below. From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] Sent: Tuesday, May 29, 2012 9:14 PM To: Kent Leung (kleung); Brandenburg, R. (Ray) van; cdni@ietf.org Subject: RE: URL Signing in Adaptive Streaming and CDNI draft Hi Kent, With respect to token time periods, it is difficult to estimate when a segment is actually going to be requested. Web pages typically request everything immediately, but that's not the case with HAS. Maybe the player gets paused and its a while between manifest request and segment request, or maybe seeking causes segments to be played out of sequence. You often end up needing long time periods on all segments to prevent undue rejections, which limits the value of having URL tokens? KL> I'm not clear what you mean by "URL tokens". Are you talking about Opti= on 5.1 or 5.2? If the latter, then the authorization token is for the HAS = session. This is not per chunk basis. The cookie can be refreshed periodica= lly during the session. So any chunk can be requested during the HAS sessio= n as long as the cookie has not expired. This is an issue for the former ca= se. To Scott's point, we may need to differentiate between URL tokens on inter-CDN acquisition vs dCDN-to-end-user tokens. Perhaps there is more value for the former than the latter? KL> I agree that there is a difference between the tokens. But URL Signing = is about delivery authorization (or content access control) and not content= acquisition. The scheme used for acquisition does not have to be the same = as for delivery. We should not be figuring out how token is used for differ= ent interfaces (e.g. between CDNs or between dCDN and end user). Instead, w= e should be figuring out how to support HAS with URL Signing. I think there= are quite a few methods. Some of them may depend on the capabilities of th= e HAS technology. If your point is that this is not CDNI issue, I don't hav= e a problem with that. CDNI does need to be aware that URL Signing is used = for delivery to end user. This impacts some of the CDNI Interfaces. As for = how URL Signing is optimized when CDN is HAS-aware, that may not need to be= defined. So using Authorization token, session-based encryption, or some o= ther methods don't need to be described in detail. Maybe just the concept t= hat the manifest URL of the Content Item is protected by URL Signing and th= e related content is associated for the HAS session is sufficient? > What if the content is already encrypted? > > KL> CDN is not aware and don't care if the content is encrypted. I don't think this is true. Depending on how the encryption is being implemented, the CDN has to care if the content is already encrypted. You mention HLS supporting encryption. That is true, but you cannot double encrypt the content? If we are talking about reusing existing HAS protocol support, then I think you need to care what existing encryption and DRM are in use. Are you assuming this would only be performed on unencrypted content and that the CDN would have some business agreement with the CP to implement a DRM packaging function? If not, I don't think we can assume one way or the other if the content is already encrypted. The manifest may not be available, and even if it is, the manifest may not tell you if the content is encrypted, especially if it is using a third party DRM. KL> Maybe I'm missing your point. Double encryption happens all the time. F= or example, I have an HTTPS session to a web server over the business IPSec= VPN. In this case, the content is encrypted with DRM. The content may be t= ransported over VPN between CSP and uCDN or between uCDN and dCDN. The cont= ent may be delivered from dCDN to end user with session-based encryption. Were you anticipating that the encryption keys would be session specific? Would they be client (subscriber) specific? I would be interested in more details on the security of the key exchange? If the keys are easily obtained, then there's little value in having segment encryption (as it pertains to authorization)? KL> So far, we've been talking in the context of the HAS session. But the k= eying method can be flexible. Anyways, I offered the Session-Based Encrypti= on as an option to bind the HAS session with the authorized manifest file f= or dCDN that is HAS-aware. The intent was to give an example and not get in= to the detailed implementation. Maybe we should step back and look at the following to see if we are on the= right track? 1. URL Signing is a method to authorize content delivery (or content = access control) 2. CDNI needs URL Signing support on Request Routing (mandatory), Met= adata (mandatory), and Logging (optional) Interfaces 3. When URL Signing is used in CDN without HAS-awareness, everything= works fine with some caveats a. Relative URL is signed for invariant portion of URL b. Request for signed URL needs to be within the expiration period (th= is can be an issue) 4. When URL Signing is used in CDN with HAS-awareness, validation of = the URL for manifest of Original Content assumes that access to the Content= Collection is authorized for the HAS session (Details of the methods are n= ot CDNI related) Kent thanx. -- Kevin J. Ma From: Kent Leung (kleung) [mailto:kleung@cisco.com] Sent: Tuesday, May 29, 2012 6:18 PM To: Kevin J Ma; Brandenburg, R. (Ray) van; cdni@ietf.org Subject: URL Signing in Adaptive Streaming and CDNI draft Hi Kevin. Thanks for your feedback. I've separated the URL Signing as a sub= -topic of HAS draft. Comments below. From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kev= in J Ma Sent: Saturday, May 26, 2012 4:37 PM To: Brandenburg, R. (Ray) van; cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft With respect to section 3.5, the time component of URL signing is not mentioned until section 3.5.3. Expiration of URL tokens, in general, is an issue with HAS. KL> The "time period" or freshness of the signed URL is mentioned in sectio= n 3.5. Perhaps it's a bit cursory as an example of potential authorization = parameters in the embedded URL. I can dedicate a paragraph in this section = for URL expiration. NTP can be used to sync the clocks on the entities that= sign and validate the URL. Not sure if the logging interface requires some= timestamp mediation? If so, maybe the same technique can be applied. Robust key management is an arguably more reliable approach to content access protection, though that would seem to be fairly well out of scope for CDNI. KL> If the key management is out-of-band from the CDNI Interfaces, then it = would be out of scope. The proposed solution in section 3.5.3, seems to be managing session state? Depending on the complexity of the cookie, this could be troublesome if there is a failover and session state is not properly synchronized? KL> Yes, this option is for per-HAS-session. There are various schemes to h= andle failover scenario, which is out of scope. And in the case of live streaming, the manifest is going to be requested every time? How is the state managed in that case? KL> For live streaming, this depends on the HAS technology. I don't think t= he draft needs to get into the details of each technology. The fundamental = concept is there is a manifest file for a Content Item which needs to be si= gned. And subsequent request for related content (i.e. chunk and sub-level= manifest file) is associated with the authorization. Is the cookie less susceptible to replay attacks than the URL token? Will the cookie work across all CDNs? KL> I can add some more info on replay protection on the cookie. Cookie exp= iration time can be used. No time synchronization issue for the same surrog= ate case. Failover across surrogates in same CDN requires NTP or other cloc= k synchronization. Cookie method is not intended to work across CDNs since = redirection should happen in this case. Moving on to section 3.5.4 is even more concerning. What if the content is already encrypted? KL> CDN is not aware and don't care if the content is encrypted. The sessio= n-based encryption is only a technique to link to the authorized state of t= he Content Item. How is authentication being handled on the key server? Who is responsible for auditing the security of the solution? Is this intended to provide DRM? work with existing DRM? circumvent existing DRM? Does it only use the DRM/encryption support of the delivery protocol? KL> There is no intention for DRM. It is an independent matter. This is onl= y for encryption for the HAS session after URL of the manifest file is vali= dated. One way to look at sections 3.5.3 and 3.5.4 is that after the initia= l URL for the Content Item is validated via URL Signing, access to related = Content Collection can use alternative methods such as authorization token = or session-based encryption during the HAS session. The advantage is these = techniques do not require URL to be rewritten which is the method used by U= RL Signing. I should probably add one more option where all content for the= Content Item use URL Signing for authorization. or is the client expected to implement an alternate protocol? KL> It's not the intent to come up with new protocol. For example, HLS alr= eady supports this method. The section points out various solution options = that are applicable to URL Signing. This may be applicable to some of the H= AS technology as I'm not clear if it's universally possible. And how is this synchronized across CDNs? KL> See earlier comment about across CDNs. Both methods are limited to same= CDN. More generally, are we attempting to define security protocols for content delivery? If so, I would like to see a more formal definition of what those requirements are? KL> No, there is no attempt to define security protocols. The objective was= to identify the options that are available when URL Signing is used for au= thorization of HAS content. Once the CDN is HAS-aware, then related content= can be grouped. There are several techniques used to group the chunks and = possibly sub-level manifest files for the HAS session. There are advantages= and disadvantages of each technique. Kent -- Kevin J. Ma From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Bra= ndenburg, R. (Ray) van Sent: Friday, May 25, 2012 10:19 AM To: cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft Hi all, I've just uploaded a new version of draft-brandenburg-cdni-has. You can find the document at: http://www.ietf.org/id/draft-brandenburg-cdni= -has-01.txt The draft is meant as an input document for the virtual meeting on Thursday= to discuss the impact of HTTP Adaptive Streaming on the CDNI Interfaces. I= n the draft a number of alternative solutions are presented for each area w= here the use of HAS might touch with the CDNI Interfaces (e.g. content acqu= isition, content purge, request routing, logging and URL signing). I'm looking forward to your comments. Have a nice weekend! Ray van Brandenburg From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Bra= ndenburg, R. (Ray) van Sent: woensdag 23 mei 2012 13:37 To: cdni@ietf.org Subject: [CDNi] Status of Adaptive Streaming and CDNI draft Hi all, Next Tuesday we have a planned interim meeting for discussing the combinati= on between HTTP Adaptive Streaming and CDNI. One of the expected inputs fo= r this meeting is a follow-up draft to draft-brandenburg-cdni-has-00. We are currently working hard at finishing this draft, but as you might hav= e seen, we have not yet uploaded a new version. Currently we are at a stage= where we have a first complete internal draft ready. However, Francois and= I have agreed that we rather spend some more time on it so that it fully c= overs all the areas of the CDNI-HAS combination than upload an incomplete v= ersion right now. We are currently planning to upload the draft this Friday= (25th of May) at the latest. I hope this gives you all enough time to read= the draft before the meeting on Tuesday. Sorry for the delay. Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_291CC3F9E50E7641901A54E85D0977C653267F5152MAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kent,

KL> Maybe I’m missing your poi= nt. Double encryption happens all the time. For example, I have an HTTPS se= ssion to a web server over the business IPSec VPN.

This is true, but the termination of tho= se tunnels is in different levels.

L3 for IPSec.&= nbsp; L5+ for HTTPS.  L7+ for HLS.  The order is well defined.

If we are talking about using the encryption suppor= t of HLS or some other

HAS protocol, and the encr= yption has already taken place, the client is

not= equipped to recognize that the content is encrypted multiple times.

If we are just talking about using HTTPS, then thats di= fferent, since the

transport is terminated at a l= ower layer than the HAS client decryption?

&= nbsp;

In another example, if the CP and the client are= using a third party DRM,

layering on an addition= al encryption scheme which the client is forced to

iPad, but has a corporate mandate to use Playread= y DRM and the segments

are encrypted with Playrea= dy.  That client is unlikedly to be able to

= handle some unexpected extra HLS encryption that a CDN may have added.=

In general, the order of the crypto operations is not= well defined here.

 

> Maybe we should step back and look at the following to see if we= are on the right track?

> 1.  URL Signin= g is a method to authorize content delivery (or content access control)

> 2.  CDNI needs URL Signing support on Requ= est Routing (mandatory), Metadata (mandatory), and Logging (optional) Inter= faces

> 3.  When URL Signing is used in = CDN without HAS-awareness, everything works fine with some caveats

>   a.      Relativ= e URL is signed for invariant portion of URL

>= ;   b.      Request for signed URL needs= to be within the expiration period (this can be an issue)

> 4.  When URL Signing is used in CDN with HAS-awareness,= validation of the URL for manifest of Original Content assumes that access= to the Content Collection is authorized for the HAS session (Details of th= e methods are not CDNI related)

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'> =

I agree with 1 and 2.  I agree with 3, but think that = b is a big issue.

I have a fundamental problem wi= th 4, however, in that: if content security

mat= ters, I dont think manifests should be delivered through the CDN, and<= /o:p>

without details of the exact (non-CDNI related) method= s, I am unable to

assess how secure they are or w= hat they might break in the process?

 <= /o:p>

thanx.

 

--  Kevin J. Ma

=  

From: Kent Leung (kleun= g) [mailto:kleung@cisco.com]
Sent: Wednesday, May 30, 2012 2:31 = AM
To: Kevin J Ma; Brandenburg, R. (Ray) van; cdni@ietf.org
Subject: RE: URL Signing in Adaptive Streaming and CDNI draft

 

Hi Kevin. Comments below.

 

From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]
Sent: = Tuesday, May 29, 2012 9:14 PM
To: Kent Leung (kleung); Brandenbur= g, R. (Ray) van; cdni@ietf.org
Subject: RE: URL Signing in Adapti= ve Streaming and CDNI draft

 

Hi Kent,

&n= bsp;

  With respect to token time periods, it is = difficult to estimate when

  a segment is ac= tually going to be requested.  Web pages typically

  request everything immediately, but that's not the case with = HAS.

  Maybe the player gets paused and its = a while between manifest request

=  and segmen= t request, or maybe seeking causes segments to be played<= /p>

 out of sequence.  You often end up needing long time per= iods on all

 segments to prevent undue rejec= tions, which limits the value of

=   having UR= L tokens?

 <= /p>

KL> I’m not clear what you mean by = “URL tokens”. Are you talking about Option 5.1 or 5.2?  If= the latter, then the authorization token is for the HAS session. This is n= ot per chunk basis. The cookie can be refreshed periodically during the ses= sion. So any chunk can be requested during the HAS session as long as the c= ookie has not expired. This is an issue for the former case.

 

  = To Scott's point, we may need to differentiate between URL tokens on

  inter-CDN acquisition vs dCDN-to-end-user tokens= .  Perhaps there is

  more value for th= e former than the latter?

&nbs= p;

KL> I agree that there is= a difference between the tokens. But URL Signing is about delivery authori= zation (or content access control) and not content acquisition. The scheme = used for acquisition does not have to be the same as for delivery. We shoul= d not be figuring out how token is used for different interfaces (e.g. betw= een CDNs or between dCDN and end user). Instead, we should be figuring out = how to support HAS with URL Signing. I think there are quite a few methods.= Some of them may depend on the capabilities of the HAS technology. If your= point is that this is not CDNI issue, I don’t have a problem with th= at. CDNI does need to be aware that URL Signing is used for delivery to end= user. This impacts some of the CDNI Interfaces. As for how URL Signing is = optimized when CDN is HAS-aware, that may not need to be defined. So using = Authorization token, session-based encryption, or some other methods don= 217;t need to be described in detail. Maybe just the concept that the manif= est URL of the Content Item is protected by URL Signing and the related con= tent is associated for the HAS session is sufficient?

=

 

> What if t= he content is already encrypted?

= > <= /o:p>

> KL> CDN is not aware and don’t care if t= he content is encrypted.

 =

  I don't think this is true.  Depending on how the encr= yption is

  being implemented, the CDN has t= o care if the content is already

=   encrypted= .  You mention HLS supporting encryption.  That is true,

  but you cannot double encrypt the content?  I= f we are talking about

  reusing existing HA= S protocol support, then I think you need to care

  what existing encryption and DRM are in use.

<= p class=3DMsoNormal> 

  Are you assuming this would onl= y be performed on unencrypted content

  and = that the CDN would have some business agreement with the CP to

  implement a DRM packaging function?  If not, I do= n't think we can

  assume one way or the oth= er if the content is already encrypted.

  Th= e manifest may not be available, and even if it is, the manifest=

  may not tell you if the content is encrypted, especi= ally if it is

  using a third party DRM.

 

KL> Maybe I’m missing your point. Double encry= ption happens all the time. For example, I have an HTTPS session to a web s= erver over the business IPSec VPN. In this case, the content is encrypted w= ith DRM. The content may be transported over VPN between CSP and uCDN or be= tween uCDN and dCDN. The content may be delivered from dCDN to end user wit= h session-based encryption.

 

  Were you anticipating that the en= cryption keys would be session

  specific?&n= bsp; Would they be client (subscriber) specific?  I would be

  interested in more details on the security of the k= ey exchange?  If

  the keys are easily = obtained, then there's little value in having

&nb= sp; segment encryption (as it pertains to authorization)?=

 

KL> So far, we’ve been talking in the context of the HAS sessi= on. But the keying method can be flexible. Anyways, I offered the Session-B= ased Encryption as an option to bind the HAS session with the authorized ma= nifest file for dCDN that is HAS-aware. The intent was to give an example a= nd not get into the detailed implementation.

 

Maybe we should step back and look at the following to see if we are on th= e right track?

 =

1.   &n= bsp;   URL Signing is a met= hod to authorize content delivery (or content access control)

2= .     = ;  CDNI needs URL Signing suppor= t on Request Routing (mandatory), Metadata (mandatory), and Logging (option= al) Interfaces

3.=        =  When URL Signing is used in CDN without HAS-awareness, everything wor= ks fine with some caveats

a.       Relative URL is signed for invariant portion of= URL

b.      Request for signed URL needs to be within the expiration period (this can = be an issue)

4.&nb= sp;      Whe= n URL Signing is used in CDN with HAS-awareness, validation of the URL for = manifest of Original Content assumes that access to the Content Collection = is authorized for the HAS session (Details of the methods are not CDNI rela= ted)

 

Kent

 

thanx.

 

--  Kevin J. Ma

 

 

From: Kent Leung (kleung) [mailto:kleu= ng@cisco.com]
Sent: Tuesday, May 29, 2012 6:18 PM
To: = Kevin J Ma; Brandenburg, R. (Ray) van; cdni@ietf.org
Subject: URL= Signing in Adaptive Streaming and CDNI draft

 

H= i Kevin. Thanks for your feedback. I’ve separated the URL Signing as = a sub-topic of HAS draft.

=  

Comments below.

 

<= div>

From: cdni-bounces@ietf.org [mailto:cdni-bo= unces@ietf.org] On Behalf Of Kevin J Ma
Sent: Saturday, Ma= y 26, 2012 4:37 PM
To: Brandenburg, R. (Ray) van; cdni@ietf.orgSubject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft

 

 

  With respect to section 3.5, the time component of URL signing= is

  not mentioned until section 3.5.3.&nbs= p; Expiration of URL tokens, in

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>  general, i= s an issue with HAS.  =

 

KL> The “time period” or freshness of th= e signed URL is mentioned in section 3.5. Perhaps it’s a bit cursory = as an example of potential authorization parameters in the embedded URL. I = can dedicate a paragraph in this section for URL expiration. NTP can be use= d to sync the clocks on the entities that sign and validate the URL. Not su= re if the logging interface requires some timestamp mediation? If so, maybe= the same technique can be applied.

 

  Robust key managemen= t is an arguably

  more reliable approach to= content access protection, though that

  wo= uld seem to be fairly well out of scope for CDNI. 

&n= bsp;

KL> If the key manageme= nt is out-of-band from the CDNI Interfaces, then it would be out of scope.<= o:p>

 

  The proposed

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>  solution i= n section 3.5.3, seems to be managing session state?

<= p class=3DMsoNormal>  Depending on the complexity of the cookie, this could be trouble= some

  if there is a failover and session st= ate is not properly synchronized?

 

KL> Yes= , this option is for per-HAS-session. There are various schemes to handle f= ailover scenario, which is out of scope.

 

  And in the cas= e of live streaming, the manifest is going to be

=   requested every time?  How is the state managed in that case?&n= bsp;

 

KL= > For live streaming, this depends on the HAS technology. I don’t = think the draft needs to get into the details of each technology. The funda= mental concept is there is a manifest file for a Content Item which needs t= o be signed. And subsequent request  for related content (i.e. chunk a= nd sub-level manifest file) is associated with the authorization.

 

  Is

  the cookie less suscept= ible to replay attacks than the URL token?

 = Will the cookie work across all CDNs?  =

 <= /span>

KL> I can add some more info on re= play protection on the cookie. Cookie expiration time can be used. No time = synchronization issue for the same surrogate case. Failover across surrogat= es in same CDN requires NTP or other clock synchronization. Cookie method i= s not intended to work across CDNs since redirection should happen in this = case.

 

  Moving on to section 3.5.4

 <= /span>

KL> CDN is not aware and don’= ;t care if the content is encrypted. The session-based encryption is only a= technique to link to the authorized state of the Content Item.  =

 

  responsible for auditing the security o= f the solution?  Is this

  intended to = provide DRM?  work with existing DRM?  circumvent

  existing DRM?  Does it only use the DRM/encryption s= upport of the

  delivery protocol? 

 

KL> The= re is no intention for DRM. It is an independent matter. This is only for e= ncryption for the HAS session after URL of the manifest file is validated. = One way to look at sections 3.5.3 and 3.5.4 is that after the initial URL f= or the Content Item is validated via URL Signing, access to related Content= Collection can use alternative methods such as authorization token or sess= ion-based encryption during the HAS session. The advantage is these techniq= ues do not require URL to be rewritten which is the method used by URL Sign= ing. I should probably add one more option where all content for the Conten= t Item use URL Signing for authorization.

 

or is the client expected = to implement an

  alternate protocol?  =

 

KL> = It’s not the intent to come up with new protocol. For example, HLS &n= bsp;already supports this method. The section points out various solution o= ptions that are applicable to URL Signing. This may be applicable to some o= f the HAS technology as I’m not clear if it’s universally possi= ble.

 

And how is this synchronized across CDNs?

=

 

KL> See earlier comment about across CDNs. Both methods are lim= ited to same CDN.

&nb= sp;

  More generally, are we attempting to define= security protocols for

  content delivery?&= nbsp; If so, I would like to see a more formal

&n= bsp;definition of what those requirements are?

 

KL> = No, there is no attempt to define security protocols. The objective was to = identify the options that are available when URL Signing is used for author= ization of HAS content. Once the CDN is HAS-aware, then related content can= be grouped. There are several techniques used to group the chunks and poss= ibly sub-level manifest files for the HAS session. There are advantages and= disadvantages of each technique.

 

Kent

 

<snip>

 

 <= /p>

From: cdni-bounces@ietf.org [mai= lto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) vanSent: Friday, May 25, 2012 10:19 AM
To: cdni@ietf.org
= Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft=

 

Hi all,

 

= I’ve just uploaded a new version of draft-brandenburg-cdni-has= .

 =

You can find the document at: http://www.ietf.org/id/draft-brandenburg-cdni-has-01= .txt

 

The draft is me= ant as an input document for the virtual meeting on Thursday to discuss the= impact of HTTP Adaptive Streaming on the CDNI Interfaces. In the draft a n= umber of alternative solutions are presented for each area where the use of= HAS might touch with the CDNI Interfaces (e.g. content acquisition, conten= t purge, request routing, logging and URL signing).

<= p class=3DMsoNormal> 

I’m looking forward to your comments.

 

= Have a nice weekend!

 

Ray van Brandenbu= rg

 

 

 

Fro= m: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Brandenburg, R. (Ray) van
Sent: woensdag 23 mei 2012 13:37To: cdni@ietf.org
Subject: [CDNi] Status of Adaptive Stre= aming and CDNI draft

=  

Hi= all,

 

Next Tuesday we have a pl= anned interim meeting for discussing the combination between HTTP Adaptive = Streaming and CDNI. One  of the expected inputs for this meeting is a = follow-up draft to draft-brandenburg-cdni-has-00.

 

We are currently working hard at finishing this draft, = but as you might have seen, we have not yet uploaded a new version. Current= ly we are at a stage where we have a first complete internal draft ready. H= owever, Francois and I have agreed that we rather spend some more time on i= t so that it fully covers all the areas of the CDNI-HAS combination than up= load an incomplete version right now. We are currently planning to upload t= he draft this Friday (25th of May) at the la= test. I hope this gives you all enough time to read the draft before the me= eting on Tuesday.

=  

Sorry for th= e delay.

 

Ray<= /p>

 

 

 

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

= --_000_291CC3F9E50E7641901A54E85D0977C653267F5152MAILR002maill_-- From kleung@cisco.com Wed May 30 11:25:08 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6AF21F842B for ; Wed, 30 May 2012 11:25:07 -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 Xjnd8pHQ8cqb for ; Wed, 30 May 2012 11:24:59 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7612011E80EA for ; Wed, 30 May 2012 11:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=71262; q=dns/txt; s=iport; t=1338402293; x=1339611893; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=fwN0gdQNaSE05zNtggZTKnZno4Ao2twBlf9Px++JFTo=; b=glYkl/Fjze8XhVI4CH+/jHuuxI1BGjLsLRlwpXqpMVO85jWz70nxFo0P 6tycxjmtaD9ToUxzjDd0VBoREP6JV7kXzjoSRmZoVm/OdRaXMxaIHVbss kXEr6QyzeZ4Djx/DQ3uDrwv3SSCbrXpxTFEauHtiUbb4yolgSDsii8mKt o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKZlxk+rRDoG/2dsb2JhbAA6CoJFsUyBB4IXAQEFEgEHAQERA0QKCwIBCBEEAQELBhABBgEGAUUJCAIEARoTB4VvgXkBC5khn3yLBRAEBoRMYAOIQJplgWaDAIE2AgcZ X-IronPort-AV: E=Sophos;i="4.75,685,1330905600"; d="scan'208,217";a="43874920" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 30 May 2012 18:20:37 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4UIKZIq020869; Wed, 30 May 2012 18:20:37 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 May 2012 11:20:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD3E90.E806A674" Date: Wed, 30 May 2012 11:20:34 -0700 Message-ID: <7A2D6D1F6AC99243A77D32820D8ABBC20F18E547@xmb-sjc-235.amer.cisco.com> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C653267F5152@MAILR002.mail.lan> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: URL Signing in Adaptive Streaming and CDNI draft Thread-Index: Ac0414J5VzCVuofZTcKanwrNrKyoTABqTCnQAEHKv5AAk6xvUAAOxjgQAAPCBkAADrrj8AAL4puw References: <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> <7A2D6D1F6AC99243A77D32820D8ABBC20F18E20C@xmb-sjc-235.amer.cisco.com> <291CC3F9E50E7641901A54E85D0977C653267F5135@MAILR002.mail.lan> <7A2D6D1F6AC99243A77D32820D8ABBC20F18E349@xmb-sjc-235.amer.cisco.com> <291CC3F9E50E7641901A54E85D0977C653267F5152@MAILR002.mail.lan> From: "Kent Leung (kleung)" To: "Kevin J Ma" , "Brandenburg, R. (Ray) van" , X-OriginalArrivalTime: 30 May 2012 18:20:36.0013 (UTC) FILETIME=[E879EDD0:01CD3E90] Subject: Re: [CDNi] URL Signing in Adaptive Streaming and CDNI 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: Wed, 30 May 2012 18:25:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD3E90.E806A674 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]=20 Sent: Wednesday, May 30, 2012 5:28 AM To: Kent Leung (kleung); Brandenburg, R. (Ray) van; cdni@ietf.org Subject: RE: URL Signing in Adaptive Streaming and CDNI draft =20 Hi Kent, =20 KL> Maybe I'm missing your point. Double encryption happens all the time. For example, I have an HTTPS session to a web server over the business IPSec VPN. =20 This is true, but the termination of those tunnels is in different levels. L3 for IPSec. L5+ for HTTPS. L7+ for HLS. The order is well defined. If we are talking about using the encryption support of HLS or some other HAS protocol, and the encryption has already taken place, the client is not equipped to recognize that the content is encrypted multiple times. If we are just talking about using HTTPS, then thats different, since the transport is terminated at a lower layer than the HAS client decryption? =20 In another example, if the CP and the client are using a third party DRM, layering on an additional encryption scheme which the client is forced to recognize and deal with may not work, e.g., a CP wants to deliver HLS to iPad, but has a corporate mandate to use Playready DRM and the segments are encrypted with Playready. That client is unlikedly to be able to handle some unexpected extra HLS encryption that a CDN may have added. In general, the order of the crypto operations is not well defined here. =20 KL> Agree that the order of crypto operations is needed to function properly. Have you encountered real world problems with this scenario? =20 > Maybe we should step back and look at the following to see if we are on the right track? > 1. URL Signing is a method to authorize content delivery (or content access control) > 2. CDNI needs URL Signing support on Request Routing (mandatory), Metadata (mandatory), and Logging (optional) Interfaces > 3. When URL Signing is used in CDN without HAS-awareness, everything works fine with some caveats > a. Relative URL is signed for invariant portion of URL > b. Request for signed URL needs to be within the expiration period (this can be an issue) > 4. When URL Signing is used in CDN with HAS-awareness, validation of the URL for manifest of Original Content assumes that access to the Content Collection is authorized for the HAS session (Details of the methods are not CDNI related) =20 I agree with 1 and 2. I agree with 3, but think that b is a big issue. I have a fundamental problem with 4, however, in that: if content security matters, I dont think manifests should be delivered through the CDN, and without details of the exact (non-CDNI related) methods, I am unable to assess how secure they are or what they might break in the process? =20 KL> Manifest file delivered via dCDN or not is another factor. This is a generic HAS issue. We still have to consider the case when manifest file is from the same dCDN used for chunk delivery for URL Signing. I think the section can describe how the requests can be associated with an HAS session to provide the logical bundling for all the content for the Original Content. =20 Kent =20 thanx. =20 -- Kevin J. Ma =20 From: Kent Leung (kleung) [mailto:kleung@cisco.com]=20 Sent: Wednesday, May 30, 2012 2:31 AM To: Kevin J Ma; Brandenburg, R. (Ray) van; cdni@ietf.org Subject: RE: URL Signing in Adaptive Streaming and CDNI draft =20 Hi Kevin. Comments below. =20 From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]=20 Sent: Tuesday, May 29, 2012 9:14 PM To: Kent Leung (kleung); Brandenburg, R. (Ray) van; cdni@ietf.org Subject: RE: URL Signing in Adaptive Streaming and CDNI draft =20 Hi Kent, =20 With respect to token time periods, it is difficult to estimate when a segment is actually going to be requested. Web pages typically request everything immediately, but that's not the case with HAS. Maybe the player gets paused and its a while between manifest request and segment request, or maybe seeking causes segments to be played out of sequence. You often end up needing long time periods on all segments to prevent undue rejections, which limits the value of having URL tokens? =20 KL> I'm not clear what you mean by "URL tokens". Are you talking about Option 5.1 or 5.2? If the latter, then the authorization token is for the HAS session. This is not per chunk basis. The cookie can be refreshed periodically during the session. So any chunk can be requested during the HAS session as long as the cookie has not expired. This is an issue for the former case. =20 To Scott's point, we may need to differentiate between URL tokens on inter-CDN acquisition vs dCDN-to-end-user tokens. Perhaps there is more value for the former than the latter? =20 KL> I agree that there is a difference between the tokens. But URL Signing is about delivery authorization (or content access control) and not content acquisition. The scheme used for acquisition does not have to be the same as for delivery. We should not be figuring out how token is used for different interfaces (e.g. between CDNs or between dCDN and end user). Instead, we should be figuring out how to support HAS with URL Signing. I think there are quite a few methods. Some of them may depend on the capabilities of the HAS technology. If your point is that this is not CDNI issue, I don't have a problem with that. CDNI does need to be aware that URL Signing is used for delivery to end user. This impacts some of the CDNI Interfaces. As for how URL Signing is optimized when CDN is HAS-aware, that may not need to be defined. So using Authorization token, session-based encryption, or some other methods don't need to be described in detail. Maybe just the concept that the manifest URL of the Content Item is protected by URL Signing and the related content is associated for the HAS session is sufficient? =20 > What if the content is already encrypted? >=20 > KL> CDN is not aware and don't care if the content is encrypted. =20 I don't think this is true. Depending on how the encryption is being implemented, the CDN has to care if the content is already encrypted. You mention HLS supporting encryption. That is true, but you cannot double encrypt the content? If we are talking about reusing existing HAS protocol support, then I think you need to care what existing encryption and DRM are in use. =20 Are you assuming this would only be performed on unencrypted content and that the CDN would have some business agreement with the CP to implement a DRM packaging function? If not, I don't think we can assume one way or the other if the content is already encrypted. The manifest may not be available, and even if it is, the manifest may not tell you if the content is encrypted, especially if it is using a third party DRM. =20 KL> Maybe I'm missing your point. Double encryption happens all the time. For example, I have an HTTPS session to a web server over the business IPSec VPN. In this case, the content is encrypted with DRM. The content may be transported over VPN between CSP and uCDN or between uCDN and dCDN. The content may be delivered from dCDN to end user with session-based encryption. =20 Were you anticipating that the encryption keys would be session specific? Would they be client (subscriber) specific? I would be interested in more details on the security of the key exchange? If the keys are easily obtained, then there's little value in having segment encryption (as it pertains to authorization)? =20 KL> So far, we've been talking in the context of the HAS session. But the keying method can be flexible. Anyways, I offered the Session-Based Encryption as an option to bind the HAS session with the authorized manifest file for dCDN that is HAS-aware. The intent was to give an example and not get into the detailed implementation. =20 Maybe we should step back and look at the following to see if we are on the right track? =20 1. URL Signing is a method to authorize content delivery (or content access control) 2. CDNI needs URL Signing support on Request Routing (mandatory), Metadata (mandatory), and Logging (optional) Interfaces 3. When URL Signing is used in CDN without HAS-awareness, everything works fine with some caveats a. Relative URL is signed for invariant portion of URL b. Request for signed URL needs to be within the expiration period (this can be an issue) 4. When URL Signing is used in CDN with HAS-awareness, validation of the URL for manifest of Original Content assumes that access to the Content Collection is authorized for the HAS session (Details of the methods are not CDNI related) =20 Kent =20 thanx. =20 -- Kevin J. Ma =20 =20 From: Kent Leung (kleung) [mailto:kleung@cisco.com]=20 Sent: Tuesday, May 29, 2012 6:18 PM To: Kevin J Ma; Brandenburg, R. (Ray) van; cdni@ietf.org Subject: URL Signing in Adaptive Streaming and CDNI draft =20 Hi Kevin. Thanks for your feedback. I've separated the URL Signing as a sub-topic of HAS draft. =20 Comments below. =20 From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kevin J Ma Sent: Saturday, May 26, 2012 4:37 PM To: Brandenburg, R. (Ray) van; cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft =20 =20 With respect to section 3.5, the time component of URL signing is not mentioned until section 3.5.3. Expiration of URL tokens, in general, is an issue with HAS. =20 =20 KL> The "time period" or freshness of the signed URL is mentioned in section 3.5. Perhaps it's a bit cursory as an example of potential authorization parameters in the embedded URL. I can dedicate a paragraph in this section for URL expiration. NTP can be used to sync the clocks on the entities that sign and validate the URL. Not sure if the logging interface requires some timestamp mediation? If so, maybe the same technique can be applied. =20 Robust key management is an arguably more reliable approach to content access protection, though that would seem to be fairly well out of scope for CDNI. =20 =20 KL> If the key management is out-of-band from the CDNI Interfaces, then it would be out of scope. =20 The proposed solution in section 3.5.3, seems to be managing session state? Depending on the complexity of the cookie, this could be troublesome if there is a failover and session state is not properly synchronized? =20 KL> Yes, this option is for per-HAS-session. There are various schemes to handle failover scenario, which is out of scope.=20 =20 And in the case of live streaming, the manifest is going to be requested every time? How is the state managed in that case? =20 =20 KL> For live streaming, this depends on the HAS technology. I don't think the draft needs to get into the details of each technology. The fundamental concept is there is a manifest file for a Content Item which needs to be signed. And subsequent request for related content (i.e. chunk and sub-level manifest file) is associated with the authorization. =20 Is the cookie less susceptible to replay attacks than the URL token? Will the cookie work across all CDNs? =20 =20 KL> I can add some more info on replay protection on the cookie. Cookie expiration time can be used. No time synchronization issue for the same surrogate case. Failover across surrogates in same CDN requires NTP or other clock synchronization. Cookie method is not intended to work across CDNs since redirection should happen in this case. =20 Moving on to section 3.5.4 is even more concerning. What if the content is already encrypted? =20 KL> CDN is not aware and don't care if the content is encrypted. The session-based encryption is only a technique to link to the authorized state of the Content Item. =20 =20 How is authentication being handled on the key server? Who is responsible for auditing the security of the solution? Is this intended to provide DRM? work with existing DRM? circumvent existing DRM? Does it only use the DRM/encryption support of the delivery protocol? =20 =20 KL> There is no intention for DRM. It is an independent matter. This is only for encryption for the HAS session after URL of the manifest file is validated. One way to look at sections 3.5.3 and 3.5.4 is that after the initial URL for the Content Item is validated via URL Signing, access to related Content Collection can use alternative methods such as authorization token or session-based encryption during the HAS session. The advantage is these techniques do not require URL to be rewritten which is the method used by URL Signing. I should probably add one more option where all content for the Content Item use URL Signing for authorization. =20 or is the client expected to implement an alternate protocol? =20 =20 KL> It's not the intent to come up with new protocol. For example, HLS already supports this method. The section points out various solution options that are applicable to URL Signing. This may be applicable to some of the HAS technology as I'm not clear if it's universally possible. =20 And how is this synchronized across CDNs? =20 KL> See earlier comment about across CDNs. Both methods are limited to same CDN. =20 More generally, are we attempting to define security protocols for content delivery? If so, I would like to see a more formal definition of what those requirements are? =20 KL> No, there is no attempt to define security protocols. The objective was to identify the options that are available when URL Signing is used for authorization of HAS content. Once the CDN is HAS-aware, then related content can be grouped. There are several techniques used to group the chunks and possibly sub-level manifest files for the HAS session. There are advantages and disadvantages of each technique. =20 Kent =20 =20 -- Kevin J. Ma =20 From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: Friday, May 25, 2012 10:19 AM To: cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft =20 Hi all, =20 I've just uploaded a new version of draft-brandenburg-cdni-has. =20 You can find the document at: http://www.ietf.org/id/draft-brandenburg-cdni-has-01.txt =20 =20 The draft is meant as an input document for the virtual meeting on Thursday to discuss the impact of HTTP Adaptive Streaming on the CDNI Interfaces. In the draft a number of alternative solutions are presented for each area where the use of HAS might touch with the CDNI Interfaces (e.g. content acquisition, content purge, request routing, logging and URL signing).=20 =20 I'm looking forward to your comments. =20 Have a nice weekend! =20 Ray van Brandenburg =20 =20 =20 From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: woensdag 23 mei 2012 13:37 To: cdni@ietf.org Subject: [CDNi] Status of Adaptive Streaming and CDNI draft =20 Hi all, =20 Next Tuesday we have a planned interim meeting for discussing the combination between HTTP Adaptive Streaming and CDNI. One of the expected inputs for this meeting is a follow-up draft to draft-brandenburg-cdni-has-00.=20 =20 We are currently working hard at finishing this draft, but as you might have seen, we have not yet uploaded a new version. Currently we are at a stage where we have a first complete internal draft ready. However, Francois and I have agreed that we rather spend some more time on it so that it fully covers all the areas of the CDNI-HAS combination than upload an incomplete version right now. We are currently planning to upload the draft this Friday (25th of May) at the latest. I hope this gives you all enough time to read the draft before the meeting on Tuesday.=20 =20 Sorry for the delay. =20 Ray =20 =20 =20 This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer ------_=_NextPart_001_01CD3E90.E806A674 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:= = Kevin J Ma [mailto:kevin.ma@azukisystems.com]
Sent: = Wednesday, May 30, 2012 5:28 AM
To: Kent Leung (kleung); = Brandenburg, R. (Ray) van; cdni@ietf.org
Subject: RE: URL = Signing in Adaptive Streaming and CDNI = draft

 

Hi = Kent,

 

KL> = Maybe I’m missing your point. Double encryption happens all the = time. For example, I have an HTTPS session to a web server over the = business IPSec VPN.

 

This is = true, but the termination of those tunnels is in different = levels.

L3 for = IPSec.  L5+ for HTTPS.  L7+ for HLS.  The order is well = defined.

If we are = talking about using the encryption support of HLS or some = other

HAS = protocol, and the encryption has already taken place, the client = is

not = equipped to recognize that the content is encrypted multiple = times.

If we are = just talking about using HTTPS, then thats different, since = the

transport = is terminated at a lower layer than the HAS client = decryption?

 

In another = example, if the CP and the client are using a third party = DRM,

layering on = an additional encryption scheme which the client is forced = to

recognize = and deal with may not work, e.g., a CP wants to deliver HLS = to

iPad, but = has a corporate mandate to use Playready DRM and the = segments

are = encrypted with Playready.  That client is unlikedly to be able = to

handle some = unexpected extra HLS encryption that a CDN may have = added.

In general, = the order of the crypto operations is not well defined = here.

 

KL> Agree that the order of crypto operations is needed to = function properly. Have you encountered real world problems with this = scenario?

 

> Maybe = we should step back and look at the following to see if we are on the = right track?

> = 1.  URL Signing is a method to authorize content delivery (or = content access control)

> = 2.  CDNI needs URL Signing support on Request Routing (mandatory), = Metadata (mandatory), and Logging (optional) = Interfaces

> = 3.  When URL Signing is used in CDN without HAS-awareness, = everything works fine with some caveats

>   a.      Relative = URL is signed for invariant portion of URL

>   b.      Request = for signed URL needs to be within the expiration period (this can be an = issue)

> = 4.  When URL Signing is used in CDN with HAS-awareness, validation = of the URL for manifest of Original Content assumes that access to the = Content Collection is authorized for the HAS session (Details of the = methods are not CDNI related)

 

I agree = with 1 and 2.  I agree with 3, but think that b is a big = issue.

I have a = fundamental problem with 4, however, in that: if content = security

matters, I = dont think manifests should be delivered through the CDN, = and

without = details of the exact (non-CDNI related) methods, I am unable = to

assess how = secure they are or what they might break in the = process?

 

KL> Manifest file delivered via dCDN or not is another factor. = This is a generic HAS issue. We still have to consider the case when = manifest file is from the same dCDN used for chunk delivery for URL = Signing. I think the section can describe how the requests can be = associated with an HAS session to provide the logical bundling for all = the content for the Original Content.

 

Kent

 

thanx.

 

--  = Kevin J. Ma

 

From:= = Kent Leung (kleung) [mailto:kleung@cisco.com]
Sent: = Wednesday, May 30, 2012 2:31 AM
To: Kevin J Ma; Brandenburg, = R. (Ray) van; cdni@ietf.org
Subject: RE: URL Signing in = Adaptive Streaming and CDNI draft

 

Hi Kevin. Comments below.

 

From:= = Kevin J Ma [mailto:kevin.ma@azukisystems.com]
Sent: Tuesday, = May 29, 2012 9:14 PM
To: Kent Leung (kleung); Brandenburg, R. = (Ray) van; cdni@ietf.org
Subject: RE: URL Signing in Adaptive = Streaming and CDNI draft

 

Hi = Kent,

 

  With = respect to token time periods, it is difficult to estimate = when

  a = segment is actually going to be requested.  Web pages = typically

  = request everything immediately, but that's not the case with = HAS.

  = Maybe the player gets paused and its a while between manifest = request

 and = segment request, or maybe seeking causes segments to be = played

 out = of sequence.  You often end up needing long time periods on = all

 segments to prevent undue rejections, which limits = the value of

  = having URL tokens?

 

KL> I’m not clear what you mean by “URL tokens”. = Are you talking about Option 5.1 or 5.2?  If the latter, then the = authorization token is for the HAS session. This is not per chunk basis. = The cookie can be refreshed periodically during the session. So any = chunk can be requested during the HAS session as long as the cookie has = not expired. This is an issue for the former = case.

 

  To = Scott's point, we may need to differentiate between URL tokens = on

  = inter-CDN acquisition vs dCDN-to-end-user tokens.  Perhaps there = is

  more = value for the former than the latter?

 

KL> I agree that there is a difference between the tokens. But URL = Signing is about delivery authorization (or content access control) and = not content acquisition. The scheme used for acquisition does not have = to be the same as for delivery. We should not be figuring out how token = is used for different interfaces (e.g. between CDNs or between dCDN and = end user). Instead, we should be figuring out how to support HAS with = URL Signing. I think there are quite a few methods. Some of them may = depend on the capabilities of the HAS technology. If your point is that = this is not CDNI issue, I don’t have a problem with that. CDNI = does need to be aware that URL Signing is used for delivery to end user. = This impacts some of the CDNI Interfaces. As for how URL Signing is = optimized when CDN is HAS-aware, that may not need to be defined. So = using Authorization token, session-based encryption, or some other = methods don’t need to be described in detail. Maybe just the = concept that the manifest URL of the Content Item is protected by URL = Signing and the related content is associated for the HAS session is = sufficient?

 

> What = if the content is already encrypted?

> 

> KL> = CDN is not aware and don’t care if the content is = encrypted.

 

  I = don't think this is true.  Depending on how the encryption = is

  = being implemented, the CDN has to care if the content is = already

  = encrypted.  You mention HLS supporting encryption.  That is = true,

  but = you cannot double encrypt the content?  If we are talking = about

  = reusing existing HAS protocol support, then I think you need to = care

  what = existing encryption and DRM are in use.

 

  Are = you assuming this would only be performed on unencrypted = content

  and = that the CDN would have some business agreement with the CP = to

  = implement a DRM packaging function?  If not, I don't think we = can

  = assume one way or the other if the content is already = encrypted.

  The = manifest may not be available, and even if it is, the = manifest

  may = not tell you if the content is encrypted, especially if it = is

  = using a third party DRM.

 

KL> Maybe I’m missing your point. Double encryption happens = all the time. For example, I have an HTTPS session to a web server over = the business IPSec VPN. In this case, the content is encrypted with DRM. = The content may be transported over VPN between CSP and uCDN or between = uCDN and dCDN. The content may be delivered from dCDN to end user with = session-based encryption.

 

  Were = you anticipating that the encryption keys would be = session

  = specific?  Would they be client (subscriber) specific?  I = would be

  = interested in more details on the security of the key exchange?  = If

  the = keys are easily obtained, then there's little value in = having

  = segment encryption (as it pertains to = authorization)?

 

KL> So far, we’ve been talking in the context of the HAS = session. But the keying method can be flexible. Anyways, I offered the = Session-Based Encryption as an option to bind the HAS session with the = authorized manifest file for dCDN that is HAS-aware. The intent was to = give an example and not get into the detailed = implementation.

 

Maybe we should step back and look at the following to see if we are = on the right track?

 

1.       = URL Signing is a method to authorize content delivery (or content = access control)

2.       = CDNI needs URL Signing support on Request Routing (mandatory), = Metadata (mandatory), and Logging (optional) = Interfaces

3.       =  When URL Signing is used in CDN without HAS-awareness, = everything works fine with some caveats

a.       = Relative URL is signed for invariant portion of = URL

b.      = Request for signed URL needs to be within the expiration period (this = can be an issue)

4.       = When URL Signing is used in CDN with HAS-awareness, validation of the = URL for manifest of Original Content assumes that access to the Content = Collection is authorized for the HAS session (Details of the methods are = not CDNI related)

 

Kent

 

thanx.

 

--  = Kevin J. Ma

 

 

From:= = Kent Leung (kleung) [mailto:kleung@cisco.com]
Sent: Tuesday, = May 29, 2012 6:18 PM
To: Kevin J Ma; Brandenburg, R. (Ray) = van; cdni@ietf.org
Subject: URL Signing in Adaptive Streaming = and CDNI draft

 

Hi Kevin. Thanks for your feedback. I’ve separated the URL = Signing as a sub-topic of HAS draft.

 

Comments below.

 

From:= = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Kevin J Ma
Sent: Saturday, May 26, 2012 4:37 = PM
To: Brandenburg, R. (Ray) van; = cdni@ietf.org
Subject: Re: [CDNi] Status of Adaptive Streaming = and CDNI draft

 

<snip>

 

  With = respect to section 3.5, the time component of URL signing = is

  not = mentioned until section 3.5.3.  Expiration of URL tokens, = in

  = general, is an issue with HAS. 

 

KL> The “time period” or freshness of the signed URL = is mentioned in section 3.5. Perhaps it’s a bit cursory as an = example of potential authorization parameters in the embedded URL. I can = dedicate a paragraph in this section for URL expiration. NTP can be used = to sync the clocks on the entities that sign and validate the URL. Not = sure if the logging interface requires some timestamp mediation? If so, = maybe the same technique can be applied.

 

  Robust key = management is an arguably

  more reliable approach to content access = protection, though that

  = would seem to be fairly well out of scope for CDNI. 

 

KL> If the key management is out-of-band from the CDNI Interfaces, = then it would be out of scope.

 

  The = proposed

  = solution in section 3.5.3, seems to be managing session = state?

  = Depending on the complexity of the cookie, this could be = troublesome

  if = there is a failover and session state is not properly synchronized? =

 

KL> Yes, this option is for per-HAS-session. There are various = schemes to handle failover scenario, which is out of scope. =

 

  And in the case of live streaming, the = manifest is going to be

  = requested every time?  How is the state managed in that case?  =

 

KL> For live streaming, this depends on the HAS technology. I = don’t think the draft needs to get into the details of each = technology. The fundamental concept is there is a manifest file for a = Content Item which needs to be signed. And subsequent request  for = related content (i.e. chunk and sub-level manifest file) is associated = with the authorization.

 

  Is

  the = cookie less susceptible to replay attacks than the URL = token?

  Will = the cookie work across all CDNs? 

 

KL> I can add some more info on replay protection on the cookie. = Cookie expiration time can be used. No time synchronization issue for = the same surrogate case. Failover across surrogates in same CDN requires = NTP or other clock synchronization. Cookie method is not intended to = work across CDNs since redirection should happen in this = case.

 

  Moving on = to section 3.5.4

  is = even more concerning.  What if the content is already = encrypted?

 

KL> CDN is not aware and don’t care if the content is = encrypted. The session-based encryption is only a technique to link to = the authorized state of the Content Item.  

 

  How = is authentication being handled on the key server?  Who = is

  = responsible for auditing the security of the solution?  Is = this

  = intended to provide DRM?  work with existing DRM?  = circumvent

  = existing DRM?  Does it only use the DRM/encryption support of = the

  = delivery protocol? 

 

KL> There is no intention for DRM. It is an independent matter. = This is only for encryption for the HAS session after URL of the = manifest file is validated. One way to look at sections 3.5.3 and 3.5.4 = is that after the initial URL for the Content Item is validated via URL = Signing, access to related Content Collection can use alternative = methods such as authorization token or session-based encryption during = the HAS session. The advantage is these techniques do not require URL to = be rewritten which is the method used by URL Signing. I should probably = add one more option where all content for the Content Item use URL = Signing for authorization.

 

or is the = client expected to implement an

  alternate protocol? 

 

KL> It’s not the intent to come up with new protocol. For = example, HLS  already supports this method. The section points out = various solution options that are applicable to URL Signing. This may be = applicable to some of the HAS technology as I’m not clear if = it’s universally possible.

 

And how is = this synchronized across CDNs?

 

KL> See earlier comment about across CDNs. Both methods are = limited to same CDN.

 

  More = generally, are we attempting to define security protocols = for

  = content delivery?  If so, I would like to see a more = formal

 definition of what those requirements = are?

 

KL> No, there is no attempt to define security protocols. The = objective was to identify the options that are available when URL = Signing is used for authorization of HAS content. Once the CDN is = HAS-aware, then related content can be grouped. There are several = techniques used to group the chunks and possibly sub-level manifest = files for the HAS session. There are advantages and disadvantages of = each technique.

 

Kent

 

<snip>

 

--  = Kevin J. Ma

 

From:= = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Brandenburg, R. (Ray) van
Sent: Friday, May 25, 2012 10:19 = AM
To: cdni@ietf.org
Subject: Re: [CDNi] Status of = Adaptive Streaming and CDNI draft

 

Hi all,

 

I’ve just uploaded a new version of = draft-brandenburg-cdni-has.

 

You can find the document at: http://www.ietf.org/id/draft-brandenburg-cdni-has-01.txt

 

The draft is meant as an input document for the virtual meeting on = Thursday to discuss the impact of HTTP Adaptive Streaming on the CDNI = Interfaces. In the draft a number of alternative solutions are presented = for each area where the use of HAS might touch with the CDNI Interfaces = (e.g. content acquisition, content purge, request routing, logging and = URL signing).

 

I’m looking forward to your comments.

 

Have a nice weekend!

 

Ray van Brandenburg

 

 

 

From:= = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Brandenburg, R. (Ray) van
Sent: woensdag 23 mei 2012 = 13:37
To: cdni@ietf.org
Subject: [CDNi] Status of = Adaptive Streaming and CDNI draft

 

Hi = all,

 =

Next = Tuesday we have a planned interim meeting for discussing the combination = between HTTP Adaptive Streaming and CDNI. One  of the expected = inputs for this meeting is a follow-up draft to = draft-brandenburg-cdni-has-00.

 =

We are = currently working hard at finishing this draft, but as you might have = seen, we have not yet uploaded a new version. Currently we are at a = stage where we have a first complete internal draft ready. However, = Francois and I have agreed that we rather spend some more time on it so = that it fully covers all the areas of the CDNI-HAS combination than = upload an incomplete version right now. We are currently planning to = upload the draft this Friday (25th of May) = at the latest. I hope this gives you all enough time to read the draft = before the meeting on Tuesday.

 =

Sorry for = the delay.

 =

Ray

 =

 =

 =

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

------_=_NextPart_001_01CD3E90.E806A674-- From kevin.ma@azukisystems.com Wed May 30 11:39: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 2873411E80FA for ; Wed, 30 May 2012 11:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9Bxv6lz85s0 for ; Wed, 30 May 2012 11:39:21 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 32D3A11E810A for ; Wed, 30 May 2012 11:39:20 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id A4925553BEC; Wed, 30 May 2012 14:39:19 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB027.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 9951B55350C; Wed, 30 May 2012 14:39:03 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB027.mail.lan ([10.110.17.27]) with mapi; Wed, 30 May 2012 14:39:01 -0400 From: Kevin J Ma To: "Kent Leung (kleung)" , "Brandenburg, R. (Ray) van" , "cdni@ietf.org" Date: Wed, 30 May 2012 14:38:59 -0400 Thread-Topic: URL Signing in Adaptive Streaming and CDNI draft Thread-Index: Ac0414J5VzCVuofZTcKanwrNrKyoTABqTCnQAEHKv5AAk6xvUAAOxjgQAAPCBkAADrrj8AAL4puwAAIEW8A= Message-ID: <291CC3F9E50E7641901A54E85D0977C653267F53DC@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> <7A2D6D1F6AC99243A77D32820D8ABBC20F18E20C@xmb-sjc-235.amer.cisco.com> <291CC3F9E50E7641901A54E85D0977C653267F5135@MAILR002.mail.lan> <7A2D6D1F6AC99243A77D32820D8ABBC20F18E349@xmb-sjc-235.amer.cisco.com> <291CC3F9E50E7641901A54E85D0977C653267F5152@MAILR002.mail.lan> <7A2D6D1F6AC99243A77D32820D8ABBC20F18E547@xmb-sjc-235.amer.cisco.com> In-Reply-To: <7A2D6D1F6AC99243A77D32820D8ABBC20F18E547@xmb-sjc-235.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_291CC3F9E50E7641901A54E85D0977C653267F53DCMAILR002maill_" MIME-Version: 1.0 Subject: Re: [CDNi] URL Signing in Adaptive Streaming and CDNI 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: Wed, 30 May 2012 18:39:30 -0000 --_000_291CC3F9E50E7641901A54E85D0977C653267F53DCMAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent, KL> Agree that the order of crypto operations is needed to function properl= y. Have you encountered real world problems with this scenario? The Playready-HLS scenario is real. I have not yet had a CDN try to insert HLS encryption over top of it, and I sincerely hope that I never do.... From: Kent Leung (kleung) [mailto:kleung@cisco.com] Sent: Wednesday, May 30, 2012 2:21 PM To: Kevin J Ma; Brandenburg, R. (Ray) van; cdni@ietf.org Subject: RE: URL Signing in Adaptive Streaming and CDNI draft From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] Sent: Wednesday, May 30, 2012 5:28 AM To: Kent Leung (kleung); Brandenburg, R. (Ray) van; cdni@ietf.org Subject: RE: URL Signing in Adaptive Streaming and CDNI draft Hi Kent, KL> Maybe I'm missing your point. Double encryption happens all the time. F= or example, I have an HTTPS session to a web server over the business IPSec= VPN. This is true, but the termination of those tunnels is in different levels. L3 for IPSec. L5+ for HTTPS. L7+ for HLS. The order is well defined. If we are talking about using the encryption support of HLS or some other HAS protocol, and the encryption has already taken place, the client is not equipped to recognize that the content is encrypted multiple times. If we are just talking about using HTTPS, then thats different, since the transport is terminated at a lower layer than the HAS client decryption? In another example, if the CP and the client are using a third party DRM, layering on an additional encryption scheme which the client is forced to recognize and deal with may not work, e.g., a CP wants to deliver HLS to iPad, but has a corporate mandate to use Playready DRM and the segments are encrypted with Playready. That client is unlikedly to be able to handle some unexpected extra HLS encryption that a CDN may have added. In general, the order of the crypto operations is not well defined here. KL> Agree that the order of crypto operations is needed to function properl= y. Have you encountered real world problems with this scenario? > Maybe we should step back and look at the following to see if we are on t= he right track? > 1. URL Signing is a method to authorize content delivery (or content acc= ess control) > 2. CDNI needs URL Signing support on Request Routing (mandatory), Metada= ta (mandatory), and Logging (optional) Interfaces > 3. When URL Signing is used in CDN without HAS-awareness, everything wor= ks fine with some caveats > a. Relative URL is signed for invariant portion of URL > b. Request for signed URL needs to be within the expiration period= (this can be an issue) > 4. When URL Signing is used in CDN with HAS-awareness, validation of the= URL for manifest of Original Content assumes that access to the Content Co= llection is authorized for the HAS session (Details of the methods are not = CDNI related) I agree with 1 and 2. I agree with 3, but think that b is a big issue. I have a fundamental problem with 4, however, in that: if content security matters, I dont think manifests should be delivered through the CDN, and without details of the exact (non-CDNI related) methods, I am unable to assess how secure they are or what they might break in the process? KL> Manifest file delivered via dCDN or not is another factor. This is a ge= neric HAS issue. We still have to consider the case when manifest file is f= rom the same dCDN used for chunk delivery for URL Signing. I think the sect= ion can describe how the requests can be associated with an HAS session to = provide the logical bundling for all the content for the Original Content. Kent thanx. -- Kevin J. Ma From: Kent Leung (kleung) [mailto:kleung@cisco.com] Sent: Wednesday, May 30, 2012 2:31 AM To: Kevin J Ma; Brandenburg, R. (Ray) van; cdni@ietf.org Subject: RE: URL Signing in Adaptive Streaming and CDNI draft Hi Kevin. Comments below. From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] Sent: Tuesday, May 29, 2012 9:14 PM To: Kent Leung (kleung); Brandenburg, R. (Ray) van; cdni@ietf.org Subject: RE: URL Signing in Adaptive Streaming and CDNI draft Hi Kent, With respect to token time periods, it is difficult to estimate when a segment is actually going to be requested. Web pages typically request everything immediately, but that's not the case with HAS. Maybe the player gets paused and its a while between manifest request and segment request, or maybe seeking causes segments to be played out of sequence. You often end up needing long time periods on all segments to prevent undue rejections, which limits the value of having URL tokens? KL> I'm not clear what you mean by "URL tokens". Are you talking about Opti= on 5.1 or 5.2? If the latter, then the authorization token is for the HAS = session. This is not per chunk basis. The cookie can be refreshed periodica= lly during the session. So any chunk can be requested during the HAS sessio= n as long as the cookie has not expired. This is an issue for the former ca= se. To Scott's point, we may need to differentiate between URL tokens on inter-CDN acquisition vs dCDN-to-end-user tokens. Perhaps there is more value for the former than the latter? KL> I agree that there is a difference between the tokens. But URL Signing = is about delivery authorization (or content access control) and not content= acquisition. The scheme used for acquisition does not have to be the same = as for delivery. We should not be figuring out how token is used for differ= ent interfaces (e.g. between CDNs or between dCDN and end user). Instead, w= e should be figuring out how to support HAS with URL Signing. I think there= are quite a few methods. Some of them may depend on the capabilities of th= e HAS technology. If your point is that this is not CDNI issue, I don't hav= e a problem with that. CDNI does need to be aware that URL Signing is used = for delivery to end user. This impacts some of the CDNI Interfaces. As for = how URL Signing is optimized when CDN is HAS-aware, that may not need to be= defined. So using Authorization token, session-based encryption, or some o= ther methods don't need to be described in detail. Maybe just the concept t= hat the manifest URL of the Content Item is protected by URL Signing and th= e related content is associated for the HAS session is sufficient? > What if the content is already encrypted? > > KL> CDN is not aware and don't care if the content is encrypted. I don't think this is true. Depending on how the encryption is being implemented, the CDN has to care if the content is already encrypted. You mention HLS supporting encryption. That is true, but you cannot double encrypt the content? If we are talking about reusing existing HAS protocol support, then I think you need to care what existing encryption and DRM are in use. Are you assuming this would only be performed on unencrypted content and that the CDN would have some business agreement with the CP to implement a DRM packaging function? If not, I don't think we can assume one way or the other if the content is already encrypted. The manifest may not be available, and even if it is, the manifest may not tell you if the content is encrypted, especially if it is using a third party DRM. KL> Maybe I'm missing your point. Double encryption happens all the time. F= or example, I have an HTTPS session to a web server over the business IPSec= VPN. In this case, the content is encrypted with DRM. The content may be t= ransported over VPN between CSP and uCDN or between uCDN and dCDN. The cont= ent may be delivered from dCDN to end user with session-based encryption. Were you anticipating that the encryption keys would be session specific? Would they be client (subscriber) specific? I would be interested in more details on the security of the key exchange? If the keys are easily obtained, then there's little value in having segment encryption (as it pertains to authorization)? KL> So far, we've been talking in the context of the HAS session. But the k= eying method can be flexible. Anyways, I offered the Session-Based Encrypti= on as an option to bind the HAS session with the authorized manifest file f= or dCDN that is HAS-aware. The intent was to give an example and not get in= to the detailed implementation. Maybe we should step back and look at the following to see if we are on the= right track? 1. URL Signing is a method to authorize content delivery (or content = access control) 2. CDNI needs URL Signing support on Request Routing (mandatory), Met= adata (mandatory), and Logging (optional) Interfaces 3. When URL Signing is used in CDN without HAS-awareness, everything= works fine with some caveats a. Relative URL is signed for invariant portion of URL b. Request for signed URL needs to be within the expiration period (th= is can be an issue) 4. When URL Signing is used in CDN with HAS-awareness, validation of = the URL for manifest of Original Content assumes that access to the Content= Collection is authorized for the HAS session (Details of the methods are n= ot CDNI related) Kent thanx. -- Kevin J. Ma From: Kent Leung (kleung) [mailto:kleung@cisco.com] Sent: Tuesday, May 29, 2012 6:18 PM To: Kevin J Ma; Brandenburg, R. (Ray) van; cdni@ietf.org Subject: URL Signing in Adaptive Streaming and CDNI draft Hi Kevin. Thanks for your feedback. I've separated the URL Signing as a sub= -topic of HAS draft. Comments below. From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kev= in J Ma Sent: Saturday, May 26, 2012 4:37 PM To: Brandenburg, R. (Ray) van; cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft With respect to section 3.5, the time component of URL signing is not mentioned until section 3.5.3. Expiration of URL tokens, in general, is an issue with HAS. KL> The "time period" or freshness of the signed URL is mentioned in sectio= n 3.5. Perhaps it's a bit cursory as an example of potential authorization = parameters in the embedded URL. I can dedicate a paragraph in this section = for URL expiration. NTP can be used to sync the clocks on the entities that= sign and validate the URL. Not sure if the logging interface requires some= timestamp mediation? If so, maybe the same technique can be applied. Robust key management is an arguably more reliable approach to content access protection, though that would seem to be fairly well out of scope for CDNI. KL> If the key management is out-of-band from the CDNI Interfaces, then it = would be out of scope. The proposed solution in section 3.5.3, seems to be managing session state? Depending on the complexity of the cookie, this could be troublesome if there is a failover and session state is not properly synchronized? KL> Yes, this option is for per-HAS-session. There are various schemes to h= andle failover scenario, which is out of scope. And in the case of live streaming, the manifest is going to be requested every time? How is the state managed in that case? KL> For live streaming, this depends on the HAS technology. I don't think t= he draft needs to get into the details of each technology. The fundamental = concept is there is a manifest file for a Content Item which needs to be si= gned. And subsequent request for related content (i.e. chunk and sub-level= manifest file) is associated with the authorization. Is the cookie less susceptible to replay attacks than the URL token? Will the cookie work across all CDNs? KL> I can add some more info on replay protection on the cookie. Cookie exp= iration time can be used. No time synchronization issue for the same surrog= ate case. Failover across surrogates in same CDN requires NTP or other cloc= k synchronization. Cookie method is not intended to work across CDNs since = redirection should happen in this case. Moving on to section 3.5.4 is even more concerning. What if the content is already encrypted? KL> CDN is not aware and don't care if the content is encrypted. The sessio= n-based encryption is only a technique to link to the authorized state of t= he Content Item. How is authentication being handled on the key server? Who is responsible for auditing the security of the solution? Is this intended to provide DRM? work with existing DRM? circumvent existing DRM? Does it only use the DRM/encryption support of the delivery protocol? KL> There is no intention for DRM. It is an independent matter. This is onl= y for encryption for the HAS session after URL of the manifest file is vali= dated. One way to look at sections 3.5.3 and 3.5.4 is that after the initia= l URL for the Content Item is validated via URL Signing, access to related = Content Collection can use alternative methods such as authorization token = or session-based encryption during the HAS session. The advantage is these = techniques do not require URL to be rewritten which is the method used by U= RL Signing. I should probably add one more option where all content for the= Content Item use URL Signing for authorization. or is the client expected to implement an alternate protocol? KL> It's not the intent to come up with new protocol. For example, HLS alr= eady supports this method. The section points out various solution options = that are applicable to URL Signing. This may be applicable to some of the H= AS technology as I'm not clear if it's universally possible. And how is this synchronized across CDNs? KL> See earlier comment about across CDNs. Both methods are limited to same= CDN. More generally, are we attempting to define security protocols for content delivery? If so, I would like to see a more formal definition of what those requirements are? KL> No, there is no attempt to define security protocols. The objective was= to identify the options that are available when URL Signing is used for au= thorization of HAS content. Once the CDN is HAS-aware, then related content= can be grouped. There are several techniques used to group the chunks and = possibly sub-level manifest files for the HAS session. There are advantages= and disadvantages of each technique. Kent -- Kevin J. Ma From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Bra= ndenburg, R. (Ray) van Sent: Friday, May 25, 2012 10:19 AM To: cdni@ietf.org Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft Hi all, I've just uploaded a new version of draft-brandenburg-cdni-has. You can find the document at: http://www.ietf.org/id/draft-brandenburg-cdni= -has-01.txt The draft is meant as an input document for the virtual meeting on Thursday= to discuss the impact of HTTP Adaptive Streaming on the CDNI Interfaces. I= n the draft a number of alternative solutions are presented for each area w= here the use of HAS might touch with the CDNI Interfaces (e.g. content acqu= isition, content purge, request routing, logging and URL signing). I'm looking forward to your comments. Have a nice weekend! Ray van Brandenburg From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Bra= ndenburg, R. (Ray) van Sent: woensdag 23 mei 2012 13:37 To: cdni@ietf.org Subject: [CDNi] Status of Adaptive Streaming and CDNI draft Hi all, Next Tuesday we have a planned interim meeting for discussing the combinati= on between HTTP Adaptive Streaming and CDNI. One of the expected inputs fo= r this meeting is a follow-up draft to draft-brandenburg-cdni-has-00. We are currently working hard at finishing this draft, but as you might hav= e seen, we have not yet uploaded a new version. Currently we are at a stage= where we have a first complete internal draft ready. However, Francois and= I have agreed that we rather spend some more time on it so that it fully c= overs all the areas of the CDNI-HAS combination than upload an incomplete v= ersion right now. We are currently planning to upload the draft this Friday= (25th of May) at the latest. I hope this gives you all enough time to read= the draft before the meeting on Tuesday. Sorry for the delay. Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_291CC3F9E50E7641901A54E85D0977C653267F53DCMAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kent,

KL> Agree that the order of crypto o= perations is needed to function properly. Have you encountered real world p= roblems with this scenario?

 

The Playready-HLS scenario is real.  I have not yet had a = CDN try to insert

HLS encryption over top of it, = and I sincerely hope that I never do....

&nb= sp;

From: Kent Leun= g (kleung) [mailto:kleung@cisco.com]
Sent: Wednesday, May 30, 20= 12 2:21 PM
To: Kevin J Ma; Brandenburg, R. (Ray) van; cdni@ietf.o= rg
Subject: RE: URL Signing in Adaptive Streaming and CDNI draft<= o:p>

 

=

 

 

= From:= Kevin J Ma [mailto:kevin.ma@azukisystems.com]
Sent: Wednesday, = May 30, 2012 5:28 AM
To: Kent Leung (kleung); Brandenburg, R. (Ra= y) van; cdni@ietf.org
Subject: RE: URL Signing in Adaptive Stream= ing and CDNI draft

 

Hi Kent,

=  

KL> Maybe I’m missing your point. Double encrypti= on happens all the time. For example, I have an HTTPS session to a web serv= er over the business IPSec VPN.

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'> =

This is true, but the termination of those tunnels is in di= fferent levels.

L3 for IPSec.  L5+ for HTTPS= .  L7+ for HLS.  The order is well defined.

=

If we are talking about using the encryption support of HLS or some ot= her

HAS protocol, and the encryption has already = taken place, the client is

not equipped to recogn= ize that the content is encrypted multiple times.

If we are just talking about using HTTPS, then thats different, since the<= o:p>

transport is terminated at a lower layer than the= HAS client decryption?

 <= /p>

In another example, if the CP and the client are using a third part= y DRM,

layering on an additional encryption schem= e which the client is forced to

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>recognize and dea= l with may not work, e.g., a CP wants to deliver HLS to

iPad, but has a corporate mandate to use Playready DRM and the segme= nts

are encrypted with Playready.  That clie= nt is unlikedly to be able to

handle some unexpec= ted extra HLS encryption that a CDN may have added.

 

KL> Agree that the order of crypto operations is n= eeded to function properly. Have you encountered real world problems with t= his scenario?

 <= /o:p>

> Maybe we should step back and look at the followi= ng to see if we are on the right track?

> 1.&n= bsp; URL Signing is a method to authorize content delivery (or content acce= ss control)

> 2.  CDNI needs URL Signing = support on Request Routing (mandatory), Metadata (mandatory), and Logging (= optional) Interfaces

> 3.  When URL Sign= ing is used in CDN without HAS-awareness, everything works fine with some c= aveats

>   a.    = ;  Relative URL is signed for invariant portion of URL

>   b.      Request for si= gned URL needs to be within the expiration period (this can be an issue)

> 4.  When URL Signing is used in CDN with = HAS-awareness, validation of the URL for manifest of Original Content assum= es that access to the Content Collection is authorized for the HAS session = (Details of the methods are not CDNI related)

 

I agree with 1 and 2.  I agree with 3, b= ut think that b is a big issue.

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>I have a fundamen= tal problem with 4, however, in that: if content security=

matters, I dont think manifests should be delivered through the CD= N, and

without details of the exact (non-CDNI rel= ated) methods, I am unable to

assess how secure t= hey are or what they might break in the process?

 

KL&g= t; Manifest file delivered via dCDN or not is another factor. This is a gen= eric HAS issue. We still have to consider the case when manifest file is fr= om the same dCDN used for chunk delivery for URL Signing. I think the secti= on can describe how the requests can be associated with an HAS session to p= rovide the logical bundling for all the content for the Original Content.

 

Kent

 

thanx.

<= o:p> 

--  Kevin J. Ma

<= p class=3DMsoNormal> 

<= b>From:<= /span> Kent Leung (kleung) [mailto:kleung@cisco.com]
Sent: Wednesday= , May 30, 2012 2:31 AM
To: Kevin J Ma; Brandenburg, R. (Ray) van;= cdni@ietf.org
Subject: RE: URL Signing in Adaptive Streaming and= CDNI draft

&nbs= p;

Hi Kevin. Comments below.

 

From: Kevin J Ma [mailto:kevin.ma@azukisystems.co= m]
Sent: Tuesday, May 29, 2012 9:14 PM
To: Kent Leung = (kleung); Brandenburg, R. (Ray) van; cdni@ietf.org
Subject: RE: U= RL Signing in Adaptive Streaming and CDNI draft

=

 

Hi Kent,

 

  With respect to toke= n time periods, it is difficult to estimate when

=   a segment is actually going to be requested.  Web pages typical= ly

  request everything immediately, but tha= t's not the case with HAS.

  Maybe the playe= r gets paused and its a while between manifest request

 and segment request, or maybe seeking causes segments to be pla= yed

 out of sequence.  You often end up= needing long time periods on all

 segments = to prevent undue rejections, which limits the value of

  having URL tokens?

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:#1F497D'> 

KL> I’m not c= lear what you mean by “URL tokens”. Are you talking about Optio= n 5.1 or 5.2?  If the latter, then the authorization token is for the = HAS session. This is not per chunk basis. The cookie can be refreshed perio= dically during the session. So any chunk can be requested during the HAS se= ssion as long as the cookie has not expired. This is an issue for the forme= r case.

 <= /span>

  To Scott's point, we may need to differentiate betwee= n URL tokens on

  inter-CDN acquisition vs d= CDN-to-end-user tokens.  Perhaps there is

&n= bsp; more value for the former than the latter?

 

KL&g= t; I agree that there is a difference between the tokens. But URL Signing i= s about delivery authorization (or content access control) and not content = acquisition. The scheme used for acquisition does not have to be the same a= s for delivery. We should not be figuring out how token is used for differe= nt interfaces (e.g. between CDNs or between dCDN and end user). Instead, we= should be figuring out how to support HAS with URL Signing. I think there = are quite a few methods. Some of them may depend on the capabilities of the= HAS technology. If your point is that this is not CDNI issue, I don’= t have a problem with that. CDNI does need to be aware that URL Signing is = used for delivery to end user. This impacts some of the CDNI Interfaces. As= for how URL Signing is optimized when CDN is HAS-aware, that may not need = to be defined. So using Authorization token, session-based encryption, or s= ome other methods don’t need to be described in detail. Maybe just th= e concept that the manifest URL of the Content Item is protected by URL Sig= ning and the related content is associated for the HAS session is sufficien= t?

 

> What if the content is already encrypted?<= /p>

> 

> KL> CDN is not aware a= nd don’t care if the content is encrypted.

=  

  I don't think this is true.  D= epending on how the encryption is

  being im= plemented, the CDN has to care if the content is already<= /p>

  encrypted.  You mention HLS supporting encryption. = ; That is true,

  but you cannot double encr= ypt the content?  If we are talking about

&n= bsp; reusing existing HAS protocol support, then I think you need to care

  what existing encryption and DRM are in use= .

 

  Are you= assuming this would only be performed on unencrypted content

  and that the CDN would have some business agreement wit= h the CP to

  implement a DRM packaging func= tion?  If not, I don't think we can

  a= ssume one way or the other if the content is already encrypted.<= /span>

  The manifest may not be available, and even if it is,= the manifest

  may not tell you if the cont= ent is encrypted, especially if it is

  usin= g a third party DRM.

 

KL> Maybe I’m missing y= our point. Double encryption happens all the time. For example, I have an H= TTPS session to a web server over the business IPSec VPN. In this case, the= content is encrypted with DRM. The content may be transported over VPN bet= ween CSP and uCDN or between uCDN and dCDN. The content may be delivered fr= om dCDN to end user with session-based encryption.

 

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>  Were you a= nticipating that the encryption keys would be session

=

  specific?  Would they be client (subscriber) specific?&nbs= p; I would be

  interested in more details o= n the security of the key exchange?  If

&nb= sp; the keys are easily obtained, then there's little value in having<= /o:p>

  segment encryption (as it pertains to authoriza= tion)?

 

=

KL> So far, we’ve been talking in the = context of the HAS session. But the keying method can be flexible. Anyways,= I offered the Session-Based Encryption as an option to bind the HAS sessio= n with the authorized manifest file for dCDN that is HAS-aware. The intent = was to give an example and not get into the detailed implementation.

 

Maybe we should step back and look at the following= to see if we are on the right track?

 

1.       URL Signing is a method to authorize content delivery (or content acce= ss control)

2.&nbs= p;      CDNI= needs URL Signing support on Request Routing (mandatory), Metadata (mandat= ory), and Logging (optional) Interfaces

3.       =  When URL Signing is used in CDN without HAS-a= wareness, everything works fine with some caveats

a.    = ;   Relative URL is signed = for invariant portion of URL

<= ![if !supportLists]>b.      Request for signed URL needs to be within the expi= ration period (this can be an issue)

4.       When URL Signing is used in CDN with HAS-awareness, va= lidation of the URL for manifest of Original Content assumes that access to= the Content Collection is authorized for the HAS session (Details of the m= ethods are not CDNI related)

 

Kent<= /span>

 

tha= nx.

 

--  Kev= in J. Ma

 

&n= bsp;

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Kent Leu= ng (kleung) [mailto:kleung@cisco.com]
Sent: Tuesday, May 29, 201= 2 6:18 PM
To: Kevin J Ma; Brandenburg, R. (Ray) van; cdni@ietf.or= g
Subject: URL Signing in Adaptive Streaming and CDNI draft<= /o:p>

 

Hi Kevin. Thanks for your feedback. I’ve separ= ated the URL Signing as a sub-topic of HAS draft.

 

Comments below.

 

From: cdni-bounc= es@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kevin J MaSent: Saturday, May 26, 2012 4:37 PM
To: Brandenburg, R.= (Ray) van; cdni@ietf.org
Subject: Re: [CDNi] Status of Adaptive = Streaming and CDNI draft

 

<snip>

=  

  With respect to section 3.5, the ti= me component of URL signing is

  not mention= ed until section 3.5.3.  Expiration of URL tokens, in

  general, is an issue with HAS. 

&nbs= p;

KL> The “time perio= d” or freshness of the signed URL is mentioned in section 3.5. Perhap= s it’s a bit cursory as an example of potential authorization paramet= ers in the embedded URL. I can dedicate a paragraph in this section for URL= expiration. NTP can be used to sync the clocks on the entities that sign a= nd validate the URL. Not sure if the logging interface requires some timest= amp mediation? If so, maybe the same technique can be applied.

 

  Robust key management is an arguably

&nb= sp; more reliable approach to content access protection, though that

  would seem to be fairly well out of scope for CD= NI. 

 

KL> If the key management is out-of-band from the CDNI Interfaces, th= en it would be out of scope.

 

  The proposed

  solution in section 3.5.3, seems to be managing session = state?

  Depending on the complexity of the = cookie, this could be troublesome

  if there= is a failover and session state is not properly synchronized? <= /span>

 

KL> Yes, this option is for per-HAS-session. There a= re various schemes to handle failover scenario, which is out of scope.

 

<= p class=3DMsoNormal>  And in the case of live streaming, the manifest is going to= be

  requested every time?  How is the= state managed in that case? 

 

=

KL> For live streaming, this depends on the = HAS technology. I don’t think the draft needs to get into the details= of each technology. The fundamental concept is there is a manifest file fo= r a Content Item which needs to be signed. And subsequent request  for= related content (i.e. chunk and sub-level manifest file) is associated wit= h the authorization.

&nbs= p;

  Is

  Will the cookie work across all CDNs? = ;

 

KL&g= t; I can add some more info on replay protection on the cookie. Cookie expi= ration time can be used. No time synchronization issue for the same surroga= te case. Failover across surrogates in same CDN requires NTP or other clock= synchronization. Cookie method is not intended to work across CDNs since r= edirection should happen in this case.

 

  Moving on to se= ction 3.5.4

  is even more concerning. = What if the content is already encrypted?

 

KL= > CDN is not aware and don’t care if the content is encrypted. The= session-based encryption is only a technique to link to the authorized sta= te of the Content Item.  

 

  How is authentication being ha= ndled on the key server?  Who is

  resp= onsible for auditing the security of the solution?  Is this=

  intended to provide DRM?  work with existing DR= M?  circumvent

  existing DRM?  = Does it only use the DRM/encryption support of the

=

 

<= p class=3DMsoNormal>KL> There is no intention for DRM. It is an i= ndependent matter. This is only for encryption for the HAS session after UR= L of the manifest file is validated. One way to look at sections 3.5.3 and = 3.5.4 is that after the initial URL for the Content Item is validated via U= RL Signing, access to related Content Collection can use alternative method= s such as authorization token or session-based encryption during the HAS se= ssion. The advantage is these techniques do not require URL to be rewritten= which is the method used by URL Signing. I should probably add one more op= tion where all content for the Content Item use URL Signing for authorizati= on.

 

or is the client expected to implement an

<= p class=3DMsoNormal>  alternate protocol? 

 

KL> It’s not the intent to come up w= ith new protocol. For example, HLS  already supports this method. The = section points out various solution options that are applicable to URL Sign= ing. This may be applicable to some of the HAS technology as I’m not = clear if it’s universally possible.

 

And how is this synchroniz= ed across CDNs?

 = ;

KL> See earlier comment ab= out across CDNs. Both methods are limited to same CDN.

 

  More g= enerally, are we attempting to define security protocols for

  content delivery?  If so, I would like to see a mor= e formal

 definition of what those requireme= nts are?

 

KL> No, there is no attempt to define secu= rity protocols. The objective was to identify the options that are availabl= e when URL Signing is used for authorization of HAS content. Once the CDN i= s HAS-aware, then related content can be grouped. There are several techniq= ues used to group the chunks and possibly sub-level manifest files for the = HAS session. There are advantages and disadvantages of each technique.=

 

Kent

 

<snip>

 

--  Kevin J. Ma

 

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behal= f Of Brandenburg, R. (Ray) van
Sent: Friday, May 25, 2012 10:= 19 AM
To: cdni@ietf.org
Subject: Re: [CDNi] Status of A= daptive Streaming and CDNI draft

 

Hi = all,

 =

I’ve just uploaded a new= version of draft-brandenburg-cdni-has.

 

You = can find the document at: http://www.ie= tf.org/id/draft-brandenburg-cdni-has-01.txt

 

The draft is meant as an input document for the vir= tual meeting on Thursday to discuss the impact of HTTP Adaptive Streaming o= n the CDNI Interfaces. In the draft a number of alternative solutions are p= resented for each area where the use of HAS might touch with the CDNI Inter= faces (e.g. content acquisition, content purge, request routing, logging an= d URL signing).

&nbs= p;

I’m looking forward to= your comments.

 = ;

Have a nice weekend!

 

Ray van Brandenburg

 

 

 

From: cdni-bounces@ietf.org [mailto:= cdni-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van
= Sent: woensdag 23 mei 2012 13:37
To: cdni@ietf.org
Subj= ect: [CDNi] Status of Adaptive Streaming and CDNI draft

 

Hi all,

 

Next Tuesday we have a planned interim meeting for discussi= ng the combination between HTTP Adaptive Streaming and CDNI. One  of t= he expected inputs for this meeting is a follow-up draft to draft-brandenbu= rg-cdni-has-00.

&n= bsp;

We are current= ly working hard at finishing this draft, but as you might have seen, we hav= e not yet uploaded a new version. Currently we are at a stage where we have= a first complete internal draft ready. However, Francois and I have agreed= that we rather spend some more time on it so that it fully covers all the = areas of the CDNI-HAS combination than upload an incomplete version right n= ow. We are currently planning to upload the draft this Friday (25th of May) at the latest. I hope this gives you all eno= ugh time to read the draft before the meeting on Tuesday.

 

<= div>

Sorry for the delay.

 

Ray

=  

 <= o:p>

 <= /span>

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

= --_000_291CC3F9E50E7641901A54E85D0977C653267F53DCMAILR002maill_-- From lpeterson@verivue.com Wed May 30 13:00:38 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C774111E80A0 for ; Wed, 30 May 2012 13:00:38 -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 fJwfKqouafFN for ; Wed, 30 May 2012 13:00:37 -0700 (PDT) Received: from exprod8og116.obsmtp.com (exprod8og116.obsmtp.com [64.18.3.32]) by ietfa.amsl.com (Postfix) with SMTP id 8F9A911E809C for ; Wed, 30 May 2012 13:00:36 -0700 (PDT) Received: from vvexch.verivue.com ([38.83.192.68]) by exprod8ob116.postini.com ([64.18.7.12]) with SMTP ID DSNKT8Z8YZSKE3ZEMUFiFd5rp1fo1LH+G/tm@postini.com; Wed, 30 May 2012 13:00:36 PDT Received: from vvexch.verivue.com ([10.160.6.20]) by vvexch.verivue.com ([10.160.6.20]) with mapi; Wed, 30 May 2012 16:00:32 -0400 From: "Peterson, Larry" To: Stef van der Ziel Date: Wed, 30 May 2012 16:00:31 -0400 Thread-Topic: [CDNi] Status of Adaptive Streaming and CDNI draft Thread-Index: Ac0+nt5qQuCDs+dwQWCOytuBkbwZ/A== Message-ID: References: <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> <66050772-394A-4A28-92FE-6A0581D5A533@jet-stream.nl> <291CC3F9E50E7641901A54E85D0977C653267F4D1F@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI 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: Wed, 30 May 2012 20:00:38 -0000 I apologize for not being able to make the call, but I can't help but wonde= r why we're making this so complicated. The whole point of HTTP-AS is to apply RESTful principles to video delivery= , to leverage the simplicity of HTTP. It seems like a mistake to assume CDNs are purposely working against that principle, especially when doing so complicates our ability to define a base/minimal CDNI strategy. Larry On May 29, 2012, at 3:06 AM, Stef van der Ziel wrote: > Hi Kevin, > > Op 27 mei 2012 om 18:00 heeft Kevin J Ma het = volgende geschreven: > >> Hi Stef, >> >> I was not arguing that a CDN would not prefer to have the manifest. >> I was more arguing that content providers may not trust CDNs with >> the manifest generation/modification. Securing content, preventing >> unauthorized access, and preventing piracy requires much more than >> simple auth tokens. DRM is explicitly listed as out-of-scope in >> the charter, so as I said, if the intent is to define a security >> protocol, then I would like to see more requirements. If, however, >> I have misunderstood, and section 3.5.4 is describing an existing >> feature that is widely supported across CDNs today, that just needs >> CDNI support, then I suppose that would be different. >> > > In general CDNs must offer the ability to secure access to content. > Access restriction and DRM can complement each other and don't necessaril= y overlap. > Many CDNs use tokens between portals and request routers and between requ= est routers and delivery nodes to prevent unauthorized access to content. > > However being a stateless and segmented technology, HAS introduces a new = massive gap in the security by having manifest files in between the request= router and the actual content. So it is a responsibility for the CDN to cl= ose this gap. > > I know that many platforms who call themselves CDNs are nothing more than= a managed caching environment. So you can pull anything through. So coming= from this angle it makes sense to assume that you can simply distribute ma= nifests besides the CDN. I'm trying to educate here that this vision is too= simple and that we foresee that content providers will demand from CDNs th= at their content is protected by actively managing the manifests. > > Doing nothing about manifest control, these passive CDNs have a wide open= security problem. I see many possibilities for people to reconstruct manif= ests and abuse federated CDNs by directly pulling off objects from caches. > > If these CDNs would allow direct access to segments, that would be a bloc= king issue for other CDNs to actually federate with these CDNs. Because it = breaks the level of security they are offering to their content publishing = customers. > > >> As for asset management, I agree the CDN needs to know what files go >> together, but I do not agree that a CDN should be allowed to modify >> a manifest file any way it wants, or generate any manifest it wants >> and present that to the end user. Manifest files may contain other >> information besides segment file locations, e.g., DRM info, targeted >> ad insertions, subscription-based customizations, etc., which the >> content provider may not trust the CDN with. I would like to know >> where the boundaries are of what the CDN may modify? Much of this >> requires subscriber-awareness. How subscriber-aware are we assuming >> the CDN to be? One might argue that the CDN should perform all these >> functions and be a one-stop intelligent content delivery shop, but >> that seems improbable in the short-run? > > The real problem is that manifest files are quite open, not well designed= and immature so everyone in the value chain thinks they can just use and a= buse the manifest file for whatever purpose they have. > > Content publishers may want to dynamically adjust the manifest files to a= ctually change the content on a per request basis. > > At the same time CDNs must be able to adjust the manifest files to do ses= sion tracking, access protection, management, etc. Without actually changin= g the content by the way! > > These requirements can't be supported at the same time today. In my view = the core role of a manifest is to instruct the client how to reconstruct se= gments into a fluent stream. However there are secondary roles which are in= conflict: content adaptation (ad insertion for insance) and CDN distributi= on management, asset management, session management, access management. > > The solution would be to wait for manifest files to become more mature. I= prefer to have manifest files roles to be split into content management ma= nifests and distribution management manifests. > > Anyway it is too easy to assume that CDNs don't change manifests so they = don't need to serve out manifests. They do, so CDNi should be aware of it. = It is not a matter of being an advanced feature, it is how many CDNs simply= work from a core philosophy around HAS. > > I'm not asking CDNi to make serving out manifests mandatory, because that= would be a similar mistake the other way around, what i propose is that CD= Ni should be aware of which CDNs cannot control manifests, and which CDNs m= ake manifest control mandatory. > > >> Perhaps a more general question: Are we talking about making CDNs >> HAS aware, or making CDNI HAS aware? It feels more like the former, >> with the latter being an after-thought, and it is not clear to me >> how the former fits into the charter? Going straight from the uCDN >> routing every segment, to the uCDN supporting modification of a half >> dozen manifest formats feels disingenuous. Is there no BCP for how >> to configure DNS-RR to take the load off the uCDN RR, or a simple >> set of metadata to describe the source content structure which can >> facilitate more efficient content acquisition? > > I think you hit a weak spot in CDNi. Some CDNs use passive DNS rr and oth= ers use active HTTP rr. Some support both. Some also use redirect instructi= onal files which IMHO is the best technology since it is active and guarant= ees much higher uptime and performance. If you want I can share more detail= s about this because it would be a great feature for CDNi. > > You are right that active rr CDNs may not want to federate to DNS based C= DNs because their service level would drop below the SLA they offered to th= eir customer. And you are right that some scenarios may simply not work, fo= r instance when a uCDN manifest based anti-deeplinking and a dCDN hasn't im= plemented this. Some CDNs don't care about manifests, others need them to d= o their job. It isn't guaranteed that CDNs are always interchangeable. > > So that is why it is so important that CDNi doesn't rule out specific tec= hnology visions, architecture designs or technology choices. It should supp= ort these different flavors and definitely not rule out specific ones. And = this is a typical example of information that should be shared between CDNs= via a capabilities API, so CDNs can decide if they want to federate with o= ther CDNs that cannot support the features they require. > > Best Stef > > >> >> thanx. >> >> -- Kevin J. Ma >> >> From: Stef van der Ziel [mailto:stef@jet-stream.nl] >> Sent: Sunday, May 27, 2012 9:03 AM >> To: Kevin J Ma >> Cc: Brandenburg, R. (Ray) van; cdni@ietf.org >> Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft >> >> Hi Kevin, >> >> Actually, many CDNs prefer to serve out both the segments and the manife= st files. >> Sure, dumb caching/DNS based CDNs can be used to deliver segments and th= ey wouldn't care about segments. They will just pump out the delivered obje= cts. But intelligent CDNs that are actually usable for commercial/secure an= d manageable HAS, need the manifests. >> >> IMHO the role of a manifest file should not be confused with the role of= a referrer file. >> A manifest is to represent the entire content, not just to the client bu= t in the entire chain of encoding, protection, CDN and clients. >> A referrer file is the proper way to point to the (logical) content from= any remote location. >> >> We hardly ever see manifest files to be distributed outside of the CDN i= n reality. It is not a fairly common scenario and should not be. In more au= tomated environments, it can actually be the CDN that creates the manifest. >> >> The assumption that manifest files should or can be distributed offline = or outside the CDN is mostly wrong. The assumption that you can point from = a manifest to a CDN for the segments won't work since a proper CDN would (s= hould) block direct access to segments to prevent deep linking. But we unde= rstand why people make these assumptions, we've heard other statements from= HAS enthusiasts that don't make sense in the real world. >> >> Serving out the manifests alongside the segments from the same CDN accou= nt is done for multiple reasons, which do not at all adapt the content: >> >> - Logical asset recognition (parsing the manifests so the CDN understand= s that the segments are part of a logical entity) >> - Logical asset management (processing, copying, managing manifests and = subsequent segments as if they are one asset) >> - Logical asset reporting (reporting manifests and subsequent segments v= ia web interfaces and APIs as if they are one asset) >> - Request routing control (CDNs only produce URLs for manifest files and= will not accept requests for segments to prevent unnecessary request routi= ng overload by having to request route every individual segment request) >> - Access control (CDNs will not allow direct access to segments but only= via the manifest file to prevent deep-linking, you don't want any third pa= rty to publish a manifest file on an unlicensed portal and then point users= to the segments on the CDN without any access control) >> - Session control (http streaming is stateless and that is quite dramati= c for CDNs because you lose control over the session and over session loggi= ng) >> >> There are additional reasons for CDNs to be able to adapt the manifest f= iles but do so without changing the actual content: >> - For instance, they could dynamically insert base URLs to point users t= o a group of servers to improve the availability. >> - Or they could dynamically insert tokens into the manifest to control a= ccess to segments. >> - Or they could dynamically insert session keys to be able to track a un= ique user session over multiple federated CDNs. >> - Or they could dynamically remove higher or lower bit rates to better c= ontrol the actual QoE on a per request basis. >> >> Concluding: >> To a CDN, the segments aren't actually that interesting. They are just p= ieces of useless raw data that needs to be protected, managed and served. >> For a CDN, the manifest represents the content and is a critical compone= nt so they need to be able to parse, alter and serve them. >> >> I think the above by itself describes some interesting challenges. Just = one example: how are CDNs going to guarantee anti-deeplinking to segments i= n a federated constellation where multiple nodes of multiple CDNs and reque= st routers need to be aware of each others sessions and tokens, etc? >> >> My 2 cents. >> >> Kind regards, Stef van der Ziel >> >> -- >> Owner Jet-Stream | StreamZilla >> GMT+1 Office: +31 50 5261820 | Mobile: +31 6 23406348 >> www.jet-stream.com | www.streamzillacdn.com >> this communication is confidential >> >> >> >> >> On 27 mei 2012, at 01:37, Kevin J Ma wrote: >> >> >> Hi Ray, >> >> I read through the updated draft and had a number of comments ahead of >> the meeting. >> >> First, a general comment about manifest files. The document seems >> to assume that manifest files will be distributed through the CDN. >> There are many services where this is not the case, often to prevent >> modification. There is a large focus in the document on how to modify >> manifest files, in some cases where the manifest file itself is not >> necessarily relevant. I believe there are ways to optimize HAS >> delivery without modifying manifest files, and in imo, manifest >> manipulation falls under content adaptation which the wg declared to >> be out of scope for the initial phase? >> >> With respect section 2.2, I believe I commented on this in the >> initial draft, but I still feel that the relative vs absolute URL >> discussion is rather misleading. It seems to imply that: >> a) the HOST portion of a relative URL cannot point to a RR, that >> b) a RR must be accessed through some web service like API, and that >> c) absolute URLs can only point to specific surrogates. >> While these are all valid examples of how to use URLs, they do not >> seem to be typical cases. For us, a typical service has a DNS >> address which points to a base directory in one or more CDNs. The >> relative path from that base directory is the same in all CDNs. The >> hostname does not point to any one surrogate, and each CDN is still >> able to redirect requests as it sees fit. >> >> With respect to sections 3.1 and 3.2, while I agree that content >> storage and acquisition optimization is important, and that there >> should be metadata which can describe the format of the content, I >> do think the CDN needs to be fully HAS aware, nor do I think that >> the CDN necessarily needs access to the manifest file. I also do >> not see a "significant" impact to the MI. The metadata interface >> will have the ability to define metadata that applies to a set of >> content assets, per the META-10 requirement. Ultimately, the CDN >> needs to be able to respond to content requests from the client, >> even if that client got a manifest file directly from the content >> provider (not from the CDN) and is expecting the content to be in >> the format that was provided to the CDN by the content provider. >> How it got the content and how it stores it is out of scope? >> >> With respect to section 3.3, I think that a third case is missing, >> where the content provider does not provide the manifest file to the >> CDN (which can be a fairly common case). >> >> With respect to sections 3.3.2 and 3.3.3, would not DNS-based >> redirection solve the issue by simply directing manifest/chunk >> requests to the dCDN, rather than doing a manifest rewrite for every >> request (especially in the case of live streaming where the manifest >> might be changing on every chunk)? Also, presumably, the RR would >> only rewrite URLs which were within its own domain (i.e., not >> blackholing ad insertion segments, etc.)? >> >> With respect to section 3.5, the time component of URL signing is >> not mentioned until section 3.5.3. Expiration of URL tokens, in >> general, is an issue with HAS. Robust key management is an arguably >> more reliable approach to content access protection, though that >> would seem to be fairly well out of scope for CDNI. The proposed >> solution in section 3.5.3, seems to be managing session state? >> Depending on the complexity of the cookie, this could be troublesome >> if there is a failover and session state is not properly synchronized? >> And in the case of live streaming, the manifest is going to be >> requested every time? How is the state managed in that case? Is >> the cookie less susceptible to replay attacks than the URL token? >> Will the cookie work across all CDNs? Moving on to section 3.5.4 >> is even more concerning. What if the content is already encrypted? >> How is authentication being handled on the key server? Who is >> responsible for auditing the security of the solution? Is this >> intended to provide DRM? work with existing DRM? circumvent >> existing DRM? Does it only use the DRM/encryption support of the >> delivery protocol? or is the client expected to implement an >> alternate protocol? And how is this synchronized across CDNs? >> More generally, are we attempting to define security protocols for >> content delivery? If so, I would like to see a more formal >> definition of what those requirements are? >> >> With respect to section 3.6.2, it seems that we just want to be able >> to purge a set of content assets. Would a URI prefix not be sufficient= ? >> >> thanx. >> >> -- Kevin J. Ma >> >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Brandenburg, R. (Ray) van >> Sent: Friday, May 25, 2012 10:19 AM >> To: cdni@ietf.org >> Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft >> >> Hi all, >> >> I=92ve just uploaded a new version of draft-brandenburg-cdni-has. >> >> You can find the document at: http://www.ietf.org/id/draft-brandenburg-c= dni-has-01.txt >> >> The draft is meant as an input document for the virtual meeting on Thurs= day to discuss the impact of HTTP Adaptive Streaming on the CDNI Interfaces= . In the draft a number of alternative solutions are presented for each are= a where the use of HAS might touch with the CDNI Interfaces (e.g. content a= cquisition, content purge, request routing, logging and URL signing). >> >> I=92m looking forward to your comments. >> >> Have a nice weekend! >> >> Ray van Brandenburg >> >> >> >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Brandenburg, R. (Ray) van >> Sent: woensdag 23 mei 2012 13:37 >> To: cdni@ietf.org >> Subject: [CDNi] Status of Adaptive Streaming and CDNI draft >> >> Hi all, >> >> Next Tuesday we have a planned interim meeting for discussing the combin= ation between HTTP Adaptive Streaming and CDNI. One of the expected inputs= for this meeting is a follow-up draft to draft-brandenburg-cdni-has-00. >> >> We are currently working hard at finishing this draft, but as you might = have seen, we have not yet uploaded a new version. Currently we are at a st= age where we have a first complete internal draft ready. However, Francois = and I have agreed that we rather spend some more time on it so that it full= y covers all the areas of the CDNI-HAS combination than upload an incomplet= e version right now. We are currently planning to upload the draft this Fri= day (25th of May) at the latest. I hope this gives you all enough time to r= ead the draft before the meeting on Tuesday. >> >> Sorry for the delay. >> >> Ray >> >> >> >> This e-mail and its contents are subject to the DISCLAIMER at http://www= .tno.nl/emaildisclaimer >> >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >> > From stockhammer@nomor.de Wed May 30 13:09: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 772D611E80A0 for ; Wed, 30 May 2012 13:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTmhJE8cg5Ke for ; Wed, 30 May 2012 13:09:07 -0700 (PDT) Received: from mo6-p00-ob.rzone.de (mo6-p00-ob.rzone.de [IPv6:2a01:238:20a:202:5300::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF56611E811B for ; Wed, 30 May 2012 13:09:06 -0700 (PDT) X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu1/8loZf+4JHTB1Fvz/6Kg9 X-RZG-CLASS-ID: mo00 Received: from [192.168.10.151] (188-192-153-251-dynip.superkabel.de [188.192.153.251]) by smtp.strato.de (josoe mo77) (RZmta 29.10 DYNA|AUTH) with ESMTPA id a073e6o4UHSkaW ; Wed, 30 May 2012 22:09:00 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Thomas Stockhammer In-Reply-To: Date: Wed, 30 May 2012 22:09:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <52EB616A-5984-4F9C-B32A-637D7D0FB72B@nomor.de> References: <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> <66050772-394A-4A28-92FE-6A0581D5A533@jet-stream.nl> <291CC3F9E50E7641901A54E85D0977C653267F4D1F@MAILR002.mail.lan> To: "Peterson, Larry" X-Mailer: Apple Mail (2.1278) Cc: "cdni@ietf.org" Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI 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: Wed, 30 May 2012 20:09:09 -0000 +1 /T On May 30, 2012, at 10:00 PM, Peterson, Larry wrote: > I apologize for not being able to make the call, but I can't help but = wonder > why we're making this so complicated. >=20 > The whole point of HTTP-AS is to apply RESTful principles to video = delivery, > to leverage the simplicity of HTTP. It seems like a mistake to assume = CDNs > are purposely working against that principle, especially when doing so > complicates our ability to define a base/minimal CDNI strategy. >=20 > Larry >=20 > On May 29, 2012, at 3:06 AM, Stef van der Ziel wrote: >=20 >> Hi Kevin, >>=20 >> Op 27 mei 2012 om 18:00 heeft Kevin J Ma = het volgende geschreven: >>=20 >>> Hi Stef, >>>=20 >>> I was not arguing that a CDN would not prefer to have the manifest. >>> I was more arguing that content providers may not trust CDNs with >>> the manifest generation/modification. Securing content, preventing >>> unauthorized access, and preventing piracy requires much more than >>> simple auth tokens. DRM is explicitly listed as out-of-scope in >>> the charter, so as I said, if the intent is to define a security >>> protocol, then I would like to see more requirements. If, however, >>> I have misunderstood, and section 3.5.4 is describing an existing >>> feature that is widely supported across CDNs today, that just needs >>> CDNI support, then I suppose that would be different. >>>=20 >>=20 >> In general CDNs must offer the ability to secure access to content. >> Access restriction and DRM can complement each other and don't = necessarily overlap. >> Many CDNs use tokens between portals and request routers and between = request routers and delivery nodes to prevent unauthorized access to = content. >>=20 >> However being a stateless and segmented technology, HAS introduces a = new massive gap in the security by having manifest files in between the = request router and the actual content. So it is a responsibility for the = CDN to close this gap. >>=20 >> I know that many platforms who call themselves CDNs are nothing more = than a managed caching environment. So you can pull anything through. So = coming from this angle it makes sense to assume that you can simply = distribute manifests besides the CDN. I'm trying to educate here that = this vision is too simple and that we foresee that content providers = will demand from CDNs that their content is protected by actively = managing the manifests. >>=20 >> Doing nothing about manifest control, these passive CDNs have a wide = open security problem. I see many possibilities for people to = reconstruct manifests and abuse federated CDNs by directly pulling off = objects from caches. >>=20 >> If these CDNs would allow direct access to segments, that would be a = blocking issue for other CDNs to actually federate with these CDNs. = Because it breaks the level of security they are offering to their = content publishing customers. >>=20 >>=20 >>> As for asset management, I agree the CDN needs to know what files = go >>> together, but I do not agree that a CDN should be allowed to modify >>> a manifest file any way it wants, or generate any manifest it wants >>> and present that to the end user. Manifest files may contain other >>> information besides segment file locations, e.g., DRM info, targeted >>> ad insertions, subscription-based customizations, etc., which the >>> content provider may not trust the CDN with. I would like to know >>> where the boundaries are of what the CDN may modify? Much of this >>> requires subscriber-awareness. How subscriber-aware are we = assuming >>> the CDN to be? One might argue that the CDN should perform all = these >>> functions and be a one-stop intelligent content delivery shop, but >>> that seems improbable in the short-run? >>=20 >> The real problem is that manifest files are quite open, not well = designed and immature so everyone in the value chain thinks they can = just use and abuse the manifest file for whatever purpose they have. >>=20 >> Content publishers may want to dynamically adjust the manifest files = to actually change the content on a per request basis. >>=20 >> At the same time CDNs must be able to adjust the manifest files to do = session tracking, access protection, management, etc. Without actually = changing the content by the way! >>=20 >> These requirements can't be supported at the same time today. In my = view the core role of a manifest is to instruct the client how to = reconstruct segments into a fluent stream. However there are secondary = roles which are in conflict: content adaptation (ad insertion for = insance) and CDN distribution management, asset management, session = management, access management. >>=20 >> The solution would be to wait for manifest files to become more = mature. I prefer to have manifest files roles to be split into content = management manifests and distribution management manifests. >>=20 >> Anyway it is too easy to assume that CDNs don't change manifests so = they don't need to serve out manifests. They do, so CDNi should be aware = of it. It is not a matter of being an advanced feature, it is how many = CDNs simply work from a core philosophy around HAS. >>=20 >> I'm not asking CDNi to make serving out manifests mandatory, because = that would be a similar mistake the other way around, what i propose is = that CDNi should be aware of which CDNs cannot control manifests, and = which CDNs make manifest control mandatory. >>=20 >>=20 >>> Perhaps a more general question: Are we talking about making CDNs >>> HAS aware, or making CDNI HAS aware? It feels more like the = former, >>> with the latter being an after-thought, and it is not clear to me >>> how the former fits into the charter? Going straight from the uCDN >>> routing every segment, to the uCDN supporting modification of a = half >>> dozen manifest formats feels disingenuous. Is there no BCP for how >>> to configure DNS-RR to take the load off the uCDN RR, or a simple >>> set of metadata to describe the source content structure which can >>> facilitate more efficient content acquisition? >>=20 >> I think you hit a weak spot in CDNi. Some CDNs use passive DNS rr and = others use active HTTP rr. Some support both. Some also use redirect = instructional files which IMHO is the best technology since it is active = and guarantees much higher uptime and performance. If you want I can = share more details about this because it would be a great feature for = CDNi. >>=20 >> You are right that active rr CDNs may not want to federate to DNS = based CDNs because their service level would drop below the SLA they = offered to their customer. And you are right that some scenarios may = simply not work, for instance when a uCDN manifest based = anti-deeplinking and a dCDN hasn't implemented this. Some CDNs don't = care about manifests, others need them to do their job. It isn't = guaranteed that CDNs are always interchangeable. >>=20 >> So that is why it is so important that CDNi doesn't rule out specific = technology visions, architecture designs or technology choices. It = should support these different flavors and definitely not rule out = specific ones. And this is a typical example of information that should = be shared between CDNs via a capabilities API, so CDNs can decide if = they want to federate with other CDNs that cannot support the features = they require. >>=20 >> Best Stef >>=20 >>=20 >>>=20 >>> thanx. >>>=20 >>> -- Kevin J. Ma >>>=20 >>> From: Stef van der Ziel [mailto:stef@jet-stream.nl] >>> Sent: Sunday, May 27, 2012 9:03 AM >>> To: Kevin J Ma >>> Cc: Brandenburg, R. (Ray) van; cdni@ietf.org >>> Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft >>>=20 >>> Hi Kevin, >>>=20 >>> Actually, many CDNs prefer to serve out both the segments and the = manifest files. >>> Sure, dumb caching/DNS based CDNs can be used to deliver segments = and they wouldn't care about segments. They will just pump out the = delivered objects. But intelligent CDNs that are actually usable for = commercial/secure and manageable HAS, need the manifests. >>>=20 >>> IMHO the role of a manifest file should not be confused with the = role of a referrer file. >>> A manifest is to represent the entire content, not just to the = client but in the entire chain of encoding, protection, CDN and clients. >>> A referrer file is the proper way to point to the (logical) content = from any remote location. >>>=20 >>> We hardly ever see manifest files to be distributed outside of the = CDN in reality. It is not a fairly common scenario and should not be. In = more automated environments, it can actually be the CDN that creates the = manifest. >>>=20 >>> The assumption that manifest files should or can be distributed = offline or outside the CDN is mostly wrong. The assumption that you can = point from a manifest to a CDN for the segments won't work since a = proper CDN would (should) block direct access to segments to prevent = deep linking. But we understand why people make these assumptions, we've = heard other statements from HAS enthusiasts that don't make sense in the = real world. >>>=20 >>> Serving out the manifests alongside the segments from the same CDN = account is done for multiple reasons, which do not at all adapt the = content: >>>=20 >>> - Logical asset recognition (parsing the manifests so the CDN = understands that the segments are part of a logical entity) >>> - Logical asset management (processing, copying, managing manifests = and subsequent segments as if they are one asset) >>> - Logical asset reporting (reporting manifests and subsequent = segments via web interfaces and APIs as if they are one asset) >>> - Request routing control (CDNs only produce URLs for manifest files = and will not accept requests for segments to prevent unnecessary request = routing overload by having to request route every individual segment = request) >>> - Access control (CDNs will not allow direct access to segments but = only via the manifest file to prevent deep-linking, you don't want any = third party to publish a manifest file on an unlicensed portal and then = point users to the segments on the CDN without any access control) >>> - Session control (http streaming is stateless and that is quite = dramatic for CDNs because you lose control over the session and over = session logging) >>>=20 >>> There are additional reasons for CDNs to be able to adapt the = manifest files but do so without changing the actual content: >>> - For instance, they could dynamically insert base URLs to point = users to a group of servers to improve the availability. >>> - Or they could dynamically insert tokens into the manifest to = control access to segments. >>> - Or they could dynamically insert session keys to be able to track = a unique user session over multiple federated CDNs. >>> - Or they could dynamically remove higher or lower bit rates to = better control the actual QoE on a per request basis. >>>=20 >>> Concluding: >>> To a CDN, the segments aren't actually that interesting. They are = just pieces of useless raw data that needs to be protected, managed and = served. >>> For a CDN, the manifest represents the content and is a critical = component so they need to be able to parse, alter and serve them. >>>=20 >>> I think the above by itself describes some interesting challenges. = Just one example: how are CDNs going to guarantee anti-deeplinking to = segments in a federated constellation where multiple nodes of multiple = CDNs and request routers need to be aware of each others sessions and = tokens, etc? >>>=20 >>> My 2 cents. >>>=20 >>> Kind regards, Stef van der Ziel >>>=20 >>> -- >>> Owner Jet-Stream | StreamZilla >>> GMT+1 Office: +31 50 5261820 | Mobile: +31 6 23406348 >>> www.jet-stream.com | www.streamzillacdn.com >>> this communication is confidential >>>=20 >>>=20 >>>=20 >>>=20 >>> On 27 mei 2012, at 01:37, Kevin J Ma wrote: >>>=20 >>>=20 >>> Hi Ray, >>>=20 >>> I read through the updated draft and had a number of comments ahead = of >>> the meeting. >>>=20 >>> First, a general comment about manifest files. The document seems >>> to assume that manifest files will be distributed through the CDN. >>> There are many services where this is not the case, often to = prevent >>> modification. There is a large focus in the document on how to = modify >>> manifest files, in some cases where the manifest file itself is not >>> necessarily relevant. I believe there are ways to optimize HAS >>> delivery without modifying manifest files, and in imo, manifest >>> manipulation falls under content adaptation which the wg declared to >>> be out of scope for the initial phase? >>>=20 >>> With respect section 2.2, I believe I commented on this in the >>> initial draft, but I still feel that the relative vs absolute URL >>> discussion is rather misleading. It seems to imply that: >>> a) the HOST portion of a relative URL cannot point to a RR, that >>> b) a RR must be accessed through some web service like API, and = that >>> c) absolute URLs can only point to specific surrogates. >>> While these are all valid examples of how to use URLs, they do not >>> seem to be typical cases. For us, a typical service has a DNS >>> address which points to a base directory in one or more CDNs. The >>> relative path from that base directory is the same in all CDNs. = The >>> hostname does not point to any one surrogate, and each CDN is still >>> able to redirect requests as it sees fit. >>>=20 >>> With respect to sections 3.1 and 3.2, while I agree that content >>> storage and acquisition optimization is important, and that there >>> should be metadata which can describe the format of the content, I >>> do think the CDN needs to be fully HAS aware, nor do I think that >>> the CDN necessarily needs access to the manifest file. I also do >>> not see a "significant" impact to the MI. The metadata interface >>> will have the ability to define metadata that applies to a set of >>> content assets, per the META-10 requirement. Ultimately, the CDN >>> needs to be able to respond to content requests from the client, >>> even if that client got a manifest file directly from the content >>> provider (not from the CDN) and is expecting the content to be in >>> the format that was provided to the CDN by the content provider. >>> How it got the content and how it stores it is out of scope? >>>=20 >>> With respect to section 3.3, I think that a third case is missing, >>> where the content provider does not provide the manifest file to the >>> CDN (which can be a fairly common case). >>>=20 >>> With respect to sections 3.3.2 and 3.3.3, would not DNS-based >>> redirection solve the issue by simply directing manifest/chunk >>> requests to the dCDN, rather than doing a manifest rewrite for = every >>> request (especially in the case of live streaming where the = manifest >>> might be changing on every chunk)? Also, presumably, the RR would >>> only rewrite URLs which were within its own domain (i.e., not >>> blackholing ad insertion segments, etc.)? >>>=20 >>> With respect to section 3.5, the time component of URL signing is >>> not mentioned until section 3.5.3. Expiration of URL tokens, in >>> general, is an issue with HAS. Robust key management is an = arguably >>> more reliable approach to content access protection, though that >>> would seem to be fairly well out of scope for CDNI. The proposed >>> solution in section 3.5.3, seems to be managing session state? >>> Depending on the complexity of the cookie, this could be = troublesome >>> if there is a failover and session state is not properly = synchronized? >>> And in the case of live streaming, the manifest is going to be >>> requested every time? How is the state managed in that case? Is >>> the cookie less susceptible to replay attacks than the URL token? >>> Will the cookie work across all CDNs? Moving on to section 3.5.4 >>> is even more concerning. What if the content is already encrypted? >>> How is authentication being handled on the key server? Who is >>> responsible for auditing the security of the solution? Is this >>> intended to provide DRM? work with existing DRM? circumvent >>> existing DRM? Does it only use the DRM/encryption support of the >>> delivery protocol? or is the client expected to implement an >>> alternate protocol? And how is this synchronized across CDNs? >>> More generally, are we attempting to define security protocols for >>> content delivery? If so, I would like to see a more formal >>> definition of what those requirements are? >>>=20 >>> With respect to section 3.6.2, it seems that we just want to be = able >>> to purge a set of content assets. Would a URI prefix not be = sufficient? >>>=20 >>> thanx. >>>=20 >>> -- Kevin J. Ma >>>=20 >>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Brandenburg, R. (Ray) van >>> Sent: Friday, May 25, 2012 10:19 AM >>> To: cdni@ietf.org >>> Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft >>>=20 >>> Hi all, >>>=20 >>> I=92ve just uploaded a new version of draft-brandenburg-cdni-has. >>>=20 >>> You can find the document at: = http://www.ietf.org/id/draft-brandenburg-cdni-has-01.txt >>>=20 >>> The draft is meant as an input document for the virtual meeting on = Thursday to discuss the impact of HTTP Adaptive Streaming on the CDNI = Interfaces. In the draft a number of alternative solutions are presented = for each area where the use of HAS might touch with the CDNI Interfaces = (e.g. content acquisition, content purge, request routing, logging and = URL signing). >>>=20 >>> I=92m looking forward to your comments. >>>=20 >>> Have a nice weekend! >>>=20 >>> Ray van Brandenburg >>>=20 >>>=20 >>>=20 >>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Brandenburg, R. (Ray) van >>> Sent: woensdag 23 mei 2012 13:37 >>> To: cdni@ietf.org >>> Subject: [CDNi] Status of Adaptive Streaming and CDNI draft >>>=20 >>> Hi all, >>>=20 >>> Next Tuesday we have a planned interim meeting for discussing the = combination between HTTP Adaptive Streaming and CDNI. One of the = expected inputs for this meeting is a follow-up draft to = draft-brandenburg-cdni-has-00. >>>=20 >>> We are currently working hard at finishing this draft, but as you = might have seen, we have not yet uploaded a new version. Currently we = are at a stage where we have a first complete internal draft ready. = However, Francois and I have agreed that we rather spend some more time = on it so that it fully covers all the areas of the CDNI-HAS combination = than upload an incomplete version right now. We are currently planning = to upload the draft this Friday (25th of May) at the latest. I hope this = gives you all enough time to read the draft before the meeting on = Tuesday. >>>=20 >>> Sorry for the delay. >>>=20 >>> Ray >>>=20 >>>=20 >>>=20 >>> This e-mail and its contents are subject to the DISCLAIMER at = http://www.tno.nl/emaildisclaimer >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>>=20 >> >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. From flefauch@cisco.com Thu May 31 00:15:45 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F3921F863F for ; Thu, 31 May 2012 00:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.497 X-Spam-Level: X-Spam-Status: No, score=-10.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 FEMFxrLdsEkT for ; Thu, 31 May 2012 00:15:43 -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 AB23411E809A for ; Thu, 31 May 2012 00:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=21536; q=dns/txt; s=iport; t=1338448542; x=1339658142; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Tfd1400kFVuOjBr+jyR6PkideyiGNpIicKPgXCpDgu8=; b=RFZbwbtozjgXVgSb5t2lr2ka74cYzueME9GK33+gYvF+uULxq5Rfs5jE KxgHeR5uoEC5x3SgxSCxmmJCOpLS1JcDztBX9Pk8/56NvikYgyQF1bw6t PPxT+Lu5w6ZZs0wccScmJasyyLNb6CIVn2Esi99gHRQ0EUtKap+CJ3ugG Q=; X-IronPort-AV: E=Sophos;i="4.75,689,1330905600"; d="scan'208";a="5187842" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 31 May 2012 07:15:40 +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 q4V7FdTN008267; Thu, 31 May 2012 07:15:39 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Francois Le Faucheur In-Reply-To: <52EB616A-5984-4F9C-B32A-637D7D0FB72B@nomor.de> Date: Thu, 31 May 2012 09:15:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <649B3FEA-A7E6-4300-B111-2CD8A659C116@cisco.com> References: <291CC3F9E50E7641901A54E85D0977C653267F4D10@MAILR002.mail.lan> <66050772-394A-4A28-92FE-6A0581D5A533@jet-stream.nl> <291CC3F9E50E7641901A54E85D0977C653267F4D1F@MAILR002.mail.lan> <52EB616A-5984-4F9C-B32A-637D7D0FB72B@nomor.de> To: Thomas Stockhammer X-Mailer: Apple Mail (2.1278) Cc: "cdni@ietf.org" Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI 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: Thu, 31 May 2012 07:15:46 -0000 Hi Larry, Thomas, Thanks for the useful additional input. During the extended design team meeting, with respect to the Request = Routing question, my perception is that there was a fairly clear = consensus for 1) have CDNI support operation without any Manifest File = manipulation, 2) possibly allow the uCDN to optionally manipulate = manifest files -but that would not be specified by CDNI and would not = affect the CDNI interfaces and 3) do not go down the path of specifying = Manifest File manipulation by dCDN and specifying extensions to CDNI = interfaces to support that. So the solution proposed will likely not be "so complicated". But it is = useful to bring up all the options, have them documented (in cdni-has), = identify the pros & cons and then document the rationale for the = recommendations that will be made to the group. Cheers Francois On 30 May 2012, at 22:09, Thomas Stockhammer wrote: > +1 >=20 > /T >=20 > On May 30, 2012, at 10:00 PM, Peterson, Larry wrote: >=20 >> I apologize for not being able to make the call, but I can't help but = wonder >> why we're making this so complicated. >>=20 >> The whole point of HTTP-AS is to apply RESTful principles to video = delivery, >> to leverage the simplicity of HTTP. It seems like a mistake to assume = CDNs >> are purposely working against that principle, especially when doing = so >> complicates our ability to define a base/minimal CDNI strategy. >>=20 >> Larry >>=20 >> On May 29, 2012, at 3:06 AM, Stef van der Ziel wrote: >>=20 >>> Hi Kevin, >>>=20 >>> Op 27 mei 2012 om 18:00 heeft Kevin J Ma = het volgende geschreven: >>>=20 >>>> Hi Stef, >>>>=20 >>>> I was not arguing that a CDN would not prefer to have the manifest. >>>> I was more arguing that content providers may not trust CDNs with >>>> the manifest generation/modification. Securing content, preventing >>>> unauthorized access, and preventing piracy requires much more than >>>> simple auth tokens. DRM is explicitly listed as out-of-scope in >>>> the charter, so as I said, if the intent is to define a security >>>> protocol, then I would like to see more requirements. If, however, >>>> I have misunderstood, and section 3.5.4 is describing an existing >>>> feature that is widely supported across CDNs today, that just needs >>>> CDNI support, then I suppose that would be different. >>>>=20 >>>=20 >>> In general CDNs must offer the ability to secure access to content. >>> Access restriction and DRM can complement each other and don't = necessarily overlap. >>> Many CDNs use tokens between portals and request routers and between = request routers and delivery nodes to prevent unauthorized access to = content. >>>=20 >>> However being a stateless and segmented technology, HAS introduces a = new massive gap in the security by having manifest files in between the = request router and the actual content. So it is a responsibility for the = CDN to close this gap. >>>=20 >>> I know that many platforms who call themselves CDNs are nothing more = than a managed caching environment. So you can pull anything through. So = coming from this angle it makes sense to assume that you can simply = distribute manifests besides the CDN. I'm trying to educate here that = this vision is too simple and that we foresee that content providers = will demand from CDNs that their content is protected by actively = managing the manifests. >>>=20 >>> Doing nothing about manifest control, these passive CDNs have a wide = open security problem. I see many possibilities for people to = reconstruct manifests and abuse federated CDNs by directly pulling off = objects from caches. >>>=20 >>> If these CDNs would allow direct access to segments, that would be a = blocking issue for other CDNs to actually federate with these CDNs. = Because it breaks the level of security they are offering to their = content publishing customers. >>>=20 >>>=20 >>>> As for asset management, I agree the CDN needs to know what files = go >>>> together, but I do not agree that a CDN should be allowed to modify >>>> a manifest file any way it wants, or generate any manifest it wants >>>> and present that to the end user. Manifest files may contain other >>>> information besides segment file locations, e.g., DRM info, = targeted >>>> ad insertions, subscription-based customizations, etc., which the >>>> content provider may not trust the CDN with. I would like to know >>>> where the boundaries are of what the CDN may modify? Much of this >>>> requires subscriber-awareness. How subscriber-aware are we = assuming >>>> the CDN to be? One might argue that the CDN should perform all = these >>>> functions and be a one-stop intelligent content delivery shop, but >>>> that seems improbable in the short-run? >>>=20 >>> The real problem is that manifest files are quite open, not well = designed and immature so everyone in the value chain thinks they can = just use and abuse the manifest file for whatever purpose they have. >>>=20 >>> Content publishers may want to dynamically adjust the manifest files = to actually change the content on a per request basis. >>>=20 >>> At the same time CDNs must be able to adjust the manifest files to = do session tracking, access protection, management, etc. Without = actually changing the content by the way! >>>=20 >>> These requirements can't be supported at the same time today. In my = view the core role of a manifest is to instruct the client how to = reconstruct segments into a fluent stream. However there are secondary = roles which are in conflict: content adaptation (ad insertion for = insance) and CDN distribution management, asset management, session = management, access management. >>>=20 >>> The solution would be to wait for manifest files to become more = mature. I prefer to have manifest files roles to be split into content = management manifests and distribution management manifests. >>>=20 >>> Anyway it is too easy to assume that CDNs don't change manifests so = they don't need to serve out manifests. They do, so CDNi should be aware = of it. It is not a matter of being an advanced feature, it is how many = CDNs simply work from a core philosophy around HAS. >>>=20 >>> I'm not asking CDNi to make serving out manifests mandatory, because = that would be a similar mistake the other way around, what i propose is = that CDNi should be aware of which CDNs cannot control manifests, and = which CDNs make manifest control mandatory. >>>=20 >>>=20 >>>> Perhaps a more general question: Are we talking about making CDNs >>>> HAS aware, or making CDNI HAS aware? It feels more like the = former, >>>> with the latter being an after-thought, and it is not clear to me >>>> how the former fits into the charter? Going straight from the uCDN >>>> routing every segment, to the uCDN supporting modification of a = half >>>> dozen manifest formats feels disingenuous. Is there no BCP for how >>>> to configure DNS-RR to take the load off the uCDN RR, or a simple >>>> set of metadata to describe the source content structure which can >>>> facilitate more efficient content acquisition? >>>=20 >>> I think you hit a weak spot in CDNi. Some CDNs use passive DNS rr = and others use active HTTP rr. Some support both. Some also use redirect = instructional files which IMHO is the best technology since it is active = and guarantees much higher uptime and performance. If you want I can = share more details about this because it would be a great feature for = CDNi. >>>=20 >>> You are right that active rr CDNs may not want to federate to DNS = based CDNs because their service level would drop below the SLA they = offered to their customer. And you are right that some scenarios may = simply not work, for instance when a uCDN manifest based = anti-deeplinking and a dCDN hasn't implemented this. Some CDNs don't = care about manifests, others need them to do their job. It isn't = guaranteed that CDNs are always interchangeable. >>>=20 >>> So that is why it is so important that CDNi doesn't rule out = specific technology visions, architecture designs or technology choices. = It should support these different flavors and definitely not rule out = specific ones. And this is a typical example of information that should = be shared between CDNs via a capabilities API, so CDNs can decide if = they want to federate with other CDNs that cannot support the features = they require. >>>=20 >>> Best Stef >>>=20 >>>=20 >>>>=20 >>>> thanx. >>>>=20 >>>> -- Kevin J. Ma >>>>=20 >>>> From: Stef van der Ziel [mailto:stef@jet-stream.nl] >>>> Sent: Sunday, May 27, 2012 9:03 AM >>>> To: Kevin J Ma >>>> Cc: Brandenburg, R. (Ray) van; cdni@ietf.org >>>> Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft >>>>=20 >>>> Hi Kevin, >>>>=20 >>>> Actually, many CDNs prefer to serve out both the segments and the = manifest files. >>>> Sure, dumb caching/DNS based CDNs can be used to deliver segments = and they wouldn't care about segments. They will just pump out the = delivered objects. But intelligent CDNs that are actually usable for = commercial/secure and manageable HAS, need the manifests. >>>>=20 >>>> IMHO the role of a manifest file should not be confused with the = role of a referrer file. >>>> A manifest is to represent the entire content, not just to the = client but in the entire chain of encoding, protection, CDN and clients. >>>> A referrer file is the proper way to point to the (logical) content = from any remote location. >>>>=20 >>>> We hardly ever see manifest files to be distributed outside of the = CDN in reality. It is not a fairly common scenario and should not be. In = more automated environments, it can actually be the CDN that creates the = manifest. >>>>=20 >>>> The assumption that manifest files should or can be distributed = offline or outside the CDN is mostly wrong. The assumption that you can = point from a manifest to a CDN for the segments won't work since a = proper CDN would (should) block direct access to segments to prevent = deep linking. But we understand why people make these assumptions, we've = heard other statements from HAS enthusiasts that don't make sense in the = real world. >>>>=20 >>>> Serving out the manifests alongside the segments from the same CDN = account is done for multiple reasons, which do not at all adapt the = content: >>>>=20 >>>> - Logical asset recognition (parsing the manifests so the CDN = understands that the segments are part of a logical entity) >>>> - Logical asset management (processing, copying, managing manifests = and subsequent segments as if they are one asset) >>>> - Logical asset reporting (reporting manifests and subsequent = segments via web interfaces and APIs as if they are one asset) >>>> - Request routing control (CDNs only produce URLs for manifest = files and will not accept requests for segments to prevent unnecessary = request routing overload by having to request route every individual = segment request) >>>> - Access control (CDNs will not allow direct access to segments but = only via the manifest file to prevent deep-linking, you don't want any = third party to publish a manifest file on an unlicensed portal and then = point users to the segments on the CDN without any access control) >>>> - Session control (http streaming is stateless and that is quite = dramatic for CDNs because you lose control over the session and over = session logging) >>>>=20 >>>> There are additional reasons for CDNs to be able to adapt the = manifest files but do so without changing the actual content: >>>> - For instance, they could dynamically insert base URLs to point = users to a group of servers to improve the availability. >>>> - Or they could dynamically insert tokens into the manifest to = control access to segments. >>>> - Or they could dynamically insert session keys to be able to track = a unique user session over multiple federated CDNs. >>>> - Or they could dynamically remove higher or lower bit rates to = better control the actual QoE on a per request basis. >>>>=20 >>>> Concluding: >>>> To a CDN, the segments aren't actually that interesting. They are = just pieces of useless raw data that needs to be protected, managed and = served. >>>> For a CDN, the manifest represents the content and is a critical = component so they need to be able to parse, alter and serve them. >>>>=20 >>>> I think the above by itself describes some interesting challenges. = Just one example: how are CDNs going to guarantee anti-deeplinking to = segments in a federated constellation where multiple nodes of multiple = CDNs and request routers need to be aware of each others sessions and = tokens, etc? >>>>=20 >>>> My 2 cents. >>>>=20 >>>> Kind regards, Stef van der Ziel >>>>=20 >>>> -- >>>> Owner Jet-Stream | StreamZilla >>>> GMT+1 Office: +31 50 5261820 | Mobile: +31 6 23406348 >>>> www.jet-stream.com | www.streamzillacdn.com >>>> this communication is confidential >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 27 mei 2012, at 01:37, Kevin J Ma wrote: >>>>=20 >>>>=20 >>>> Hi Ray, >>>>=20 >>>> I read through the updated draft and had a number of comments ahead = of >>>> the meeting. >>>>=20 >>>> First, a general comment about manifest files. The document seems >>>> to assume that manifest files will be distributed through the CDN. >>>> There are many services where this is not the case, often to = prevent >>>> modification. There is a large focus in the document on how to = modify >>>> manifest files, in some cases where the manifest file itself is not >>>> necessarily relevant. I believe there are ways to optimize HAS >>>> delivery without modifying manifest files, and in imo, manifest >>>> manipulation falls under content adaptation which the wg declared = to >>>> be out of scope for the initial phase? >>>>=20 >>>> With respect section 2.2, I believe I commented on this in the >>>> initial draft, but I still feel that the relative vs absolute URL >>>> discussion is rather misleading. It seems to imply that: >>>> a) the HOST portion of a relative URL cannot point to a RR, that >>>> b) a RR must be accessed through some web service like API, and = that >>>> c) absolute URLs can only point to specific surrogates. >>>> While these are all valid examples of how to use URLs, they do not >>>> seem to be typical cases. For us, a typical service has a DNS >>>> address which points to a base directory in one or more CDNs. The >>>> relative path from that base directory is the same in all CDNs. = The >>>> hostname does not point to any one surrogate, and each CDN is still >>>> able to redirect requests as it sees fit. >>>>=20 >>>> With respect to sections 3.1 and 3.2, while I agree that content >>>> storage and acquisition optimization is important, and that there >>>> should be metadata which can describe the format of the content, I >>>> do think the CDN needs to be fully HAS aware, nor do I think that >>>> the CDN necessarily needs access to the manifest file. I also do >>>> not see a "significant" impact to the MI. The metadata interface >>>> will have the ability to define metadata that applies to a set of >>>> content assets, per the META-10 requirement. Ultimately, the CDN >>>> needs to be able to respond to content requests from the client, >>>> even if that client got a manifest file directly from the content >>>> provider (not from the CDN) and is expecting the content to be in >>>> the format that was provided to the CDN by the content provider. >>>> How it got the content and how it stores it is out of scope? >>>>=20 >>>> With respect to section 3.3, I think that a third case is missing, >>>> where the content provider does not provide the manifest file to = the >>>> CDN (which can be a fairly common case). >>>>=20 >>>> With respect to sections 3.3.2 and 3.3.3, would not DNS-based >>>> redirection solve the issue by simply directing manifest/chunk >>>> requests to the dCDN, rather than doing a manifest rewrite for = every >>>> request (especially in the case of live streaming where the = manifest >>>> might be changing on every chunk)? Also, presumably, the RR would >>>> only rewrite URLs which were within its own domain (i.e., not >>>> blackholing ad insertion segments, etc.)? >>>>=20 >>>> With respect to section 3.5, the time component of URL signing is >>>> not mentioned until section 3.5.3. Expiration of URL tokens, in >>>> general, is an issue with HAS. Robust key management is an = arguably >>>> more reliable approach to content access protection, though that >>>> would seem to be fairly well out of scope for CDNI. The proposed >>>> solution in section 3.5.3, seems to be managing session state? >>>> Depending on the complexity of the cookie, this could be = troublesome >>>> if there is a failover and session state is not properly = synchronized? >>>> And in the case of live streaming, the manifest is going to be >>>> requested every time? How is the state managed in that case? Is >>>> the cookie less susceptible to replay attacks than the URL token? >>>> Will the cookie work across all CDNs? Moving on to section 3.5.4 >>>> is even more concerning. What if the content is already encrypted? >>>> How is authentication being handled on the key server? Who is >>>> responsible for auditing the security of the solution? Is this >>>> intended to provide DRM? work with existing DRM? circumvent >>>> existing DRM? Does it only use the DRM/encryption support of the >>>> delivery protocol? or is the client expected to implement an >>>> alternate protocol? And how is this synchronized across CDNs? >>>> More generally, are we attempting to define security protocols for >>>> content delivery? If so, I would like to see a more formal >>>> definition of what those requirements are? >>>>=20 >>>> With respect to section 3.6.2, it seems that we just want to be = able >>>> to purge a set of content assets. Would a URI prefix not be = sufficient? >>>>=20 >>>> thanx. >>>>=20 >>>> -- Kevin J. Ma >>>>=20 >>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On = Behalf Of Brandenburg, R. (Ray) van >>>> Sent: Friday, May 25, 2012 10:19 AM >>>> To: cdni@ietf.org >>>> Subject: Re: [CDNi] Status of Adaptive Streaming and CDNI draft >>>>=20 >>>> Hi all, >>>>=20 >>>> I=92ve just uploaded a new version of draft-brandenburg-cdni-has. >>>>=20 >>>> You can find the document at: = http://www.ietf.org/id/draft-brandenburg-cdni-has-01.txt >>>>=20 >>>> The draft is meant as an input document for the virtual meeting on = Thursday to discuss the impact of HTTP Adaptive Streaming on the CDNI = Interfaces. In the draft a number of alternative solutions are presented = for each area where the use of HAS might touch with the CDNI Interfaces = (e.g. content acquisition, content purge, request routing, logging and = URL signing). >>>>=20 >>>> I=92m looking forward to your comments. >>>>=20 >>>> Have a nice weekend! >>>>=20 >>>> Ray van Brandenburg >>>>=20 >>>>=20 >>>>=20 >>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On = Behalf Of Brandenburg, R. (Ray) van >>>> Sent: woensdag 23 mei 2012 13:37 >>>> To: cdni@ietf.org >>>> Subject: [CDNi] Status of Adaptive Streaming and CDNI draft >>>>=20 >>>> Hi all, >>>>=20 >>>> Next Tuesday we have a planned interim meeting for discussing the = combination between HTTP Adaptive Streaming and CDNI. One of the = expected inputs for this meeting is a follow-up draft to = draft-brandenburg-cdni-has-00. >>>>=20 >>>> We are currently working hard at finishing this draft, but as you = might have seen, we have not yet uploaded a new version. Currently we = are at a stage where we have a first complete internal draft ready. = However, Francois and I have agreed that we rather spend some more time = on it so that it fully covers all the areas of the CDNI-HAS combination = than upload an incomplete version right now. We are currently planning = to upload the draft this Friday (25th of May) at the latest. I hope this = gives you all enough time to read the draft before the meeting on = Tuesday. >>>>=20 >>>> Sorry for the delay. >>>>=20 >>>> Ray >>>>=20 >>>>=20 >>>>=20 >>>> This e-mail and its contents are subject to the DISCLAIMER at = http://www.tno.nl/emaildisclaimer >>>>=20 >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >>>>=20 >>> >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 > --- > Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || http://www.nomor-research.com > Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Thu May 31 06:27: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 EAF0E21F865E for ; Thu, 31 May 2012 06:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.51 X-Spam-Level: X-Spam-Status: No, score=-10.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 klo1rBTnE5W4 for ; Thu, 31 May 2012 06:27:02 -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 075C621F8653 for ; Thu, 31 May 2012 06:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=8971; q=dns/txt; s=iport; t=1338470822; x=1339680422; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=hYpiLtaOL1+1HCZxpU0Odv93PibkUL1pO9RKkmQ2qRg=; b=h8P8DxhbPfHu6aNYKK8LjnCyoAmgK41/vUqflKguqgqv/0P2993uORGb D/T+/Ao41VUw/HYFyd7aaCqdtGf2ZGYUkVcm+uHyhkN2qB8w8WX6iaqeL gRdtpHodaKCeZLidYLbsZepDhx/OFPE1srtfbR0QLom/sJy3r1rmimp/W 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEABBxx0+Q/khN/2dsb2JhbAAqGrQLgQeCMQGBFRmBJAeFb4F6CymXRIEon2QEixECHoIEgkJgA5UYhU+IPoFmgmKBVQg X-IronPort-AV: E=Sophos;i="4.75,692,1330905600"; d="scan'208";a="73868664" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 31 May 2012 13:27:00 +0000 Received: from [144.254.53.99] ([144.254.53.99]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q4VDR0SR027039 for ; Thu, 31 May 2012 13:27:00 GMT From: Francois Le Faucheur Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 31 May 2012 15:27:02 +0200 Message-Id: <5B58A245-3F8F-4BAE-945C-F02D158FCCC4@cisco.com> To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [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: Thu, 31 May 2012 13:27:04 -0000 Folks, Here are draft notes from the May 29 extended design team meeting. Let = us know 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, USA) =3D 16:00 CET (e.g Paris, France) =3D 22:00 CST (e.g. = Beijing, China) Finish Time: 10:00 PDT (e.g San Francisco, USA) =3D 13:00 EDT (e.g = Boston, USA) =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&= rKey=3Da34577e4e4e8ec5a=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 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 = design 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 work 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 terminology: 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 same "HAS session" may be coming from different origin servers = and may be following different CDN paths. Include the example of Ad = insertion possibly locally sourced: Ray, possibly with input from Kevin * 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 * add to cdni-has a clarification that, in some situations, the = manifest file follows the same delivery path as the corresponding chunks = (and therefore may be visible to CDNs on the chunk delivery path) and = that in some situations the manifest file follows a different delivery = path (e.g. delivery directly by CSP or uCDN to client) and therefore is = not visible to dCDN. Indicate 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 chunks of a Content Collection to indicate those are = likely to be requested in 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 & cons discussion = indicate that impact on CDNI interfaces is very small (since the new = "Access Correlation Hint" doe snot include any HAS-scheme awareness) 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 =85 only file = storage benefit), and single CDNs already do local optimization today = without this. It is the responsibility of dCDN to do scaleable file = management, not of CDNI. o approach 1.2 would bring benefits but requires full = HAS awareness and significant CDNI extension that would significantly = impact our milestones, so we don't recommend to include in current work. = Good candidate for rechartering 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 work". o approach 2.2 would bring benefits but requires full = HAS awareness and significant CDNI extension that would significantly = impact our milestones, so 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 content. With Dynamic Acquisition, triggered = acquisition of subsequent chunks probably has an extra benefit of = avoiding acquisition latency on cache-miss. With Prepositioning, there = may be specific ways to enhance those (e.g. a single 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 = typo 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. Pages have relative-URLs that reference media on the = same page which may actually 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 this already exists in single CDN: Ray (possibly with = input from Ben). * 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 * in cdni-has, in section discussing option 3.2, clarify that = this is somewhat transparent to CDNI (i.e. it happens in uCDN before = CDNI plays) but that it is worth explicitly discussing (in particular in = the framework) _if we want to allow it_ because it affects how the uCDN = will make use of the CDNI 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 the 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 extensions to CDNI interfaces). We need a little = more discussion as to whether it shoudl actually be allowed or not. 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 * Do the existing HAS schemes allow combination of use of = Relative URLs for normal access to content + use of Absolute URLs with = Redirection for backup 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 2012 * Ray & co-authors to rev up cdni-has * run another virtual meeting of extended design team in 2nd = half of June. From oskar.vandeventer@tno.nl Thu May 31 07:22: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 A055721F85C5 for ; Thu, 31 May 2012 07:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.845 X-Spam-Level: *** X-Spam-Status: No, score=3.845 tagged_above=-999 required=5 tests=[AWL=-1.551, BAYES_00=-2.599, GB_MUTUALBENEFIT=2, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_BACKHAIR_11=1, J_CHICKENPOX_31=0.6, MANGLED_ONLINE=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3eLo8v9vpYi for ; Thu, 31 May 2012 07:22:40 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBD021F8468 for ; Thu, 31 May 2012 07:22:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,692,1330902000"; d="scan'208";a="15380656" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1b.tno.nl with ESMTP; 31 May 2012 16:22:35 +0200 Received: from EXC-MBX01.tsn.tno.nl ([169.254.1.223]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0283.003; Thu, 31 May 2012 16:22:35 +0200 From: "Deventer, M.O. (Oskar) van" To: "cdni@ietf.org" Thread-Topic: [CDNi] Two additional definitions for cdni-framework Thread-Index: AQHNLgYLeY8BkZtou0meYd3bttB6nJbNBwAAgAv41OCACxVYIA== Date: Thu, 31 May 2012 14:22:34 +0000 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> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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: Thu, 31 May 2012 14:22:43 -0000 Dear Larry and Francois, > Yes... Generally, it would be good to do a survey of terminology = > various docs have introduced recently, and converge on the core = > definitions. CDNi terminology is also under development by the ETSI CDNi activity (ETSI_= CDN@list.etsi.org). So while we are harmonizing terminology between IETF do= cuments, we should also consider the relevant ETSI documents. These are the relevant ETSI document: Use cases and requirements: http://docbox.etsi.org/MCD/Open/Latest_Drafts/c= dn-i013v0011.pdf Architecture and information flows: http://docbox.etsi.org/TISPAN/Open/NGN_= LATEST_DRAFTS/RELEASE_INDEPENDENT/02086_ts182032_cdn-i_architecture_v004.pdf Here is an initial analysis of CDNi terminology and approaches by ETSI and = IETF. -The terms "distribution" and "delivery" seem to consistent between ETSI an= d IETF. The first term is intra- and inter-CDN, whereas the second term is = about delivery to a user agent. -There may to be an inconsistency between the IETF and ETSI definitions of = Upstream CDN and Downstream CDN. The IETF Problem Statement defines these i= n terms of redirection (upstream redirects to downstream). ETSI defines the= se in terms of distribution (upstream closer to Content Provider, downstrea= m closer to Consumer). Especially in case of HAS content, there may be no r= edirection for individual chunks (segments, fragments), whereas we would st= ill consider the chunk-delivering-CDN the "downstream CDN". Would this requ= ire a refinement of the IETF definition? -Unlike ETSI, IETF has no terminology for segmented content yet. This is wo= rk in progress on http://tools.ietf.org/id/draft-brandenburg-cdni-has-00.tx= t, and we are trying to remain aligned. -The IETF Framework document defines four interfaces (or five, if one count= s the moving-of-content), whereas ETSI has only two (or three, if one count= s ...). These are the ETSI ones: -Interconnection Control: ... is used for controlling interconnection pe= er and transferred over this point information related to CDN capabilities = and status, including footprint exchange, capability exchange, interconnect= ion status reporting and network usage/performance logging. -Request Routing and Content Control: ... is used for requesting content= and to transfer content related information, including content metadata ex= change, content requests and content status reporting. The reason for having only two interfaces is that having more interfaces th= an needed takes unnecessary implementation complexity and additional config= uration and management effort. Can you tell me why IETF CDNi has four inter= faces, and why two is not enough? -IETF has a rather loose definition of Content: "Any form of digital data [= including] continuous media." ETSI has a more strict and CDNi-functional definition of Content Item: "A u= niquely addressable content element in a CDN. A content item is defined by = the fact that it has its own Content Metadata associated with it. It is the= object of content distribution and request routing operations in a CDN. Ex= ample of Content Items are a video file/ stream, an audio file/stream, an i= mage file or segmented content together with an associated manifest file." Would it make sense to add this definition of "Content Item" to the Problem= Statement or Framework documents? -ETSI distinguishes logging ("recording event ...") from reporting ("provid= ing access to recorded events ..."). This includes the possibility that the= dCDN processes the logged information, e.g. into a standardized, possibly = aggregated format. IETF uses only the term logging. Does this preclude repo= rting processed logging information between CDNs? Depending on the response to this analysis, I would be happy to draft some = refined definitions. Thank you. Best regards, Oskar ETSI rapporteur on CDNi work items Dr. ir. M.O. (Oskar) van Deventer TNO - Innovation for Life Senior Scientist Media Networking Media & Network Services T=A0+31 (0)88 866 70 78 M=A0+31 (0)65 191 49 18 E=A0oskar.vandeventer@tno.nl -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Fra= ncois Le Faucheur Sent: Thursday, 17 May, 2012 02:16 To: Peterson, Larry Cc: cdni@ietf.org Subject: Re: [CDNi] Two additional definitions for cdni-framework Larry and all, My understanding is that: * problem-statement includes a set of "core" definitions. = * framework will be cleaned up to refer to problem-statement for all the "= core" definitions (and not redefine them) * framework will include the additional definitions of general interest to= the working group. I believe there are a few already in framework in that = category. = * I think we are converging that: * "Delivering CDN" fits in the category of additional definitions to be i= ncluded in the framework * "Access CDN" does not fit that category and shoudl not be introduced in= framework. If folks (in particular authors of other documents) feel that they have def= initions that shoudl go into framework, please indicate so on the list. Thanks Francois On 9 May 2012, at 19:05, Peterson, Larry wrote: > Yes... Generally, it would be good to do a survey of terminology = > various docs have introduced recently, and converge on the core = > definitions. > = > Larry > = > On May 9, 2012, at 11:47 AM, Francois Le Faucheur wrote: > = >> Hi Larry, >> = >> Can you confirm this can be done in next rev of cdni-framework? >> = >> Tx >> = >> Francois >> = >> = >> On 9 May 2012, at 17:19, wrote: >> = >>> Hi Fran=E7ois, >>> = >>> Thanks for your review. We are integrating your comments. >>> = >>> About your comments on Section 1.1, I definitely think the terms "Acces= s CDN" and "Delivering CDN" are useful more broadly than just in the use ca= ses document. Therefore, I would be in favor of moving them to the framewor= k document as you propose. >>> = >>> Access CDN: >>> A CDN that includes Surrogates in the same network (e.g., same Aut= onomous System) as the End User. An Access CDN may have specific informatio= n about >>> the End User and the network, for instance, End User's >>> profile and access capabilities. >>> = >>> Delivering CDN: >>> The CDN that delivers the requested piece of content to >>> the End User. In particular, the Delivering CDN can be an >>> Access CDN. >>> = >>> = >>> Best regards, >>> = >>> Gilles >>> = >>> = >>> -----Message d'origine----- >>> De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part = >>> de Francois Le Faucheur Envoy=E9 : mercredi 25 avril 2012 18:46 =C0 : >>> draft-ietf-cdni-use-cases@tools.ietf.org >>> Cc : cdni@ietf.org >>> Objet : [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases >>> = >>> To use-cases authors, >>> = >>> Below are my shepherd review comments of cdni-uses-cases. >>> = >>> I think the document is in a good shape and captures well the key targe= ted use cases. >>> I identified two remaining significant points to be addressed, and also= have included many suggestions to improve the document. >>> I suggest we resolve the two significant points on the list and leave i= t to editor/authors to decide how to dispose of the suggestions for improve= ment offline. >>> = >>> Cheers >>> = >>> Francois >>> = >>> = >>> Significant points >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> = >>> *** section 8 security considerations I have a few specific issues = >>> with the current text of the Security Considerations section. But I don= 't really see the need to have an expanded Security Considerations section = in both the use-case document and the problem-statement (particularly consi= dering that the first IESG review comments on problem-statement suggest exp= anding the security considerations section there), in particular because th= e security considerations currently brought up in use-cases are not specifi= c to individual use cases bur rather generic to the whole CDN interconnecti= on problem space. >>> So my proposal would be to remove the whole discussion from use-cases (= i.e. the first 4 paragraphs) and refer to the Security Considerations secti= on of the Problem Statement e.g.. by replacing: >>> " >>> This document focuses on the motivational use cases for CDN Interconnec= tion, and does not analyze these threats in detail. >>> " >>> with: >>> " >>> This document focuses on the motivational use cases for CDN Interconnec= tion, and does not analyze the associated threats. Those are discussed in [= I-D.ietf-cdni-problem-statement]. >>> " >>> = >>> = >>> ***section A.1: >>> I still have a problem with the text of that section. >>> I thought we had converged on an agreement that the text would: >>> * explain that CSPs may take into account very multiple/arbitrary/s= pecific criteria in their policy >>> * explain that the CDNs are only expected to enforce a few specific= policy rules (e.g. geo-blocking, time window) and for enforcement of all f= ancy CSP policy we propose that the responsibilities be divided into (1) th= e CSP being responsible for the fancy policy decision and (ii) the CDN for = merely enforcing the CSP decision without having to understand the policy (= e.g. via URI signing). >>> Do we not agree on that or not? >>> = >>> The current text says that CDN selection and surrogate selection "are i= nfluenced by these policies" (referring to the fancy CSP policies). I do no= t agree with that. I don;t think we want CDN Selection or Surrogate selecti= on to be influenced by whether a movie shoudl be available 14 or 28 days af= ter DVD release, or whether a given resolution is "too high" for a particul= ar user or terminal. >>> = >>> Also, the paragraph keeps talking about "dCDN selection or Surrogate se= lection" may fail for some fancy policy reasons. I don't understand what it= means to "fail" , but more importantly again, I don't think we want CDN re= quest routing decisions to be factoring very fancy CSP policy rules. >>> Do we agree or not? >>> = >>> The last paragraphs gives examples of the CSP objectives of supporting = delivery policies in CDNs, and those are fine and can be achieved with the = set of mechanisms discussed above (i.e. goeblocking + time window + URI sig= ning). >>> = >>> = >>> Suggestions for improvements >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> = >>> ***Abstract >>> replace "CDNI" by "CDN Interconnection". >>> = >>> *** section 1: >>> expand the first instance of CDNI into "CDN Interconnection (CDNI)". >>> = >>> *** section 1: >>> "Then, the document highlights the need for interoperability to = >>> exchange and enforce content delivery policies (Section 5)." >>> I'd suggest replacing "for interoperability to exchange" by "for intero= perability to allow exchange" or by "for interoperability in order to excha= nge" >>> = >>> *** section 1.1: >>> Do you feel that the two additional terms are really specific to the us= e-case document (in which case their definition should stay in this documen= t) or are they likely useful in other documents (in which case their defini= tion should be migrated to the framework document)? >>> Personally, I would say that those terms might be useful in other docum= ents/discussions (eg I am pretty sure we'd need to refer to the "Delivering= CDN" in other context). >>> = >>> *** section 1.1: >>> "Access CDN: >>> A CDN that is directly connected to the End User's access." >>> I think this definition needs to be a little more specific. "Directly c= onnected" does not mean "L2 connectivity" (because an on-net cache maybe a = few L2 hops away), nor does it mean "L3 connectivity" (because an OTT CDN c= ache has IP connectivity to an enduser). I think you mean something in betw= een, more or less that the CDN and the access are within the same IP admin= istrative domain, or something close to that. Can you try refine that defin= ition? >>> = >>> *** section 1.3: >>> " o improve the experience for the End User; for instance delivery has >>> lower latency (decreased round-trip-time between the user and the >>> delivery server) and better robustness," >>> To be more comprehensive in justifying the claims, how about: >>> " o improve the experience for the End User; for instance delivery has >>> lower latency (decreased round-trip-time and higher throughput betwee= n the user and the >>> delivery server) and better robustness (ability to use multiple deliv= ery servers)," >>> = >>> *** section 1.3: >>> "o reduce the Content Service Provider's (CSP) costs, such as >>> datacenter capacity, space, and electricity consumption, as >>> popular content is delivered through the CDN rather than through >>> the CSP's servers." >>> The current wording raises the question of "if it reduces the costs by = reducing expenses in the CSP datacenter, why does it not correspondingly in= crease the cost by increasing expenses in the CDN (which the CDN provider t= hen charges back to the CSP)?" >>> I think the gain is in the scale and effective pooling of CDN resources= across many CSPs. Could you refine the wording to explain why there is ind= eed a net gain? >>> = >>> *** section 1.3: >>> Replace: >>> " >>> An example is depicted in Figure 1. Two CDN Providers establish a CDN = Interconnection. >>> " >>> with: >>> " >>> An example is depicted in Figure 1 where two CDN Providers establish a = CDN Interconnection. >>> " >>> (this is to minimize the redundancy with the sentence coming below: = >>> "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their >>> CDNs.") >>> = >>> = >>> *** section 1.3: >>> replace: >>> " >>> "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs= ." >>> with: >>> "Independently, CDN Provider 'A' and CDN Provider 'B' agree to intercon= nect their CDNs." >>> this is to clarify that the A<->B agreement is not specific to the = >>> 1<->A agreement >>> = >>> = >>> *** section 1.3: >>> replace: >>> " >>> When a User Agent requests content from CSP-1, CDN-A considers that del= ivery by CDN-B is appropriate " >>> with: >>> " >>> When a given User Agent requests content from CSP-1, CDN-A may consider= that delivery by CDN-B is appropriate " >>> = >>> = >>> *** section 1.3: >>> replace: >>> " >>> CDN-A has delegated the handling of requests for CSP-1's content throug= h the CDN Interconnection agreement, thus, the content is actually delivere= d from CDN-B. >>> " >>> with: >>> " >>> Through the CDN Interconnection arrangements put in place between CDN-A= and CDN-B (as a result of the CDN Interconnection agreement established be= tween CDN Provider 'A' and CDN Provider 'B'), CDN-A can redirect the reques= t to CDN-B and the content is actually delivered to the User Agent by CDN-B. >>> " >>> (the current wording suggests that all deliveries of CSP1 content = >>> would be handled by CDN-B, which is typically not the case i.e. only = >>> a subset of the requests are redirected thy CDN-A to CDN-B) >>> = >>> = >>> *** section 1.3: >>> replace: >>> " >>> CSP-1 benefits because it only needs to make one business agreement and= one physical connection, with CDN Provider 'A' >>> " >>> with: >>> " >>> CSP-1 benefits because it only needs to make one business agreement and= one technical arrangement with CDN Provider 'A' >>> " >>> (this is because the interfacing between CSP and uCDN comprises more th= an "physical connection"). >>> = >>> = >>> *** section 1.3: >>> replace: >>> " >>> CSP-1 had also gone to the trouble of making a business agreement with = CDN Provider 'B' >>> " >>> with: >>> " >>> CSP-1 had also gone to the trouble of making a business agreement and t= echnical arrangemement with CDN Provider 'B' >>> " >>> = >>> *** section 1.3: >>> replace: >>> " >>> But it does not want >>> " >>> with: >>> " >>> However, CSP-2 may not want >>> " >>> = >>> *** section 2.1: >>> after >>> " >>> o without incurring additional transit and other network costs that >>> would result from serving content from geographically or >>> topologically remote Surrogates. >>> " >>> add: >>> " >>> o without incurring the cost of deploying and operating Surrogates and = the associated CDN infrastructure that may not be justified in the correspo= nding geographic region (e.g. because of relatively low delivery volume, or= conversely because of the high investments that would be needed to satisfy= the high volume) " >>> = >>> = >>> *** section 2.2: >>> replace: >>> " >>> A large CDN Provider may also operate CDNs from several subsidiaries (w= hich may rely on different CDN technologies, see Section 4.2). In certain c= ircumstances, the CDN Provider needs to make its CDNs interoperate to provi= de a consistent service to its customers on its whole footprint. >>> " >>> with: >>> " >>> A large CDN Provider may have several subsidiaries that also each opera= te their own CDN (which may rely on different CDN technologies, see Section= 4.2). In certain circumstances, the CDN Provider needs to make these CDNs = interoperate to provide a consistent service to its customers on the whole = collective footprint. >>> " >>> = >>> = >>> *** section 2.3: >>> replace: >>> " >>> injected into the access network >>> " >>> with: >>> " >>> injected into the ISP network >>> " >>> = >>> *** section 2.3: >>> replace: >>> " >>> There are mutual benefits to the Access CDN, " >>> with: >>> " >>> There are mutual benefits to the ISP (acting as an Access CDN), " >>> = >>> = >>> *** section 2.3: >>> replace: >>> " >>> for example, QoS and reduced round trip time. >>> " >>> with: >>> " >>> for example, reduced content startup time or increased video quality an= d resolution of adaptive streaming content. >>> " >>> (I don't think RTT is very meaningful to a CSP customer) >>> = >>> = >>> *** section 2.4: >>> The nomadic user is currently defined as "moving between CDNs" which is= sort of a self-serving definition to justify CDN interconnection. I think = we should rather define the nomadic user as "moving between access networks= " and then justify that leveraging local CDNs can bring a lot of benefits. >>> This requires the following text edits: >>> s/who move between CDNs/who move between access networks/ s/moving = >>> between different CDN Providers/moving between different access = >>> networks/ >>> = >>> *** section 2.4: >>> replace: >>> " >>> which may reside >>> " >>> with: >>> " >>> which may be located >>> " >>> = >>> *** section 2.4:" >>> I propose to remove the sentence: >>> " >>> The term "Nomadic" does not necessarily relate to geographic roaming. >>> " >>> because this point has already been fully (and better) clarified in the= preceding paragraph. >>> = >>> = >>> = >>> *** section 2.4: >>> replace: >>> " >>> the WiFi or mobile provider >>> " >>> with: >>> " >>> the WiFi or mobile provider (NSP B) >>> " >>> = >>> = >>> *** section 3.1: >>> replace: >>> " >>> needs CDN capacities >>> " >>> with: >>> " >>> needs CDN capacity >>> " >>> = >>> *** section 3.2.1: >>> The text mentions two options (use OS, use another CDN). I think the se= ction shoudl probably also mention the most obvious option (i.e. use other = surrogates in the same CDN). Or alternatively, clarify that the considered = situation is where there is a partial failure of some surrogates resulting = in the remaining surrogates being fully loaded. >>> = >>> = >>> *** section 3.2.1: >>> replace: >>> " >>> to both distribute load between origin servers and attempt content = >>> acquisition from alternate origin servers when acquisition failures occ= ur. When normal content acquisition fails, a CDN may need to try other ori= gin server options, " >>> with: >>> " >>> to both distribute load between content sources and attempt content = >>> acquisition from alternate content sources when acquisition failures oc= cur. When normal content acquisition fails, a CDN may need to try other co= ntent source options, " >>> (I believe everywhere else we use "origin server" to refer to the OS = >>> of the CSP and "content source" as the generic term for getting = >>> content including origin server and uCDN) >>> = >>> *** section 3.2.2: >>> replace: >>> " >>> the selection of content acquisition sources should be considered. >>> " >>> with: >>> " >>> the selection of content acquisition sources should be considered and f= acilitated. >>> " >>> (i.e. it is not just a matter of "thinking" about it: it must be explic= itly allowed or at leads made easier). >>> = >>> = >>> *** section 4.1: >>> "to serve a proportion of its traffic that requires HTTPS." >>> can you include a reference for HTTPS? >>> = >>> = >>> *** section 5: >>> replace: >>> " >>> An important aspect of the above use cases " >>> with: >>> " >>> An important aspect common to all the above use cases " >>> = >>> = >>> *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on = >>> line 618, but no explicit reference was found in the text I'd suggest y= ou add an explicit reference. For example, in "1. Introduction" you could = replace: >>> " >>> The document can be used to guide the definition of the requirements to= be supported by the various CDNI interfaces defined in [I-D.ietf-cdni-prob= lem-statement]. >>> " >>> by >>> " >>> The document can be used to guide the definition of the requirements (a= s documented in [I-D.ietf-cdni-requirements]) to be supported by the set of= CDNI interfaces defined in [I-D.ietf-cdni-problem-statement]. >>> " >>> (BTW, independely of the reference issue, "the set of CDNI interfaces" = might read better than "the various CDNI interfaces"). >>> = >>> = >>> *** The document has a disclaimer for pre-RFC5378 work, but was first = submitted on or after 10 November 2008. Does it really need the disclaimer? >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >> = > = _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer