Internet Research Task Force (IRTF) C. Westphal, Ed. Request for Comments: 7933 Huawei Category: Informational S. Lederer ISSN: 2070-1721 D. Posch C. Timmerer Alpen-Adria University Klagenfurt A. Azgin W. Liu Huawei C. Mueller BitMovin A. Detti University of Rome Tor Vergata D. Corujo Instituto de Telecomunicacoes Aveiro J. Wang City University of Hong Kong M. Montpetit MIT N. Murray Athlone Institute of Technology August 2016 Adaptive Video Streaming over Information-Centric Networking (ICN)
AbstractThis document considers the consequences of moving the underlying network architecture from the current Internet to an Information- Centric Networking (ICN) architecture on video distribution. As most of the traffic in future networks is expected to be video, we consider how to modify the existing video streaming mechanisms. Several important topics related to video distribution over ICN are presented. The wide range of scenarios covered includes the following: evolving Dynamic Adaptive Streaming over HTTP (DASH) to work over ICN and leverage the recent ISO/IEC Moving Picture Experts Group (MPEG) standard, layering encoding over ICN, introducing distinct requirements for video using Peer-to-Peer (P2P) mechanisms, adapting the Peer-to-Peer Streaming Protocol (PPSP) for ICN, creating more stringent requirements over ICN because of delay constraints added by Internet Protocol Television (IPTV), and managing digital rights in ICN. Finally, in addition to considering how existing mechanisms would be impacted by ICN, this document lists some research issues to design ICN-specific video streaming mechanisms.
Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Information- Centric Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7933. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Use Case Scenarios for ICN and Video Streaming . . . . . . . 5 4. Video Download . . . . . . . . . . . . . . . . . . . . . . . 6 5. Video Streaming and ICN . . . . . . . . . . . . . . . . . . . 7 5.1. Introduction to Client-Driven Streaming and DASH . . . . 7 5.2. Layered Encoding . . . . . . . . . . . . . . . . . . . . 8 5.3. Interactions of Video Streaming with ICN . . . . . . . . 8 5.3.1. Interactions of DASH with ICN . . . . . . . . . . . . 8 5.3.2. Interaction of ICN with Layered Encoding . . . . . . 10 5.4. Possible Integration of Video Streaming and ICN Architecture . . . . . . . . . . . . . . . . . . . . . . 11 5.4.1. DASH over CCN . . . . . . . . . . . . . . . . . . . . 11 5.4.2. Testbed, Open-Source Tools, and Dataset . . . . . . . 13
6. P2P Video Distribution and ICN . . . . . . . . . . . . . . . 14 6.1. Introduction to PPSP . . . . . . . . . . . . . . . . . . 14 6.2. PPSP over ICN: Deployment Concepts . . . . . . . . . . . 16 6.2.1. PPSP Short Background . . . . . . . . . . . . . . . . 16 6.2.2. From PPSP Messages to ICN Named-Data . . . . . . . . 16 6.2.3. Support of PPSP Interaction through a Pull-Based ICN API . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.2.4. Abstract Layering for PPSP over ICN . . . . . . . . . 18 6.2.5. PPSP Interaction with the ICN Routing Plane . . . . . 19 6.2.6. ICN Deployment for PPSP . . . . . . . . . . . . . . . 19 6.3. Impact of MPEG-DASH Coding Schemes . . . . . . . . . . . 20 7. IPTV and ICN . . . . . . . . . . . . . . . . . . . . . . . . 21 7.1. IPTV Challenges . . . . . . . . . . . . . . . . . . . . . 21 7.2. ICN Benefits for IPTV Delivery . . . . . . . . . . . . . 22 8. Digital Rights Management in ICN . . . . . . . . . . . . . . 24 8.1. Broadcast Encryption for DRM in ICN . . . . . . . . . . . 24 8.2. AAA-Based DRM for ICN Networks . . . . . . . . . . . . . 27 8.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 27 8.2.2. Implementation . . . . . . . . . . . . . . . . . . . 28 9. Future Steps for Video in ICN . . . . . . . . . . . . . . . . 28 9.1. Large-Scale Live Events . . . . . . . . . . . . . . . . . 29 9.2. Video Conferencing and Real-Time Communications . . . . . 29 9.3. Store-and-Forward Optimized Rate Adaptation . . . . . . 29 9.4. Heterogeneous Wireless Environment Dynamics . . . . . . 30 9.5. Network Coding for Video Distribution in ICN . . . . . . 32 9.6. Synchronization Issues for Video Distribution in ICN . . 32 10. Security Considerations . . . . . . . . . . . . . . . . . . 33 11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 33 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 12.1. Normative References . . . . . . . . . . . . . . . . . . 34 12.2. Informative References . . . . . . . . . . . . . . . . . 34 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
Lederer13b] [Lederer13a] [Grandl13] [Detti12]. This document is informed by these works, as well as others. In this document, we give a brief overview of the existing solutions for the selected scenarios. We then examine the interactions of such existing mechanisms with the ICN architecture and list some of the interactions any video streaming mechanism will have to consider. Finally, we identify some areas for future research.
RFC7476]. For our purpose, we assume here that "ICN" refers to an architecture where content is retrieved by name and with no binding of content to a specific network location. Both live and on-demand consumption of multimedia content come with timing requirements for the delivery of the content. Additionally, real-time use cases (such as audio-video conferencing [Jacobson09a], game streaming, etc.) come with stricter timing requirements. Long startup delays, buffering periods, poor video quality, etc., should be avoided to achieve a better Quality of Experience (QoE) for the consumer of the content. For a definition of QoE in the context of video distribution, please refer to [LeCallet13]. The working definition is as follows: Quality of Experience (QoE) is the degree of delight or annoyance of the user of an application or service. It results from the fulfillment of his or her expectations with respect to the utility and/or enjoyment of the application or service in the light of the user's personality and current state. Of course, these requirements are heavily influenced by routing decisions and caching, which are central parts of ICN and that have to be considered when streaming video in such infrastructures. Due to this range of requirements, we find it useful to narrow the focus to four scenarios (more can be included later): o a video download architecture similar to that of Apple iTunes, where the whole file is being downloaded to the client and can be replayed there multiple times; o a video streaming architecture for playing back movies, which is relevant for the naming and caching aspects of ICN as well as the interaction with the rate adaptation mechanism necessary to deliver the best QoE to the end user; o a P2P architecture for sharing videos, which introduces more stringent routing requirements in terms of locating copies of the content as the location of the peers evolves and peers join and leave the swarm they use to exchange video chunks (for P2P definitions and taxonomy, please refer to RFC 5694; and o IPTV, which introduces requirements for multicasting and adds stronger delay constraints.
Other scenarios, such as video conferencing and real-time video communications, are not explicitly discussed in this document even though they are in scope. Also, events of mass-media distribution, such as a large crowd at a live event, add new requirements to be included in later versions. The current state-of-the-art protocols in an IP context can be modified for the ICN architecture. The remainder of this document is organized as follows: Section 4 discusses video download; Section 5 briefly describes DASH [ISO-DASH] and Layered Encoding (Modification Detection Code (MDC), Scalable Video Coding (SVC)); Section 6 focuses on P2P and PPSP; Section 7 highlights the requirements of IPTV; Section 8 describes the issues of DRM; and Section 9 lists some research issues to be solved for ICN-specific video delivery mechanisms. Video-conferencing and real-time-video communications will be described in further detail in future works. Mass distribution of content at live, large-scale events (stadiums, concert halls, etc.) for which there is no clearly adopted existing protocol is another topic for further research.
ISO-DASH] is to use segments of media content, which can be encoded at different resolutions, bit rates, etc., as so-called representations. These segments are served by conventional HTTP web servers and can be addressed via HTTP GET requests from the client. As a consequence, the streaming system is pull-based and the entire streaming logic is located on the client, which makes it scalable and allows for adaptation of the media stream to the client's capabilities. In addition to this, the content can be distributed using conventional CDNs and their HTTP infrastructure, which also scales very well. In order to specify the relationship between the contents' media segments and the associated bit rate, resolution, and
timeline, the Media Presentation Description (MPD) is used, which is an XML document. The MPD refers to the available media segments using HTTP URLs, which can be used by the client for retrieving them. ISO-DASH] have several elements in common: o the client-initiated pull approach; o the content being dealt with in pieces (or chunks); o the support of efficient replication and distribution of content pieces within the network; o the scalable, session-free nature of the exchange between the client and the server at the streaming layer: the client is free to request any chunk from any location; and o the support for potentially multiple source locations. For the last point, DASH may list multiple source URLs in a manifest, and ICN is agnostic to the location of a copy it is receiving. We do not imply that current video streaming mechanisms attempt to draw the
content from multiple sources concurrently. This is a potential benefit of ICN but is not considered in the current approaches mentioned in this document. As ICN is a promising candidate for the Future Internet (FI) architecture, it is useful to investigate its suitability in combination with multimedia streaming standards like MPEG-DASH. In this context, the purpose of this section is to present the usage of ICN instead of HTTP in MPEG-DASH. However, there are some issues that arise from using a dynamic rate adaptation mechanism in an ICN architecture (note that some of the issues are related to caching and are not necessarily unique to ICN): o Naming of the data in DASH does not necessarily follow the ICN convention of any of the ICN proposals. Several chunks of the same video stream might currently go by different names that, for instance, do not share a common prefix. There is a need to harmonize the naming of the chunks in DASH with the naming conventions of the ICN. The naming convention of using a filename/time/encoding format could, for instance, be made compatible with the convention of CCN. o While chunks can be retrieved from any server, the rate adaptation mechanism attempts to estimate the available network bandwidth so as to select the proper playback rate and keep its playback buffer at the proper level. Therefore, there is a need to either include some location semantics in the data chunks so as to properly assess the throughput to a specific location or to design a different mechanism to evaluate the available network bandwidth. o The typical issue of access control and accounting happens in this context, where chunks can be cached in the network outside of the administrative control of the content publisher. It might be a requirement from the owner of the video stream that access to these data chunks needs to be accounted/billed/monitored. o Dynamic streaming multiplies the representations of a given video stream, therefore diminishing the effectiveness of caching: namely, to get a hit for a chunk in the cache, it has to be for the same format and encoding values. Alternatively, to get the same hit rate as a stream using a single encoding, the cache size must be scaled up to include all the possible representations. o Caching introduces oscillatory dynamics as it may modify the estimation of the available bandwidth between the end user and the repository from which it is getting the chunks. For instance, if an edge cache holds a low resolution representation near the user,
the user getting these low resolution chunks will observe a good performance and will then request higher resolution chunks. If those are hosted on a server with poor performance, then the client would have to switch back to the low representation. This oscillation may be detrimental to the perceived QoE of the user. o The ICN transport mechanism needs to be compatible to some extent with DASH. To take a CCN example, the rate at which interests are issued should be such that the chunks received in return arrive fast enough and with the proper encoding to keep the playback buffer above some threshold. o The usage of multiple network interfaces is possible in ICN, enabling a seamless handover between them. For the combination with DASH, an intelligent strategy that should focus on traffic load-balancing between the available links may be necessary. This would increase the effective media throughput of DASH by leveraging the combined available bandwidth of all links; however, it could potentially lead to high variations of the media throughput. o DASH does not define how the MPD is retrieved; hence, this is compatible with CCN. However, the current profiles defined within MPEG-DASH require the MPD to contain HTTP URLs (including HTTP and HTTPS URI schemes) to identify segments. To enable a more integrated approach as described in this document, an additional profile for DASH over CCN has to be defined, enabling ICN/CCN- based URIs to identify and request the media segments. We describe in Section 5.4 a potential implementation of a dynamic adaptive video stream over ICN, based upon DASH and CCN [Jacobson09b].
audio stream) and inter-stream synchronization (see Section 9 for other synchronization aspects to be included in the "Future Steps for Video in ICN"); and o Naming of the different layers: when the client requests an object, the request can be satisfied with the base layer alone, aggregated with enhancement layers. Should one request be sufficient to provide different streams? In a CCN architecture, for instance, this would violate a "one Interest, one Data packet" principle and the client would need to specify each layer it would like to receive. In a Pub/Sub architecture, the Rendezvous Point would have to make a decision as to which layers (or which pointer to which layer's location) to return. Detti12], and the DASH client implementing a native CCN interface. The former transforms an HTTP request to a corresponding Interest packet as well as a Data packet back to an HTTP response, including reliable transport as offered by TCP. This may be a good compromise to implement CCN in a managed network and to support legacy devices. Since such a proxy is already described in [Detti12], this document
focuses on a more integrated approach, aiming at fully exploiting the potential of a CCN DASH client. That is, we describe a native CCN interface within the DASH client, which adopts a CCN naming scheme (CCN URIs) to denote segments in the MPD. In this architecture, only the network access component on the client has to be modified and the segment URIs within MPD have to be updated according to the CCN naming scheme. Initially, the DASH client retrieves the MPD containing the CCN URIs of the content representations including the media segments. The naming scheme of the segments may reflect intrinsic features of CCN like versioning and segmentation support. Such segmentation support is already compulsory for multimedia streaming in CCN; thus, it can also be leveraged for DASH-based streaming over CCN. The CCN versioning can be adopted in a further step to signal different representations of the DASH-based content, which enables an implicit adaptation of the requested content to the clients' bandwidth conditions. That is, the Interest packet already provides the desired characteristics of a segment (such as bit rate, resolution, etc.) within the content name (or potentially within parameters defined as extra types in the packet formats). Additionally, if bandwidth conditions of the corresponding interfaces or routing paths allow so, DASH media segments could be aggregated automatically by the CCN nodes, which reduces the amount of Interest packets needed to request the content. However, such approaches need further research, specifically in terms of additional intelligence and processing power needed at the CCN nodes. After requesting the MPD, the DASH client will start to request particular segments. Therefore, CCN Interest packets are generated by the CCN access component and forwarded to the available interfaces. Within the CCN, these Interest packets leverage the efficient interest aggregation for, e.g., popular content, as well as the implicit multicast support. Finally, the Interest packets are satisfied by the corresponding Data packets containing the video segment data, which are stored on the origin server or any CCN node, respectively. With an increasing popularity of the content, it will be distributed across the network resulting in lower transmission delays and reduced bandwidth requirements for origin servers and content providers, respectively. With the extensive usage of in-network caching, new drawbacks are introduced since the streaming logic is located at the client, i.e., clients are not aware of each other and the network infrastructure and cache states. Furthermore, negative effects are introduced when multiple clients compete in a bottleneck and when caching influences this bandwidth competition. As mentioned above, the clients request individual portions of the content based on available bandwidth,
which is calculated using throughput estimations. This uncontrolled distribution of the content influences the adaptation process of adaptive streaming clients. The impact of this falsified throughput estimation could be tremendous and leads to a wrong adaptation decision that may impact the QoE at the client, as shown in [Mueller12]. In ICN, the client does not have the knowledge from which source the requested content is actually served or how many origin servers of the content are available, as this is transparent and depends on the name-based routing. This introduces the challenge that the adaptation logic of the adaptive streaming client is not aware of the event when the ICN routing decides to switch to a different origin server or content is coming through a different link/interface. As most algorithms implementing the adaption logic use bandwidth measurements and related heuristics, the adaptation decisions are no longer valid when changing origin servers (or links), and these decisions potentially cause playback interruptions and, consequently, stalling. Additionally, ICN supports the usage of multiple interfaces. A seamless handover between these interfaces (and different sources for the content) comes together with changes in performance, e.g., due to switching between fixed and wireless, 3G/4G and Wi-Fi networks, different types of servers (say with/ without Shared Secret Data (SSD) or hardware acceleration), etc. Considering these characteristics of ICN, adaptation algorithms merely based on bandwidth measurements are not appropriate anymore, as potentially each segment can be transferred from another ICN node or interface, all with different bandwidth conditions. Thus, adaptation algorithms taking into account these intrinsic characteristics of ICN are preferred over algorithms based on mere bandwidth measurements. ITEC-DASH]. In particular, it provides two client-player implementations, (i) a libdash extension for DASH over CCN and (ii) a VLC plugin implementing DASH over CCN. For both implementations, the CCNx implementation has been used as a basis. The general architecture of libdash is organized in modules so that the library implements a MPD parser and an extensible connection manager. The library provides object-oriented interfaces for these modules to access the MPD and the downloadable segments. These components are extended to support DASH over CCN and are located in a separate development branch of the GitHub project available at <http://www.github.com/bitmovin/libdash>. libdash comes together with a fully featured DASH player with a QT-based front end, demonstrating
the usage of libdash and providing a scientific evaluation platform. As an alternative, patches for the DASH plugin of the VLC player are provided. These patches can be applied to the latest source code checkout of VLC resulting in a DASH-over-CCN-enabled VLC player. Finally, a DASH-over-CCN dataset is provided in the form of a CCNx repository. It includes 15 different quality representation of the well-known Big Buck Bunny Movie, ranging from 100 kbps to 4500 kbps. The content is split into segments of two seconds and is described by an associated MPD using the presented naming scheme in Section 5.1. This repository can be downloaded from [ITEC-DASH] and is also provided by a publicly accessible CCNx node. Associated routing commands for the CCNx namespaces of the content are provided via scripts coming together with the dataset and can be used as a public testbed. Castro03]. Using a progressive encoding (e.g., Multiple Description Coding or H.264 Scalable Video Coding), multiple trees could be set up to support video rate adaptation. On each tree, an enhancement stream is sent. The higher the number of received streams, the higher the video quality. A peer controls the video rate by either fetching or not fetching the streams delivered over the distribution trees. The Pull/Mesh-based solution is inspired by the BitTorrent file sharing mechanism. A tracker collects information about the state of the swarm (i.e., the set of participating peers). A peer forms a mesh overlay network with a subset of peers and exchanges data with them. A peer announces what data items it disposes and requests missing data items that are announced by connected peers. In case of
live streaming, the involved data set includes only a recent window of data items published by the source. Also, in this case, the use of a progressive encoding can be exploited for video rate adaptation. Pull/Mesh-based P2PVS solutions are the more promising candidate for the ICN deployment, since most of ICN approach provides a pull-based API [Jacobson09b] [Detti11] [Chai11] [NETINF]. In addition, Pull/Mesh-based P2PVS are more robust than the Push/Tree-based one [Magharei07], and the PPSP working group [IETF-PPSP] is also proposing a Pull/Mesh-based solution. +------------------------------------------------+ | | | +--------------------------------+ | | | Tracker | | | +--------------------------------+ | | | ^ ^ | |Tracker | | Tracker |Tracker | |Protocol| | Protocol |Protocol | | | | | | | V | | | | +---------+ Peer +---------+ | | | Peer |<----------->| Peer | | | +---------+ Protocol +---------+ | | | ^ | | | |Peer | | | |Protocol | | V | | | +---------------+ | | | Peer | | | +---------------+ | | | +------------------------------------------------+ Figure 1: PPSP System Architecture [RFC6972] Figure 1 reports the PPSP architecture presented in [RFC6972]. PEERs announce and share video chunks and a TRACKER maintains a list of PEERs participating in a specific audio-video channel or in the distribution of a streaming file. The TRACKER functionality may be centralized in a server or distributed over the PEERs. PPSP standardizes the peer and Tracker Protocols, which can run directly over UDP or TCP. This document discusses some preliminary concepts about the deployment of PPSP on top of an ICN that exposes a pull-based API, meanwhile considering the impact of MPEG-DASH streaming format.
Bakker15] and the Peer-to-Peer Streaming Tracker Protocol (PPSP-TP) is defined in [RFC7846]. Some of the operations carried out by the Tracker Protocol are the following: when a peer wishes to join the streaming session, it contacts the tracker (CONNECT message), obtains a PEER_ID and a list of PEER_IDs (and IP addresses) of other peers that are participating to the SWARM and that the tracker has singled out for the requesting peer (this may be a subset of the all peers of the SWARM); in addition to this join operation, a peer may contact the tracker to request to renew the list of participating peers (FIND message), to periodically update its status to the tracker (STAT_REPORT message), and so on. Some of the operations carried out by the Peer Protocol include the following: using the list of peers delivered by the tracker, a peer establishes a session with them (HANDSHAKE message); a peer periodically announces to neighboring peers which chunks it has available for download (HAVE message); using these announcements, a peer requests missing chunks from neighboring peers (REQUEST messages), which will be sent back to them (DATA message).
The naming scheme differentiates named-data and located-named-data items. In the case of named-data, the naming scheme only includes a content identifier (e.g., the name of the video chunk) without any prefix identifying who provides the content. For instance, a DATA message containing the video chunk "#1" may be named as "ccnx:/swarmID/chunk/chunkID", where swarmID is a unique identifier of the streaming session, "chunk" is a keyword, and chunkID is the chunk identifier (e.g., an integer number). In case of located-named-data, the naming scheme includes a location- prefix, which uniquely identifies the host generating the data item. This prefix may be the PEER_ID in case the host was a peer or a tracker identifier in case the host was the tracker. For instance, a HAVE message generated by a Peer B may be named as "ccnx:/swarmID/peer/PEER_ID/HAVE", where "peer" is a keyword, PEER_ID_B is the identifier of Peer B, and HAVE is a keyword. Jacobson09b], a PPSP DATA message may be carried by a CCN DATA message and a REQUEST message can be transferred by a CCN Interest. Conversely, the support of push-based PPSP operations may be more difficult. We need an adaptation functionality that carries out a push-based operation using the underlying pull-based service primitives. For instance, a possible approach is to use the request/ response (i.e., Interest/Data) four-way handshakes proposed in [Jacobson09a]. Another possibility is that receivers periodically send out request messages of the named-data that neighbors will push and, when available, the sender inserts the pushed data within a response message.
+-----------------------------------+ | Application | +-----------------------------------+ | PPSP (TCP/IP) | +-----------------------------------+ | ICN - PPSP Adaptation Layer (AL) | +-----------------------------------+ | ICN Architecture | +-----------------------------------+ Figure 2: Mediator Approach Figure 2 provides a possible abstract layering for PPSP over ICN. The Adaptation Layer acts as a mediator (proxy) between legacy PPSP entities based on TCP/IP and the ICN architecture. In fact, the role the mediator is to use ICN to transfer PPSP legacy messages. This approach makes it possible to merely reuse TCP/IP P2P applications whose software includes also PPSP functionality. This "all-in-one" development approach may be rather common since the PPSP application interface is not going to be specified. Moreover, if the operating system will provide libraries that expose a PPSP API, these will be initially based on an underlying TCP/IP API. Also, in this case, the mediator approach would make it possible to easily reuse both the PPSP libraries and the Application on top of an ICN. +-----------------------------------+ | Application | +-----------------------------------+ | ICN-PPSP | +-----------------------------------+ | ICN Architecture | +-----------------------------------+ Figure 3: Clean-Slate Approach Figure 3 sketches a clean-slate layering approach in which the application directly includes or interacts with a PPSP version based on ICN. It's likely such a PPSP_ICN integration could yield a simpler development also because it does not require implementing a TCP/IP to ICN translation as in the Mediator approach. However, the clean-slate approach requires developing the application (in case of embedded PPSP functionality) or the PPSP library from scratch without exploiting what might already exist for TCP/IP.
Overall, the Mediator approach may be considered the first step of a migration path towards ICN-native PPSP applications. Jacobson09b]). A cross-layer interaction between the ICN routing plane and the PPSP may be required to support a PPSP session. Indeed, ICN shall forward request messages (e.g., CCN Interest) towards the proper peer that can handle them. Depending on the layering approach, this cross- layer interaction is controlled either by the Adaptation Layer or by the ICN-PPSP. For example, if a Peer A receives a HAVE message indicating that Peer B disposes of the video chunk named "ccnx:/swarmID/chunk/chunkID", then the former should insert in its ICN forwarding table an entry for the prefix "ccnx:/swarmID/chunk/ chunkID" whose next hop locator (e.g., IP address) is the network address of Peer B [Detti13].
specifically take place for those ICN architectures for which the name resolution (i.e., name to next hop) occurs en route, like the CCN architecture. For instance, using the CCN architecture, to fetch a named-data item offered by a Peer A the on-path public ICN entities have to route the request messages towards the Peer A. This implies that the ICN forwarding tables of public ICN nodes may contain many entries, e.g., one entry per video chunk, and these entries are difficult to be aggregated since peers may have available only sparse parts of a big content, whose names have a same prefix (e.g., "ccnx:/swarmID"). Another possibility is to wrap all PPSP messages into a located- named-data. In this case, the forwarding tables should contain "only" the PEER_ID prefixes (e.g., "ccnx:/swarmID/peer/PEER_ID"), thus scaling down the number of entries from number of chunks to number of peers. However, in this case, the ICN mechanisms recognize the same video chunk offered by different peers as different content, thus losing caching and multicasting ICN benefits. In any case, routing entries should be updated either on the basis of the availability of named-data items on peers or on the presence of peers, and these events in a P2P session are rapidly changing and possibly hampering the convergence of the routing plane. Finally, since peers have an impact on the ICN forwarding table of public nodes, this may open obvious security issues.
by a Peer B (e.g., R2), and this prevents the former from fetching video chunks from the latter since Peer B only has chunks available that are coded at a rate different from the ones needed by Peer A. To overcome this issue, a common distributed rate selection algorithm could force peers to select the same coding rate [Detti13]; nevertheless, this approach may be not feasible in the case of many peers. The use of an SVC encoding (Annex G extension of the H.264/MPEG-4 Advanced Video Coding (AVC) video compression standard) should make rate adaptation possible while neither reducing peer collaborations nor the in-network caching effectiveness. For a single video chunk, an SVC encoder produces different files for the different rates (roughly "layers"), and these files are progressively related to each other. Starting from a base layer that provides the minimum rate encoding, the next rates are encoded as an "enhancement layer" of the previous one. For instance, in case the video is coded with three rates, R1 (base layer), R2 (enhancement layer n.1), and R3 (enhancement layer n.2), then for each DASH segment, we have three files: S.R1, S.R2, and S.R3. The file S.R1 is the segment coded at the minimum rate (base layer). The file S.R2 enhances S.R1, so S.R1 and S.R2 can be combined to obtain a segment coded at rate R2. To get a segment coded at rate R2, a peer shall fetch both S.R1 and S.R2. This progressive dependence among files that encode the same segment at different rates makes peer cooperation possible, also in case peers player have autonomously selected different coding rates. For instance, if Peer A has selected the rate R1, the downloaded files S.R1 are useful also for a Peer B that has selected the rate R2, and vice versa.