idnits 2.17.1 draft-irtf-icnrg-videostreaming-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 10. Security Considerations' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 11. IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** There are 21 instances of too long lines in the document, the longest one being 110 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1667 has weird spacing: '...orkshop on I...' == Line 1668 has weird spacing: '...cations over ...' == Line 1672 has weird spacing: '...amework for ...' == Line 1695 has weird spacing: '... Paper on D...' == Line 1697 has weird spacing: '...Systems and ...' == (1 more instance...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 27, 2016) is 2893 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '2' on line 1588 looks like a reference -- Missing reference section? '3' on line 1594 looks like a reference -- Missing reference section? '4' on line 1601 looks like a reference -- Missing reference section? '6' on line 1610 looks like a reference -- Missing reference section? 'RFC2119' on line 203 looks like a reference -- Missing reference section? '7' on line 1617 looks like a reference -- Missing reference section? '25' on line 1694 looks like a reference -- Missing reference section? '1' on line 1584 looks like a reference -- Missing reference section? '5' on line 1605 looks like a reference -- Missing reference section? '8' on line 1621 looks like a reference -- Missing reference section? '9' on line 1628 looks like a reference -- Missing reference section? '30' on line 1717 looks like a reference -- Missing reference section? '10' on line 1632 looks like a reference -- Missing reference section? '11' on line 1636 looks like a reference -- Missing reference section? '12' on line 1643 looks like a reference -- Missing reference section? '13' on line 1645 looks like a reference -- Missing reference section? '14' on line 1650 looks like a reference -- Missing reference section? 'RFC6972' on line 1578 looks like a reference -- Missing reference section? '15' on line 1652 looks like a reference -- Missing reference section? '16' on line 1655 looks like a reference -- Missing reference section? '17' on line 1659 looks like a reference -- Missing reference section? '31' on line 1721 looks like a reference -- Missing reference section? '22' on line 1680 looks like a reference -- Missing reference section? '23' on line 1684 looks like a reference -- Missing reference section? '18' on line 1663 looks like a reference -- Missing reference section? '19' on line 1665 looks like a reference -- Missing reference section? '20' on line 1671 looks like a reference -- Missing reference section? '21' on line 1676 looks like a reference -- Missing reference section? '24' on line 1689 looks like a reference -- Missing reference section? '26' on line 1700 looks like a reference -- Missing reference section? '27' on line 1704 looks like a reference -- Missing reference section? '28' on line 1709 looks like a reference -- Missing reference section? '29' on line 1713 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 35 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ICNRG C. Westphal, Ed. 2 Internet Draft Huawei 3 Intended status: Informational S. Lederer 4 Expires: October 26, 2016 D. Posh 5 C. Timmerer 6 Alpen-Adria University Klagenfurt 7 Aytac Azgin 8 S. Liu 9 Huawei 10 C. Mueller 11 Bitmovin 12 A.Detti 13 University of Rome Tor Vergata 14 D. Corujo 15 University of Aveiro 16 J. Wang 17 City University of Hong-Kong 18 Marie-Jose Montpetit 19 Niall Murray 20 Athlone Institute of Technology 22 April 27, 2016 24 Adaptive Video Streaming over ICN 25 draft-irtf-icnrg-videostreaming-08.txt 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. This document may not be modified, 34 and derivative works of it may not be created, and it may not be 35 published except as an Internet-Draft. 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. This document may not be modified, 39 and derivative works of it may not be created, except to publish it 40 as an RFC and to translate it into languages other than English. 42 This document may contain material from IETF Documents or IETF 43 Contributions published or made publicly available before November 44 10, 2008. The person(s) controlling the copyright in some of this 45 material may not have granted the IETF Trust the right to allow 46 modifications of such material outside the IETF Standards Process. 47 Without obtaining an adequate license from the person(s) controlling 48 the copyright in such materials, this document may not be modified 49 outside the IETF Standards Process, and derivative works of it may 50 not be created outside the IETF Standards Process, except to format 51 it for publication as an RFC or to translate it into languages other 52 than English. 54 Internet-Drafts are working documents of the Internet Engineering 55 Task Force (IETF), its areas, and its working groups. Note that 56 other groups may also distribute working documents as Internet- 57 Drafts. 59 Internet-Drafts are draft documents valid for a maximum of six 60 months and may be updated, replaced, or obsoleted by other documents 61 at any time. It is inappropriate to use Internet-Drafts as 62 reference material or to cite them other than as "work in progress." 64 The list of current Internet-Drafts can be accessed at 65 http://www.ietf.org/ietf/1id-abstracts.txt 67 The list of Internet-Draft Shadow Directories can be accessed at 68 http://www.ietf.org/shadow.html 70 This Internet-Draft will expire on October 27, 2016. 72 Copyright Notice 74 Copyright (c) 2016 IETF Trust and the persons identified as the 75 document authors. All rights reserved. 77 This document is subject to BCP 78 and the IETF Trust's Legal 78 Provisions Relating to IETF Documents 79 (http://trustee.ietf.org/license-info) in effect on the date of 80 publication of this document. Please review these documents 81 carefully, as they describe your rights and restrictions with 82 respect to this document. 84 Abstract 86 This document considers the consequences of moving the underlying 87 network architecture from the current Internet to an Information- 88 Centric Network (ICN) architecture on video distribution. As most of 89 the traffic in future networks is expected to be video, we consider 90 how to modify the existing video streaming mechanisms. Several 91 important topics related to video distribution over ICN are 92 presented, covering a wide range of scenarios: we look at how to 93 evolve DASH to work over ICN, and leverage the recent ISO/IEC Moving 94 Picture Experts Group (MPEG) Dynamic Adaptive Streaming over HTTP 95 (DASH) standard; we consider layered encoding over ICN; Peer-to-Peer 96 (P2P) mechanisms introduce distinct requirements for video and we 97 look at how to adapt PPSP for ICN; Internet Protocol Television 98 (IPTV) adds delay constraints, and this will create more stringent 99 requirements over ICN as well. As part of the discussion on video, 100 we discuss Digital Rights Management (DRM) in ICN. Finally, in 101 addition to considering how existing mechanisms would be impacted by 102 ICN, this document lists some research issues to design ICN specific 103 video streaming mechanisms. 105 Table of Contents 106 1. Introduction....................................................... 4 107 2. Conventions used in this document.................................. 5 108 3. Use case scenarios for ICN and Video Streaming..................... 5 109 4. Video download..................................................... 7 110 5. Video streaming and ICN............................................ 7 111 5.1. Introduction to client-driven streaming and DASH ............... 7 112 5.2. Layered Encoding .............................................. 8 113 5.3. Interactions of Video Streaming with ICN ....................... 9 114 5.3.1. Interaction of DASH and ICN ................................ 9 115 5.3.2. Interaction of ICN with Layered Encoding .................. 11 116 5.4. Possible Integration of Video streaming and ICN architecture .. 12 117 5.4.1. DASH over CCN ............................................. 12 118 5.4.2. Testbed, Open Source Tools, and Dataset ................... 14 119 6. P2P video distribution and ICN.................................... 15 120 6.1. Introduction to PPSP .......................................... 15 121 6.2. PPSP over ICN: deployment concepts ............................ 16 122 6.2.1. PPSP short background ..................................... 16 123 6.2.2. From PPSP messages to ICN named-data ...................... 17 124 6.2.3. Support of PPSP interaction through a pull-based ICN API .. 18 125 6.2.4. Abstract layering for PPSP over ICN ....................... 18 126 6.2.5. PPSP interaction with the ICN routing plane ............... 19 127 6.2.6. ICN deployment for PPSP ................................... 20 128 6.3. Impact of MPEG DASH coding schemes ............................ 21 129 7. IPTV and ICN...................................................... 22 130 7.1. IPTV challenges ............................................... 22 131 7.2. ICN benefits for IPTV delivery ................................ 23 132 8. Digital Rights Managements in ICN................................. 25 133 8.1. Broadcast Encryption for DRM in ICN ........................... 25 134 8.2. AAA Based DRM for ICN Networks ................................ 28 135 8.2.1. Overview .................................................. 28 136 8.2.2. Implementation ............................................ 29 138 9. Future Steps for Video in ICN..................................... 30 139 9.1. Large Scale Live Events ....................................... 30 140 9.2. Video Conferencing and Real-Time Communications ............... 30 141 9.3. Store-and-Forward Optimized Rate Adaptation ................... 30 142 9.4. Heterogeneous Wireless Environment Dynamics ................... 31 143 9.5. Network Coding for Video Distribution in ICN .................. 33 144 9.6. Synchronization Issues for Video Distribution in ICN .......... 33 145 10. Security Considerations.......................................... 34 146 11. IANA Considerations.............................................. 34 147 12. Conclusions...................................................... 34 148 13. References....................................................... 35 149 13.1. Normative References ......................................... 35 150 13.2. Informative References ....................................... 35 151 14. Authors' Addresses............................................... 38 152 15. Acknowledgements................................................. 39 154 1. Introduction 156 The unprecedented growth of video traffic has triggered a rethinking 157 of how content is distributed, both in terms of the underlying 158 Internet architecture and in terms of the streaming mechanisms to 159 deliver video objects. 161 In particular, the IRTF ICNRG research group has been chartered to 162 study new architectures centered upon information; the main 163 contributor to Internet traffic (and information dissemination) is 164 video, and this is expected to stay the same in the near future. If 165 ICN is expected to become prominent, it will have to support video 166 streaming efficiently. 168 As such, it is necessary to discuss along two directions: 170 . Can the current video streaming mechanisms be leveraged and 171 adapted to an ICN architecture? 173 . Can (and should) new, ICN-specific video streaming mechanisms 174 be designed to fully take advantage of the new abstractions 175 exposed by the ICN architecture? 177 This document intends to focus on the first question, in an attempt 178 to define the use cases for video streaming and some requirements. 180 This document focuses on a few scenarios, namely Netflix-like video 181 streaming, peer-to-peer video sharing and IPTV, and identifies how 182 the existing protocols can be adapted to an ICN architecture. In 183 doing so, it also identifies the main issues with these protocols in 184 this ICN context. 186 Some documents have started to consider the ICN-specific 187 requirements of dynamic adaptive streaming [2][3][4][6]. 189 In this document, we give a brief overview of the existing solutions 190 for the selected scenarios. We then consider the interactions of 191 such existing mechanisms with the ICN architecture and list some of 192 the interactions any video streaming mechanism will have to 193 consider. We then identify some areas for future research. 195 2. Conventions used in this document 197 In examples, "C:" and "S:" indicate lines sent by the client and 198 server respectively. 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 202 document are to be interpreted as described in RFC-2119 [RFC2119]. 204 In this document, these words will appear with that interpretation 205 only when in ALL CAPS. Lower case uses of these words are not to be 206 interpreted as carrying RFC-2119 significance. 208 3. Use case scenarios for ICN and Video Streaming 210 For ICN specific descriptions, we refer to the other research group 211 documents. For our purpose, we assume here that ICN means an 212 architecture where content is retrieved by name and with no binding 213 of content to a specific network location. 215 The consumption of multimedia content comes along with timing 216 requirements for the delivery of the content, for both, live and on- 217 demand consumption. Additionally, real-time use cases such as audio- 218 /video conferencing [7], game streaming, etc., come along with more 219 strict timing requirements. Long startup delays, buffering periods 220 or poor quality, etc., should be avoided to achieve a good Quality 221 of Experience (QoE) to the consumer of the content. (For a 222 definition of QoE in the context of video distribution, please refer 223 to [25]. The working definition is: "Quality of Experience (QoE) is 224 the degree of delight or annoyance of the user of an application or 225 service. It results from the fulfillment of his or her expectations 226 with respect to the utility and / or enjoyment of the application or 227 service in the light of the user's personality and current state.") 229 Of course, these requirements are heavily influenced by routing 230 decisions and caching, which are central parts of ICN and which have 231 to be considered when streaming video in such infrastructures. 233 Due to this range of requirements, we find it useful to narrow the 234 focus on four scenarios (more can be included later): 236 - a video download architecture similar to that of Apple iTtunes(R), 237 where the whole file is being downloaded to the client and can be 238 replayed there multiple times; 239 - a video streaming architecture for playing back movies; this is 240 relevant for the naming and caching aspects of ICN, as well as the 241 interaction with the rate adaptation mechanism necessary to 242 deliver the best QoE to the end-user; 243 - a peer-to-peer architecture for sharing videos; this introduces 244 more stringent routing requirements in terms of locating copies of 245 the content, as the location of the peers evolves and peers join 246 and leave the swarm they use to exchange video chunks (for Peer- 247 to-Peer definitions and taxonomy, please refer to RFC5694); 248 - IPTV; this introduces requirements for multicasting and adds 249 stronger delay constraints. 251 Other scenarios, such as video-conferencing and real-time video 252 communications are not explicitly discussed in this document, while 253 they are in scope. Also, events of mass-media distribution, such as 254 a large crowd in a live event, are also adding new requirements to 255 be included in later version. 257 We discuss how the current state-of-the-art protocols in an IP 258 context can be modified for the ICN architecture. The remainder of 259 this document is organized as follows. In the next section, we 260 consider video download. Then in Section 5, we briefly describe DASH 261 [1], and Layered Encoding (MDC, SVC). P2P is the focus of Section 6, 262 where we describe PPSP. Section 7 highlights the requirements of 263 IPTV, while Section 8 describes the issues of DRM. Section 9 lists 264 some research issues to be solved for ICN-specific video delivery 265 mechanisms. 267 Videoconferencing and real-time video communications will be 268 detailed more in future versions of this document; as well as the 269 mass distribution of content at live large-scale events (stadium, 270 concert hall, etc) for which there is no clearly adopted existing 271 protocol. 273 4. Video download 275 Video download, namely the fetching of a video file from a server or 276 a cache down to the user's local storage, is a natural application 277 of ICN. It should be supported natively without requiring any 278 specific considerations. 280 This is supported now by a host of protocols (say, SCP, FTP, or over 281 HTTP), which would need to be replaced by the protocols to retrieve 282 content in ICNs. 284 However, current mechanisms are built atop existing transport 285 protocols. Some ICN proposals (say, CCN or NDN for instance) attempt 286 to leverage the work done upon these transport protocol and it has 287 been proposed to use mechanisms such as the TCP congestion window 288 (and the associated Adaptive Increase, Multiplicative Decrease - 289 AIMD) to decide how many object requests ("interests" in CCN/NDN 290 terminology) should be in flight at any point in time. 292 It should be noted that ICN intrinsically supports different 293 transport mechanisms, which could achieve better performance than 294 TCP, as they subsume TCP into a special case. For instance, one 295 could imagine a link-by-link transport coupled with caching. This is 296 enabled by the ICN architecture, and would facilitate the point-to- 297 point download of video files. 299 5. Video streaming and ICN 301 5.1. Introduction to client-driven streaming and DASH 303 Media streaming over the hypertext transfer protocol (HTTP) and in a 304 further consequence streaming over the transmission control protocol 305 (TCP) has become omnipresent in today's Internet. Content providers 306 such as Netflix, Hulu, and Vudu do not deploy their own streaming 307 equipment but use the existing Internet infrastructure as it is and 308 they simply deploy their own services over the top (OTT). This 309 streaming approach works surprisingly well without any particular 310 support from the underlying network due to the use of efficient 311 video compression, content delivery networks (CDNs), and adaptive 312 video players. Earlier video streaming research mostly recommended 313 to use the user datagram protocol (UDP) combined with the real time 314 transport protocol (RTP). It assumed it would not be possible to 315 transfer multimedia data smoothly with TCP, because of its 316 throughput variations and large retransmission delays. This point of 317 view has significantly evolved today. HTTP streaming, and especially 318 its most simple form known as progressive download, has become very 319 popular over the past few years because it has some major benefits 320 compared to RTP streaming. As a consequence of the consistent use of 321 HTTP for this streaming method, the existing Internet 322 infrastructure, consisting of proxies, caches and CDNs, could be 323 used. Originally, this architecture was designed to support best 324 effort delivery of files and not real time transport of multimedia 325 data. Nevertheless, real time streaming based on HTTP could also 326 take advantage of this architecture, in comparison to RTP, which 327 could not leverage any of the aforementioned components. Another 328 benefit that results from the use of HTTP is that the media stream 329 could easily pass firewalls or network address translation (NAT) 330 gateways, which was definitely a key for the success of HTTP 331 streaming. However, HTTP streaming is not the holy grail of 332 streaming as it also introduces some drawbacks compared to RTP. 333 Nevertheless, in an ICN-based video streaming architecture these 334 aspects also have to be considered. 336 The basic concept of DASH [1] is to use segments of media content, 337 which can be encoded at different resolutions, bit rates, etc., as 338 so-called representations. These segments are served by conventional 339 HTTP Web servers and can be addressed via HTTP GET requests from the 340 client. As a consequence, the streaming system is pull-based and the 341 entire streaming logic is located on the client, which makes it 342 scalable, and allows to adapt the media stream to the client's 343 capabilities. 345 In addition to this, the content can be distributed using 346 conventional CDNs and their HTTP infrastructure, which also scales 347 very well. In order to specify the relationship between the 348 contents' media segments and the associated bit rate, resolution, 349 and timeline, the Media Presentation Description (MPD) is used, 350 which is a XML document. The MPD refers to the available media 351 segments using HTTP URLs, which can be used by the client for 352 retrieving them. 354 5.2. Layered Encoding 356 Another approach for video streaming consist in using layered 357 encoding. Namely, scalable video coding formats the video stream 358 into different layers: a base layer which can be decoded to provide 359 the lowest bit rate for the specific stream, and enhancement layers 360 which can be transmitted separately if network conditions allow. The 361 higher layers offer higher resolutions and enhancement of the video 362 quality, while the layered approach allows to adapt to the network 363 conditions. This is used in MPEG-4 scalable profile or H.263+. 364 H264SVC is available, but not much deployed. JPEG2000 has a wavelet 365 transform approach for layered encoding, but has not been deployed 366 much either. 368 It is not clear if the layered approach is fine-grained enough for 369 rate control. 371 5.3. Interactions of Video Streaming with ICN 373 5.3.1. Interaction of DASH and ICN 375 Video streaming, and DASH in particular, have been designed with 376 goals that are aligned with that of most ICN proposals. Namely, it 377 is a client-based mechanism, which requests items (in this case, 378 chunks of a video stream) by name. 380 ICN and MPEG-DASH [1] have several elements in common: 382 - the client-initiated pull approach; 383 - the content being dealt with in pieces (or chunks); 384 - the support of efficient replication and distribution of content 385 pieces within the network; 386 - the scalable, session-free nature of the exchange between the 387 client and the server at the streaming layer: the client is free 388 to request any chunk from any location; 389 - the support for potentially multiple source locations. 391 For the last point, DASH may list multiple source URLs in a 392 manifest, and ICN is agnostic to the location of a copy it is 393 receiving. We do not imply that current video streaming mechanisms 394 attempt to draw the content from multiple sources concurrently. This 395 is a potential benefit of ICN, but is not considered in the current 396 approaches mentioned in this document. 398 As ICN is a promising candidate for the Future Internet (FI) 399 architecture, it is useful to investigate its suitability in 400 combination with multimedia streaming standards like MPEG-DASH. In 401 this context, the purpose of this section is to present the usage of 402 ICN instead of HTTP in MPEG-DASH 404 However, there are some issues that arise from using a dynamic rate 405 adaptation mechanism in an ICN architecture (note that some of the 406 issues are related to caching, and not necessarily unique to ICN): 408 o Naming of the data in DASH does not necessarily follow the ICN 409 convention of any of the ICN proposals. Several chunks of the 410 same video stream might currently go by different names that for 411 instance do not share a common prefix. There is a need to 412 harmonize the naming of the chunks in DASH with the naming 413 conventions of the ICN. The naming convention of using a 414 filename/time/encoding format could for instance be made 415 compatible with the convention of CCN. 417 o While chunks can be retrieved from any server, the rate 418 adaptation mechanism attempts to estimate the available network 419 bandwidth so as to select the proper playback rate and keep its 420 playback buffer at the proper level. Therefore, there is a need 421 to either include some location semantics in the data chunks so 422 as to properly assess the throughput to a specific location; or 423 to design a different mechanism to evaluate the available network 424 bandwidth. 426 o The typical issue of access control and accounting happens in 427 this context, where chunks can be cached in the network outside 428 of the administrative control of the content publisher. It might 429 be a requirement from the owner of the video stream that access 430 to these data chunks needs to be accounted/billed/monitored. 432 o Dynamic streaming multiplies the representations of a given video 433 stream, therefore diminishing the effectiveness of caching: 434 namely, to get a hit for a chunk in the cache, it has to be for 435 the same format and encoding values. Alternatively, to get the 436 same hit rate as for a stream using a single encoding, the cache 437 size must be scaled up to include all the possible 438 representations. 440 o Caching introduces oscillatory dynamics as it may modify the 441 estimation of the available bandwidth between the end user and 442 the repository where it is getting the chunks from. For instance, 443 if an edge cache holds a low resolution representation near the 444 user, the user getting this low resolution chunks will observe a 445 good performance, and will then request higher resolution chunks. 446 If those are hosted on a server with poor performance, then the 447 client would have to switch back to the low representation. This 448 oscillation may be detrimental to the perceived QoE of the user. 450 o The ICN transport mechanism needs to be compatible to some extent 451 with DASH. To take a CCN example, the rate at which interests are 452 issued should be such that the chunks received in return arrive 453 fast enough and with the proper encoding to keep the playback 454 buffer above some threshold. 456 o The usage of multiple network interfaces is possible in ICN, 457 enabling a seamless handover between them. For the combination 458 with DASH, an intelligent strategy which should focus on traffic 459 load balancing between the available links may be necessary. This 460 would increase the effective media throughput of DASH by 461 leveraging the combined available bandwidth of all links, 462 however, it could potentially lead to high variations of the 463 media throughput. 465 o DASH does not define how the MPD is retrieved; hence, this is 466 compatible with CCN. However, the current profiles defined within 467 MPEG-DASH require the MPD to contain HTTP-URLs (incl. http and 468 https URI schemes) to identify segments. To enable a more 469 integrated approach as described in this document, an additional 470 profile for DASH over CCN has to be defined, enabling ICN/CCN- 471 based URIs to identify and request the media segments. 473 We describe in Section 5.4 a potential implementation of a dynamic 474 adaptive video stream over ICN, based upon DASH and CCN [5]. 476 5.3.2. Interaction of ICN with Layered Encoding 478 Issues of interest to an Information-Centric network architecture in 479 the context of layered video streaming include: 481 . Caching of the multiple layers. The caching priority should go 482 to the base layer, and defining caching policy to decide when 483 to cache enhancement layers; 484 . Synchronization of multiple content streams, as the multiple 485 layers may come from different sources in the network (for 486 instance, the base layer might be cached locally while the 487 enhancement layers may be stored in the origin server). Video 488 and audio video streams must be synchronized, and this includes 489 both intra-layer synchronization (for the layers of the same 490 video or audio stream) and inter-stream synchronization (see 491 Section 9 for other synchronization aspects to be included in 492 the "Future Steps for Video in ICN"); 493 . Naming of the different layers: when the client requests an 494 object, the request can be satisfied with the base layer alone, 495 aggregated with enhancement layers. Should one request be 496 sufficient to provide different streams? In a CCN architecture 497 for instance, this would violate a one interest-one data packet 498 principle and the client would need to specify each layer it 499 would like to receive. In a Pub/Sub architecture, the 500 rendezvous point would have to make a decision as to which 501 layers (or which pointer to which layer's location) to return. 503 5.4. Possible Integration of Video streaming and ICN architecture 505 5.4.1. DASH over CCN 507 DASH is intended to enable adaptive streaming, i.e., each content 508 piece can be provided in different qualities, formats, languages, 509 etc., to cope with the diversity of todays' networks and devices. As 510 this is an important requirement for Future Internet proposals like 511 CCN, the combination of those two technologies seems to be obvious. 512 Since those two proposals are located at different protocol layers - 513 DASH at the application and CCN at the network layer - they can be 514 combined very efficiently to leverage the advantages of both and 515 potentially eliminate existing disadvantages. As CCN is not based on 516 classical host-to-host connections, it is possible to consume 517 content from different origin nodes as well as over different 518 network links in parallel, which can be seen as an intrinsic error 519 resilience feature w.r.t. the network. This is a useful feature of 520 CCN for adaptive multimedia streaming within mobile environments 521 since most mobile devices are equipped with multiple network links 522 like 3G and WiFi. CCN offers this functionality out of the box which 523 is beneficial when used for DASH-based services. In particular, it 524 is possible to enable adaptive video streaming handling both 525 bandwidth and network link changes. That is, CCN handles the network 526 link decision and DASH is implemented on top of CCN to adapt the 527 video stream to the available bandwidth. 529 In principle, there are two options to integrate DASH and CCN: a 530 proxy service acting as a broker between HTTP and CCN as proposed in 531 [6], and the DASH client implementing a native CCN interface. The 532 former transforms an HTTP request to a corresponding interest packet 533 as well as a data packet back to an HTTP response, including 534 reliable transport as offered by TCP. This may be a good compromise 535 to implement CCN in a managed network and to support legacy devices. 536 Since such a proxy is already described in [6] this draft focuses on 537 a more integrated approach, aiming at fully exploiting the potential 538 of a CCN DASH Client. That is, we describe a native CCN interface 539 within the DASH client, which adopts a CCN naming scheme (CCN URIs) 540 to denote segments in the Media Presentation Description (MPD). In 541 this architecture, only the network access component on the client 542 has to be modified and the segment URIs within MPD have to be 543 updated according to the CCN naming scheme. 545 Initially, the DASH client retrieves the MPD containing the CCN URIs 546 of the content representations including the media segments. The 547 naming scheme of the segments may reflect intrinsic features of CCN 548 like versioning and segmentation support. Such segmentation support 549 is already compulsory for multimedia streaming in CCN and, thus, can 550 also be leveraged for DASH-based streaming over CCN. The CCN 551 versioning can be adopted in a further step to signal different 552 representations of the DASH-based content, which enables an implicit 553 adaptation of the requested content to the clients' bandwidth 554 conditions. That is, the interest packet already provides the 555 desired characteristics of a segment (such as bit rate, resolution, 556 etc.) within the content name (or potentially within parameters 557 defined as extra types in the packet formats). Additionally, if 558 bandwidth conditions of the corresponding interfaces or routing 559 paths allow so, DASH media segments could be aggregated 560 automatically by the CCN nodes, which reduces the amount of interest 561 packets needed to request the content. However, such approaches need 562 further research, specifically in terms of additional intelligence 563 and processing power needed at the CCN nodes. 565 After requesting the MPD, the DASH client will start to request 566 particular segments. Therefore, CCN interest packets are generated 567 by the CCN access component and forwarded to the available 568 interfaces. Within the CCN, these interest packets leverage the 569 efficient interest aggregation for, e.g., popular content, as well 570 as the implicit multicast support. Finally, the interest packets are 571 satisfied by the corresponding data packets containing the video 572 segment data, which are stored on the origin server or any CCN node, 573 respectively. With an increasing popularity of the content, it will 574 be distributed across the network resulting in lower transmission 575 delays and reduced bandwidth requirements for origin servers and 576 content providers respectively. 578 With the extensive usage of in-network caching, new drawbacks are 579 introduced since the streaming logic is located at the client, i.e., 580 clients are not aware of each other and the network infrastructure 581 and cache states. Furthermore, negative effects are introduced when 582 multiple clients are competing for a bottleneck and when caching is 583 influencing this bandwidth competition. As mentioned above, the 584 clients request individual portions of the content based on 585 available bandwidth, which is calculated using throughput 586 estimations. This uncontrolled distribution of the content 587 influences the adaptation process of adaptive streaming clients. The 588 impact of this falsified throughput estimation could be tremendous 589 and leads to a wrong adaptation decision which may impact the 590 Quality of Experience (QoE) at the client, as shown in [8]. In ICN, 591 the client does not have the knowledge from which source the 592 requested content is actually served or how many origin servers of 593 the content are available, as this is transparent and depends on the 594 name-based routing. This introduces the challenge that the 595 adaptation logic of the adaptive streaming client is not aware of 596 the event when the ICN routing decides to switch to a different 597 origin server or content is coming through a different 598 link/interface. As most algorithms implementing the adaption logic 599 are using bandwidth measurements and related heuristics, the 600 adaptation decisions are no longer valid when changing origin 601 servers (or links) and potentially cause playback interruptions and, 602 consequently, stalling. Additionally, ICN supports the usage of 603 multiple interfaces. A seamless handover between these interfaces 604 (and different sources for the content) comes together with changes 605 in performance, e.g., due to switching between fixed and wireless, 606 3G/4G and WiFi networks, or between different types of servers (say 607 with/without SSD, or with/without hardware acceleration), etc. 609 Considering these characteristics of ICN, adaptation algorithms 610 merely based on bandwidth measurements are not appropriate anymore, 611 as potentially each segment can be transferred from another ICN node 612 or interface, all with different bandwidth conditions. Thus, 613 adaptation algorithms taking into account these intrinsic 614 characteristics of ICN are preferred over algorithms based on mere 615 bandwidth measurements. 617 5.4.2. Testbed, Open Source Tools, and Dataset 619 For the evaluations of DASH over CCN, a testbed with open source 620 tools and datasets is provided in [9]. In particular, it provides 621 two client player implementations, (i) a libdash extension for DASH 622 over CCN and (ii) a VLC plugin implementing DASH over CCN. For both 623 implementations the CCNx implementation has been used as a basis. 625 The general architecture of libdash is organized in modules, so that 626 the library implements a MPD parser and an extensible connection 627 manager. The library provides object-oriented interfaces for these 628 modules to access the MPD and the downloadable segments. These 629 components are extended to support DASH over CCN and available in a 630 separate development branch of the github project available at 631 http://www.github.com/bitmovin/libdash. libdash comes together with 632 a fully featured DASH player with a QT-based frontend, demonstrating 633 the usage of libdash and providing a scientific evaluation platform. 634 As an alternative, patches for the DASH plugin of the VLC player are 635 provided. These patches can be applied to the latest source code 636 checkout of VLC resulting in a DASH over CCN-enabled VLC player. 638 Finally, a DASH over CCN dataset is provided in form of a CCNx 639 repository. It includes 15 different quality representation of the 640 well-known Big Buck Bunny Movie, ranging from 100 kbps up to 4500 641 kbps. The content is split into segments of two seconds, and 642 described by an associated MPD using the presented naming scheme in 643 Section 4.1. This repository can be downloaded from [9], and is also 644 provided by a public accessible CCNx node. Associated routing 645 commands for the CCNx namespaces of the content are provided via 646 scripts coming together with the dataset and can be used as a public 647 testbed. 649 6. P2P video distribution and ICN 651 Another form of distributing content - and video in particular- 652 which ICNs need to support is Peer-to-Peer distribution (P2P). We 653 see now how an existing protocol such as PPSP can be modified to 654 work in an ICN environment. 656 6.1. Introduction to PPSP 658 P2P video Streaming (PPS) is a popular approach to redistribute live 659 media over Internet. The proposed P2PVS solutions can be roughly 660 classified in two classes: 662 - Push/Tree based 664 - Pull/Mesh based 666 The Push/Tree based solution creates an overlay network among peers 667 that has a tree shape [30]. Using a progressive encoding (e.g. 668 Multiple Description Coding or H.264 Scalable Video Coding), 669 multiple trees could be set up to support video rate adaptation. On 670 each tree an enhancement stream is sent. The higher the number of 671 received streams, the higher the video quality. A peer controls the 672 video rate by fetching or not the streams delivered over the 673 distribution trees. 675 The Pull/Mesh based solution is inspired by the BitTorrent file 676 sharing mechanism. A Tracker collects information about the state of 677 the swarm (i.e. set of participating peers). A peer forms a mesh 678 overlay network with a subset of peers, and exchange data with them. 679 A peer announces what data items it disposes and requests missing 680 data items that are announced by connected peers. In case of live 681 streaming, the involved data set includes only a recent window of 682 data items published by the source. Also in this case, the use of a 683 progressive encoding can be exploited for video rate adaptation. 685 Pull/Mesh based P2PVS solutions are the more promising candidate for 686 the ICN deployment, since most of ICN approach provides a pull-based 687 API [5][10][11][12]. In addition, Pull/Mesh based P2PVS are more 688 robust than Push/Tree based one [13] and the Peer to Peer Streaming 689 Protocol (PPSP) working group [14] is also proposing a Pull/Mesh 690 based solution. 692 +------------------------------------------------+ 693 | | 694 | +--------------------------------+ | 695 | | Tracker | | 696 | +--------------------------------+ | 697 | | ^ ^ | 698 |Tracker | | Tracker |Tracker | 699 |Protocol| | Protocol |Protocol | 700 | | | | | 701 | V | | | 702 | +---------+ Peer +---------+ | 703 | | Peer |<----------->| Peer | | 704 | +---------+ Protocol +---------+ | 705 | | ^ | 706 | | |Peer | 707 | | |Protocol | 708 | V | | 709 | +---------------+ | 710 | | Peer | | 711 | +---------------+ | 712 | | 713 +------------------------------------------------+ 714 Figure 1: PPSP System Architecture (source [RFC6972]) 716 Figure 1 reports the PPSP architecture presented in [RFC6972]. PEERs 717 announce and share video chunks and a TRACKER maintains a list of 718 PEERs participating in a specific audio/video channel or in the 719 distribution of a streaming file. The tracker functionality may be 720 centralized in a server or distributed over the PEERs. PPSP 721 standardize the Peer and Tracker Protocols, which can run directly 722 over UDP or TCP. 724 This document discusses some preliminary concepts about the 725 deployment of PPSP on top of an ICN that exposes a pull-based API, 726 meanwhile considering the impact of MPEG DASH streaming format. 728 6.2. PPSP over ICN: deployment concepts 730 6.2.1. PPSP short background 732 PPSP specifies peer protocol (PPSPP) [15] and tracker protocol 733 (PPSP-TP)[16]. 735 Some of the operations carried out by the tracker protocol are the 736 followings. When a peer wishes to join the streaming session it 737 contacts the Tracker (CONNECT message), obtains a PEER_ID and a list 738 of PEER_IDs (and IP addresses) of other peers that are participating 739 to the SWARM and that the tracker has singled out for the requesting 740 peer (this may be a subset of the all peers of the SWARM). In 741 addition to this join operation, a peer may contact the tracker to 742 request to renew the list of participating peers (FIND message), to 743 periodically update its status to the tracker (STAT_REPORT message), 744 etc. 746 Some of the operations carried out by the peer protocol are the 747 following. Using the list of peers delivered by the tracker, a peer 748 establishes a session with them (HANDSHAKE message). A peer 749 periodically announces to neighboring peers which chunks it has 750 available for download (HAVE message). Using these announcements, a 751 peer requests missing chunks from neighboring peers (REQUEST 752 messages), which will send back them (DATA message). 754 6.2.2. From PPSP messages to ICN named-data 756 An ICN provides users with data items exposed by names. The bundle 757 name and data item is usually referred as named-data, named-content, 758 etc. To transfer PPSP messages though an ICN the messages should be 759 wrapped as named-data items, and receivers should request them by 760 name. 762 A PPSP entity receives messages from peers and/or tracker. Some 763 operations require gathering the messages generated by another 764 specific host (peer or tracker). For instance, if a peer A wishes to 765 gain information about video chunks available from peer B, the 766 former shall fetch the PPSP HAVE messages specifically generated by 767 the later. We refer to these kinds of named-data as "located-named- 768 data", since they should be gathered from a specific location (e.g. 769 peer B). 771 For other PPSP operations, such as fetching a DATA message (i.e. a 772 video chunk), as long as a peer receives the requested content, it 773 doesn't matter which endpoint generated the data.We refer to this 774 information with the generic term "named-data". 776 The naming scheme differentiates named-data and located-named-data 777 items. In case of named-data, the naming scheme only includes a 778 content identifier (e.g. the name of the video chunk), without any 779 prefix identifying who provides the content. For instance, a DATA 780 message containing the video chunk #1 may be named as 781 "ccnx:/swarmID/chunk/chunkID", where swarmID is a unique identifier 782 of the streaming session, "chunk" is a keyword and chunkID is the 783 chunk identifier (e.g. a integer number). 785 In case of located-named-data, the naming scheme includes a 786 location-prefix, which uniquely identifies the host generating the 787 data item. This prefix may be the PEER_ID in case the host was a 788 peer or a tracker identifier in case the host was the tracker. For 789 instance, a HAVE message generated by a peer B may be named as 790 "ccnx:/swarmID/peer/PEER_ID/HAVE", where "peer" is a keyword, 791 PEER_ID_B is the identifier of peer B and HAVE is a keyword. 793 6.2.3. Support of PPSP interaction through a pull-based ICN 794 API 796 The PPSP procedures are based both on pull and push interactions. 797 For instance, the distribution of chunks availability can be 798 classified as a push-based operation, since a peer sends an 799 "unsolicited" information (HAVE message) to neighboring peers. 800 Conversely the procedure used to receive video chunks can be 801 classified as pull-based, since it is supported by a 802 request/response interaction (i.e. REQUEST, DATA messages). 804 As we said, we refer to an ICN architecture which provides a pull- 805 based API. Accordingly, the mapping of PPSP pull-based procedure is 806 quite simple. For instance, using the CCN architecture [5] a PPSP 807 DATA message may be carried by a CCN Data message and a REQUEST 808 message can transferred by a CCN Interest. 810 Conversely, the support of push-based PPSP operations may be more 811 difficult. We need of an adaptation functionality that carries out a 812 push-based operation using the underlying pull-based service 813 primitives. For instance, a possible approach is to use the 814 request/response (i.e. Interest/Data) four ways handshakes proposed 815 in [7]. Another possibility is that receivers periodically send out 816 request messages of the named-data that neighbors will push and, 817 when available, sender inserts the pushed data within a response 818 message. 820 6.2.4. Abstract layering for PPSP over ICN 822 +-----------------------------------+ 823 | Application | 824 +-----------------------------------+ 825 | PPSP (TCP/IP) | 826 +-----------------------------------+ 827 | ICN - PPSP Adaptation Layer (AL) | 828 +-----------------------------------+ 829 | ICN Architecture | 830 +-----------------------------------+ 831 Figure 2: Mediator approach 833 Figure 2 provides a possible abstract layering for PPSP over ICN. 834 The Adaptation Layer acts as a mediator (proxy) between legacy PPSP 835 entities based on TCP/IP and the ICN architecture. In facts, the 836 role the mediator is to use ICN to transfer PPSP legacy messages. 838 This approach makes possible to merely reuse TCP/IP P2P applications 839 whose software includes also PPSP functionality. This "all-in-one" 840 development approach may be rather common since the PPSP-Application 841 interface is not going to be specified. Moreover, if the Operating 842 System will provide libraries that expose a PPSP API, these will be 843 initially based on a underlying TCP/IP API. Also in this case, the 844 mediator approach would make possible to easily reuse both the PPSP 845 libraries and the Application on top of an ICN. 847 +-----------------------------------+ 848 | Application | 849 +-----------------------------------+ 850 | ICN-PPSP | 851 +-----------------------------------+ 852 | ICN Architecture | 853 +-----------------------------------+ 855 Figure 3: Clean-slate approach 857 Figure 3 sketches a clean-slate layering approach in which the 858 application directly includes or interacts with a PPSP version based 859 on ICN. Likely such a PPSP_ICN integration could yield a simplier 860 development, also because it does not require implementing a TCP/IP 861 to ICN translation as in the Mediator approach. However, the clean- 862 slate approach requires developing the application (in case of 863 embedded PPSP functionality) or the PPSP library from scratch, 864 without exploiting what might already exist for TCP/IP. 866 Overall, the Mediator approach may be considered as the first step 867 of a migration path towards ICN native PPSP applications. 869 6.2.5. PPSP interaction with the ICN routing plane 871 Upon the ICN API a user (peer) requests a content and the ICN sends 872 it back. The content is gathered by the ICN from any source, which 873 could be the closest peer that disposes of the named-data item, an 874 in-network cache, etc. Actually, "where" to gather the content is 875 controlled by an underlying ICN routing plane, which sets up the ICN 876 forwarding tables (e.g. CCN FIB [5]). 878 A cross-layer interaction between the ICN routing plane and the PPSP 879 may be required to support a PPSP session. Indeed, ICN shall forward 880 request messages (e.g. CCN Interest) towards the proper peer that 881 can handle them. Depending on the layering approach, this cross- 882 layer interaction is controlled either by the Adaptation Layer or by 883 the ICN-PPSP. For example, if a peer A receives a HAVE message 884 indicating that peer B disposes of the video chunk named 885 "ccnx:/swarmID/chunk/chunkID", then former should insert in its ICN 886 forwarding table an entry for the prefix 887 "ccnx:/swarmID/chunk/chunkID" whose next hop locator (e.g. IP 888 address) is the network address of peer B [17]. 890 6.2.6. ICN deployment for PPSP 892 The ICN functionality that supports a PPSP session may be "isolated" 893 or "integrated" with the one of a public ICN. 895 In the isolated case, a PPSP session is supported by an instance of 896 an ICN (e.g. deployed on top of IP), whose functionalities operate 897 only on the limited set of nodes participating to the swarm, i.e. 898 peers and the tracker. This approach resembles the one followed by 899 current P2P application, which usually form an overlay network among 900 peers of a P2P application. And intermediate public IP routers do 901 not carry out P2P functionalities. 903 In the integrated case, the nodes of a public ICN may be involved in 904 the forwarding and in-network caching procedures. In doing so, the 905 swarm may benefit from the presence of in-network caches so limiting 906 uplink traffic on peers and inter-domain traffic too. These are 907 distinctive advantages of using PPSP over a public ICN, rather than 908 over TCP/IP. In addition, such advantages aren't likely manifested 909 in the case of isolated deployment. 911 However, the possible interaction between the PPSP and the routing 912 layer of a public ICN may be dramatic, both in terms of explosion of 913 the forwarding tables and in terms of security. These issues 914 specifically take place for those ICN architectures for which the 915 name resolution (i.e. name to next-hop) occurs en-route, like the 916 CCN architecture. 918 For instance, using the CCN architecture, to fetch a named-data item 919 offered by a peer A the on-path public ICN entities have to route 920 the request messages towards the peer A. This implies that the ICN 921 forwarding tables of public ICN nodes may contain many entries, e.g. 923 one entry per video chunk, and these entries are difficult to be 924 aggregated since peers may have available only sparse parts of a big 925 content, whose names have a same prefix (e.g. "ccnx:/swarmID"). 926 Another possibility is to wrap all PPSP messages into a located- 927 named-data. In this case the forwarding tables should contain "only" 928 the PEER_ID prefixes (e.g. "ccnx:/swarmID/peer/PEER_ID"), so scaling 929 down the number of entries from number of chunks to number of peers. 930 However, in this case the ICN mechanisms recognize a same video 931 chunk offered by different peers as different contents, so vanishing 932 caching and multicasting ICN benefits. Moreover, in any case routing 933 entries should be updated either the base of the availability of 934 named-data items on peers or on the presence of peers, and these 935 events in a P2P session is rapidly changing so possibly hampering 936 the convergence of the routing plane. Finally, since peers have an 937 impact on the ICN forwarding table of public nodes, this may open 938 obvious security issues. 940 6.3. Impact of MPEG DASH coding schemes 942 The introduction of video rate adaptation may significantly decrease 943 the effectiveness of P2P cooperation and of in-network caching, 944 depending of the kind of the video coding used by the MPEG DASH 945 stream. 947 In case of a MPEG DASH streaming with MPEG AVC encoding, a same 948 video chunk is independently encoded at different rates and the 949 encoding output is a different file for each rate. For instance, in 950 case of a video encoded at three different rates R1,R2,R3, for each 951 segment S we have three distinct files: S.R1, S.R2, S.R3. These 952 files are independent of each other. To fetch a segment coded at R2 953 kbps, a peer shall request the specific file S.R2. Receiver-driven 954 algorithms, implemented by the video client, usually handle the 955 estimation of the best coding rate. 957 The independence among files associated to different encoding rates 958 and the heterogeneity of peer bandwidths, may dramatically reduce 959 the interaction among peers, the effectiveness of in-network caching 960 (in case of integrated deployment), and consequently the ability of 961 PPSP to offload the video server (i.e. a seeder peer). Indeed, a 962 peer A may select a coding rate (e.g. R1) different from the one 963 selected by a peer B (e.g. R2) and this prevents the former to fetch 964 video chunks from the later, since peer B only has chunks available 965 that are coded at a rate different from the ones needed by A. To 966 overcome this issue, a common distributed rate selection algorithm 967 could force peers to select the same coding rate [17]; nevertheless 968 this approach may be not feasible in the in case of many peers. 970 The use of SVC encoding (Annex G extension of the H.264/MPEG-4 AVC 971 video compression standard) should make rate adaptation possible, 972 meanwhile neither reducing peer collaborations nor the in-network 973 caching effectiveness. For a single video chunk, a SVC encoder 974 produces different files for the different rates (roughly "layers"), 975 and these files are progressively related each other. Starting from 976 a base-layer which provides the minimum rate encoding, the next 977 rates are encoded as an "enhancement layer" of the previous one. For 978 instance, in case the video is coded with three rates R1 (base- 979 layer), R2 (enhancement-layer n.1), R3 (enhancement-layer n.2), then 980 for each DASH segment we have three files S.R1, S.R2 and S.R3. The 981 file S.R1 is the segment coded at the minimum rate (base-layer). The 982 file S.R2 enhances S.R1, so as S.R1 and S.R2 can be combined to 983 obtain a segment coded at rate R2. To get a segment coded at rate 984 R2, a peer shall fetch both S.R1 and S.R2. This progressive 985 dependence among files that encode a same segment at different rates 986 makes peer cooperation possible, also in case peers player have 987 autonomously selected different coding rates. For instance, if peer 988 A has selected the rate R1, the downloaded files S.R1 are useful 989 also for a peer B that has selected the rate R2, and vice versa. 991 7. IPTV and ICN 993 7.1. IPTV challenges 995 IPTV refers to the delivery of quality content broadcast over the 996 Internet, and is typically associated with strict quality 997 requirements, i.e., with a perceived latency of less than 500 ms and 998 a packet loss rate that is multiple orders lower than the current 999 loss rates experienced in the most commonly used access networks 1000 (see [31]). We can summarize the major challenges for the delivery 1001 of IPTV service as follows. 1003 Channel change latency represents a major concern for the IPTV 1004 service. Perceived latency during channel change should be less than 1005 500ms. To achieve this objective over the IP infrastructure, we have 1006 multiple choices: 1008 (i) receiving fast unicast streams from a dedicated server (most 1009 effective but not resource efficient); 1010 (ii) connecting to other peers in the network (efficiency depends 1011 on peer support, effective and resource efficient, if also 1012 supported with a dedicated server); 1014 (iii) connecting to multiple multicast sessions at once (effective 1015 but not resource efficient, and depends on the accuracy of 1016 the prediction model used to track user activity). 1018 The second major challenge is the error recovery. Typical IPTV 1019 service requirements dictate the mean time between artifacts to be 1020 approximately 2 hours (see [31]). This suggests the perceived loss 1021 rate to be around or less than 10^-7. Current IP-based solutions 1022 rely on the following proactive and reactive recovery techniques: 1023 (i) joining the FEC multicast stream corresponding to the perceived 1024 packet loss rate (not efficient as the recovery strength is chosen 1025 based on worst-case loss scenarios), (ii) making unicast recovery 1026 requests to dedicated servers (requires active support from the 1027 service provider), (iii) probing peers to acquire repair packets 1028 (finding matching peers and enabling their cooperation is another 1029 challenge). 1031 7.2. ICN benefits for IPTV delivery 1033 ICN presents significant advantages for the delivery of IPTV 1034 traffic. For instance, ICN inherently supports multicast and allows 1035 for quick recovery from packet losses (with the help of in-network 1036 caching). Similarly, peer support is also provided in the shape of 1037 in-network caches that typically act as the middleman between two 1038 peers, enabling therefore earlier access to IPTV content. 1040 However, despite these advantages, delivery of IPTV service over 1041 Information Centric Networks brings forth new challenges. We can 1042 list some of these challenges as follows: 1044 . Messaging overhead: ICN is a pull-based architecture and relies 1045 on a unique balance between requests and responses. A user 1046 needs to make a request for each data packet. In the case of 1047 IPTV, with rates up to, and likely to be, above 15Mbps, we 1048 observe significant traffic upstream to bring those streams. As 1049 the number of streams increases (including the same session at 1050 different quality levels and other formats), so does the burden 1051 on the routers. Even if the majority of requests are aggregated 1052 at the core, routers close to the edge (where we observe the 1053 biggest divergence in user requests) will experience a 1054 significant increase in overhead to process these requests. The 1055 same is true at the user side, as the uplink usage multiplies 1056 in the number of sessions a user requests (for instance, to 1057 minimize the impact of bandwidth fluctuations). 1058 . Cache control: As the IPTV content expires at a rapid rate 1059 (with a likely expiry threshold of 1s), we need solutions to 1060 effectively flush out such content to also prevent degradation 1061 impact on other cached content, with the help of intelligently 1062 chosen naming conventions. However, to allow for fast recovery 1063 and optimize access time to sessions (from current or new 1064 users), the timing of such expirations needs to be adaptive to 1065 network load and user demand. However, we also need to support 1066 quick access to earlier content, whenever needed, for instance, 1067 when the user accesses the rewind feature (note that in-network 1068 caches will not be of significant help in such scenarios due to 1069 overhead required to maintain such content). 1070 . Access accuracy: To receive the up-to-date session data, users 1071 need to be aware of such information at the time of their 1072 request. Unlike IP multicast, since the users join a session 1073 indirectly, session information is critical to minimize 1074 buffering delays and reduce the startup latency. Without such 1075 information, and without any active cooperation from the 1076 intermediate routers, stale data can seriously undermine the 1077 efficiency of content delivery. Furthermore, finding a cache 1078 does not necessarily equate to joining a session, as the look- 1079 ahead latency for the initial content access point may have a 1080 shorter lifetime than originally intended. For instance, if the 1081 user that has initiated the indirect multicast leaves the 1082 session early, the requests from the remaining users need to 1083 experience an additional latency of one RTT as they travel 1084 towards the content source. If the startup latency is chosen 1085 depending on the closeness to the intermediate router, going to 1086 the content source in-session can lead to undesired pauses. 1088 It should be noted that IPTV includes more than just multicast. Many 1089 implementations include "trick plays" (fast forward, pause, rewind) 1090 that often transform a multicast session into multiple unicast 1091 sessions. In this context, ICN is beneficial, as the caching offers 1092 an implicit multicast, but without tight synchronization constraints 1093 in between two different users. One user may rewind, and start 1094 playing forward again, drawing from a nearby cache of the content 1095 recently viewed by another user (whereas in a strict multicast 1096 session, the opportunity of one user lagging off behind would be 1097 more difficult to implement). 1099 8. Digital Rights Managements in ICN 1101 This section discusses the need for Digital Rights Management (DRM) 1102 functionalities for multimedia streaming over ICN. It focuses on two 1103 possible approaches: modifying AAA to support DRM in ICN, and using 1104 Broadcast Encryption. 1106 It is assumed that ICN will be used heavily for digital content 1107 dissemination. It is vital to consider DRM for digital content 1108 distribution. In today's Internet there are two predominant classes 1109 of business models for on-demand video streaming. The first model is 1110 based on advertising revenues. Non-copyright protected (usually 1111 user-generated content, UGC) is offered by large infrastructure 1112 providers like Google (YouTube) at no charge. The infrastructure is 1113 financed by spliced advertisements into the content. In this context 1114 DRM considerations may not be required, since producers of UGC may 1115 only strive for the maximum possible dissemination. Some producers 1116 of UGC are mainly interested to share content with their families, 1117 friends, colleges or others and have no intention to make profit. 1118 However, the second class of business models requires DRM, because 1119 they are primarily profit oriented. For example, large on-demand 1120 streaming platforms like Netflix establish business models based on 1121 subscriptions. Consumers may have to pay a monthly fee in order to 1122 get access to copyright protected content like TV series, movies or 1123 music. This model may be ad-supported and free to the content 1124 consumer, like YouTube Channels or Spotify. But the creator of the 1125 content expects some remuneration for his work. From the perspective 1126 of the service providers and the copyright owners, only clients that 1127 pay the fee (explicitly or implicitly through ad placement) should 1128 be able to access and consume the content. Anyway, the challenge is 1129 to find an efficient and scalable way of access control to digital 1130 content, which is distributed in information-centric networks. 1132 8.1. Broadcast Encryption for DRM in ICN 1134 The section discusses Broadcast Encryption (BE) as a suitable basis 1135 for DRM functionalities in conformance to the ICN communication 1136 paradigm. Especially when network inherent caching is considered the 1137 advantage of BE will be highlighted. 1139 In ICN, data packets can be cached inherently in the network and any 1140 network participant can request a copy of these packets. This makes 1141 it very difficult to implement an access control for content that is 1142 distributed via ICN. A naive approach is to encrypt the transmitted 1143 data for each consumer with a distinct key. This prohibits everyone 1144 other than the intended consumers to decrypt and consume the data. 1145 However, this approach is not suitable for ICN's communication 1146 paradigm since it would reduce the benefits gained from the inherent 1147 network caching. Even if multiple consumers request the same content 1148 the requested data for each consumer would differ using this 1149 approach. A better but still insufficient idea is to use a single 1150 key for all consumers. This does not destruct the benefits of ICN's 1151 caching ability. The drawback is that if one of the consumers 1152 illegally distributes the key, the system is broken and any entity 1153 in the network can access the data. Changing the key after such an 1154 event is useless since the provider has no possibility to identify 1155 the illegal distributer. Therefore this person cannot be stopped 1156 from distributing the new key again. In addition to this issue other 1157 challenges have to be considered. Subscriptions expire after a 1158 certain time and then it has to be ensured that these consumers 1159 cannot access the content anymore. For a provider that serves 1160 millions of daily consumers (e.g. Netflix) there could be a 1161 significant number of expiring subscriptions per day. Publishing a 1162 new key every time a subscription expires would require an 1163 unsuitable amount of computational power just to re-encrypt the 1164 collection of audio-visual content. 1166 A possible approach to solve these challenges is Broadcast 1167 Encryption (BE) [22] as proposed in [23]. From this point on, this 1168 section will focus only on BE as an enabler for DRM functionality in 1169 the use case of ICN video streaming. This subsection continues with 1170 the explanation of how BE works and shows how BE can be used to 1171 implement an access control scheme in the context of content 1172 distribution in ICN. 1174 BE actually carries a misleading name. One might expect a concrete 1175 encryption scheme. However, it belongs to the family of key- 1176 management schemes (KMS). KMS are responsible for the generation, 1177 exchange, storage and replacement of cryptographic keys. The most 1178 interesting characteristics of Broadcast Encryption Schemes (BES) 1179 are: 1181 . A BES typically uses a global trusted entity called the 1182 licensing agent (LA), which is responsible for spreading a set 1183 of pre-generated secrets among all participants. Each 1184 participant gets a distinct subset of secrets assigned from the 1185 LA. 1186 . The participants can agree on a common session key, which is 1187 chosen by the LA. The LA broadcasts an encrypted message that 1188 includes the key. Participants with a valid set of secrets can 1189 derive the session-key from this message. 1191 . The number of participants in the system can change 1192 dynamically. Entities may join or leave the communication group 1193 at any time. If a new entity joins the LA passes on a valid set 1194 of secrets to that entity. If an entity leaves (or is forced to 1195 leave) the LA revokes the entity's subset of keys, which means 1196 that it cannot derive the correct session key anymore when the 1197 LA distributes a new key. 1198 . Traitors (entities that reveal their secrets) can be traced and 1199 excluded from ongoing communication. The algorithms and 1200 preconditions to identify a traitor vary between concrete BES. 1202 This listing already illustrates why BE is suitable to control the 1203 access to data that is distributed via an information-centric 1204 network. BE enables the usage of a single session key for 1205 confidential data transmission between a dynamically changing subset 1206 or network participants. ICN caches can be utilized since the data 1207 is encrypted only with a single key known by all legitimate clients. 1208 Furthermore, traitors can be identified and removed from the system. 1209 The issue of re-encryption still exists, because the LA will 1210 eventually update the session key when a participant should be 1211 excluded. However, this disadvantage can be relaxed in some way if 1212 the following points are considered: 1214 . The updates of the session key can be delayed until a set of 1215 compromised secrets has been gathered. Note that secrets may 1216 become compromised because of two reasons. First, a traitor 1217 could have illegally revealed the secret. Second, the 1218 subscription of an entity expired. Delayed revocation 1219 temporarily enables some non-legitimate entities to consume 1220 content. However, this should not be a severe problem in home 1221 entertainment scenarios. Updating the session key in regular 1222 (not too short) intervals is a good tradeoff. The longer the 1223 interval last the less computational resources are required for 1224 content re-encryption and the better the cache utilization in 1225 the ICN will be. To evict old data from ICN caches that has 1226 been encrypted with the prior session key the publisher could 1227 indicate a lifetime for transmitted packets. 1228 . Content should be re-encrypted dynamically at request time. 1229 This has the benefit that untapped content is not re-encrypted 1230 if the content is not requested during two session key updates 1231 and therefore no resources are wasted. Furthermore, if the 1232 updates are triggered in non-peak times the maximum amount of 1233 resource needed at one point in time can be lowered 1234 effectively, since in peak times generally more diverse content 1235 is requested. 1236 . Since the amount of required computational resources may vary 1237 strongly from time to time it would be beneficial for any 1238 streaming provider to use cloud-based services to be able to 1239 dynamically adapt the required resources to the current needs. 1240 Regarding to a lack of computation time or bandwidth the cloud 1241 service could be used to scale up to overcome shortages. 1243 Figure 4 show the potential usage of BE in a multimedia delivery 1244 frameworks that builds upon ICN infrastructure and uses the concept 1245 of dynamic adaptive streaming, e.g., DASH. BE would be implemented 1246 on the top to have an efficient and scalable way of access control 1247 to the multimedia content. 1249 +--------Multimedia Delivery Framework--------+ 1250 | | 1251 | Technologies Properties | 1252 | +----------------+ +----------------+ | 1253 | | Broadcast |<--->| Controlled | | 1254 | | Encryption | | Access | | 1255 | +----------------+ +----------------+ | 1256 | |Dynamic Adaptive|<--->| Multimedia | | 1257 | | Streaming | | Adaptation | | 1258 | +----------------+ +----------------+ | 1259 | | ICN |<--->| Cachable | | 1260 | | Infrastructure | | Data Chunks | | 1261 | +----------------+ +----------------+ | 1262 +---------------------------------------------+ 1264 Figure 4: A potential multimedia framework using BE. 1266 8.2 . AAA Based DRM for ICN Networks 1268 8.2.1. Overview 1270 Recently, a novel approach to Digital Rights Management (DRM) has 1271 emerged to link DRM to usual network management operations, hence 1272 linking DRM to authentication, authorization, and accounting (AAA) 1273 services. ICN provides the abstraction of an architecture where 1274 content is requested by name and could be served from anywhere. In 1275 DRM, the content provider (the origin of the content) allows the 1276 destination (the end user account) to use the content. The content 1277 provider and content storage/cache are at two different entities in 1278 ICC and for traditional DRM only source and destination count and 1279 not the intermediate storage. The proposed solution allows the 1280 provider of the caching to be involved in the DRM policies using 1281 well known AAA mechanisms. It is important to note that this 1282 solution is compatible with the proposes the Broadcast Encryption 1283 (BE) proposed earlier in this draft. The BE proposes a technology as 1284 this solution is more operational. 1286 8.2.2. Implementation 1288 With the proposed AAA-based DRM, when content is requested by name 1289 from a specific destination, the request could link back to both the 1290 content provider and the caching provider via traditional AAA 1291 mechanisms, and trigger the appropriate DRM policy independently 1292 from where the content is stored. In this approach the caching, DRM 1293 and AAA remain independent entities but can work together through 1294 ICN mechanisms. The proposed solution enables extending the 1295 traditional DRM done by the content provider to jointly being done 1296 by content provider and network/caching provider. 1298 The solution is based on the concept of a "token". The content 1299 provider authenticates the end user and issues an encrypted token to 1300 authenticate the a named content ID or IDs that the user can access. 1301 The token will be shared with the network provider and used as the 1302 interface to the AAA protocols. At this point all content access is 1303 under the control of the network provider and the ICN. The 1304 controllers and switches can manage the content requests and handle 1305 mobility. The content can be accessed from anywhere as long as 1306 the token remains valid or the content is available in the network. 1307 In such a scheme the content provider does not need to be contacted 1308 every time a named content is requested. This reduces the load of 1309 the content provider network and creates a DRM mechanism that is 1310 much more appropriate for the distributed caching and peer-to-peer 1311 storage characteristic of ICN networks. In particular, the content 1312 requested by name can be served from anywhere under the only 1313 condition that the storage/cache can verify that the token is valid 1314 for content access. 1316 The solution is also fully customizable to both content and network 1317 provider's needs as the tokens can be issued based on user accounts, 1318 location and hardware (MAC address for example) linking it naturally 1319 to legacy authentication mechanisms. In addition, since both content 1320 and network providers are involved in DRM policies pollution attacks 1321 and other illegal requests for the content can be more easily 1322 detected. The proposed AAA-based DRM is currently under full 1323 development. 1325 9. Future Steps for Video in ICN 1327 The explosion of online video services, along with their increased 1328 consumption by mobile wireless terminals, further exacerbates the 1329 challenges of Video Adaptation leveraging ICN mechanisms. The 1330 following sections present a series of research items derived from 1331 these challenges, further introducing next steps for the subject. 1333 9.1. Large Scale Live Events 1335 An active area of investigation and a potential use case where ICN 1336 would provide significant benefits, is that of distributing content, 1337 and video in particular, using local communications in large scale 1338 events such as sports event in a stadium, a concert or a large 1339 demonstration. 1341 Such use-case involves locating content that is generated on the fly 1342 and requires discovery mechanisms in addition to sharing mechanisms. 1343 The scalability of the distribution becomes important as well. 1345 9.2. Video Conferencing and Real-Time Communications 1347 Current protocols for video-conferencing have been designed, and 1348 this document needs to take input from them to identify the key 1349 research issues. Real-time communications add timing constraints 1350 (both in terms of delay and in terms of synchronization) to the 1351 scenario discussed above. 1353 AR and VR (and immersive multimedia experiences in general) are 1354 clearly an area of further investigation, as they involve combining 1355 multiple streams of data from multiple users into a coherent whole. 1356 This raises issues of multi-source multi-destination multimedia 1357 streams that ICN may be equipped to deal with in a more natural 1358 manner than IP that is inherently unicast. 1360 9.3. Store-and-Forward Optimized Rate Adaptation 1362 One of the benefits of ICN is to allow the network to insert caching 1363 in the middle of the data transfer. This can be used to reduce the 1364 overall bandwidth demands over the network by caching content for 1365 future re-use. But it provides more opportunities for optimizing 1366 video streams. 1368 Consider for instance the following scenario: a client is connected 1369 via an ICN network to a server. Let's say the client is connected 1370 wirelessly to a node that has a caching capability, which is 1371 connected through a WAN to the server. Assume further that the 1372 capacity of each of the links (both the wireless and the WAN logical 1373 links) vary with time. 1375 If the rate adaptation is provided in an end-to-end manner, as in 1376 current mechanisms like DASH, then the maximal rate that can be 1377 supported at the client is that of the minimal bandwidth on each 1378 link. 1380 For instance, if during time period 1, the wireless capacity is 1 1381 and the wired capacity is 2, and during time period 2, the wireless 1382 is 2 due to some hotspot, and the wired is 1 due to some congestion 1383 in the network, then the best end-to-end rate that can be achieved 1384 is 1 during each period. 1386 However, if the cache is used during time period 1 to pre-fetch 2 1387 units of data, then during period 2, there is 1 unit of data at the 1388 cache, and another unit of data, which can be streamed from the 1389 server, and the rate that can be achieved is therefore 2 units of 1390 data. In this case, the average bandwidth rises from 1 to 1.5 over 1391 the 2 periods. 1393 This straw man example illustrate a) the benefit of ICN for 1394 increasing the throughput of the network, and b) the need for the 1395 special rate adaptation mechanisms to be designed so as to take 1396 advantage of this gain. End-to-end rate adaptation cannot take 1397 advantage of the cache availability. 1399 9.4. Heterogeneous Wireless Environment Dynamics 1401 With the ever-growing increase in online services being accessed by 1402 mobile devices, operators have been deploying different overlapping 1403 wireless access networking technologies. In this way, in the same 1404 area, user terminals are within range of different cellular, Wi-Fi 1405 or even WiMAX networks. Moreover, with the advent of the Internet of 1406 Things (e.g., surveillance cameras feeding video footage), this list 1407 can be further complemented with more specific short-range 1408 technologies, such as Bluetooth or ZigBee. 1410 In order to leverage from this plethora of connectivity 1411 opportunities, user terminals are coming equipped with different 1412 wireless access interfaces, providing them with extended 1413 connectivity opportunities. In this way, such devices become able to 1414 select the type of access which best suits them according to 1415 different criteria, such as available bandwidth, battery 1416 consumption, access do different link conditions according to the 1417 user profile or even access to different content. Ultimately, these 1418 aspects contribute to the Quality of Experience perceived by the 1419 end-user, which is of utmost importance when it comes to video 1420 content. 1422 However, the fact that these users are mobile and using wireless 1423 technologies, also provides a very dynamic setting, where the 1424 current optimal link conditions at a specific moment might not last 1425 or be maintained while the user moves. These aspects have been amply 1426 analyzed in recently finished projects such as FP7 MEDIEVAL [18], 1427 where link events reporting on wireless conditions and available 1428 alternative connection points were combined with vide requirements 1429 and traffic optimization mechanisms, towards the production of a 1430 joint network and mobile terminal mobility management decision. 1431 Concretely, in [19] link information about the deterioration of the 1432 wireless signal was sent towards a mobility management controller in 1433 the network. This input was combined with information about the user 1434 profile, as well as of the current video service requirements, and 1435 used to trigger the decrease or increase of scalable video layers, 1436 adjusting the video to the ongoing link conditions. Incrementally, 1437 the video could also be adjusted when a new better connectivity 1438 opportunity presents itself. 1440 In this way, regarding Video Adaptation, ICN mechanisms can leverage 1441 from their intrinsic multiple source support capability and go 1442 beyond the monitoring of the status of the current link, thus 1443 exploiting the availability of different connectivity possibilities 1444 (e.g., different "interfaces"). Moreover, information obtained from 1445 the mobile terminal's point of view of its network link, as well as 1446 information from the network itself (i.e., load, policies, and 1447 others), can generate scenarios where such information is combined 1448 in a joint optimization procedure allowing the content to be forward 1449 to users using the best available connectivity option (e.g., 1450 exploiting management capabilities supported by ICN intrinsic 1451 mechanisms as in [20]). 1453 In fact, ICN base mechanisms can further be exploited in enabling 1454 new deployment scenarios such as preparing the network for mass 1455 requests from users attending a large multimedia event (i.e., 1456 concert, sports), allowing video to be adapted according to content, 1457 user and network requirements and operation capabilities in a 1458 dynamic way. 1460 The enablement of such scenarios require further research, with the 1461 main points highlighted as follows: 1463 . Development of a generic video services (and obviously content) 1464 interface allowing the definition and mapping of their 1465 requirements (and characteristics) into the current capabilities 1466 of the network; 1468 . How to define a scalable mechanism allowing either the video 1469 application at the terminal, or some kind of network management 1470 entity, to adapt the video content in a dynamic way; 1472 . How to develop the previous research items using intrinsic ICN 1473 mechanisms (i.e., naming and strategy layers); 1475 . Leverage intelligent pre-caching of content to prevent stalls and 1476 poor quality phases, which lead to bad Quality of Experience of 1477 the user. This includes in particular the usage in mobile 1478 environments, which are characterized by severe bandwidth changes 1479 as well as connection outages, as shown in [21]; 1481 . How to take advantage of the multi-path opportunities over the 1482 heterogeneous wireless interfaces. 1484 9.5. Network Coding for Video Distribution in ICN 1486 An interesting research area for combining heterogeneous sources is 1487 to use network coding [24]. Network coding allows to asynchronously 1488 combine multiple sources by having each of them send information 1489 that is not duplicated by the other but can be combined to retrieve 1490 the video stream. 1492 However, this creates issues in ICN in terms of defining the proper 1493 rate adaptation for the video stream; securing the encoded data; 1494 caching the encoded data; timeliness of the encoded data; overhead 1495 of the network coding operations both in network resources and in 1496 added buffering delay, etc. 1498 Network coding has shown promise in reducing buffering events in 1499 unicast, multicast and P2P setting. [26] considers strategies using 1500 network coding to enhance QoE for multimedia communications. Network 1501 coding can be applied to multiple streams, but also within a single 1502 stream as an equivalent of a composable erasure code. Clearly, there 1503 is a need for further investigation of network coding in ICN, 1504 potentially as a topic of activity in the research group. 1506 9.6. Synchronization Issues for Video Distribution in ICN 1508 ICN de-couples the fetching of video chunks from the location of 1509 these chunks. This means an audio chunk may be received from one 1510 network element (cache/storage/server) while a video chunk may be 1511 received from another one while another chunk (say, the next one, or 1512 another layer from the same video stream) may come from a third 1513 element. This introduces disparity in the retrieval times and 1514 locations of the different elements of a video stream that need to 1515 be played at the same (or almost same) time. Synchronization of such 1516 delivery and playback may require specific synchronization tools for 1517 video delivery in ICN. 1519 Other synchronization aspects involve: 1521 - synchronizing within a single stream, for instance the consecutive 1522 chunks of a single stream, or the multiple layers of a layered 1523 scheme, when sources and transport layers may be different. Re- 1524 ordering the packets of a stream distributed over multiple sources 1525 at the video client, or ensuring that multiple chunks coming from 1526 multiple sources arrive within an acceptable time window; 1527 - synchronizing multiple streams, such as the audio and video 1528 components of a video stream, which can be received from 1529 independent sources; 1530 - synchronizing multiple streams from multiple sources to multiple 1531 destinations, such as mass distribution of live events. For 1532 instance, for live video streams or video-conferencing, some level 1533 of synchronization is required so that people watching the stream 1534 view the same events at the same time. 1536 Some of these issues were addressed in [27] in the context of social 1537 video consumption. Network coding, with traffic engineering, is 1538 considered as a potential solution for synchronization issues. Other 1539 approaches could be considered that are specific for ICN as well. 1541 Traffic engineering in ICN [28,29] may be required to provide proper 1542 synchronization of multiple streams. 1544 10. Security Considerations 1546 This is informational. There are no specific security considerations 1547 outside of those mentioned in the text. 1549 11. IANA Considerations 1551 This document does not require any IANA action. 1553 12. Conclusions 1555 This draft proposed adaptive video streaming for ICN, identified 1556 potential problems and presented the combination of CCN with DASH as 1557 a solution. As both concepts, DASH and CCN, maintain several 1558 elements in common, like, e.g., the content in different versions 1559 being dealt with in segments, combination of both technologies seems 1560 useful. Thus, adaptive streaming over CCN can leverage advantages 1561 such as, e.g., efficient caching and intrinsic multicast support of 1562 CCN, routing based on named data URIs, intrinsic multi-link and 1563 multi-source support, etc. 1565 In this context, the usage of CCN with DASH in mobile environments 1566 comes together with advantages compared to today's solutions, 1567 especially for devices equipped with multiple network interfaces. 1568 The retrieval of data over multiple links in parallel is a useful 1569 feature, specifically for adaptive multimedia streaming, since it 1570 offers the possibility to dynamically switch between the available 1571 links depending on their bandwidth capabilities, transparent to the 1572 actual DASH client. 1574 13. References 1576 13.1. Normative References 1578 [RFC6972] Y. Zhang, N. Zong, "Problem Statement and Requirements of 1579 the Peer-to-Peer Streaming Protocol (PPSP)", RFC6972, July 1580 2013 1582 13.2. Informative References 1584 [1] ISO/IEC DIS 23009-1.2, Information technology - Dynamic 1585 adaptive streaming over HTTP (DASH) - Part 1: Media 1586 presentation description and segment formats 1588 [2] Lederer, S., Mueller, C., Rainer, B., Timmerer, C., 1589 Hellwagner, H., "An Experimental Analysis of Dynamic Adaptive 1590 Streaming over HTTP in Content Centric Networks", in 1591 Proceedings of the IEEE International Conference on Multimedia 1592 and Expo 2013, San Jose, USA, July, 2013 1594 [3] Liu, Y., Geurts, J., Point, J., Lederer, S., Rainer, B., 1595 Mueller, C., Timmerer, C., Hellwagner, H., "Dynamic Adaptive 1596 Streaming over CCN: A Caching and Overhead Analysis", in 1597 Proceedings of the IEEE international Conference on 1598 Communication (ICC) 2013 - Next-Generation Networking 1599 Symposium, Budapest, Hungary, June, 2013 1601 [4] Grandl, R., Su, K., Westphal, C., "On the Interaction of 1602 Adaptive Video Streaming with Content-Centric Networks", 1603 eprint arXiv:1307.0794, July 2013. 1605 [5] V. Jacobson, D. Smetters, J. Thornton, M. Plass, N. Briggs and 1606 R. Braynard, "Networking named content", in Proc. of the 5th 1607 int. Conf. on Emerging Networking Experiments and Technologies 1608 (CoNEXT '09). ACM, New York, NY, USA, 2009, pp. 1-12. 1610 [6] A. Detti, M. Pomposini, N. Blefari-Melazzi, S. Salsano and A. 1611 Bragagnini, "Offloading cellular networks with Information- 1612 Centric Networking: The case of video streaming", In Proc. of 1613 the Int. Symp. on a World of Wireless, Mobile and Multimedia 1614 Networks (WoWMoM '12), IEEE, San Francisco, CA, USA, 1-3, 1615 2012. 1617 [7] V. Jacobson, D. K. Smetters, N. H. Briggs, M. F. Plass, P. 1618 Stewart, J. D. Thornton, and R. L. Braynard, "VoCCN: Voice 1619 over content-centric networks," in ACM ReArch Workshop, 2009 1621 [8] Christopher Mueller, Stefan Lederer and Christian Timmerer, A 1622 proxy effect analysis and fair adaptation algorithm for 1623 multiple competing dynamic adaptive streaming over HTTP 1624 clients, In Proceedings of the Conference on Visual 1625 Communications and Image Processing (VCIP) 2012, San Diego, 1626 USA, November 27-30, 2012. 1628 [9] DASH Research at the Institute of Information Technology, 1629 Multimedia Communication Group, Alpen-Adria Universitaet 1630 Klagenfurt, URL: http://dash.itec.aau.at 1632 [10] A. Detti, N. Blefari-Melazzi, S. Salsano, and M. Pomposini 1633 CONET: A content centric inter-networking architecture," in ACM 1634 Workshop on Information-Centric Networking (ICN), 2011. 1636 [11] W. K. Chai, N. Wang, I. Psaras, G. Pavlou, C. Wang, G. C. de 1637 Blas, F. Ramon-Salguero, L. Liang, S. Spirou, A. Beben, and E. 1638 Hadjioannou, "CURLING: Content-ubiquitous resolution and 1639 delivery infrastructure for next-generation services," IEEE 1640 Communications Magazine, vol. 49, no. 3, pp. 112-120, March 1641 2011 1643 [12] NetInf project Website http://www.netinf.org 1645 [13] N. Magharei, R. Rejaie, Yang Guo, "Mesh or Multiple-Tree: A 1646 Comparative Study of Live P2P Streaming Approaches," INFOCOM 1647 2007. 26th IEEE International Conference on Computer 1648 Communications. IEEE , vol., no., pp.1424,1432, 6-12 May 2007 1650 [14] PPSP WG Website https://datatracker.ietf.org/wg/ppsp/ 1652 [15] A. Bakker, R. Petrocco, V. Grishchenko, "Peer-to-Peer Streaming 1653 Peer Protocol (PPSPP)", draft-ietf-ppsp-peer-protocol-08 1655 [16] Rui S. Cruz, Mario S. Nunes, Yingjie Gu, Jinwei Xia, Joao P. 1656 Taveira, Deng Lingli, "PPSP Tracker Protocol-Base Protocol 1657 (PPSP-TP/1.0)", draft-ietf-ppsp-base-tracker-protocol-02 1659 [17] A.Detti, B. Ricci, N. Blefari-Melazzi,"Peer-To-Peer Live 1660 Adaptive Video Streaming for Information Centric Cellular 1661 Networks", IEEE PIMRC 2013,London, UK, 8-11 September 2013 1663 [18] http://www.ict-medieval.eu 1665 [19] B. Fu, G. Kunzmann, M. Wetterwald, D. Corujo, R. Costa, "QoE- 1666 aware Traffic Management for Mobile Video Delivery", Proc. 2013 1667 IEEE ICC, Workshop on Immersive & Interactive Multimedia 1668 Communications over the Future Internet (IIMC), Budapest, 1669 Hungary, Jun 2013. 1671 [20] Corujo D., Vidal I., Garcia-Reinoso J., Aguiar R., "A Named 1672 Data Networking Flexible Framework for Management 1673 Communications", IEEE Communications Magazine, Vol. 50, no. 12, 1674 pp. 36-43, Dec 2012 1676 [21] Crabtree B., Stevens T., Allan B., Lederer S., Posch D., 1677 Mueller C., Timmerer C., Video Adaptation in Limited or Zero 1678 Network Coverage, CCNxConn 2013,PARC, Palo Alto, pp. 1-2, 2013 1680 [22] Fiat A., Naor M., "Broadcast Encryption", in Advances in 1681 Cryptology (Crypto'93), volume 773 of Lecture Notes in Computer 1682 Science, pages 480-491. Springer Berlin / Heidelberg, 1994. 1684 [23] Posch D., Hellwagner H., Schartner P., "On-Demand Video 1685 Streaming based on Dynamic Adaptive Encrypted Content Chunks", th in Proceedings of the 8 International Workshop on Secure 1686 Network Protocols (NPSec'13), Los Alamitos, IEEE Computer 1687 Society Press, October, 2013. 1689 [24] Montpetit M.J., Westphal C., Trossen D., "Network Coding Meets 1690 Information Centric Networks," in Proceedings of the workshop 1691 on Name-Oriented Mobility (NOM), jointly with ACM MobiHoc 2013, 1692 Hilton Head, SC, June 2013. 1694 [25] Le Callet P., Moeller S. and Perkis A. (eds.), Qualinet 1695 White Paper on Definitions of Quality of Experience 1696 (2012). European Network on Quality of Experience in Multimedia 1697 Systems and Services (COST Action IC 1003), Lausanne, 1698 Switzerland, Version 1.2, March 2013. 1700 [26] Medard M., Kim M., ParandehGheibi M., Zeng W., Montpetit M.J., 1701 Quality of Experience for Multimedia Communications: Network 1702 Coding Strategies, Technical Report, MIT, 2012/3 1704 [27] Montpetit M.J., Holtzman H., Chakrabarti K., Matijasevic M., 1705 Social video consumption: Synchronized viewing experiences 1706 across devices and networks, IEEE International Conference on 1707 Communications Workshops (ICC), 2013, 286-290 1709 [28] Su K., Westphal C., On the Benefit of Information Centric 1710 Networks for Traffic Engineering, IEEE ICC Conference, June 1711 2014 1713 [29] Chanda A., Westphal C., Raychaudhuri D., Content Based Traffic 1714 Engineering in Software Defined Information Centric Networks, 1715 in IEEE INFOCOM Workshop NOMEN'13, April, 2013 1717 [30] Castro M., Druschel P., Kermarrec A.-M., Nandi A., Rowstron A., 1718 Singh A. SplitStream: Highbandwidth multicast in cooperative 1719 environments. In Proceedings of ACM SOSP (2003). 1721 [31] ATIS IPTV Interoperability Forum, ATIS IFF, 1722 http://www.atis.org/iif/deliv.asp 1724 14. Authors' Addresses 1726 Stefan Lederer, Christian Timmerer, Daniel Posch 1727 Alpen-Adria University Klagenfurt 1728 Universitaetsstrasse 65-67, 9020 Klagenfurt, Austria 1730 Email: {firstname.lastname}@itec.aau.at 1732 Cedric Westphal, Aytac Azgin. Shucheng (Will) Liu 1733 Huawei 1734 2330 Central Expressway, Santa Clara, CA95050, USA 1736 Email: {cedric.westphal,aytac.azgin,liushucheng}@huawei.com 1737 Christopher Mueller 1738 bitmovin GmbH 1739 Lakeside B01, 9020 Klagenfurt, Austria 1741 Email: christopher.mueller@bitmovin.net 1743 Andrea Detti 1744 Electronic Engineering Dept. 1745 University of Rome Tor Vergata 1746 Via del Politecnico 1, Rome, Italy 1748 Email: andrea.detti@uniroma2.it 1750 Daniel Corujo, 1751 Advanced Telecommunications and Networks Group 1752 Instituto de Telecomunicacoes 1753 Campus Universitario de Santiago 1754 P-3810-193 Aveiro, Portugal 1756 Email: dcorujo@av.it.pt 1758 Jianping Wang 1759 City University of Hong Kong 1760 Hong Kong, China 1762 Email: jianwang@cityu.edu.hk 1764 Marie-Jose Montpetit 1766 Email: marie@mjmontpetit.com 1768 Niall Murray 1769 Dept. of Electronic, Computer and Software Engineering 1770 Athlone Institute of Technology 1771 Dublin Rd., Athlone, Ireland 1773 Email: nmurray@research.ait.ie 1775 15. Acknowledgements 1777 This work was supported in part by the EC in the context of the 1778 SocialSensor (FP7-ICT-287975) project and partly performed in the 1779 Lakeside Labs research cluster at AAU. SocialSensor receives 1780 research funding from the European Community's Seventh Framework 1781 Programme. The work for this document was also partially performed 1782 in the context of the FP7/NICT EU-JAPAN GreenICN project, 1783 http://www.greenicn.org. Apart from this, the European Commission 1784 has no responsibility for the content of this draft. The information 1785 in this document is provided as is and no guarantee or warranty is 1786 given that the information is fit for any particular purpose. The 1787 user thereof uses the information at its sole risk and liability. 1788 The authors would like to thank Shucheng (Will) Liu from Huawei for 1789 supporting Dr. Wang's research and Marie-Jose Montpetit of MIT for 1790 her help in writing the AAA for DRM section.