tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7933

Informational
Pages: 40
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: IRTF

Adaptive Video Streaming over Information-Centric Networking (ICN)

Part 1 of 2, p. 1 to 21
None       Next Section

 


Top       ToC       Page 1 
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)

Abstract

   This 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.

[Page 2] 
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.

Table of Contents

   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

Top      ToC       Page 3 
   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

Top      ToC       Page 4 
1.  Introduction

   The unprecedented growth of video traffic has triggered a rethinking
   of how content is distributed, both in terms of the underlying
   Internet architecture and in terms of the streaming mechanisms to
   deliver video objects.

   In particular, the IRTF ICNRG research group has been chartered to
   study new architectures centered upon information; the main
   contributor to Internet traffic (and information dissemination) is
   video, and this is expected to stay the same in the near future.  If
   ICN is expected to become prominent, it will have to support video
   streaming efficiently.

   As such, it is necessary to discuss going in two separate directions:

      Can the current video streaming mechanisms be leveraged and
      adapted to an ICN architecture?

      Can (and should) new, ICN-specific video streaming mechanisms be
      designed to fully take advantage of the new abstractions exposed
      by the ICN architecture?

   This document focuses on the first question in an attempt to define
   the use cases for video streaming and some requirements.  It also
   focuses on a few scenarios (namely, Netflix-like video streaming, P2P
   video sharing, and IPTV) and identifies how the existing protocols
   can be adapted to an ICN architecture.  In doing so, it also
   identifies the main issues with these protocols in this ICN context.

   In addition to this document, other works have considered specific
   aspects of dynamic adaptive streaming in ICN [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.

2.  Conventions Used in This Document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server, respectively.

Top      ToC       Page 5 
3.  Use Case Scenarios for ICN and Video Streaming

   For ICN-specific descriptions, we refer to the other research group
   documents [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.

Top      ToC       Page 6 
   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.

4.  Video Download

   Video download, namely the fetching of a video file from a server or
   a cache down to the user's local storage, is a natural application of
   ICN.  It should be supported natively without requiring any specific
   considerations.

   This is supported now by a host of protocols (say, Secure Copy (SCP),
   FTP, or over HTTP), which would need to be replaced by new ICN-
   specific protocols to retrieve content in ICNs.

   However, current mechanisms are built atop existing transport
   protocols.  Some ICN proposals (Context-Centric Network (CCN) or
   Named Data Networking (NDN), for instance) attempt to leverage the
   work done upon these transport protocols.  One proposal is to use the
   TCP congestion window (and the associated Adaptive Increase,
   Multiplicative Decrease (AIMD)) to decide how many object requests
   ("Interests" in CCN/NDN terminology) should be in flight at any point
   in time.

   It should be noted that ICN intrinsically supports different
   transport mechanisms, which could achieve better performance than
   TCP, as they subsume TCP into a special case.  For instance, one
   could imagine a link-by-link transport coupled with caching.  This is
   enabled by the ICN architecture and would facilitate the point-to-
   point download of video files.

Top      ToC       Page 7 
5.  Video Streaming and ICN

5.1.  Introduction to Client-Driven Streaming and DASH

   Media streaming over HTTP and, in a further consequence, streaming
   over the TCP, has become omnipresent in today's Internet.  Content
   providers such as Netflix, Hulu, and Vudu do not deploy their own
   streaming equipment: they use the existing Internet infrastructure as
   it is and simply deploy their own services Over The Top (OTT).  This
   streaming approach works surprisingly well without any particular
   support from the underlying network due to the use of efficient video
   compression, Content Delivery Networks (CDNs), and adaptive video
   players.  Earlier video streaming research mostly recommended use of
   the User Datagram Protocol (UDP) combined with the Real-time
   Transport Protocol (RTP).  It assumed it would not be possible to
   transfer multimedia data smoothly with TCP, because of its throughput
   variations and large retransmission delays.  This point of view has
   significantly evolved today.  HTTP streaming, and especially its most
   simple form known as progressive download, has become very popular
   over the past few years because it has some major benefits compared
   to RTP streaming.  As a consequence of the consistent use of HTTP for
   this streaming method, the existing Internet infrastructure
   consisting of proxies, caches, and CDNs could be used.  Originally,
   this architecture was designed to support best-effort delivery of
   files and not real-time transport of multimedia data.  Nevertheless,
   real-time streaming based on HTTP could also take advantage of this
   architecture, in comparison to RTP, which could not leverage any of
   the aforementioned components.  Another benefit that results from the
   use of HTTP is that the media stream could easily pass firewalls or
   Network Address Translation (NAT) gateways, which was definitely a
   key for the success of HTTP streaming.  However, HTTP streaming is
   not the holy grail of streaming as it also introduces some drawbacks
   compared to RTP.  Nevertheless, in an ICN-based video streaming
   architecture these aspects also have to be considered.

   The basic concept of DASH [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

Top      ToC       Page 8 
   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.

5.2.  Layered Encoding

   Another approach for video streaming consists in using layered
   encoding.  Namely, scalable video coding formats the video stream
   into different layers: a base layer that can be decoded to provide
   the lowest bit rate for the specific stream and enhancement layers
   that can be transmitted separately if network conditions allow.  The
   higher layers offer higher resolutions and enhancement of the video
   quality, while the layered approach allows for adaptation to the
   network conditions.  This is used in an MPEG-4 scalable profile or
   H.263+.  H264SVC is available but not much deployed.  JPEG2000 has a
   wavelet transform approach for layered encoding but has not been
   deployed much either.  It is not clear if the layered approach is
   fine-grained enough for rate control.

5.3.  Interactions of Video Streaming with ICN

5.3.1.  Interactions of DASH with ICN

   Video streaming (DASH in particular) has been designed with a goal
   that is aligned with that of most ICN proposals: it is a client-based
   mechanism that requests items (in this case, chunks of a video
   stream) by name.

   ICN and MPEG-DASH [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

Top      ToC       Page 9 
   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,

Top      ToC       Page 10 
      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].

5.3.2.  Interaction of ICN with Layered Encoding

   Issues of interest to an ICN architecture in the context of layered
   video streaming include:

   o  Caching of the multiple layers.  The caching priority should go to
      the base layer and to defining caching policy in order to decide
      when to cache enhancement layers;

   o  Synchronization of multiple content streams, as the multiple
      layers may come from different sources in the network (for
      instance, the base layer might be cached locally while the
      enhancement layers may be stored in the origin server).  Video and
      audio-video streams must be synchronized, and this includes both
      intra-layer synchronization (for the layers of the same video or

Top      ToC       Page 11 
      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.

5.4.  Possible Integration of Video Streaming and ICN Architecture

5.4.1.  DASH over CCN

   DASH is intended to enable adaptive streaming, i.e., each content
   piece can be provided in different qualities, formats, languages,
   etc., to cope with the diversity of today's networks and devices.  As
   this is an important requirement for Future Internet proposals like
   CCN, the combination of those two technologies seems to be obvious.
   Since those two proposals are located at different protocol layers --
   DASH at the application and CCN at the network layer -- they can be
   combined very efficiently to leverage the advantages of both and
   potentially eliminate existing disadvantages.  As CCN is not based on
   classical host-to-host connections, it is possible to consume content
   from different origin nodes as well as over different network links
   in parallel, which can be seen as an intrinsic error resilience
   feature with respect to the network.  This is a useful feature of CCN
   for adaptive multimedia streaming within mobile environments since
   most mobile devices are equipped with multiple network links like 3G
   and Wi-Fi.  CCN offers this functionality out of the box, which is
   beneficial when used for DASH-based services.  In particular, it is
   possible to enable adaptive video streaming handling both bandwidth
   and network link changes.  That is, CCN handles the network link
   decision and DASH is implemented on top of CCN to adapt the video
   stream to the available bandwidth.

   In principle, there are two options to integrate DASH and CCN: a
   proxy service acting as a broker between HTTP and CCN as proposed in
   [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

Top      ToC       Page 12 
   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,

Top      ToC       Page 13 
   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.

5.4.2.  Testbed, Open-Source Tools, and Dataset

   For the evaluations of DASH over CCN, a testbed with open-source
   tools and datasets is provided in [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

Top      ToC       Page 14 
   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.

6.  P2P Video Distribution and ICN

   Peer-to-Peer distribution is another form of distributing content --
   and video in particular -- that ICNs need to support.  We see now how
   an existing protocol such as PPSP can be modified to work in an ICN
   environment.

6.1.  Introduction to PPSP

   P2P Video Streaming (P2PVS) is a popular approach to redistribute
   live media over the Internet.  The proposed P2PVS solutions can be
   roughly classified in two classes:

   o  Push/Tree-based

   o  Pull/Mesh-based

   The Push/Tree-based solution creates an overlay network among Peers
   that has a tree shape [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

Top      ToC       Page 15 
   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.

Top      ToC       Page 16 
6.2.  PPSP over ICN: Deployment Concepts

6.2.1.  PPSP Short Background

   The Peer-to-Peer Streaming Peer Protocol (PPSPP) is defined in
   [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).

6.2.2.  From PPSP Messages to ICN Named-Data

   An ICN provides users with data items exposed by names.  The bundle
   name and data item is usually referred as "named-data", "named-
   content", etc.  To transfer PPSP messages through an ICN, the
   messages should be wrapped as named-data items and receivers should
   request them by name.

   A PPSP entity receives messages from peers and/or a tracker.  Some
   operations require gathering the messages generated by another
   specific host (peer or tracker).  For instance, if Peer A wishes to
   gain information about video chunks available from Peer B, the former
   shall fetch the PPSP HAVE messages specifically generated by the
   latter.  We refer to these kinds of named-data as "located-named-
   data" since they should be gathered from a specific location (e.g.,
   Peer B).

   For other PPSP operations, such as fetching a DATA message (i.e., a
   video chunk), as long as a peer receives the requested content, it
   doesn't matter which endpoint generated the data.  We refer to this
   information with the generic term "named-data".

Top      ToC       Page 17 
   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.

6.2.3.  Support of PPSP Interaction through a Pull-Based ICN API

   The PPSP procedures are based both on pull and push interactions.
   For instance, the distribution of chunks availability can be
   classified as a push-based operation since a peer sends "unsolicited"
   information (HAVE message) to neighboring peers.  Conversely, the
   procedure used to receive video chunks can be classified as pull-
   based since it is supported by a request/response interaction (i.e.,
   REQUEST, DATA messages).

   As we said, we refer to an ICN architecture that provides a pull-
   based API.  Accordingly, the mapping of PPSP pull-based procedure is
   quite simple.  For instance, using the CCN architecture
   [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.

Top      ToC       Page 18 
6.2.4.  Abstract Layering for PPSP over ICN

                   +-----------------------------------+
                   |            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.

Top      ToC       Page 19 
   Overall, the Mediator approach may be considered the first step of a
   migration path towards ICN-native PPSP applications.

6.2.5.  PPSP Interaction with the ICN Routing Plane

   Upon the ICN API, a user (peer) requests content and the ICN sends it
   back.  The content is gathered by the ICN from any source, which
   could be the closest peer that disposes of the named-data item, an
   in-network cache, etc.  Actually, "where" to gather the content is
   controlled by an underlying ICN routing plane, which sets up the ICN
   forwarding tables (e.g., CCN FIB [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].

6.2.6.  ICN Deployment for PPSP

   The ICN functionality that supports a PPSP session may be "isolated"
   or "integrated" with one from a public ICN.

   In the isolated case, a PPSP session is supported by an instance of
   an ICN (e.g., deployed on top of an IP) whose functionalities operate
   only on the limited set of nodes participating to the swarm, i.e.,
   peers and the tracker.  This approach resembles the one followed by a
   current P2P application, which usually forms an overlay network among
   peers of a P2P application; intermediate public IP routers do not
   carry out P2P functionalities.

   In the integrated case, the nodes of a public ICN may be involved in
   the forwarding and in-network caching procedures.  In doing so, the
   swarm may benefit from the presence of in-network caches, thus
   limiting uplink traffic on peers and inter-domain traffic, too.
   These are distinctive advantages of using PPSP over a public ICN
   rather than over TCP/IP.  In addition, such advantages aren't likely
   manifested in the case of isolated deployment.

   However, the possible interaction between the PPSP and the routing
   layer of a public ICN may be dramatic, both in terms of explosion of
   the forwarding tables and in terms of security.  These issues

Top      ToC       Page 20 
   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.

6.3.  Impact of MPEG-DASH Coding Schemes

   The introduction of video rate adaptation may significantly decrease
   the effectiveness of P2P cooperation and of in-network caching,
   depending of the kind of the video coding used by the MPEG-DASH
   stream.

   In case of an MPEG-DASH streaming with MPEG AVC encoding, the same
   video chunk is independently encoded at different rates and the
   encoding output is a different file for each rate.  For instance, in
   case of a video encoded at three different rates, R1, R2, and R3; for
   each segment S, we have three distinct files: S.R1, S.R2, and S.R3.
   These files are independent of each other.  To fetch a segment coded
   at R2 kbps, a peer shall request the specific file S.R2.  Receiver-
   driven algorithms, implemented by the video client, usually handle
   the estimation of the best coding rate.

   The independence among files associated with different encoding rates
   and the heterogeneity of peer bandwidths may dramatically reduce the
   interaction among peers, the effectiveness of in-network caching (in
   case of integrated deployment), and consequently, the ability of PPSP
   to offload the video server (i.e., a seeder peer).  Indeed, a Peer A
   may select a coding rate (e.g., R1) different from the one selected

Top      ToC       Page 21 
   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.



(page 21 continued on part 2)

Next Section