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