idnits 2.17.1 draft-krishnan-cdni-long-tail-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 272 has weird spacing: '... be access...' == Line 274 has weird spacing: '... user devi...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 26, 2013) is 3959 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.ietf-cdni-problem-statement-08' is mentioned on line 115, but not defined == Missing Reference: 'I-D.ietf-cdni-requirements-06' is mentioned on line 117, but not defined == Missing Reference: 'I-D.ietf-cdni-framework-03' is mentioned on line 119, but not defined == Missing Reference: 'I-D.ietf-cdni-use-cases-10' is mentioned on line 121, but not defined == Unused Reference: '1' is defined on line 285, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 288, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 295, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) -- Duplicate reference: RFC2119, mentioned in 'RFC2119', was also mentioned in '1'. -- Duplicate reference: RFC2234, mentioned in 'RFC2234', was also mentioned in '2'. ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 5 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CDNI R. Krishnan 2 Internet Draft Brocade Communications 3 Intended status: Informational M. Li 4 Expires: November 2013 B. Khasnabish 5 ZTE USA 6 C. Ge 7 China Telecom 8 May 26, 2013 10 Best practices and Requirements for delivering Long Tail 11 personalized content delivery over CDN Interconnections 13 draft-krishnan-cdni-long-tail-05.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with 18 the provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC-2119 [RFC2119]. 59 Abstract 61 The content desire of users is evolving from most popular to long 62 tail personalized content. This document discusses the best 63 practices and requirements for delivering long tail personalized 64 content in CDN Interconnection scenarios. 66 Table of Contents 68 1. Introduction...................................................2 69 2. Conventions used in this document..............................3 70 3. No Caching in CDNs.............................................3 71 4. Benefits of HTTP Adaptive Streaming............................6 72 5. Other techniques for delivering long tail personalized content.6 73 6. Acknowledgements...............................................7 74 7. References.....................................................7 75 7.1. Normative References......................................7 76 7.2. Informative References....................................7 78 1. Introduction 80 Typically, the CDNI interface between CDNs is a long-haul backbone 81 network where bandwidth is premium. For user content requests from 82 the downstream CDN (dCDN), a cache in the dCDN addresses the CDNI 83 bandwidth challenge by being able to serve the content from the dCDN 84 and avoiding accessing the content from the upstream CDN (uCDN). The 85 cache has limited storage space/processing power and relies on the 86 fact that the same piece of content is of interest to a lot of 87 users. 89 Most popular content is of interest to a lot of users; examples are 90 latest movies, latest catch-up episodes etc. A single copy of the 91 content is delivered across CDNI to the cache; the content is 92 delivered to multiple users from the cache. Thus, most popular 93 content is very amenable to caching. 95 Long tail personalized content is of interest to only a few users; 96 examples are documentaries, very old movies etc. Long tail 97 personalized content is typically not shared by many users and 98 caching of long tail personalized content could lead to cache 99 thrashing issues. Thus, long tail personalized content is not 100 amenable to caching. 102 This document discusses the best practices and requirements for 103 delivering long tail personalized content in CDN Interconnection 104 scenarios. This will be pursued further in the second phase of the 105 CDNI work. 107 2. Conventions used in this document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 This document reuses the terminology defined in: 115 [I-D.ietf-cdni-problem-statement-08], 117 [I-D.ietf-cdni-requirements-06], 119 [I-D.ietf-cdni-framework-03], and 121 [I-D.ietf-cdni-use-cases-10]. 123 3. No Caching in CDNs 125 Long tail personalized content is typically not shared by many users 126 and not amenable to caching. Avoiding caching in the CDNs has the 127 following benefits 1) Better cache utilization 2) Avoid unnecessary 128 HTTP redirection. 130 Each CDN has a local monitoring server which monitors the end user 131 content usage in the CDN. By monitoring the content usage, each CDN 132 determines whether or not the content should be cached locally in 133 the CDN. Through the CDNI interface, each dCDN propagates this 134 information to the uCDN(s). Thus, the uCDN(s) determine the dCDNs in 135 which the content should be cached/not cached. This results in the 136 following CDNI metadata interface requirement and request routing 137 interface changes which are described in this draft. 139 An example interconnected CDN topology is depicted in Figure 1; CDN- 140 A and CDN-B are uCDNs which have a relationship with the Content 141 Service Provider(CSP). CDN-C, where the end users are connected, is 142 a dCDN and has a local monitoring server. 144 +-------+ 145 | CSP | 146 +-------+ 147 / \ 148 ,--,--,--./ \,--,--,--. 149 ,-' `-. ,-' `-. 150 ( CDN Provider A ) ( CDN Provider B ) 151 `-. (CDN-A) ,-' `-. (CDN-B) ,-' 152 `--'--'--' `--'--'--' 153 \\ // 154 \\,--,--,--.// 155 ,-' `-. 156 ( CDN Provider C ) 157 `-. (CDN-C) ,-' 158 `--'--'--' 159 | 160 +------------+ 161 | User Agent | 162 +------------+ 163 === CDN Interconnect 165 Figure 1: Interconnected CDNs with one dCDN 167 Metadata interface requirement 169 The CDNI Metadata Distribution interface shall provide indication 170 by the dCDN to the uCDN whether the content should be cached or 171 not cached in the dCDN. This information should be on a per URL 172 basis. The default behavior would be to cache the content in the 173 dCDN 175 Referring to the example in Fig. 2, Section 3 [I-D.ietf-cdni- 176 framework]; it shows Operator A as the uCDN and Operator B as the 177 dCDN, where the former has a relationship with a content provider 178 and the latter being the best CDN to deliver content to the end- 179 user. Referring to the HTTP example in Fig. 3, Section 3.2 [I- 180 D.ietf-cdni-framework]; 182 Request routing interface changes 183 Step 2: A Request Router for Operator A (which is the uCDN) 184 processes the HTTP request. The HTTP URL metadata is looked up in 185 a metadata database. For long tail personalized content, the 186 metadata database lookup result indicates that the content should 187 not be cached by the dCDN. The Request Router for Operator A 188 recognizes that the end-user is best served by the uCDN without 189 any caching the in dCDN and returns a 302 redirect message with 190 the URL of Operator A delivery node. The end-user proceeds to 191 retrieve the data from Operator A delivery node. This is 192 illustrated in Figure 2 below. 194 End-User Operator B(dCDN) Operator A(uCDN) 195 |DNS cdn.csp.com | | 196 |-------------------------------------------------->| 197 | | |(1) 198 |IPaddr of A's Request Router | 199 |<--------------------------------------------------| 200 | | | 201 |HTTP cdn.csp.com | | 202 |-------------------------------------------------->| 203 | | |(2) 204 |302 URL of Operator A delivery node | 205 |<--------------------------------------------------| 206 | | | 207 |DNS Operator A delivery node | 208 |-------------------------------------------------->| 209 | | |(3) 210 |IPaddr of Operator A's Delivery Node | 211 |<--------------------------------------------------| 212 | | | 213 |Data Request | | 214 |-------------------------------------------------->| 215 | | |(4) 216 |Data Response | | 217 |<--------------------------------------------------| 218 | | | 220 Figure 2: Request Routing interface for long tail personalized content 222 Logging and Auditing requirements 224 Work in progress 226 4. Benefits of HTTP Adaptive Streaming 228 As discussed before, long tail personalized content is not amenable 229 to caching. Also, there is heavy asymmetric usage of the network 230 between peak and quiet hours, where the peak hour load is much 231 higher than the quiet hour load. These create unique bandwidth 232 challenges across CDNI. HTTP Adaptive Streaming (HAS), which can 233 adapt to network congestion, is ideally suited for delivering long 234 tail personalized content across interconnected CDNs. 236 5. Other techniques for delivering long tail personalized content 238 Approach 1 240 If the uCDN has a charging agreement with the dCDN that the dCDN 241 pays fixed monthly money to uCDN (no matter how much traffic they 242 exchange each month) and the CDN has enough storage capacity, the 243 cache control of the long tail content is not that necessary, but 244 let each CDN decide whether to cache the content or not locally. If 245 the user request is redirected to dCDN but the dCDN does not cache 246 the content, the dCDN can acquire the content from its uCDN. 248 Approach 2 250 If static control is desired for long tail content, the CSP can 251 assign a second-level domain name for such kind of content, e.g. 252 nocache.example.com/contentID, so that when this content is injected 253 into CDNI system, CDN would determine whether to cache it or not 254 according to this domain name. 256 Approach 3 258 So far, what has been discussed is streaming delivery of long tail 259 personalized content. Caching in the end user device is another 260 technique which can be used to address the bandwidth challenges 261 created by streaming delivery of long tail personalized content over 262 CDNI. This introduces a new model for long tail personalized content 263 delivery. The various components of this model can be defined as 264 1)End user chooses the content to watch 2) The content is downloaded 265 in the background and cached in the end user device 3)End user is 266 notified of content availability. This model is typically applicable 267 for long form content where the overhead in managing a background 268 download is justifiable. 270 Caching in the end user device can have potential DRM issues which 271 can be addressed using the following techniques 1) The content can 272 be accessed by the end user only for playback 2) The content has a 273 time expiry after which it destructs itself 3) In the case of end 274 user device loss, the content destructs itself. 276 6. Acknowledgements 278 The authors would like to thank Francois Le Faucheur, Kevin Ma, Jin 279 Weiyi and Ben Niven-Jenkins for their input. 281 7. References 283 7.1. Normative References 285 [1] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, March 1997. 288 [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 289 Syntax Specifications: ABNF", RFC 2234, Internet Mail 290 Consortium and Demon Internet Ltd., November 1997. 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, March 1997. 295 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 296 Syntax Specifications: ABNF", RFC 2234, Internet Mail 297 Consortium and Demon Internet Ltd., November 1997. 299 7.2. Informative References 301 [I-D.ietf-cdni-framework]L. Peterson et al., "Framework for CDN 302 Interconnection", http://www.ietf.org/id/draft-ietf-cdni-framework- 303 03.txt, February 2013. 305 [I-D.ietf-cdni-problem-statement]B. Niven-Jenkins et al., "Content 306 Distribution Network Interconnection (CDNI) Problem 307 Statement", http://tools.ietf.org/id/draft-ietf-cdni-problem- 308 statement-08.txt, June 2012, and 309 http://datatracker.ietf.org/doc/rfc6707/, Sep. 2012. 311 [I-D.ietf-cdni-requirements]K. Leung et al., "Content Distribution 312 Network Interconnection (CDNI) Requirements", 313 http://www.ietf.org/id/draft-ietf-cdni-requirements-06.txt, April 314 2013. 316 [I-D.ietf-cdni-use-cases]Bertrand, G. et al., "Use Cases for Content 317 Delivery Network Interconnection", http://tools.ietf.org/id/draft- 318 ietf-cdni-use-cases-10.txt, August 2012, 319 http://datatracker.ietf.org/doc/rfc6770/, November, 2012 321 Authors' Addresses 323 Ram Krishnan 324 Brocade Communications 325 San Jose, 95134, USA 327 Phone: +001-408-406-7890 328 Email: ramk@brocade.com 330 Mian Li 331 ZTE Corporation 332 Nanjing, 210012 333 China 335 Phone: 336 Email: li.mian@zte.com.cn 338 Bhumip Khasnabish 339 ZTE Corporation 340 New Jersey, 07960, USA 342 Phone: +001-781-752-8003 343 Email: bhumip.khasnabish@zteusa.com, vumip1@gmail.com 345 Chen Ge 346 China Telecom 347 109 West Zhongshan Ave 348 Guangzhou, Tianhe District, China 350 Phone: 351 Email: cheng@gsta.com