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