idnits 2.17.1 draft-irtf-icnrg-videostreaming-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 8. 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 110 characters in excess of 72. == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 905 has weird spacing: '...o bring those...' == 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 (March 10, 2014) is 3697 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 162, but not defined == Missing Reference: 'BE' is mentioned on line 1096, but not defined == Missing Reference: 'DAECC' is mentioned on line 1096, but not defined == Unused Reference: '22' is defined on line 1332, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 1336, but no explicit reference was found in the text == 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: Sept 10th, 2014 Alpen-Adria University Klagenfurt 5 C. Westphal, Ed. 6 Aytac Azgin 7 Huawei 8 C. Mueller 9 Bitmovin 10 A.Detti 11 University of Rome Tor Vergata 12 D. Corujo 13 University of Aveiro 15 March 10, 2014 17 Adaptive Video Streaming over ICN 18 draft-irtf-icnrg-videostreaming-00.txt 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. This document may not be modified, 27 and derivative works of it may not be created, and it may not be 28 published except as an Internet-Draft. 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. This document may not be modified, 32 and derivative works of it may not be created, except to publish it 33 as an RFC and to translate it into languages other than English. 35 This document may contain material from IETF Documents or IETF 36 Contributions published or made publicly available before November 37 10, 2008. The person(s) controlling the copyright in some of this 38 material may not have granted the IETF Trust the right to allow 39 modifications of such material outside the IETF Standards Process. 40 Without obtaining an adequate license from the person(s) controlling 41 the copyright in such materials, this document may not be modified 42 outside the IETF Standards Process, and derivative works of it may 43 not be created outside the IETF Standards Process, except to format 44 it for publication as an RFC or to translate it into languages other 45 than English. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF), its areas, and its working groups. Note that 49 other groups may also distribute working documents as Internet- 50 Drafts. 52 Internet-Drafts are draft documents valid for a maximum of six 53 months and may be updated, replaced, or obsoleted by other documents 54 at any time. It is inappropriate to use Internet-Drafts as 55 reference material or to cite them other than as "work in progress." 57 The list of current Internet-Drafts can be accessed at 58 http://www.ietf.org/ietf/1id-abstracts.txt 60 The list of Internet-Draft Shadow Directories can be accessed at 61 http://www.ietf.org/shadow.html 63 This Internet-Draft will expire on August 19, 2014. 65 Copyright Notice 67 Copyright (c) 2014 IETF Trust and the persons identified as the 68 document authors. All rights reserved. 70 This document is subject to BCP 78 and the IETF Trust's Legal 71 Provisions Relating to IETF Documents 72 (http://trustee.ietf.org/license-info) in effect on the date of 73 publication of this document. Please review these documents 74 carefully, as they describe your rights and restrictions with 75 respect to this document. 77 Abstract 79 This document presents the usage of Information Centric Networks 80 (ICN) for adaptive multimedia streaming and identifies problems, 81 which have to be considered for such applications. Several topics 82 related to video distribution over ICN are presented: DASH over ICN, 83 which leverages the recent ISO/IEC MPEG Dynamic Adaptive Streaming 84 over HTTP (DASH) standard, layered encoding over ICN, PPSP over ICN 85 and IPTV over ICN. DASH over ICN offers the possibility to transfer 86 data from multiple sources as well as over multiple links in 87 parallel, which is definitely an important feature, e.g., for mobile 88 devices offering multiple network links. In addition to this, the 89 named multimedia content is routed and cached efficiently by the 90 underlying network. Finally, PPSP extends the P2P semantics to video 91 streaming in ICNs. 93 Table of Contents 94 1. INTRODUCTION ................................................. 3 95 2. CONVENTIONS USED IN THIS DOCUMENT............................. 4 96 3. A SHORT PRIMER ON ICN AND VIDEO STREAMING .................... 4 97 3.1. INTRODUCTION TO CLIENT-DRIVEN STREAMING AND DASH .......... 5 98 3.2. LAYERED ENCODING .......................................... 6 99 4. INTERACTIONS OF VIDEO STREAMING WITH ICN ..................... 6 100 4.1. INTERACTION OF DASH AND ICN................................ 6 101 4.2. INTERACTION OF ICN WITH LAYERED ENCODING .................. 8 102 5. POSSIBLE INTEGRATION OF VIDEO STREAMING AND ICN ARCHITECTURE.. 9 103 5.1. DASH OVER CCN ............................................. 9 104 5.1.1. Testbed, Open Source Tools, and Dataset ............... 11 105 5.2. P2P CASE: P2P LIVE ADAPTIVE VIDEO STREAMING ............... 12 106 5.2.1. ................... 14 107 5.2.2. ................... 18 108 5.3. IPTV AND ICN .............................................. 19 109 5.3.1. IPTV challenges ....................................... 19 110 5.3.2. ICN benefits for IPTV delivery ........................ 20 111 6. FUTURE STEPS FOR VIDEO IN ICN................................. 22 112 6.1. HETEROGENEOUS WIRELESS ENVIRONMENT DYNAMICS ............... 22 113 6.2. DIGITAL RIGHTS MANAGEMENT OF MULTIMEDIA CONTENT IN ICN .... 24 114 7. SECURITY CONSIDERATIONS ...................................... 27 115 8. IANA CONSIDERATIONS .......................................... 27 116 9. CONCLUSIONS ............................................ 27 117 10. REFERENCES ........................................... 28 118 10.1. NORMATIVE REFERENCES ..................................... 28 119 10.2. INFORMATIVE REFERENCES ................................... 28 120 11. AUTHORS' ADDRESSES .......................................... 30 121 12. ACKNOWLEDGEMENTS ............................................ 31 123 1. Introduction 125 The unprecedented growth of video traffic has triggered a rethinking 126 of how content is distributed, both in terms of the underlying 127 Internet architecture and in terms of the streaming mechanisms to 128 deliver video objects. 130 In particular, the IRTF ICN working group has been chartered to 131 study new architectures centered upon information; while Dynamic 132 Adaptive Streaming over HTTP (DASH)[1] has been developed to provide 133 an open, common delivery mechanism for video streams that is able to 134 adapt to the network conditions. 136 DASH is designed to run over the current Internet architecture (more 137 accurately, over HTTP) but a similar video streaming mechanism would 138 be required in an ICN architecture. 140 However, dynamic adaptive streaming in an ICN will encounter some 141 issues that will require specific adjustment to make it fully 142 functional in such environments. 144 Some documents have started to consider the ICN-specific 145 requirements of dynamic adaptive streaming [2][3][4][6]. 147 In this document, we give a brief overview of what is dynamic 148 adaptive video streaming. We then consider the interactions of such 149 adaptive mechanism with the ICN architecture and list some of the 150 interactions any video streaming mechanism will have to consider. We 151 describe an implementation of DASH over CCN as a possible mechanism 152 for video streaming in an ICN architecture. 154 2. Conventions used in this document 156 In examples, "C:" and "S:" indicate lines sent by the client and 157 server respectively. 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in RFC-2119 [RFC2119]. 163 In this document, these words will appear with that interpretation 164 only when in ALL CAPS. Lower case uses of these words are not to be 165 interpreted as carrying RFC-2119 significance. 167 In this document, the characters ">>" preceding an indented line(s) 168 indicates a compliance requirement statement using the key words 169 listed above. This convention aids reviewers in quickly identifying 170 or finding the explicit compliance requirements of this RFC. 172 3. A Short Primer on ICN and Video Streaming 174 For ICN specific descriptions, we refer to the other working group 175 documents. For our purpose, we assume here that ICN means an 176 architecture where content is retrieved by name and with no binding 177 of content to a specific network location. 179 The consumption of multimedia content comes along with timing 180 requirements for the delivery of the content, for both, live and on- 181 demand consumption. Additionally, real-time use cases such as audio- 182 /video conferencing [7], game streaming, etc., come along with more 183 strict timing requirements. Long startup delays, buffering periods 184 or poor quality, etc., should be avoided to achieve a good Quality 185 of Experience (QoE) to the consumer of the content. Of course, these 186 requirements are heavily influenced by routing decisions and 187 caching, which are central parts of ICN and which have to be 188 considered when streaming video in such infrastructures. 190 For video streaming, we briefly describe DASH [1], and Layered 191 Encoding (MDC, SVC) and IPTV. Videoconference and real-time video 192 communications are also part of the scope of this document. 194 3.1. Introduction to client-driven streaming and DASH 196 Media streaming over the hypertext transfer protocol (HTTP) and in a 197 further consequence streaming over the transmission control protocol 198 (TCP) has become omnipresent in today's Internet. Content providers 199 such as Netflix, Hulu, and Vudu do not deploy their own streaming 200 equipment but use the existing Internet infrastructure as it is and 201 they simply utilize their own services over the top (OTT). This 202 streaming approach works surprisingly well without any particular 203 support from the underlying network due to the use of efficient 204 video compression, content delivery networks (CDNs), and adaptive 205 video players. The assumption of earlier video streaming research, 206 which mostly recommended the user datagram protocol (UDP) and the 207 real time transport protocol (RTP), that it would not be possible to 208 transfer multimedia data smoothly with TCP, because of its 209 throughput variations and large retransmission delays, could be seen 210 as a delusion from today's point of view. HTTP streaming, and 211 especially its most simple form which is known as progressive 212 download, has become very popular over the past few years because it 213 has some major benefits compared to RTP streaming. As a consequence 214 of the consistent use of HTTP for this streaming method, the 215 existing Internet infrastructure, consisting of proxies, caches and 216 CDNs, could be used. Originally, this architecture was designed to 217 support best effort delivery of files and not real time transport of 218 multimedia data. Nevertheless, also real time streaming based on 219 HTTP could take advantage from this architecture, in comparison to 220 RTP, which could not leverage any of the aforementioned components. 221 Another benefit that results from the use of HTTP is that the media 222 stream could easily pass firewalls or network address translation 223 (NAT) gateways, which was definitely a key for the success of HTTP 224 streaming. However, HTTP streaming is not the holy grail of 225 streaming as it also introduces some drawbacks compared to RTP. 226 Nevertheless, in an ICN-based video streaming architecture these 227 aspects also have to be considered. 229 The basic concept of DASH [1] is to use segments of media content, 230 which can be encoded at different resolutions, bitrates, etc., as 231 so-called representations. These segments are served by conventional 232 HTTP Web servers and can be addressed via HTTP GET requests from the 233 client. As a consequence, the streaming system is pull-based and the 234 entire streaming logic is located on the client, which makes it 235 scalable, and possible to adapt the media stream to the client's 236 capabilities. 238 In addition to this, the content can be distributed using 239 conventional CDNs and their HTTP infrastructure, which also scales 240 very well. In order to specify the relationship between the 241 contents' media segments and the associated bitrate, resolution, and 242 timeline, the Media Presentation Description (MPD) is used, which is 243 a XML document. The MPD refers the available media segments using 244 HTTP URLs, which can be used by the client for retrieving them. 246 3.2. Layered Encoding 248 Scalable video coding formats the video stream into different 249 layers: a base layer which can be decoded to provide the lowest bit 250 rate for the specific stream, and enhancement layers which can be 251 transmitted separately if network conditions allow. This is used in 252 MPEG-4 scalable profile or H.263+. 254 4. Interactions of Video Streaming with ICN 256 4.1. Interaction of DASH and ICN 258 Video streaming, and DASH in particular, have been designed with 259 goals that are aligned with that of most ICN proposals. Namely, it 260 is a client-based mechanism, which requests items (in this case, 261 chunks of a video stream) by name. 263 ICN and MPEG-DASH [1] have several elements in common: 265 - the client-initiated pull approach; 266 - the content being dealt with in pieces (or chunks); 267 - the support of efficient replication and distribution of content 268 pieces within the network; 270 - the session-free nature of the exchange between the client and the 271 server at the streaming layer: the client is free to request any 272 chunk from any location; 273 - the support for potentially multiple sources. 275 As ICN is a promising candidate for the Future Internet (FI) 276 architecture, it is useful to investigate its suitability in 277 combination with multimedia streaming standards like MPEG-DASH. In 278 this context, the purpose of this draft is to present the usage of 279 ICN instead of HTTP in MPEG-DASH 281 However, there are some issues that arise from using a dynamic rate 282 adaptation mechanism in an ICN architecture: 284 o Naming of the data in DASH does not necessarily follow the ICN 285 convention of any of the ICN proposals. Several chunks of the 286 same video stream might currently go by different names that for 287 instance do not share a common prefix. There is a need to 288 harmonize the naming of the chunks in DASH with the naming 289 conventions of the ICN. The naming convention of using a 290 filename/time/encoding format could for instance be made 291 compatible with the convention of CCN. 293 o While chunks can be retrieved from any server, the rate 294 adaptation mechanism attempts to estimate the available network 295 bandwidth so as to select the proper playback rate and keep its 296 playback buffer at the proper level. Therefore, there is a need 297 to either include some location semantics in the data chunks so 298 as to properly assess the throughput to a specific location; or 299 to design a different mechanism to evaluate the available network 300 bandwidth. 302 o The typical issue of access control and accounting happens in 303 this context, where chunks can be cached in the network outside 304 of the administrative control of the content publisher. It might 305 be a requirement from the owner of the video stream that access 306 to these data chunks needs to be accounted/billed/monitored. 308 o Dynamic streaming multiplies the representations of a given video 309 stream, therefore diminishing the effectiveness of caching: 310 namely, to get a hit for a chunk in the cache, it has to be for 311 the same format and encoding values. Alternatively, to get the 312 same hit rate as for a stream using a single encoding, the cache 313 size must be scaled up to include all the possible 314 representations. 316 o Caching introduces oscillatory dynamics as it may modify the 317 estimation of the available bandwidth between the end user and 318 the repository where it is getting the chunks from. For instance, 319 if an edge cache holds a low resolution representation near the 320 user, the user getting this low resolution chunks will observe a 321 good performance, and will then request higher resolution chunks. 322 If those are hosted on a server with poor performance, then the 323 client would have to switch back to the low representation. This 324 oscillation may be detrimental to the perceived QoE of the user. 326 o The ICN transport mechanism needs to be compatible to some extent 327 with DASH. To take a CCN example, the rate at which interests are 328 issued should be such that the chunks received in return arrive 329 fast enough and with the proper encoding to keep the playback 330 buffer above some threshold. 332 o The usage of multiple network interfaces is possible in ICN, 333 enabling a seamless handover between them. For the combination 334 with DASH, an intelligent strategy which should focus on traffic 335 load balancing between the available links may be necessary. This 336 would increase the effective media throughput of DASH by 337 leveraging the combined available bandwidth of all links, 338 however, it could potentially lead to high variations of the 339 media throughput. 341 o DASH does not define how the MPD is retrieved; hence, this is 342 compatible with CCN. However, the current profiles defined within 343 MPEG-DASH require the MPD to contain HTTP-URLs (incl. http and 344 https URI schemes) to identify segments. To enable a more 345 integrated approach as described in this document, an additional 346 profile for DASH over CCN has to be defined, enabling ICN/CCN- 347 based URIs to identify and request the media segments. 349 We describe in Section 5 a potential implementation of a dynamic 350 adaptive video stream over ICN, based upon DASH and CCN [5]. 352 4.2. Interaction of ICN with Layered Encoding 354 Issues of interest to an Information-Centric network architecture in 355 the context of layered video streaming include: 357 . Caching of the multiple layers. The caching priority should go 358 to the base layer, and defining caching policy to decide when 359 to cache enhancement layers 360 . Synchronization of multiple content streams, as the multiple 361 layers may come from different sources in the network (for 362 instance, the base layer might be cached locally while the 363 enhancement layers may be stored in the origin server) 364 . Naming of the different layers: when the client requests an 365 object, the request can be satisfied with the base layer alone, 366 aggregated with enhancement layers. Should one request be 367 sufficient to provide different streams? In a CCN architecture 368 for instance, this would violate a one interest-one data packet 369 principle and the client would need to specify each layer it 370 would like to receive. In a Pub/Sub architecture, the 371 rendezvous point would have to make a decision as to which 372 layers (or which pointer to which layer's location) to return. 374 5. Possible Integration of Video streaming and ICN architecture 376 5.1. DASH over CCN 378 DASH is intended to enable adaptive streaming, i.e., each content 379 piece can be provided in different qualities, formats, languages, 380 etc., to cope with the diversity of todays' networks and devices. As 381 this is an important requirement for Future Internet proposals like 382 CCN, the combination of those two technologies seems to be obvious. 383 Since those two proposals are located at different protocol layers - 384 DASH at the application and CCN at the network layer - they can be 385 combined very efficiently to leverage the advantages of both and 386 potentially eliminate existing disadvantages. As CCN is not based on 387 classical host-to-host connections, it is possible to consume 388 content from different origin nodes as well as over different 389 network links in parallel, which can be seen as an intrinsic error 390 resilience feature w.r.t. the network. This is a useful feature of 391 CCN for adaptive multimedia streaming within mobile environments 392 since most mobile devices are equipped with multiple network links 393 like 3G and WiFi. CCN offers this functionality out of the box which 394 is beneficial when used for DASH-based services. In particular, it 395 is possible to enable adaptive video streaming handling both 396 bandwidth and network link changes. That is, CCN handles the network 397 link decision and DASH is implemented on top of CCN to adapt the 398 video stream to the available bandwidth. 400 In principle, there are two options to integrate DASH and CCN: a 401 proxy service acting as a broker between HTTP and CCN as proposed in 402 [6], and the DASH client implementing a native CCN interface. The 403 former transforms an HTTP request to a corresponding interest packet 404 as well as a data packet to an HTTP response, including reliable 405 transport as offered by TCP. This may be a good compromise to 406 implement CCN in a managed network and to support legacy devices. As 407 such a proxy is already described in [6] this draft focuses on a 408 more integrated approach, aiming at fully exploiting the potential 409 CCN DASH Client. That is, a native CCN interface within the DASH 410 client, which adopts a CCN naming scheme (CCN URIs) to denote 411 segments in the Media Presentation Description (MPD). In this 412 architecture, only the network access component on the client has to 413 be modified and the segment URIs within MPD have to be updated 414 according to the CCN naming scheme. 416 Initially, the DASH client retrieves the MPD containing the CCN URIs 417 of the content representations including the media segments. The 418 naming scheme of the segments may reflect intrinsic features of CCN 419 like versioning and segmentation support. Such segmentation support 420 is already compulsory for multimedia streaming in CCN and, thus, can 421 also be leveraged for DASH-based streaming over CCN. The CCN 422 versioning can be adopted in a further step to signal different 423 representations of the DASH-based content, which enables an implicit 424 adaptation of the requested content to the clients' bandwidth 425 conditions. That is, the interest packet already provides the 426 desired characteristics of a segment (such as bit rate, resolution, 427 etc.) within the content name. Additionally, if bandwidth conditions 428 of the corresponding interfaces or routing paths allow so, DASH 429 media segments could be aggregated automatically by the CCN nodes, 430 which reduces the amount of interest packets needed to request the 431 content. However, such approaches need further research, 432 specifically in terms of additional intelligence and processing 433 power needed at the CCN nodes. 435 After requesting the MPD, the DASH client will start to request 436 particular segments. Therefore, CCN interest packets are generated 437 by the CCN access component and forwarded to the available 438 interfaces. Within the CCN, these interest packets leverage the 439 efficient interest aggregation for, e.g., popular content, as well 440 as the implicit multicast support. Finally, the interest packets are 441 satisfied by the corresponding data packets containing the video 442 segment data, which are stored on the origin server or any CCN node, 443 respectively. With an increasing popularity of the content, it will 444 be distributed across the network resulting in lower transmission 445 delays and reduced bandwidth requirements for origin servers and 446 content providers respectively. 448 With the extensive usage of in-network caching, new drawbacks are 449 introduced as a consequence that the streaming logic is located at 450 the client, i.e., clients are not aware of each other and the 451 network infrastructure and cache states. Furthermore, negative 452 effects are introduced when multiple clients are competing for a 453 bottleneck and when caching is influencing this bandwidth 454 competition. As mentioned above, the clients request individual 455 portions of the content based on available bandwidth which is 456 calculated using throughput estimations. This uncontrolled 457 distribution of the content influences the adaptation process of 458 adaptive streaming clients. The impact of this falsified throughput 459 estimation could be tremendous and leads to a wrong adaptation 460 decision which may impact the Quality of Experience (QoE) at the 461 client, as shown in [8]. In ICN, the client does not have the 462 knowledge from which source the requested content is actually served 463 or how many origin servers of the content are available, as this is 464 transparent and depends on the name-based routing. This introduces 465 the challenge that the adaptation logic of the adaptive streaming 466 client is not aware of the event when the ICN routing decides to 467 switch to a different origin server or content is coming through a 468 different link/interface. As most algorithms implementing the 469 adaption logic are using bandwidth measurements and related 470 heuristics, the adaptation decisions are no longer valid when 471 changing origin servers (or links) and potentially cause playback 472 interruptions and, consequently, stalling. Additionally, ICN 473 supports the usage of multiple interfaces and a seamless handover 474 between them, which again comes together with bandwidth changes, 475 e.g., switching between fixed and wireless, 3G/4G and WiFi networks, 476 etc. Considering these characteristics of ICN, adaptation algorithms 477 merely based on bandwidth measurements are not appropriate anymore, 478 as potentially each segment can be transferred from another ICN node 479 or interface, all with different bandwidth condition. Thus, 480 adaptation algorithms taking into account these intrinsic 481 characteristics of ICN are preferred over algorithms based on mere 482 bandwidth measurements. 484 5.1.1. Testbed, Open Source Tools, and Dataset 486 For the evaluations of DASH over CCN, a testbed with open source 487 tools and datasets is provided in [9]. In particular, it provides 488 two client player implementations, (i) a libdash extension for DASH 489 over CCN and (ii) a VLC plugin implementing DASH over CCN. For both 490 implementations the CCNx implementation has been used as a basis. 492 The general architecture of libdash is organized in modules, so that 493 the library implements a MPD parser and an extensible connection 494 manager. The library provides object-oriented interfaces for these 495 modules to access the MPD and the downloadable segments. These 496 components are extended to support DASH over CCN and available in a 497 separate development branch of the github project available at 498 http://www.github.com/bitmovin/libdash. libdash comes together with 499 a fully featured DASH player with a QT-based frontend, demonstrating 500 the usage of libdash and providing a scientific evaluation platform. 501 As an alternative, patches for the DASH plugin of the VLC player are 502 provided. These patches can be applied to the latest source code 503 checkout of VLC resulting in a DASH over CCN-enabled VLC player. 505 Finally, a DASH over CCN dataset is provided in form of a CCNx 506 repository. It includes 15 different quality representation of the 507 well-known Big Buck Bunny Movie, ranging from 100 kbps up to 4500 508 kbps. The content is split into segments of two seconds, and 509 described by an associated MPD using the presented naming scheme in 510 Section 4.1. This repository can be downloaded from [9], and is also 511 provided by a public accessible CCNx node. Associated routing 512 commands for the CCNx namespaces of the content are provided via 513 scripts coming together with the dataset and can be used as a public 514 testbed. 516 5.2. P2P case: P2P live adaptive video streaming 518 P2P video Streaming (PPS) is a popular approach to redistribute live 519 media over Internet. The proposed P2PVS solutions can be roughly 520 classified in two classes: 522 - Push/Tree based 524 - Pull/Mesh based 526 The Push/Tree based solution creates an overlay network among peers 527 that has a tree shape. Using a progressive encoding (e.g. Multiple 528 Description Coding or H.264 Scalable Video Coding), multiple trees 529 could be set up to support video rate adaptation. On each tree an 530 enhancement stream is sent. The more the number of stream received, 531 the higher the video quality. A peer control video rate by fetching 532 or not the streams delivered on the distribution trees. 534 The Pull/Mesh based solution is inspired by the BitTorrent file 535 sharing mechanism. A Tracker collects information about the state of 536 the swarm (i.e. set of participating peers). A peer forms a mesh 537 overlay network with a subset of peers, and exchange data with them. 538 A peer announces what data items it disposes and requests missing 539 data items that are announced by connected peers. In case of live 540 streaming, the involved data set regards only a recent window of 541 data items published by the source. Also in this case, the use of a 542 progressive encoding can be exploited for video rate adaptation. 544 Pull/Mesh based P2PVS solutions are the more promising candidate for 545 the ICN deployment, since most of ICN approach provides a pull-based 546 API [5][10][11][12]. In addition, Pull/Mesh based P2PVS are more 547 robust than Push/Tree based one [13] and the Peer to Peer Streaming 548 Protocol (PPSP) working group [14] is also proposing a Pull/Mesh 549 based solution. 551 +------------------------------------------------+ 552 | | 553 | +--------------------------------+ | 554 | | Tracker | | 555 | +--------------------------------+ | 556 | | ^ ^ | 557 |Tracker | | Tracker |Tracker | 558 |Protocol| | Protocol |Protocol | 559 | | | | | 560 | V | | | 561 | +---------+ Peer +---------+ | 562 | | Peer |<----------->| Peer | | 563 | +---------+ Protocol +---------+ | 564 | | ^ | 565 | | |Peer | 566 | | |Protocol | 567 | V | | 568 | +---------------+ | 569 | | Peer | | 570 | +---------------+ | 571 | | 572 +------------------------------------------------+ 573 Figure 1: PPSP System Architecture (source [RFC6972]) 575 Figure 1 reports the PPSP architecture presented in [RFC6972]. PEERs 576 announce and share video chunks and a TRACKER maintains a list of 577 PEERs participating in a specific audio/video channel or in the 578 distribution of a streaming file. The tracker functionality may be 579 centralized in a server or distributed over the PEERs. PPSP 580 standardize the Peer and Tracker Protocols, which can run directly 581 over UDP or TCP. 583 This document discusses some preliminary concepts about the 584 deployment of PPSP on top of an ICN that exposes a pull-based API, 585 meanwhile considering the impact of MPEG DASH streaming format. 587 5.2.1. 589 5.2.1.1. PPSP short background 591 PPSP specifies peer protocol (PPSPP) [15] and tracker protocol 592 (PPSP-TP)[16]. 594 Some of the operations carried out by the tracker protocol are the 595 followings. When a peer wishes to join the streaming session it 596 contacts the Tracker (CONNECT message), obtains a PEER_ID and a list 597 of PEER_IDs (and IP addresses) of other peers that are participating 598 to the SWARM and that the tracker has singled out for the requesting 599 peer (this may be a subset of the all peers of the SWARM). In 600 addition to this join operation, a peer may contact the tracker to 601 request to renew the list of participating peers (FIND message), to 602 periodically update its status to the tracker (STAT_REPORT message), 603 etc. 605 Some of the operations carried out by the peer protocol are the 606 following. Using the list of peers delivered by the tracker, a peer 607 establishes a session with them (HANDSHAKE message). A peer 608 periodically announces to neighboring peers which chunks it has 609 available for download (HAVE message). Using these announcements, a 610 peer requests missing chunks from neighboring peers (REQUEST 611 messages), which will send back them (DATA message). 613 5.2.1.2. From PPSP messages to ICN named-data 615 An ICN provides users with data items exposed by names. The bundle 616 name and data item is usually referred as named-data, named-content, 617 etc. To transfer PPSP messages though an ICN the messages should be 618 be wrapped as named-data items, and receivers should request them by 619 name. 621 A PPSP entity receives messages from peers and/or tracker. Some 622 operations require gathering the messages generated by another 623 specific host (peer or tracker). For instance, if a peer A wishes to 624 gain information about video chunks available from peer B, the 625 former shall fetch the PPSP HAVE messages specifically generated by 626 the later. We refer to these kinds of named-data as "located-named- 627 data", since they should be gathered from a specific location (e.g. 628 peer B). 630 For other PPSP operations, like to fetch a DATA message (i.e. a 631 video chunk), what it is relevant for a peer is just to receive the 632 requested content, independently from who is the endpoint that 633 generate the data. We refer this information with the generic term 634 "named-data". 636 The naming scheme differentiates named-data and located-named-data 637 items. In case of named-data, the naming scheme only includes a 638 content identifier (e.g. the name of the video chunk), without any 639 prefix identifying who provides the content. For instance, a DATA 640 message containing the video chunk n. 1 may be named as 641 "ccnx:/swarmID/chunk/chunkID", where swarmID is a unique identifier 642 of the streaming session, "chunk" is a keyword and chunkID is the 643 chunk identifier (e.g. a integer number). 645 In case of located-named-data, the naming scheme includes a 646 location-prefix, which uniquely identifies the host generating the 647 data item. This prefix may be the PEER_ID in case the host was a 648 peer or a tracker identifier in case the host was the tracker. For 649 instance, a HAVE message generated by a peer B may be named as 650 "ccnx:/swarmID/peer/PEER_ID/HAVE", where "peer" is a keyword, 651 PEER_ID_B is the identifier of peer B and HAVE is a keyword. 653 5.2.1.3. Support of PPSP interaction through a pull-based 654 ICN API 656 The PPSP procedures are based both on pull and push interactions. 657 For instance, the distribution of chunks availability can be 658 classified as a push-based operation, since a peer sends an 659 "unsolicited" information (HAVE message) to neighboring peers. 660 Conversely the procedure used to receive video chunks can be 661 classified as pull-based, since it is supported by a 662 request/response interaction (i.e. REQUEST, DATA messages). 664 As we said, we refer to an ICN architecture which provides a pull- 665 based API. Accordingly, the mapping of PPSP pull-based procedure is 666 quite simple. For instance, using the CCN architecture [5] a PPSP 667 DATA message may be carried by a CCN Data message and a REQUEST 668 message can transferred by a CCN Interest. 670 Conversely, the support of push-based PPSP operations may be more 671 difficult. We need of an adaptation functionality that carries out a 672 push-based operation using the underlying pull-based service 673 primitives. For instance, a possible approach is to use the 674 request/response (i.e. Interest/Data) four ways handshakes proposed 675 in [7]. Another possibility is that receivers periodically send out 676 request messages of the named-data that neighbors will push and, 677 when available, sender inserts the pushed data within a response 678 message. 680 5.2.1.4. Abstract layering for PPSP over ICN 682 +-----------------------------------+ 683 | Application | 684 +-----------------------------------+ 685 | PPSP (TCP/IP) | 686 +-----------------------------------+ 687 | ICN - PPSP Adaptation Layer (AL) | 688 +-----------------------------------+ 689 | ICN Architecture | 690 +-----------------------------------+ 691 Figure 2: Mediator approach 693 Figure 2 provides a possible abstract layering for PPSP over ICN. 694 The Adaptation Layer acts as a mediator (proxy) between legacy PPSP 695 entities based on TCP/IP and the ICN architecture. In facts, the 696 role the mediator is to use ICN to transfer PPSP legacy messages. 698 This approach makes possible to merely reuse TCP/IP P2P applications 699 whose software includes also PPSP functionality. This "all-in-one" 700 development approach may be rather common since the PPSP-Application 701 interface is not going to be specified. Moreover, if the Operating 702 System will provide libraries that expose a PPSP API, these will be 703 initially based on a underlying TCP/IP API. Also in this case, the 704 mediator approach would make possible to easily reuse both the PPSP 705 libraries and the Application on top of an ICN. 707 +-----------------------------------+ 708 | Application | 709 +-----------------------------------+ 710 | ICN-PPSP | 711 +-----------------------------------+ 712 | ICN Architecture | 713 +-----------------------------------+ 715 Figure 3: Clean-slate approach 717 Figure 3 sketches a clean-slate layering approach in which the 718 application directly includes or interacts with a PPSP version based 719 on ICN. Likely such a PPSP_ICN integration could yield a simplier 720 development, also because it does not require implementing a TCP/IP 721 to ICN translation as in the Mediator approach. However, the clean- 722 slate approach requires developing the application (in case of 723 embedded PPSP functionality) or the PPSP library from scratch, 724 without exploiting what might already exist for TCP/IP. 726 Overall, the Mediator approach may be considered as the first step 727 of a migration path towards ICN native PPSP applications. 729 5.2.1.5. PPSP interaction with the ICN routing plane 731 Upon the ICN API a user (peer) requests a content and the ICN sends 732 it back. The content is gathered by the ICN from any source, which 733 could be the closest peer that disposes of the named-data item, an 734 in-network cache, etc. Actually, "where" to gather the content is 735 controlled by an underlying ICN routing plane, which sets up the ICN 736 forwarding tables (e.g. CCN FIB [5]). 738 A cross-layer interaction between the ICN routing plane and the PPSP 739 may be required to support a PPSP session. Indeed, ICN shall forward 740 request messages (e.g. CCN Interest) towards the proper peer that 741 can handle them. Depending on the layering approach, this cross- 742 layer interaction is controlled either by the Adaptation Layer or by 743 the ICN-PPSP. For example, if a peer A receives a HAVE message 744 indicating that peer B disposes of the video chunk named 745 "ccnx:/swarmID/chunk/chunkID", then former should insert in its ICN 746 forwarding table an entry for the prefix 747 "ccnx:/swarmID/chunk/chunkID" whose next hop locator (e.g. IP 748 address) is the network address of peer B [17]. 750 5.2.1.6. ICN deployment for PPSP 752 The ICN functionality that supports a PPSP session may be "isolated" 753 or "integrated" with the one of a public ICN. 755 In the isolated case, a PPSP session is supported by an instance of 756 an ICN (e.g. deployed on top of IP), whose functionalities operate 757 only on the limited set of nodes participating to the swarm, i.e. 758 peers and the tracker. This approach resembles the one followed by 759 current P2P application, which usually form an overlay network among 760 peers of a P2P application. And intermediate public IP routers do 761 not carry out P2P functionalities. 763 In the integrated case, the nodes of a public ICN may be involved in 764 the forwarding and in-network caching procedures. In doing so, the 765 swarm may benefit from the presence of in-network caches so limiting 766 uplink traffic on peers and inter-domain traffic too. These are 767 distinctive advantages of using PPSP over a public ICN, rather than 768 over TCP/IP. In addition, such advantages aren't likely manifested 769 in the case of isolated deployment. 771 However, the possible interaction between the PPSP and the routing 772 layer of a public ICN may be dramatic, both in terms of explosion of 773 the forwarding tables and in terms of security. These issues 774 specifically take place for those ICN architectures for which the 775 name resolution (i.e. name to next-hop) occurs en-route, like the 776 CCN architecture. 778 For instance, using the CCN architecture, to fetch a named-data item 779 offered by a peer A the on-path public ICN entities have to route 780 the request messages towards the peer A. This implies that the ICN 781 forwarding tables of public ICN nodes may contain many entries, e.g. 782 one entry per video chunk, and these entries are difficult to be 783 aggregated since peers avail sparse parts of a big content, whose 784 names have a same prefix (e.g. "ccnx:/swarmID"). Another possibility 785 is to wrap all PPSP messages into a located-named-data. In this case 786 the forwarding tables should contain "only" the PEER_ID prefixes 787 (e.g. "ccnx:/swarmID/peer/PEER_ID"), so scaling down the number of 788 entries from number of chunks to number of peers. However, in this 789 case the ICN mechanisms recognize a same video chunk offered by 790 different peers as different contents, so vanishing caching and 791 multicasting ICN benefits. Moreover, in any case routing entries 792 should be updated either the base of the availability of named-data 793 items on peers or on the presence of peers, and these events in a 794 P2P session is rapidly changing so possibly hampering the 795 convergence of the routing plane. Finally, since peers have an 796 impact on the ICN forwarding table of public nodes, this may open 797 obvious security issues. 799 5.2.2. 801 The introduction of video rate adaptation may valuably decrease the 802 effectiveness of P2P cooperation and of in-network caching, 803 depending of the kind of the video coding used by the MPEG DASH 804 stream. 806 In case of a MPEG DASH streaming with MPEG AVC encoding, a same 807 video chunk is independently encoded at different rates and the 808 encoding output is a different file for each rate. For instance, in 809 case of a video encoded at three different rates R1,R2,R3, for each 810 segment S we have three distinct files: S.R1, S.R2, S.R3. These 811 files are independent of each other. To fetch a segment coded at R2 812 kbps, a peer shall request the specific file S.R2. The estimation of 813 the best coding rate is usually handled by receiver-driven 814 algorithms, implemented by the video client. 816 The independence among files associated to different encoding rates 817 and the heterogeneity of peer bandwidths, may dramatically reduce 818 the interaction among peers, the effectiveness of in-network caching 819 (in case of integrated deployment), and consequently the ability of 820 PPSP to offload the video server (i.e. a seeder peer). Indeed, a 821 peer A may select a coding rate (e.g. R1) different from the one 822 selected by a peer B (e.g. R2) and this prevents the former to fetch 823 video chunks from the later, since peer B avails of chunks coded at 824 a rate different from the ones needed by A. To overcome this issue, 825 a common distributed rate selection algorithm could force peers to 826 select the same coding rate [17]; nevertheless this approach may be 827 not feasible in the in case of many peers. 829 The use of SVC encoding (Annex G extension of the H.264/MPEG-4 AVC 830 video compression standard) should make rate adaptation possible, 831 meanwhile neither reducing peer collaborations nor the in-network 832 caching effectiveness. For a single video chunk, a SVC encoder 833 produces different files for the different rates (roughly "layers"), 834 and these files are progressively related each other. Starting from 835 a base-layer which provides the minimum rate encoding, the next 836 rates are encoded as an "enhancement layer" of the previous one. For 837 instance, in case the video is coded with three rates R1 (base- 838 layer), R2 (enhancement-layer n.1), R3 (enhancement-layer n.2), then 839 for each DASH segment we have three files S.R1, S.R2 and S.R3. The 840 file S.R1 is the segment coded at the minimum rate (base-layer). The 841 file S.R2 enhances S.R1, so as S.R1 and S.R2 can be combined to 842 obtain a segment coded at rate R2. To get a segment coded at rate 843 R2, a peer shall fetch both S.R1 and S.R2. This progressive 844 dependence among files that encode a same segment at different rates 845 makes peer cooperation possible, also in case peers player have 846 autonomously selected different coding rates. For instance, if peer 847 A has selected the rate R1, the downloaded files S.R1 are useful 848 also for a peer B that has selected the rate R2, and vice versa. 850 5.3. IPTV and ICN 852 5.3.1. IPTV challenges 854 IPTV refers to the delivery of quality content broadcast over the 855 Internet, and is typically associated with strict quality 856 requirements, i.e., with a perceived latency of less than 500 ms and 857 a packet loss rate that is multiple orders lower than the current 858 loss rates experienced in the most commonly used access networks. We 859 can summarize the major challenges for the delivery of IPTV service 860 as follows. 862 Channel change latency represents a major concern for the IPTV 863 service. Perceived latency during channel change should be less than 864 500ms. To achieve this objective over the IP infrastructure, we have 865 multiple choices: 867 (i) receiving fast unicast streams from a dedicated server (most 868 effective but not resource efficient), 869 (ii) connecting to other peers in the network (efficiency depends 870 on peer support, effective and resource efficient, if also 871 supported with a dedicated server), 872 (iii) connecting to multiple multicast sessions at once (effective 873 but not resource efficient, and depends on the accuracy of 874 the prediction model used to track user activity). 876 The second major challenge is the error recovery. Typical IPTV 877 service requirements dictate the mean time between artifacts to be 878 approximately 2 hours. This suggests the perceived loss rate to be 879 around or less than 10^-7. Current IP-based solutions rely on the 880 following proactive and reactive recovery techniques: (i) joining 881 the FEC multicast stream corresponding to the perceived packet loss 882 rate (not efficient as the recovery strength is chosen based on 883 worst-case loss scenarios), (ii) making unicast recovery requests to 884 dedicated servers (requires active support from the service 885 provider), (iii) probing peers to acquire repair packets (finding 886 matching peers and enabling their cooperation is another challenge). 888 5.3.2. ICN benefits for IPTV delivery 890 ICN presents significant advantages for the delivery of IPTV 891 traffic. For instance, ICN inherently supports multicast and allows 892 for quick recovery from packet losses (with the help of in-network 893 caching). Similarly, peer support is also provided in the shape of 894 in-network caches that typically act as the middleman between two 895 peers, enabling therefore earlier access to IPTV content. 897 However, despite these advantages, delivery of IPTV service over 898 Information Centric Networks brings forth new challenges. We can 899 list some of these challenges as follows: 901 . Messaging overhead: ICN is a pull-based architecture and relies 902 on a unique balance between requests and responses. A user 903 needs to make a request for each data packet. In the case of 904 IPTV, with rates up to, and likely to be, above 15Mbps, we 905 observe significant traffic upstream to bring those streams. 907 As the number of streams increase (including the same session 908 at different quality levels), so as the burden on the routers. 909 Even if the majority of requests are aggregated at the core, 910 routers close to the edge (where we observe the biggest 911 divergence in user requests) will experience a significant 912 increase in overhead to process these requests. The same is 913 true at the user side, as the uplink usage multiplies in the 914 number of sessions a user requests (for instance, to minimize 915 the impact of bandwidth fluctuations). 916 . Cache control: As the IPTV content expires at a rapid rate 917 (with a likely expiry threshold of 1s), we need solutions to 918 effectively flush out such content to also prevent degradatory 919 impact on other cached content, with the help of intelligently 920 chosen naming conventions. However, to allow for fast recovery 921 and optimize access time to sessions (from current or new 922 users), the timing of such expirations needs to be adaptive to 923 network load and user demand. However, we also need to support 924 quick access to earlier content, whenever needed, for instance, 925 when the user accesses the rewind feature (note that in-network 926 caches will not be of significant help in such scenarios due to 927 overhead required to maintain such content). 928 . Access accuracy: To receive the up-to-date session data, users 929 need to be aware of such information at the time of their 930 request. Unlike IP multicast, since the users join a session 931 indirectly, session information is critical to minimize 932 buffering delays and reduce the startup latency. Without such 933 information, and without any active cooperation from the 934 intermediate routers, stale data can seriously undermine the 935 efficiency of content delivery. Furthermore, finding a cache 936 does not necessarily equate to joining a session, as the look- 937 ahead latency for the initial content access point may have a 938 shorter lifetime than originally intended. For instance, if the 939 user that has initiated the indirect multicast leaves the 940 session early, the requests from the remaining users need to 941 experience an additional latency of one RTT as they travel 942 towards the content source. If the startup latency is chosen 943 depending on the closeness to the intermediate router, going to 944 the content source in-session can lead to undesired pauses. 946 6. Future Steps for Video in ICN 948 The explosion of online video services, along with their increased 949 consumption by mobile wireless terminals, further exacerbates the 950 challenges of Video Adaptation leveraging ICN mechanisms. The 951 following sections present a series of research items derived from 952 these challenges, further introducing next steps for the subject. 954 6.1. Heterogeneous Wireless Environment Dynamics 956 With the ever-growing increase in online services being accessed by 957 mobile devices, operators have been deploying different overlapping 958 wireless access networking technologies. In this way, in the same 959 area, user terminals are within range of different cellular, Wi-Fi 960 or even WiMAX networks. Moreover, with the advent of the Internet of 961 Things (e.g., surveillance cameras feeding video footage), this list 962 can be further complemented with more specific short-range 963 technologies, such as Bluetooth or ZigBee. 965 In order to leverage from this plethora of connectivity 966 opportunities, user terminals are coming equipped with different 967 wireless access interfaces, providing them with extended 968 connectivity opportunities. In this way, such devices become able to 969 select the type of access which best suits them according to 970 different criteria, such as available bandwidth, battery 971 consumption, access do different link conditions according to the 972 user profile or even access to different content. Ultimately, these 973 aspects contribute to the Quality of Experience perceived by the 974 end-user, which is of utmost importance when it comes to video 975 content. 977 However, the fact that these users are mobile and using wireless 978 technologies, also provides a very dynamic setting, where the 979 current optimal link conditions at a specific moment might not last 980 or be maintained while the user moves. These aspects have been amply 981 analyzed in recently finished projects such as FP7 MEDIEVAL [18], 982 where link events reporting on wireless conditions and available 983 alternative connection points were combined with vide requirements 984 and traffic optimization mechanisms, towards the production of a 985 joint network and mobile terminal mobility management decision. 986 Concretely, in [19] link information about the deterioration of the 987 wireless signal was sent towards a mobility management controller in 988 the network. This input was combined with information about the user 989 profile, as well as of the current video service requirements, and 990 used to trigger the decrease or increase of scalable video layers, 991 adjusting the video to the ongoing link conditions. Incrementally, 992 the video could also be adjusted when a new better connectivity 993 opportunity presents itself. 995 In this way, regarding Video Adaptation, ICN mechanisms can leverage 996 from their intrinsic multiple source support capability and go 997 beyond the monitoring of the status of the current link, thus 998 exploiting the availability of different connectivity possibilities 999 (e.g., different "interfaces"). Moreover, information obtained from 1000 the mobile terminal's point of view of its network link, as well as 1001 information from the network itself (i.e., load, policies, and 1002 others), can generate scenarios where such information is combined 1003 in a joint optimization procedure allowing the content to be forward 1004 to users using the best available connectivity option (e.g., 1005 exploiting management capabilities supported by ICN intrinsic 1006 mechanisms as in [20]). 1008 In fact, ICN base mechanisms can further be exploited in enabling 1009 new deployment scenarios such as preparing the network for mass 1010 requests from users attending a large multimedia event (i.e., 1011 concert, sports), allowing video to be adapted according to content, 1012 user and network requirements and operation capabilities in a 1013 dynamic way. 1015 The enablement of such scenarios require further research, with the 1016 main points highlighted as follows: 1018 . Development of a generic video services (and obviously content) 1019 interface allowing the definition and mapping of their 1020 requirements (and characteristics) into the current capabilities 1021 of the network; 1023 . How to define a scalable mechanism allowing either the video 1024 application at the terminal, or some kind of network management 1025 entity, to adapt the video content in a dynamic way; 1027 . How to develop the previous research items using intrinsic ICN 1028 mechanisms (i.e., naming and strategy layers); 1030 . Leverage intelligent pre-caching of content to prevent stalls and 1031 poor quality phases, which lead to bad Quality of Experience of 1032 the user. This includes in particular the usage in mobile 1033 environments, which are characterized by severe bandwidth changes 1034 as well as connection outages, as shown in [21]. 1036 6.2. Digital Rights Management of Multimedia Content in ICN 1038 This subsection discusses the need for Digital Rights Management 1039 (DRM) functionalities for multimedia streaming over ICN. The 1040 discussion will show that Broadcast Encryption (BE) is a suitable 1041 basis for DRM functionalities in conformance to the ICN 1042 communication paradigm. Especially when network inherent caching is 1043 considered the advantage of BE will be highlighted. 1045 It is assumed that ICN will be used heavily for digital content 1046 dissemination. When digital content is distributed it is vital to 1047 consider DRM. In today's Internet there are two predominant classes 1048 of business models for on-demand video streaming. The first model is 1049 based on advertising revenues. Non copyright protected usually user- 1050 generated content (UGC) is offered by large infrastructure providers 1051 like Google (YouTube) at no charge. The infrastructure is financed 1052 by spliced advertisements into the content. In this context DRM 1053 considerations are usually not required, since producers of UGC just 1054 strive for the maximum possible dissemination. Producers of UGC are 1055 mainly interested to share content with their families, friends, 1056 colleges or others and have no intention to make profit. However, 1057 the second class of business models requires DRM, because they are 1058 primarily profit oriented. For example, large on-demand streaming 1059 platforms like Netflix establish business models based on 1060 subscriptions. Consumers have to pay a monthly fee in order to get 1061 access to copyright protected content like TV series, movies or 1062 music. From the perspective of the service providers and the 1063 copyright owners only clients that pay the fee should be able to 1064 access and consume the content. Anyway, the challenge is to find an 1065 efficient and scalable way of access control to digital content, 1066 which is distributed in information-centric networks. 1068 In ICN, data packets can be cached inherently in the network and any 1069 network participant can request a copy of these packets. This makes 1070 it very difficult to implement an access control for content that is 1071 distributed via ICN. A naive approach is to encrypt the transmitted 1072 data for each consumer with a distinct key. This hinders everyone 1073 else than the intended consumers to decrypt and consume the data. 1074 However, this approach is not suitable for ICN's communication 1075 paradigm since it would destruct any benefits gained from network 1076 inherent caching. Even if multiple consumers request the same 1077 content the requested data for each consumer would differ using this 1078 approach. A better but still insufficient idea is to use a single 1079 key for all consumers. This does not destruct the benefits of ICN's 1080 caching ability. Though, the drawback is that if one of the 1081 consumers illegally distributes the key the system is broken and any 1082 entity in the network can access the data. Changing the key after 1083 such an event is useless since the provider has no possibility to 1084 identify the illegal distributer. Therefore this person cannot be 1085 stopped from distributing the new key again. In addition to this 1086 issue other challenges have to be considered. Subscriptions expire 1087 after a certain time and then it has to be ensured that these 1088 consumers cannot access the content anymore. For a provider that 1089 daily serves millions of consumers (e.g. Netflix) there could be a 1090 significant number of expiring subscriptions a day. Publishing a new 1091 key every time a subscription expires would require an unsuitable 1092 amount of computational power just to re-encrypt the collection of 1093 audio-visual content. 1095 A possible approach to solve these challenges is Broadcast 1096 Encryption (BE) [BE] as proposed in [DAECC]. The ongoing discussion 1097 in this subsection will focus only on BE as an enabler for DRM 1098 functionality in the use case of ICN video streaming. This 1099 subsection continues with the explanation of how BE works and shows 1100 how BE can be used to implement an access control scheme in the 1101 context of content distribution in ICN. 1103 BE actually carries a misleading name. One might expect a concrete 1104 encryption scheme. However, it belongs to the family of key- 1105 management schemes (KMS). KMS are responsible for the generation, 1106 exchange, storage and replacement of cryptographic keys. The most 1107 interesting characteristics of Broadcast Encryption Schemes (BES) 1108 are: 1110 . A BES typically uses a global trusted entity called the 1111 licensing agent (LA), which is responsible for spreading a set 1112 of pre-generated secrets among all participants. Each 1113 participant gets a distinct subset of secrets assigned from the 1114 LA. 1115 . The participants can agree on a common session key, which is 1116 chosen by the LA. The LA broadcasts an encrypted message that 1117 includes the key. Participants with a valid set of secrets can 1118 derive the session-key from this message. 1119 . The number of participants in the system can change 1120 dynamically. Entities may join or leave the communication group 1121 at any time. If a new entity joins the LA passes on a valid set 1122 of secrets to that entity. If an entity leaves (or is forced to 1123 leave) the LA revokes the entity's subset of keys, which means 1124 that it cannot derive the correct session key anymore when a 1125 new key is distributed by the LA. 1126 . -Traitors (entities that reveal their secrets) can be traced 1127 and excluded from ongoing communication. The algorithms and 1128 preconditions to identify a traitor vary between concrete BES. 1130 This listing already illustrates why BE is suitable to control the 1131 access to data that is distributed via an information-centric 1132 network. BE enables the usage of a single session key for 1133 confidential data transmission between a dynamically changing subset 1134 or network participants. ICN caches can be utilized since the data 1135 is encrypted only with a single key known by all legitimate clients. 1136 Furthermore, traitors can be identified and removed from the system. 1137 The issue of re-encryption still exists, because the LA will 1138 eventually update the session key when a participant should be 1139 excluded. However, this disadvantage can be relaxed in some way if 1140 the following points are considered: 1142 . The updates of the session key can be delayed until a set of 1143 compromised secretes has been gathered. Note that secrets may 1144 become compromised because of two reasons. First, if the secret 1145 has been illegally revealed by a traitor. Second, if the 1146 subscription of an entity expires. Delayed revocation 1147 temporarily enables some non-legitimate entities to consume 1148 content. However, this should not be a severe problem in home 1149 entertainment scenarios. Updating the session key in regular 1150 (not too short) intervals is a good tradeoff. The longer the 1151 interval last the less computational resources are required for 1152 content re-encryption and the better the cache utilization in 1153 the ICN will be. To evict old data from ICN caches that has 1154 been encrypted with the prior session key the publisher could 1155 indicate a lifetime for transmitted packets. 1156 . Content should be re-encrypted dynamically at request time. 1157 This has the benefit that untapped content is not re-encrypted 1158 if the content is not requested during two session key updates 1159 and therefore no resources are wasted. Furthermore, if the 1160 updates are triggered in non-peak times the maximum amount of 1161 resource needed at one point in time can be lowered 1162 effectively, since in peak times generally more diverse content 1163 is requested. 1164 . Since the amount of required computational resources may vary 1165 strongly from time to time it would be beneficial for any 1166 streaming provider to use cloud-based services to be able to 1167 dynamically adapt the required resources to the current needs. 1168 Regarding to a lack of computation time or bandwidth the cloud 1169 service could be used to scale up to overcome shortages. 1171 Figure 4 show the potential usage of BE in a multimedia delivery 1172 frameworks that builds upon ICN infrastructure and uses the concept 1173 of dynamic adaptive streaming, e.g., DASH. BE would be implemented 1174 on the top to have an efficient and scalable way of access control 1175 to the multimedia content. 1177 +--------Multimedia Delivery Framework--------+ 1178 | | 1179 | Technologies Properties | 1180 | +----------------+ +----------------+ | 1181 | | Broadcast |<--->| Controlled | | 1182 | | Encryption | | Access | | 1183 | +----------------+ +----------------+ | 1184 | |Dynamic Adaptive|<--->| Multimedia | | 1185 | | Streaming | | Adaptation | | 1186 | +----------------+ +----------------+ | 1187 | | ICN |<--->| Cachable | | 1188 | | Infrastructure | | Data Chunks | | 1189 | +----------------+ +----------------+ | 1190 +---------------------------------------------+ 1192 Figure 4: A potential multimedia framework using BE. 1194 7. Security Considerations 1196 This is informational. Security considerations are TBD. 1198 8. IANA Considerations 1200 This is informational. IANA considerations are TBD. 1202 9. Conclusions 1204 This draft proposed adaptive video streaming for ICN, identified 1205 potential problems and presented the combination of CCN with DASH as 1206 a solution. As both concepts, DASH and CCN, maintain several 1207 elements in common, like, e.g., the content in different versions 1208 being dealt with in segments, combination of both technologies seems 1209 useful. Thus, adaptive streaming over CCN can leverage advantages 1210 such as, e.g., efficient caching and intrinsic multicast support of 1211 CCN, routing based on named data URIs, intrinsic multi-link and 1212 multi-source support, etc. 1214 In this context, the usage of CCN with DASH in mobile environments 1215 comes together with advantages compared to today's solutions, 1216 especially for devices equipped with multiple network interfaces. 1217 The retrieval of data over multiple links in parallel is a useful 1218 feature, specifically for adaptive multimedia streaming, since it 1219 offers the possibility to dynamically switch between the available 1220 links depending on their bandwidth capabilities, transparent to the 1221 actual DASH client. 1223 10. References 1225 10.1. Normative References 1227 [RFC6972] Y. Zhang, N. Zong, "Problem Statement and Requirements of 1228 the Peer-to-Peer Streaming Protocol (PPSP)", RFC6972, July 1229 2013 1231 10.2. Informative References 1233 [1] ISO/IEC DIS 23009-1.2, Information technology - Dynamic 1234 adaptive streaming over HTTP (DASH) - Part 1: Media 1235 presentation description and segment formats 1237 [2] Lederer, S., Mueller, C., Rainer, B., Timmerer, C., Hellwagner, 1238 H., "An Experimental Analysis of Dynamic Adaptive Streaming 1239 over HTTP in Content Centric Networks", in Proceedings of the 1240 IEEE International Conference on Multimedia and Expo 2013, San 1241 Jose, USA, July, 2013 1243 [3] Liu, Y., Geurts, J., Point, J., Lederer, S., Rainer, B., 1244 Mueller, C., Timmerer, C., Hellwagner, H., "Dynamic Adaptive 1245 Streaming over CCN: A Caching and Overhead Analysis", in 1246 Proceedings of the IEEE international Conference on 1247 Communication (ICC) 2013 - Next-Generation Networking 1248 Symposium, Budapest, Hungary, June, 2013 1250 [4] Grandl, R., Su, K., Westphal, C., "On the Interaction of 1251 Adaptive Video Streaming with Content-Centric Networks", 1252 eprint arXiv:1307.0794, July 2013. 1254 [5] V. Jacobson, D. Smetters, J. Thornton, M. Plass, N. Briggs and 1255 R. Braynard, "Networking named content", in Proc. of the 5th 1256 int. Conf. on Emerging Networking Experiments and Technologies 1257 (CoNEXT '09). ACM, New York, NY, USA, 2009, pp. 1-12. 1259 [6] A. Detti, M. Pomposini, N. Blefari-Melazzi, S. Salsano and A. 1260 Bragagnini, "Offloading cellular networks with Information- 1261 Centric Networking: The case of video streaming", In Proc. of 1262 the Int. Symp. on a World of Wireless, Mobile and Multimedia 1263 Networks (WoWMoM '12), IEEE, San Francisco, CA, USA, 1-3, 1264 2012. 1266 [7] V. Jacobson, D. K. Smetters, N. H. Briggs, M. F. Plass, P. 1267 Stewart, J. D. Thornton, and R. L. Braynard, "VoCCN: Voice 1268 over content-centric networks," in ACM ReArch Workshop, 2009 1270 [8] Christopher Mueller, Stefan Lederer and Christian Timmerer, A 1271 proxy effect analysis and fair adaptation algorithm for 1272 multiple competing dynamic adaptive streaming over HTTP 1273 clients, In Proceedings of the Conference on Visual 1274 Communications and Image Processing (VCIP) 2012, San Diego, 1275 USA, November 27-30, 2012. 1277 [9] DASH Research at the Institute of Information Technology, 1278 Multimedia Communication Group, Alpen-Adria University 1279 Klagenfurt, URL: http://dash.itec.aau.at 1281 [10] A. Detti, N. Blefari-Melazzi, S. Salsano, and M. Pomposini, 1282 "CONET: A content centric inter-networking architecture," 1283 in ACM Workshop on Information-Centric Networking (ICN), 1284 2011. 1286 [11] W. K. Chai, N. Wang, I. Psaras, G. Pavlou, C. Wang, G. C. de 1287 Blas, F. Ramon-Salguero, L. Liang, S. Spirou, A. Beben, 1288 and E. Hadjioannou, "CURLING: Content-ubiquitous 1289 resolution and delivery infrastructure for next-generation 1290 services," IEEE Communications Magazine, vol. 49, no. 3, 1291 pp. 112-120, March 2011 1293 [12] NetInf project Website http://www.netinf.org 1295 [13] N. Magharei, R. Rejaie, Yang Guo, "Mesh or Multiple-Tree: A 1296 Comparative Study of Live P2P Streaming Approaches," 1297 INFOCOM 2007. 26th IEEE International Conference on 1298 Computer Communications. IEEE , vol., no., pp.1424,1432, 1299 6-12 May 2007 1301 [14] PPSP WG Website https://datatracker.ietf.org/wg/ppsp/ 1303 [15] A. Bakker, R. Petrocco, V. Grishchenko, "Peer-to-Peer Streaming 1304 Peer Protocol (PPSPP)", draft-ietf-ppsp-peer-protocol-08 1306 [16] Rui S. Cruz, Mario S. Nunes, Yingjie Gu, Jinwei Xia, Joao P. 1307 Taveira, Deng Lingli, "PPSP Tracker Protocol-Base Protocol 1308 (PPSP-TP/1.0)", draft-ietf-ppsp-base-tracker-protocol-02 1310 [17] A.Detti, B. Ricci, N. Blefari-Melazzi,"Peer-To-Peer Live 1311 Adaptive Video Streaming for Information Centric Cellular 1312 Networks", IEEE PIMRC 2013,London, UK, 8-11 September 2013 1314 [18] http://www.ict-medieval.eu 1316 [19] B. Fu, G. Kunzmann, M. Wetterwald, D. Corujo, R. Costa, "QoE- 1317 aware Traffic Management for Mobile Video Delivery", Proc. 2013 1318 IEEE ICC, Workshop on Immersive & Interactive Multimedia 1319 Communications over the Future Internet (IIMC), Budapest, 1320 Hungary, Jun 2013. 1322 [20] Daniel Corujo, Ivan Vidal, Jaime Garcia-Reinoso, Rui L. Aguiar, 1323 "A Named Data Networking Flexible Framework for Management 1324 Communications", IEEE Communications Magazine, Vol. 50, no. 12, 1325 pp. 36-43, Dec 2012 1327 [21] Barry Crabtree, Tim Stevens, Brahin Allan, Stefan Lederer, 1328 Daniel Posch, Christopher Mueller, Christian Timmerer, Video 1329 Adaptation in Limited or Zero Network Coverage, CCNxConn 1330 2013,PARC, Palo Alto, pp. 1-2, 2013 1332 [22] Fiat, A., Naor, M., "Broadcast Encryption", in Advances in 1333 Cryptology (Crypto'93), volume 773 of Lecture Notes in Computer 1334 Science, pages 480-491. Springer Berlin / Heidelberg, 1994. 1336 [23] Posch, D., Hellwagner, H., Schartner, P., "On-Demand Video 1337 Streaming based on Dynamic Adaptive Encrypted Content Chunks", th in Proceedings of the 8 International Workshop on Secure 1338 Network Protocols (NPSec' 13), Los Alamitos, IEEE Computer 1339 Society Press, October, 2013. 1341 11. Authors' Addresses 1343 Stefan Lederer, Christian Timmerer, Daniel Posch 1344 Alpen-Adria University Klagenfurt 1345 Universitaetsstrasse 65-67, 9020 Klagenfurt, Austria 1347 Email: {firstname.lastname}@itec.aau.at 1349 Cedric Westphal, Aytac Azgin 1350 Huawei 1351 2330 Central Expressway, Santa Clara, CA95050, USA 1353 Email: {first.last}@huawei.com 1355 Christopher Mueller 1356 bitmovin GmbH 1357 Lakeside B01, 9020 Klagenfurt, Austria 1359 Email: christopher.mueller@bitmovin.net 1360 Andrea Detti 1361 Electronic Engineering Dept. 1362 University of Rome Tor Vergata 1363 Via del Politecnico 1, Rome, Italy 1365 Email: andrea.detti@uniroma2.it 1367 Daniel Corujo, 1368 Advanced Telecommunications and Networks Group 1369 Instituto de Telecomunicaes 1370 Campus Universitario de Santiago 1371 P-3810-193 Aveiro, Portugal 1373 Email: dcorujo@av.it.pt 1375 12. Acknowledgements 1377 This work was supported in part by the EC in the context of the 1378 SocialSensor (FP7-ICT-287975) project and partly performed in the 1379 Lakeside Labs research cluster at AAU. SocialSensor receives 1380 research funding from the European Community's Seventh Framework 1381 Programme. The work for this document was also partially performed 1382 in the context of the FP7/NICT EU-JAPAN GreenICN project, 1383 http://www.greenicn.org. Apart from this, the European Commission 1384 has no responsibility for the content of this draft. The information 1385 in this document is provided as is and no guarantee or warranty is 1386 given that the information is fit for any particular purpose. The 1387 user thereof uses the information at its sole risk and liability.