idnits 2.17.1 draft-brandenburg-cdni-has-00.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 : ---------------------------------------------------------------------------- == There are 1 instance 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 -- The document date (February 24, 2012) is 4438 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-cdni-use-cases' is defined on line 655, but no explicit reference was found in the text == Unused Reference: 'Anchor' is defined on line 663, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-cdni-problem-statement-03 == Outdated reference: A later version (-10) exists of draft-ietf-cdni-use-cases-03 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CDNI R. van Brandenburg 3 Internet-Draft O. van Deventer 4 Intended status: Informational TNO 5 Expires: August 27, 2012 February 24, 2012 7 Models for adaptive-streaming-aware CDN Interconnection 8 draft-brandenburg-cdni-has-00 10 Abstract 12 This documents presents thougths on the potential impact of 13 supporting HTTP Adaptive Streaming technologies in CDN 14 Interconnection scenarios. Our intent is to spur discussion on how 15 the different CDNI interfaces should deal with content delivered 16 using adaptive streaming technologies. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 27, 2012. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. HTTP Adaptive Streaming aspects relevant to CDNI . . . . . . . 4 55 2.1. Segmentation versus Fragmentation . . . . . . . . . . . . 4 56 2.2. Addressing chunks . . . . . . . . . . . . . . . . . . . . 5 57 2.2.1. Full Locator . . . . . . . . . . . . . . . . . . . . . 6 58 2.2.2. Relative Locator . . . . . . . . . . . . . . . . . . . 7 59 2.2.3. Chunk Request Routing . . . . . . . . . . . . . . . . 7 60 3. Impact of HAS on CDNI . . . . . . . . . . . . . . . . . . . . 8 61 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 3.1.1. On the definition of a Content Item in CDNI . . . . . 8 63 3.1.2. General CDNI-HAS Requirements . . . . . . . . . . . . 10 64 3.2. Impact on Request Routing Interface . . . . . . . . . . . 10 65 3.2.1. Dealing with manifest files . . . . . . . . . . . . . 10 66 3.2.2. HAS Request Routing . . . . . . . . . . . . . . . . . 11 67 3.2.3. Dividing content over multiple nodes . . . . . . . . . 12 68 3.2.4. HAS Requirements for the CDNI Request Routing 69 Interface . . . . . . . . . . . . . . . . . . . . . . 12 70 3.3. Impact on Metadata Interface . . . . . . . . . . . . . . . 12 71 3.3.1. HAS-specific Metadata . . . . . . . . . . . . . . . . 12 72 3.3.2. HAS Requirements for the CDNI Metadata Interface . . . 13 73 3.4. Impact on Logging Interface . . . . . . . . . . . . . . . 13 74 3.4.1. Log processing . . . . . . . . . . . . . . . . . . . . 13 75 3.4.2. HAS Requirements for the CDNI Logging Interface . . . 14 76 3.5. Impact on Control Interface . . . . . . . . . . . . . . . 14 77 3.5.1. HAS Requirements for the CDNI Control Interface . . . 14 78 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 80 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 82 6.2. Informative References . . . . . . . . . . . . . . . . . . 15 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Introduction 87 HTTP Adaptive Streaming (HAS) is an umbrella term for various HTTP- 88 based streaming technologies that allow a client to adaptively switch 89 between multiple bitrates depending on current network conditions. A 90 defining aspect of HAS is that, since it is based on HTTP, it is a 91 session-less pull-based mechanism, with a client actively requesting 92 content segments, instead of the content being pushed to the client 93 by a server. Due to this session-less nature, media servers 94 delivering content using HAS often show different characteristics 95 when compared with media servers delivering content using traditional 96 streaming methods such as RTP/RTSP, RTMP and MMS. This document 97 presents a discussion on what the impact of these different 98 characteristics is to the CDNI interfaces. The scope of this 99 document is explicitely not to define solutions, but merely to 100 identify different methods of handling HAS in a CDN and the potential 101 problems when using HAS in a CDNI context. The issues identified in 102 this document may be used as input for defining HAS-specific 103 requirements for the CDNI interfaces. 105 1.1. Terminology 107 This document uses the terminology defined in 108 [I-D.ietf-cdni-problem-statement]. 110 In addition, the following terms are used throughout this document: 112 Content Item: A uniquely adressable content element in a CDN. A 113 content item is defined by the fact that it has its own Content 114 Metadata associated with it. It is the object of a request routing 115 operation in a CDN. An example of a Content Item is a video file/ 116 stream, an audio file/stream or an image file. For a discussion on 117 what may constitute a Content Item with regards to HAS, see section 118 3.1.1. 120 Chunk: A fixed length element that is the result of a segmentation or 121 fragmentation operation being performed on a single encoding of the 122 Original Content. A chunk is independently, and uniquely, 123 addressable. Depending on the way a Chunk is stored, it may also be 124 referred to as a Segment or Fragment. 126 Fragment: A specific form of chunk (see section 2.1). A fragment is 127 stored as part of a larger file that includes all chunks that are 128 part of the Chunk Collection. 130 Segment: A specific form of chunk (see section 2.1). A segment is 131 stored as a single file from a file system perspective. 133 Original Content: Unchunked content that is the basis for a 134 segmentation of fragmentation operation. Based on Original Content, 135 multiple alternative encodings, resolutions or bitrates may be 136 derived, each of which may be fragmented or segmented. 138 Chunk Collection: The set of all chunks that are the result of a 139 single segmentation or fragmentation operation being performed on a 140 single encoding of the Original Content. A Chunk Collection is 141 described in a manifest file. 143 Content Collection: The set of all Chunk Collections that are derived 144 from the same Original Content. A Content Collection may consist of 145 multiple Chunk Collections, each being a single encoding, or variant, 146 of the Original Content. A Content Collection may be described by 147 one or more manifest files. 149 Manifest File: A manifest file, also referred to as Media 150 Presentation Description (MPD) file, is a file that list the way the 151 content has been chunked and where the various chunks are located (in 152 the case of segments) or how they can be addressed (in the case of 153 fragments). 155 2. HTTP Adaptive Streaming aspects relevant to CDNI 157 In the last couple of years, a wide variety of HAS-like protocols 158 have emerged. Among them are proprietary solutions such as Apple's 159 HTTP Live Streaming (HLS), Microsoft's Smooth Streaming (MSS) and 160 Adobe's HTTP Dynamic Streaming (HDS), and various standardized 161 solutions such as 3GPP AHS (AHS) and MPEG DASH (DASH). While all of 162 these technologies share a common set of features, each has its own 163 defining elements. This chapter will look at some of the differences 164 between these technologies and how these differences might be 165 relevant to CDNI. In particular, section 2.1 will describe the 166 various methods to store HAS content and section 2.2 will list three 167 methods that are used to address HAS content in a CDN. 169 2.1. Segmentation versus Fragmentation 171 All HAS implementations are based around a concept referred to as 172 chunking: the concept of having a server split content up in numerous 173 fixed length chunks, which are independently decodable. By 174 sequentially requesting and receiving chunks, a client can recreate 175 and play out the content. An advantage of this mechanism is that it 176 allows a client to seamlessly switch between different encodings of 177 the same Original Content. Before requesting a particular chunk, a 178 client can choose between mulitple alternatives of the same chunk, 179 irrespective of the encoding of the chuncks it has requested earlier. 181 NOTE: The set of all chunks belonging to a single encoding, and thus 182 the result of a single chunking operation, will from now on be 183 referred to as a Chunk Collection. The set of all encodings of the 184 same Original Content will be referred to as a Content Collection. A 185 Content Collection can therefore consist of multiple Chunk 186 Collections. 188 While every HAS implementation uses some form of chunking, not all 189 implementations store the resulting chunks in the same way. In 190 general, there are two distinct methods of performing chunking and 191 storing the results: segmentation and fragmentation. 193 - With segmentation, which is for example mandatory in all versions 194 of HLS prior to version 7, the chunks, in this case also referred 195 to as segments, are stored completely independent from each other, 196 with each segment being stored as a seperate file from a file 197 system perspective. This means that each segment has its own 198 unique URL with which it can be retrieved. 200 - With fragmentation (or virtual segmentation), which is for example 201 used in Microsoft's Smooth Streaming, all chunks, or fragments, 202 belonging to the same Chunk Collection are stored together, as 203 part of a single file. While there are a number of container 204 formats which allow for storing this type chunked content, 205 Fragmented MP4 is most commonly used. With fragmentation, a 206 specific chunk is adressable by subfixing the common file URL with 207 an identifier uniquely identifying the chunk one is interested in, 208 either by timestamp, by byterange, or in some other way. 210 While one can argue about the merits of each of these two different 211 methods of handling chunks, both have their advantages and drawbacks 212 in a CDN environment. For example, fragmentation is often regarded 213 as a method that introduces less overhead, both from a storage and 214 processing perspective. Segmentation on the other hand, is regarded 215 as being more flexible and efficient with regards to caching. In 216 practice, current HAS implementations increasingly support both 217 methods. 219 2.2. Addressing chunks 221 In order for a client to request chunks, either in the form of 222 segments or in the form of fragments, it needs to know how the 223 content has been chunked and where to find the chunks. For this 224 purpose, most HAS protocols use a concept that is often referred to 225 as a manifest file (also known as Media Presentation Description, or 226 MPD): a file that lists the way the content has been chunked and 227 where the various chunks are located (in the case of segments) or how 228 they can be addressed (in the case of fragments). A manifest file, 229 or set of manifest files, may also identify the different encodings, 230 and thus Chunk Collections, the content is available in. 232 In general, a HAS client will first request and receive a manifest 233 file, and then, after parsing the information in the manifest file, 234 proceed with sequentially requesting the chunks listed in the 235 manifest file. Each HAS implementation has its own manifest file 236 format and even within a particular format there are different 237 methods available to specify the location of a chunk. 239 Of course managing the location of files is a core aspect of every 240 CDN, and each CDN will have its own method of doing so. Some CDNs 241 may be purely cache-based, with no higher-level knowledge of where 242 each file resides at each instant in time. Other CDNs may have 243 dedicated management nodes which, at each instant in time, do know at 244 which servers each file resides. The CDNI interfaces designed in the 245 CDNI WG will probably need to be agnostic to these kinds of CDN- 246 internal architecture decisions. In the case of HAS there is a 247 strict relationship between the location of the content in the CDN 248 (in this case chunks) and the content itself (the locations specified 249 in the manifest file). It is therefore useful to have an 250 understanding of the different methods in use in CDNs today for 251 specifying chunk locations in manifest files. The different methods 252 for doing so are described in sections 2.2.1 to 2.2.3. 254 Although these sections are especially relevant for segmented 255 content, due to its inherent distributed nature, the discussed 256 methods are also applicable to fragmented content. Furthermore, it 257 should be noted that the methods detailed below for specifying 258 locations of content items in manifest files do not only relate to 259 temporally segmented content (e.g. segments and fragments), but are 260 also relevant in situations where content is made available in 261 multiple qualities, encodings, or variants. In this case the content 262 consists of multiple chunk collections, which may be described by 263 either a single manifest file or multiple interrelated manifest 264 files. In the latter case, there may be a high-level manifest file 265 describing the various available bitrates, with URLs pointing to 266 seperate manifest files describing the details of each specific 267 bitrate. For specifying the locations of the other manifest files, 268 the same methods apply that are used for specifying chunk locations. 270 2.2.1. Full Locator 272 One method for specifying locations of chunks (or other manifest 273 files) in a manifest file is through the use of a Full Locator. A 274 Full Locator takes the form of an URL and is defined by the fact that 275 it directly points to the specific chunk on the actual the server 276 that is expected to deliver the requested chunk to the client. 278 An example of a Full Locator is the following: 280 http://deliverynode.server.cdn.com/content_1/segments/ 281 segment1_1.ts 283 As can be seen from this example URL, the URL includes both the 284 identifier of the requested segment (in this case segment1_1.ts), as 285 well as the server that is expected to deliver the segment (in this 286 case deliverynode.server.cdn.com). With this, the client has enough 287 information to directly request the specific segment from the 288 specified delivery node. 290 2.2.2. Relative Locator 292 Another method for specifying chunk locations in a manifest file is 293 through the use of Relative Locator. A Relative Locator is a pointer 294 that is relative to the location where the manifest file has been 295 acquired from. In most cases a Relative Locator will take the form 296 of a string that has to be appended to the location of the manifest 297 file to get the location of a specific chunk. This means that in the 298 case a manifest with a Relative Locator is used, all chunks will be 299 delivered by the same delivery node that delivered the manifest file. 300 A Relative Locator will therefore not include a hostname. 302 For example, in the case a manifest file has been requested (and 303 received) from 304 http://deliverynode.server.cdn.com/content_1/manifest.xml, a Relative 305 Locator pointing to a specific segment referenced in the manifest 306 might be: 308 segments/segment1_1.ts 310 Which means that the client should take the location of the manifest 311 file and append the Relative Locator. In this case, the segment 312 would then be requested from 313 http://deliverynode.server.cdn.com/content_1/segments/segment1_1.ts 315 2.2.3. Chunk Request Routing 317 A final method for specifying chunk locations in a manifest file is 318 through the use of request routing. In this case, chunks are handled 319 by the request routing system of a CDN just as if they were 'normal' 320 content items. A chunk request comes in at a central request routing 321 node and is handled just as if it were a regular content request, 322 which might include looking up the delivery node best suited for 323 delivering the requested chunk to the particular user and sending an 324 HTTP redirect to the user with the URL pointing to the requested 325 chunk on the specified delivery node. 327 An example of an URL pointing to a redirection mechanism might look 328 as follows: 330 http://requestrouting.cdn.com/ 331 content_request?content=content_1&segment=segment1_1.ts 333 As can be seen from this example URL, the URL includes a pointer to a 334 general CDN request routing function and includes some arguments 335 identifying the requested segment. 337 3. Impact of HAS on CDNI 339 In the previous chapter, some of the unique properties of HAS have 340 been discussed. Furthermore, some of the CDN-specific design 341 decision with regards to addressing chunks have been detailed. In 342 this chapter, the impact of supporting HAS in CDNI will be discussed. 343 The scope of this chapter is explicitely not to define solutions, but 344 merely to identify potential problems and issues that need to be 345 agreed on. For this purpose, each subsection will pose a number of 346 open questions that will need to be answered by the CDNI WG. At a 347 later stage, the answers to these questions may be used to solicit 348 HAS-related requirements for the CDNI Interfaces. 350 The chapter is divided into three subsections. The first subsection, 351 3.1, will discuss the impact supporting HAS has on the general CDNI 352 architecture, use cases and requirements. The other four 353 subsections, 3.2 to 3.5, will discuss the impact of HAS on each of 354 the four CDNI Interfaces. 356 3.1. General 358 This section will discuss the impact supporting HTTP Adaptive 359 Streaming has on the general CDNI architecture, use cases and 360 requirements. 362 3.1.1. On the definition of a Content Item in CDNI 364 [I-D.ietf-cdni-problem-statement] defines content as 366 Content: Any form of digital data. One important form of content 367 with additional constraints on distribution and delivery is 368 continuous media (i.e. where there is a timing relationship 369 between source and sink). 371 This very broad definition of content is useful for generalizing the 372 CDNI interfaces in a way that allows them to be agnostic to the type 373 of content that is delivered. However, what a Content Item in a CDN 374 constitutes may become relevant in the context of HAS if one 375 considers a Content Item to be the element with which Content 376 Metadata is associated, and the element that is the object of a 377 CDN(I) request routing operation. 379 An example of a Content Item in the general sense is a video file or 380 stream, such as a TV show or movie, or an audio file, such as an MP3. 381 In a simple case, a single MP3 is a single Content Item. In a more 382 complex case, a particular piece of content is made available in 383 multiple resolutions, languages or qualities. A video item, for 384 example, might be made available in three different resolutions. In 385 these cases, it depends on the datamodel of a particular CDN (or a 386 particular Content Provider) how it defines a Content Item. In some 387 CDNs, all three video files might be seen as seperate Content Items, 388 each with their own set of Content Metadata. In other CDNs, the 389 three alternative encodings of the same content are seen as a single 390 Content Item, with a single set of Content Metadata describing that 391 the content consists of three different versions. The CDNI 392 Interfaces defined in the CDNI WG are affected by these kinds 393 differences in the ways different CDNs work and might need to be 394 agnostic to these kinds of CDN-internal (or even Content Provider- 395 related) decisions. 397 For content delivered using HAS, there is an even wider variety in 398 the way different CDNs might interpret the definition of a Content 399 Item. For example, CDNs using the Relative Locator method (see 400 section 2.2.2) in their manifest files, might define all chunks that 401 are part of the same Content Collection, and therefore referenced in 402 the same (set of) manifest file(s), as a single Content Item for the 403 purposes of Content Metadata and request routing. Other CDNs might 404 define all chunks related to a single encoding of a particular video 405 item, and thus part of the same Chunk Collection, as a single Content 406 Item, thereby having multiple inter-related Content Items which are 407 part of the same 'parent' Content Item. Yet another group of CDNs, 408 especially those using the Chunk Request Routing method (see Section 409 2.2.3), might define every individual chunk as a seperate Content 410 Item, with a seperate set of metadata describing each chunk. 412 In order for the CDNI WG to realise a standardized method of dealing 413 with metadata, logging and request routing, it will be important to 414 first have a common understanding of the term Content Item, and what 415 it constitutes, especially with regard to HAS. One option would be 416 to not impose a specific model, but allow the CDNI interfaces to 417 support all the different definitions of Content Item (i.e. from 418 considering each chunk to be a Content Item to considering all chunks 419 originating from the same Original Content, and thus part of the same 420 Content Collection, to be a single content item). 422 o Should the CDNI Interfaces be agnostic to the definition of a 423 Content Item in a particular CDN? 425 And if this is not the case, then 427 o What constitutes a Content Item for the purposes of associating 428 metadata and request routing? 430 o How does the definition of a Content Item relate to Chunks, Chunk 431 Collections and Content Collection? 433 If the WG decides to not impose a specific definition of what 434 constitutes a Content Item, it is for further study whether it is 435 required for all parties involved in the delivery of a single video 436 item, CSP, uCDN and dCDN, to use the same definition. For example, 437 is it possible for the uCDN to define a complete Content Collection 438 as a single Content Item, but for the dCDN which delivers the actual 439 content to see each chunk as a seperate Content Item and handle the 440 metadata accordingly? 442 o Is it necessary for all CDNs involved in the delivery of a single 443 video item to use the same definition of a Content Item (e.g. can 444 the uCDN define a Content Collection as a Content Item and the 445 dCDN define a chunk as a Content Item)? 447 3.1.2. General CDNI-HAS Requirements 449 This section is a placeholder for HAS-specific CDNI requirements that 450 are not related to a specific CDNI interface. 452 3.2. Impact on Request Routing Interface 454 This section will discuss the impact supporting HTTP Adaptive 455 Streaming has on the CDNI Request Routing Interface. 457 3.2.1. Dealing with manifest files 459 In section 2.2, three different methods for identifying and 460 addressing chunks from within a manifest file were described: Full 461 Locators, Relative Locators and Chunk Request Routing. Of course not 462 every current CDN will use and/or support all three methods. Some 463 CDNs may only support one of the three methods, while others may 464 support two or all three. 466 The question is whether all CDNs involved in the delivery of a single 467 video item need to support the same method. Is it for example 468 possible for a dCDN to use Chunck Request Routing while the uCDN uses 469 Full Locators? This question boils down to the more fundamental 470 question of who manages manifest file. Should a dCDN be allowed to 471 change a manifest file? Or even create a new one? 473 o Should the CDNI Interfaces be agnostic to the way chunks are 474 identified in the manifest file and requested by the client? 476 o Should it be possible for a uCDN and dCDN to use two different 477 methods of addressing chunks in manifest files? 479 And, related to this 481 o Should a dCDN be able to adapt a manifest file (i.e. is a manifest 482 file part of the content, and therefore by definition not 483 adaptable, or is it part of the delivery method) ? 485 If the CDNI WG decides that the anwer to these questions is negative, 486 this will probably mean that the only supported method for Chunk 487 Adressing is using Relative Locators. For both Full Locators as well 488 as Chunk Request Routing, it is necessary for the delivering CDN to 489 change the URLs specified in the manifest file. 491 3.2.2. HAS Request Routing 493 One of the essential questions relating to HAS and request routing is 494 whether CDNI request routing is handled on a per chunk level, a per 495 Content Collection level, or somewhere in between. This question is 496 tightly related to the definition of a Content Item, discussed in 497 section 3.1.1. If a Content Item is the object of request routing, 498 then it depends on the definition of a Content Item what type of 499 content element is being request routed. 501 o Should the CDNI Interfaces specify what element of a HAS stream is 502 being request routed (i.e. should the CDNI interfaces support per- 503 chunk request routing) ? 505 While having a seperate request routing operation for every chunk 506 will probably not be very efficient, only allowing for entire Content 507 Collections to be request routed is very limiting. For example, it 508 might be efficient for a dCDN targeted at mobile devices to only host 509 (and thus be able to deliver) the lower resolution encodings of a 510 given video item. In this case it probably wouldn't make sense to 511 force the mobile CDN to host all resolutions (including the very high 512 ones with multi-channel audio) that are hosted by the uCDN since 513 there will be no clients accessing the high resolution content 514 through the mobile CDN. 516 o Should it be possible for a dCDN to host (and deliver) only a 517 subset of all the chunks, or chunk collections, of a given Content 518 Collection? 520 3.2.3. Dividing content over multiple nodes 522 An aspect that is related to the issues discussed in sections 3.2.1 523 and 3.2.2, is that of dividing content over multiple delivery nodes. 524 In non-cache-based CDNs, where the location of content on delivery 525 nodes is managed by a centralized process and where content is often 526 pre-positioned, different Chunk Collections belonging to the same 527 Content Collection, or even different chunks belonging to the same 528 Chunk Collection, may be distributed over different delivery nodes. 529 For example, the most popular resolutions of a particular Content 530 Collection may be hosted on more delivery nodes than the less popular 531 resolutions. In order to allow for this kind of internal CDN 532 optimization it is necessary that the dCDN is able adapt the manifest 533 file. 535 o Should it be possible for a dCDN to distribute the chunks, or 536 Chunk Collections, constituting a given Content Collection over 537 its delivery nodes? 539 3.2.4. HAS Requirements for the CDNI Request Routing Interface 541 This section is a placeholder for HAS-specific requirements for the 542 CDNI Request Routing interface. 544 3.3. Impact on Metadata Interface 546 This section will discuss the impact supporting HTTP Adaptive 547 Streaming has on the CDNI Metadata Interface. 549 3.3.1. HAS-specific Metadata 551 In section 3.1.1, the impact of HAS on the definition of a Content 552 Item, and what constitutes a Content Item was discussed. More 553 specifically, it was discussed how different CDNs might see chunks or 554 chunk collections as Content Items or as parts of Content Items. 555 This question also has an effect on the way the CDNI Metadata 556 Interface. If one defines a Content Item as the CDN element with 557 which Content Metadata is associated, this raises the question how 558 Content Metadata is associated with HAS content. For example, is 559 there specific metadata element associated with each chunk, with each 560 chunk collection, with each content collection, or is there a 561 specific form of metadata for HAS content? 562 o Is Content Metadata associated with Content Collections, Chunk 563 Collections or chunks? 565 o Is it necessary to extend the CDNI Metadata model with HAS- 566 specific extensions? 568 3.3.2. HAS Requirements for the CDNI Metadata Interface 570 This section is a placeholder for HAS-specific requirements for the 571 CDNI Metadata interface. 573 3.4. Impact on Logging Interface 575 This section will discuss the impact supporting HTTP Adaptive 576 Streaming has on the CDNI Logging Interface. 578 3.4.1. Log processing 580 One aspect of using HAS in a CDN context that has been getting a lot 581 of attention is logging. In contrast to other streaming solutions 582 which are either session-based (e.g. RTP) or using a single file 583 (e.g. Progressive Download), the chunked nature of HAS means that 584 regular logging methods that simply log each content request will 585 generate extremely large log files with a seperate entry for each 586 chunk being accessed. Apart from the large file size of these log 587 files, a further problem is that due to the distributed nature of 588 these log entries it can be difficult to trace them back to a 589 specific number of clients or users, which makes reporting difficult. 591 For this reason, some CDNs use dedicated log processing software 592 which accumulates, processes and aggregates log files. This log 593 processing software is a further element where different CDNs might 594 have different approaches. For example, some CDNs might do the log 595 processing at a low-level, such as real-time in the delivery nodes. 596 Other CDNs might process the log files in batches at a centralized 597 location, such as once every hour or every day. 599 For the CDNI Logging interface, it will be necessary to realise a 600 common understanding on what type of logging information is passed 601 between the uCDn and the dCDN in the case a HAS-like protocol is used 602 for delivery. Ideally, this interface is agnostic to the CDN- 603 internal method of log processing. However, this might not be 604 possible. For example, it can be argued that for transparency 605 reasons, it is necessary for the dCDN to communicate the raw log 606 files back to the uCDN. On the other hand, this creates a very large 607 overhead in the inter-CDN communication, with log files for popular 608 content possibly exceeding the file size of the content itself. 609 Another method would be to require the dCDN to aggregate the log 610 files before reporting back to the uCDN, however this would require 611 the dCDN to have specific log processing software. 613 o Should the CDNI Logging Interface define a specific log-file 614 format to be used for HAS content? 616 3.4.2. HAS Requirements for the CDNI Logging Interface 618 This section is a placeholder for HAS-specific requirements for the 619 CDNI Logging interface. 621 3.5. Impact on Control Interface 623 This section will discuss the impact supporting HTTP Adaptive 624 Streaming has on the CDNI Control Interface. 626 NOTE: At this point the impact of HAS on the CDNI Control Interface 627 has not yet been determined. 629 3.5.1. HAS Requirements for the CDNI Control Interface 631 This section is a placeholder for HAS-specific requirements for the 632 CDNI Control interface. 634 4. IANA Considerations 636 This document makes no request of IANA. 638 Note to RFC Editor: this section may be removed on publication as an 639 RFC. 641 5. Security Considerations 643 TBD. 645 6. References 647 6.1. Normative References 649 [I-D.ietf-cdni-problem-statement] 650 Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 651 Distribution Network Interconnection (CDNI) Problem 652 Statement, draft-ietf-cdni-problem-statement-03", 653 January 2012. 655 [I-D.ietf-cdni-use-cases] 656 Bertrand, G., Ed., Stephan, E., Watson, G., Burbridge, T., 657 Eardley, P., and K. Ma, "Use Cases for Content Delivery 658 Network Interconnection, draft-ietf-cdni-use-cases-03", 659 January 2012. 661 6.2. Informative References 663 [Anchor] "". 665 Authors' Addresses 667 Ray van Brandenburg 668 TNO 669 Brassersplein 2 670 Delft 2612CT 671 the Netherlands 673 Phone: +31-88-866-7000 674 Email: ray.vanbrandenburg@tno.nl 676 M. Oskar van Deventer 677 TNO 678 Brassersplein 2 679 Delft 2612CT 680 the Netherlands 682 Phone: +31-88-866-7000 683 Email: oskar.vandeventer@tno.nl