7.  IPTV and ICN

7.1.  IPTV Challenges

   IPTV refers to the delivery of quality content broadcast over the
   Internet and is typically associated with strict quality
   requirements, i.e., with a perceived latency of less than 500 ms and
   a packet loss rate that is multiple orders lower than the current
   loss rates experienced in the most commonly used access networks (see
   [ATIS-IIF]).  We can summarize the major challenges for the delivery
   of IPTV service as follows.

   Channel change latency represents a major concern for the IPTV
   service.  Perceived latency during channel change should be less than
   500 ms.  To achieve this objective over the IP infrastructure, we
   have multiple choices:

   i     receive fast unicast streams from a dedicated server (most
         effective but not resource efficient);

   ii    connect to other peers in the network (efficiency depends on
         peer support, effective and resource efficient, if also
         supported with a dedicated server); and

   iii   connect to multiple multicast sessions at once (effective but
         not resource efficient and depends on the accuracy of the
         prediction model used to track user activity).

   The second major challenge is the error recovery.  Typical IPTV
   service requirements dictate the mean time between artifacts to be
   approximately 2 hours (see [ATIS-IIF]).  This suggests the perceived
   loss rate to be less than or equal to 10^-7.  Current IP-based
   solutions rely on the following proactive and reactive recovery
   techniques: (i) joining the Forward Error Correction (FEC) multicast
   stream corresponding to the perceived packet loss rate (not
   efficient, as the recovery strength is chosen based on worst-case
   loss scenarios); (ii) making unicast recovery requests to dedicated
   servers (requires active support from the service provider); (iii)
   probing peers to acquire repair packets (finding matching peers and
   enabling their cooperation is another challenge).

7.2.  ICN Benefits for IPTV Delivery

   ICN presents significant advantages for the delivery of IPTV traffic.
   For instance, ICN inherently supports multicast and allows for quick
   recovery from packet losses (with the help of in-network caching).
   Similarly, peer support is also provided in the shape of in-network
   caches that typically act as the middleman between two peers,
   therefore enabling earlier access to IPTV content.

   However, despite these advantages, delivery of IPTV service over ICNs
   brings forth new challenges.  We can list some of these challenges as
   follows:

   o  Messaging overhead: ICN is a pull-based architecture and relies on
      a unique balance between requests and responses.  A user needs to
      make a request for each Data packet.  In the case of IPTV, with
      rates up to (and likely to be) above 15 Mbps, we observe
      significant traffic upstream to bring those streams.  As the
      number of streams increases (including the same session at

      different quality levels and other formats), so does the burden on
      the routers.  Even if the majority of requests are aggregated at
      the core, routers close to the edge (where we observe the biggest
      divergence in user requests) will experience a significant
      increase in overhead to process these requests.  The same is true
      at the user side, as the uplink usage multiplies in the number of
      sessions a user requests (for instance, to minimize the impact of
      bandwidth fluctuations).

   o  Cache control: As the IPTV content expires at a rapid rate (with a
      likely expiry threshold of 1 s), we need solutions to effectively
      flush out such content to also prevent degradation impact on other
      cached content, with the help of intelligently chosen naming
      conventions.  However, to allow for fast recovery and optimize
      access time to sessions (from current or new users), the timing of
      such expirations needs to be adaptive to network load and user
      demand.  However, we also need to support quick access to earlier
      content, whenever needed; for instance, when the user accesses the
      rewind feature (note that in-network caches will not be of
      significant help in such scenarios due to the overhead required to
      maintain such content).

   o  Access accuracy: To receive the up-to-date session data, users
      need to be aware of such information at the time of their request.
      Unlike IP multicast, since the users join a session indirectly,
      session information is critical to minimize buffering delays and
      reduce the startup latency.  Without such information, and without
      any active cooperation from the intermediate routers, stale data
      can seriously undermine the efficiency of content delivery.
      Furthermore, finding a cache does not necessarily equate to
      joining a session, as the look-ahead latency for the initial
      content access point may have a shorter lifetime than originally
      intended.  For instance, if the user that has initiated the
      indirect multicast leaves the session early, the requests from the
      remaining users need to experience an additional latency of one
      RTT as they travel towards the content source.  If the startup
      latency is chosen depending on the closeness to the intermediate
      router, going to the content source in-session can lead to
      undesired pauses.

   It should be noted that IPTV includes more than just multicast.  Many
   implementations include "trick plays" (fast forward, pause, rewind)
   that often transform a multicast session into multiple unicast
   sessions.  In this context, ICN is beneficial, as the caching offers
   an implicit multicast but without tight synchronization constraints
   in between two different users.  One user may rewind and start
   playing forward again, thus drawing from a nearby cache of the

   content recently viewed by another user (whereas in a strict
   multicast session, the opportunity of one user lagging off behind
   would be more difficult to implement).

8.  Digital Rights Management in ICN

   This section discusses the need for DRM functionalities for
   multimedia streaming over ICN.  It focuses on two possible
   approaches: modifying Authentication, Authorization, and Accounting
   (AAA) to support DRM in ICN and using Broadcast Encryption.

   It is assumed that ICN will be used heavily for digital content
   dissemination.  It is vital to consider DRM for digital content
   distribution.  In today's Internet, there are two predominant classes
   of business models for on-demand video streaming.  The first model is
   based on advertising revenues.  Non-copyright protected (usually
   User-Generated Content (UGC)) content is offered by large
   infrastructure providers like Google (YouTube) at no charge.  The
   infrastructure is financed by spliced advertisements into the
   content.  In this context, DRM considerations may not be required,
   since producers of UGC may only strive for the maximum possible
   dissemination.  Some producers of UGC are mainly interested in
   sharing content with their families, friends, colleges, or others and
   have no intention making a profit.  However, the second class of
   business model requires DRM, because these entities are primarily
   profit oriented.  For example, large on-demand streaming platforms
   (e.g., Netflix) establish business models based on subscriptions.
   Consumers may have to pay a monthly fee in order to get access to
   copyright-protected content like TV series, movies, or music.  This
   model may be ad supported and free to the content consumer, like
   YouTube Channels or Spotify, but the creator of the content expects
   some remuneration for his work.  From the perspective of the service
   providers and the copyright owners, only clients that pay the fee
   (explicitly or implicitly through ad placement) should be able to
   access and consume the content.  Anyway, the challenge is to find an
   efficient and scalable way of access control to digital content,
   which is distributed in ICNs.

8.1.  Broadcast Encryption for DRM in ICN

   This section discusses Broadcast Encryption (BE) as a suitable basis
   for DRM functionalities in conformance to the ICN communication
   paradigm (network-inherent caching, considered the advantage of BE,
   will be highlighted).

   In ICN, Data packets can be cached inherently in the network, and any
   network participant can request a copy of these packets.  This makes
   it very difficult to implement an access control for content that is

   distributed via ICN.  A naive approach is to encrypt the transmitted
   data for each consumer with a distinct key.  This prohibits everyone
   other than the intended consumers from decrypting and consuming the
   data.  However, this approach is not suitable for ICN's communication
   paradigm, since it would reduce the benefits gained from the inherent
   network caching.  Even if multiple consumers request the same
   content, the requested data for each consumer would differ using this
   approach.  A better, but still insufficient, idea is to use a single
   key for all consumers.  This does not destruct the benefits of ICN's
   caching ability.  The drawback is that if one of the consumers
   illegally distributes the key, the system is broken; any entity in
   the network can access the data.  Changing the key after such an
   event is useless since the provider has no possibility to identify
   the illegal distributor.  Therefore, this person cannot be stopped
   from distributing the new key again.  In addition to this issue,
   other challenges have to be considered.  Subscriptions expire after a
   certain time, and then it has to be ensured that these consumers
   cannot access the content anymore.  For a provider that serves
   millions of daily consumers (e.g., Netflix), there could be a
   significant number of expiring subscriptions per day.  Publishing a
   new key every time a subscription expires would require an unsuitable
   amount of computational power just to re-encrypt the collection of
   audio-visual content.

   A possible approach to solve these challenges is BE [Fiat94] as
   proposed in [Posch13].  From this point on, this section will focus
   only on BE as an enabler for DRM functionality in the use case of ICN
   video streaming.  This subsection continues with the explanation of
   how BE works and shows how BE can be used to implement an access
   control scheme in the context of content distribution in ICN.

   BE actually carries a misleading name.  One might expect a concrete
   encryption scheme.  However, it belongs to the family of key
   management schemes.  These schemes are responsible for the
   generation, exchange, storage, and replacement of cryptographic keys.
   The most interesting characteristics of BE schemes are:

   o  BE schemes typically use a global trusted entity called the
      Licensing Agent (LA), which is responsible for spreading a set of
      pre-generated secrets among all participants.  Each participant
      gets a distinct subset of secrets assigned from the LA.

   o  The participants can agree on a common session key, which is
      chosen by the LA.  The LA broadcasts an encrypted message that
      includes the key.  Participants with a valid set of secrets can
      derive the session key from this message.

   o  The number of participants in the system can change dynamically.
      Entities may join or leave the communication group at any time.
      If a new entity joins, the LA passes on a valid set of secrets to
      that entity.  If an entity leaves (or is forced to leave) the LA
      revokes the entity's subset of keys, which means that it cannot
      derive the correct session key anymore when the LA distributes a
      new key.

   o  Traitors (entities that reveal their secrets) can be traced and
      excluded from ongoing communication.  The algorithms and
      preconditions to identify a traitor vary between concrete BE
      schemes.

   This listing already illustrates why BE is suitable to control the
   access to data that is distributed via an ICN.  BE enables the usage
   of a single session key for confidential data transmission between a
   dynamically changing subset or network participants.  ICN caches can
   be utilized since the data is encrypted only with a single key known
   by all legitimate clients.  Furthermore, traitors can be identified
   and removed from the system.  The issue of re-encryption still exists
   because the LA will eventually update the session key when a
   participant should be excluded.  However, this disadvantage can be
   relaxed in some way if the following points are considered:

   o  The updates of the session key can be delayed until a set of
      compromised secrets has been gathered.  Note that secrets may
      become compromised because of two reasons: first, a traitor could
      have illegally revealed the secret; second, the subscription of an
      entity expired.  Delayed revocation temporarily enables some
      illegitimate entities to consume content.  However, this should
      not be a severe problem in home entertainment scenarios.  Updating
      the session key in regular (not too short) intervals is a good
      trade- off.  The longer the interval lasts, the less computational
      resources are required for content re-encryption and the better
      the cache utilization in the ICN will be.  To evict old data from
      ICN caches that have been encrypted with the prior session key,
      the publisher could indicate a lifetime for transmitted packets.

   o  Content should be re-encrypted dynamically at request time.  This
      has the benefit that untapped content is not re-encrypted if the
      content is not requested during two session key update; therefore,
      no resources are wasted.  Furthermore, if the updates are
      triggered in non-peak times, the maximum amount of resources
      needed at one point in time can be lowered effectively since in
      peak times generally more diverse content is requested.

   o  Since the amount of required computational resources may vary
      strongly from time to time, it would be beneficial for any
      streaming provider to use cloud-based services to be able to
      dynamically adapt the required resources to the current needs.  In
      regard to a lack of computation time or bandwidth, the cloud
      service could be used to scale up to overcome shortages.

   Figure 4 shows the potential usage of BE in a multimedia delivery
   framework that builds upon ICN infrastructure and uses the concept of
   dynamic adaptive streaming, e.g., DASH.  BE would be implemented on
   the top to have an efficient and scalable way of access control to
   the multimedia content.

              +--------Multimedia Delivery Framework--------+
              |                                             |
              |     Technologies            Properties      |
              |  +----------------+     +----------------+  |
              |  |   Broadcast    |<--->|   Controlled   |  |
              |  |   Encryption   |     |     Access     |  |
              |  +----------------+     +----------------+  |
              |  |Dynamic Adaptive|<--->|   Multimedia   |  |
              |  |   Streaming    |     |   Adaptation   |  |
              |  +----------------+     +----------------+  |
              |  |       ICN      |<--->|   Cacheable    |  |
              |  | Infrastructure |     |   Data Chunks  |  |
              |  +----------------+     +----------------+  |
              +---------------------------------------------+

            Figure 4: A Potential Multimedia Framework Using BE

8.2.  AAA-Based DRM for ICN Networks

8.2.1.  Overview

   Recently, a novel approach to DRM has emerged to link DRM to usual
   network management operations, hence linking DRM to AAA services.
   ICN provides the abstraction of an architecture where content is
   requested by name and could be served from anywhere.  In DRM, the
   content provider (the origin of the content) allows the destination
   (the end-user account) to use the content.  The content provider and
   content storage/cache are at two different entities in ITU Carrier
   Code (ICC); for traditional DRM, only source and destination count
   and not the intermediate storage.  The proposed solution allows the
   provider of the caching to be involved in the DRM policies using
   well-known AAA mechanisms.  It is important to note that this
   solution is compatible with the proposal of the BE, proposed earlier
   in this document.  The BE proposes a technology, as this solution is
   more operational.

8.2.2.  Implementation

   With the proposed AAA-based DRM, when content is requested by name
   from a specific destination, the request could link back to both the
   content provider and the caching provider via traditional AAA
   mechanisms and trigger the appropriate DRM policy independently from
   where the content is stored.  In this approach, the caching, DRM, and
   AAA remain independent entities but can work together through ICN
   mechanisms.  The proposed solution enables extending the traditional
   DRM done by the content provider to jointly being done by content
   provider and network/caching provider.

   The solution is based on the concept of a "token".  The content
   provider authenticates the end user and issues an encrypted token to
   authenticate the named-content ID or IDs that the user can access.
   The token will be shared with the network provider and used as the
   interface to the AAA protocols.  At this point, all content access is
   under the control of the network provider and the ICN.  The
   controllers and switches can manage the content requests and handle
   mobility.  The content can be accessed from anywhere as long as the
   token remains valid or the content is available in the network.  In
   such a scheme, the content provider does not need to be contacted
   every time a named-content is requested.  This reduces the load of
   the content provider network and creates a DRM mechanism that is much
   more appropriate for the distributed caching and Peer-to-Peer storage
   characteristic of ICN networks.  In particular, the content requested
   by name can be served from anywhere under the only condition that the
   storage/cache can verify that the token is valid for content access.

   The solution is also fully customizable to both content and network
   provider's needs as the tokens can be issued based on user accounts,
   location, and hardware (Media Access Control (MAC) address, for
   example) linking it naturally to legacy authentication mechanisms.
   In addition, since both content and network providers are involved in
   DRM policies, pollution attacks and other illegal requests for the
   content can be more easily detected.  The proposed AAA-based DRM is
   currently under full development.

9.  Future Steps for Video in ICN

   The explosion of online video services, along with their increased
   consumption by mobile wireless terminals, further exacerbates the
   challenges of ICN mechanisms that leverage Video Adaptation.  The
   following sections present a series of research items derived from
   these challenges, further introducing next steps for the subject.

9.1.  Large-Scale Live Events

   Distributing content, and video in particular, using local
   communications in large-scale events such as sporting events in a
   stadium, a concert, or a large demonstration, is an active area of
   investigation and a potential use case where ICN would provide
   significant benefits.

   Such use cases involve locating content that is generated on the fly
   and requires discovery mechanisms in addition to sharing mechanisms.
   The scalability of the distribution becomes important as well.

9.2.  Video Conferencing and Real-Time Communications

   Current protocols for video conferencing have been designed, and this
   document takes input from them to identify the key research issues.
   Real-time communications add timing constraints (both in terms of
   delay and in terms of synchronization) to the scenario discussed
   above.

   An Access Router (AR) and a Virtual Router (VR), and immersive
   multimedia experiences in general, are clearly an area of further
   investigation, as they involve combining multiple streams of data
   from multiple users into a coherent whole.  This raises issues of
   multisource, multidestination multimedia streams that ICN may be
   equipped to deal with in a more natural manner than IP, which is
   inherently unicast.

9.3.  Store-and-Forward Optimized Rate Adaptation

   One of the benefits of ICN is to allow the network to insert caching
   in the middle of the data transfer.  This can be used to reduce the
   overall bandwidth demands over the network by caching content for
   future reuse, but it provides more opportunities for optimizing video
   streams.

   Consider, for instance, the following scenario: a client is connected
   via an ICN network to a server.  Let's say the client is connected
   wirelessly to a node that has a caching capability, which is
   connected through a WAN to the server.  Further, assume that the
   capacity of each of the links (both the wireless and the WAN logical
   links) varies with time.

   If the rate adaptation is provided in an end-to-end manner, as in
   current mechanisms like DASH, then the maximal rate that can be
   supported at the client is that of the minimal bandwidth on each
   link.

   If, for instance, during Time Period 1 the wireless capacity is 1 and
   the wired capacity is 2 and during Time Period 2 the wireless
   capacity is 2 (due to some hotspot) and the wired capacity is 1 (due
   to some congestion in the network), then the best end-to-end rate
   that can be achieved is 1 during each period.

   However, if the cache is used during Time Period 1 to pre-fetch 2
   units of data, then during Time Period 2 there is 1 unit of data at
   the cache and another unit of data that can be streamed from the
   server; therefore, the rate that can be achieved is 2 units of data.
   In this case, the average bandwidth rises from 1 to 1.5 over the two
   periods.

   This straw-man example illustrates a) the benefit of ICN for
   increasing the throughput of the network and b) the need for the
   special rate adaptation mechanisms to be designed to take advantage
   of this gain.  End-to-end rate adaptation cannot take advantage of
   the cache availability.  The authors of [Rainer16] showed that
   buffer-based adaptation mechanisms can be one approach to tackle this
   challenge.  As buffer-based adaptation does not estimate the
   available bandwidth resources (but solely considers the video buffer
   fill state), measured bandwidth fluctuations caused by cache hits are
   not existent.  Therefore, they cannot negatively impact the
   adaptation decisions (e.g., frequent representation switching).

9.4.  Heterogeneous Wireless Environment Dynamics

   With the ever-growing increase in online services being accessed by
   mobile devices, operators have been deploying different overlapping
   wireless access networking technologies.  In this way, in the same
   area, user terminals are within range of different cellular, Wi-Fi,
   or even Worldwide Interoperability for Microwave Access (WiMAX)
   networks.  Moreover, with the advent of the Internet of Things (e.g.,
   surveillance cameras feeding video footage), this list can be further
   complemented with more-specific short-range technologies, such as
   Bluetooth or ZigBee.

   In order to leverage from this plethora of connectivity
   opportunities, user terminals are coming equipped with different
   wireless access interfaces, providing them with extended connectivity
   opportunities.  In this way, such devices become able to select the
   type of access that best suits them according to different criteria,
   such as available bandwidth, battery consumption, access to different
   link conditions according to the user profile, or even access to
   different content.  Ultimately, these aspects contribute to the QoE
   perceived by the end user, which is of utmost importance when it
   comes to video content.

   However, the fact that these users are mobile and using wireless
   technologies also provides a very dynamic setting where the current
   optimal link conditions at a specific moment might not last or be
   maintained while the user moves.  These aspects have been amply
   analyzed in recently finished projects such as FP7 MEDIEVAL
   [MEDIEVAL], where link events reporting on wireless conditions and
   available alternative connection points were combined with video
   requirements and traffic optimization mechanisms towards the
   production of a joint network and mobile terminal mobility management
   decision.  Concretely, in [Fu13], link information about the
   deterioration of the wireless signal was sent towards a mobility
   management controller in the network.  This input was combined with
   information about the user profile, as well as of the current video
   service requirements, and used to trigger the decrease or increase of
   scalable video layers (adjusting the video to the ongoing link
   conditions).  Incrementally, the video could also be adjusted when a
   new, better connectivity opportunity presents itself.

   In this way, regarding Video Adaptation, ICN mechanisms can leverage
   from their intrinsic multiple source support capability and go beyond
   the monitoring of the status of the current link, thus exploiting the
   availability of different connectivity possibilities (e.g., different
   "interfaces").  Moreover, information obtained from the mobile
   terminal's point of view of its network link, as well as information
   from the network itself (i.e., load, policies, and others), can
   generate scenarios where such information is combined in a joint
   optimization procedure allowing the content to be forward to users
   using the best available connectivity option (e.g., exploiting
   management capabilities supported by ICN intrinsic mechanisms as in
   [Corujo12]).

   In fact, ICN base mechanisms can further be exploited in enabling new
   deployment scenarios such as preparing the network for mass requests
   from users attending a large multimedia event (i.e., concert,
   sports), allowing video to be adapted according to content, user and
   network requirements, and operation capabilities in a dynamic way.

   Enabling such scenarios requires further research, with the main
   points highlighted as follows:

   o  how to develop a generic video services (and obviously content)
      interface allowing the definition and mapping of their
      requirements (and characteristics) into the current capabilities
      of the network;

   o  how to define a scalable mechanism allowing either the video
      application at the terminal or some kind of network management
      entity, to adapt the video content in a dynamic way;

   o  how to develop the previous research items using intrinsic ICN
      mechanisms (i.e., naming and strategy layers);

   o  how to leverage intelligent pre-caching of content to prevent
      stalls and poor quality phases, which lead to a worse QoE for the
      user: this includes, in particular, the usage in mobile
      environments, which are characterized by severe bandwidth changes
      as well as connection outages, as shown in [Crabtree13]; and

   o  how to take advantage of the multipath opportunities over the
      heterogeneous wireless interfaces.

9.5.  Network Coding for Video Distribution in ICN

   An interesting research area for combining heterogeneous sources is
   to use network coding [Montpetit13b].  Network coding allows for
   asynchronous combining of multiple sources by having each of them
   send information that is not duplicated by the other but that can be
   combined to retrieve the video stream.

   However, this creates issues in ICN in terms of defining the proper
   rate adaptation for the video stream, securing the encoded data,
   caching the encoded data, timeliness of the encoded data, overhead of
   the network coding operations both in network resources and in added
   buffering delay, etc.

   Network coding has shown promise in reducing buffering events in
   unicast, multicast, and P2P settings.  [Medard12] considers
   strategies using network coding to enhance QoE for multimedia
   communications.  Network coding can be applied to multiple streams,
   but also within a single stream as an equivalent of a composable
   erasure code.  Clearly, there is a need for further investigation of
   network coding in ICN, potentially as a topic of activity in the
   research group.

9.6.  Synchronization Issues for Video Distribution in ICN

   ICN decouples the fetching of video chunks from their locations.
   This means an audio chunk may be received from one network element
   (cache/storage/server), a video chunk may be received from another,
   while yet another chunk (say, the next one, or another layer from the
   same video stream) may come from a third element.  This introduces
   disparity in the retrieval times and locations of the different
   elements of a video stream that need to be played at the same (or
   almost same) time.  Synchronization of such delivery and playback may
   require specific synchronization tools for video delivery in ICN.

   Other aspects involve synchronizing:

   o  within a single stream, for instance, the consecutive chunks of a
      single stream or the multiple layers of a layered scheme when
      sources and transport layers may be different.

   o  re-ordering the packets of a stream distributed over multiple
      sources at the video client, or ensuring that multiple chunks
      coming from multiple sources arrive within an acceptable time
      window;

   o  multiple streams, such as the audio and video components of a
      video stream, which can be received from independent sources; and

   o  multiple streams from multiple sources to multiple destinations,
      such as mass distribution of live events.  For instance, for live
      video streams or video conferencing, some level of synchronization
      is required so that people watching the stream view the same
      events at the same time.

   Some of these issues were addressed in [Montpetit13a] in the context
   of social video consumption.  Network coding, with traffic
   engineering, is considered as a potential solution for
   synchronization issues.  Other approaches could be considered that
   are specific to ICN as well.

   Traffic engineering in ICN [Su14] [Chanda13] may be required to
   provide proper synchronization of multiple streams.

10.  Security Considerations

   This is informational.  There are no specific security considerations
   outside of those mentioned in the text.

11.  Conclusions

   This document proposes adaptive video streaming for ICN, identified
   potential problems, and presents the combination of CCN with DASH as
   a solution.  As both concepts, DASH and CCN, maintain several
   elements in common, like, e.g., the content in different versions
   being dealt with in segments, combination of both technologies seems
   useful.  Thus, adaptive streaming over CCN can leverage advantages
   such as, e.g., efficient caching and intrinsic multicast support of
   CCN, routing based on named-data URIs, intrinsic multilink and
   multisource support, etc.

   In this context, the usage of CCN with DASH in mobile environments
   comes together with advantages compared to today's solutions,
   especially for devices equipped with multiple network interfaces.
   The retrieval of data over multiple links in parallel is a useful
   feature, specifically for adaptive multimedia streaming since it
   offers the possibility to dynamically switch between the available
   links depending on their bandwidth capabilities, which are
   transparent to the actual DASH client.

12.  References

12.1.  Normative References

   [Rainer16] Rainer, B., Posch, D., and H. Hellwagner, "Investigating
              the Performance of Pull-based Dynamic Adaptive Streaming
              in NDN", IEEE Journal on Selected Areas in Communications
              (J-SAC): Special Issue on Video Distribution over Future
              Internet, Volume 34, Number 8,
              DOI 10.1109/JSAC.2016.2577365, August 2016.

   [RFC6972]  Zhang, Y. and N. Zong, "Problem Statement and Requirements
              of the Peer-to-Peer Streaming Protocol (PPSP)", RFC 6972,
              DOI 10.17487/RFC6972, July 2013,
              <http://www.rfc-editor.org/info/rfc6972>.

12.2.  Informative References

   [ATIS-IIF] "ATIS: IIF, IPTV Interoperability Forum", 2015,
              <http://www.atis.org/iif/deliv.asp>.

   [Bakker15] Bakker, A., Petrocco, R., and V. Grishchenko, "Peer-to-
              Peer Streaming Peer Protocol (PPSPP)", RFC 7574,
              DOI 10.17487/RFC7574, July 2015,
              <http://www.rfc-editor.org/info/rfc7574>.

   [Castro03] Castro, M., Druschel, P., Kermarrec, A., Nandi, A., and A.
              Rowstron, "SplitStream: High-Bandwidth Multicast in
              Cooperative Environments", Proceedings of the 19th ACM
              Symposium on Operating Systems Principles (SOSP '03),
              DOI 10.1145/945445.945474, October 2003.

   [Chai11]   Chai, W., Wang, N., Psaras, I., Pavlou, G., Wang, C.,
              de Blas, G., Ramon-Salguero, F., Liang, L., Spirou, S.,
              Blefari-Melazzi, N., Beben, A., and E. Hadjioannou,
              "CURLING: Content-Ubiquitous Resolution and Delivery
              Infrastructure for Next Generation Services", IEEE
              Communications Magazine, Volume 49, Issue 3,
              DOI 10.1109/MCOM.2011.5723808, March 2011.

   [Chanda13] Chanda, A., Westphal, C., and D. Raychaudhuri, "Content
              Based Traffic Engineering in Software Defined Information
              Centric Networks", 2013 IEEE Conference on Computer
              Communications Workshops (INFOCOM WKSHPS),
              DOI 10.1109/INFCOMW.2013.6970717, April 2013.

   [Corujo12] Corujo, D., Vidal, I., Garcia-Reinoso, J., and R. Aguiar,
              "A Named Data Networking Flexible Framework for Management
              Communications", IEEE Communications Magazine, Volume 50,
              Issue 12, DOI 10.1109/MCOM.2012.6384449, December 2012.

   [Crabtree13]
              Crabtree, B., Stevens, T., Allan, B., Lederer, S., Posch,
              D., Mueller, C., and C. Timmerer, "Video Adaptation in
              Limited/Zero Network Coverage", CCNxCon 2013, Palo Alto
              Research Center (PARC), September 2013.

   [Detti11]  Detti, A., Blefari-Melazzi, N., Salsano, S., and M.
              Pomposini, "CONET: A Content Centric Inter-Networking
              Architecture", Proceedings of the ACM SIGCOMM Workshop on
              Information-Centric Networking,
              DOI 10.1145/2018584.2018598, August 2011.

   [Detti12]  Detti, A., Pomposini, M., Blefari-Melazzi, N., Salsano,
              S., and A. Bragagnini, "Offloading cellular networks with
              Information-Centric Networking: the case of video
              streaming", 2013 IEEE 14th International Symposium on A
              World of Wireless, Mobile and Multimedia Networks
              (WoWMoM), DOI 10.1109/WoWMoM.2012.6263734, June 2012.

   [Detti13]  Detti, A., Ricci, B., and N. Blefari-Melazzi, "Peer-To-
              Peer Live Adaptive Video Streaming for Information Centric
              Cellular Networks", 2013 IEEE 24th Annual International
              Symposium on Personal, Indoor, and Mobile Radio
              Communications (PIMRC), DOI 10.1109/PIMRC.2013.6666771,
              September 2013.

   [Fiat94]   Fiat, A. and M. Naor, "Broadcast Encryption", Advances in
              Cryptology - CRYPTO '93 Proceedings, Lecture Notes in
              Computer Science, Volume 773, pp. 480-491, 1994.

   [Fu13]     Fu, B., Kunzmann, G., Wetterwald, M., Corujo, D., and R.
              Costa, "QoE-aware traffic management for mobile video
              delivery", 2013 IEEE International Conference on
              Communications Workshops (ICC),
              DOI 10.1109/ICCW.2013.6649314, June 2013.

   [Grandl13] Grandl, R., Su, K., and C. Westphal, "On the Interaction
              of Adaptive Video Streaming with Content-Centric
              Networks", 2013 IEEE International Conference on
              Multimedia and Expo (ICME), DOI 10.1109/ICME.2013.6607500,
              July 2013.

   [IETF-PPSP]
              IETF, "Peer to Peer Streaming Protocol (ppsp)",
              <https://datatracker.ietf.org/wg/ppsp/>.

   [ISO-DASH] ISO, "Information technology -- Dynamic adaptive streaming
              over HTTP (DASH) -- Part 1: Media presentation description
              and segment formats", ISO/IEC 23009-1:2014, May 2014.

   [ITEC-DASH]
              "ITEC - Dynamic Adaptive Streaming over HTTP", DASH
              Research at the Institute of Information
              Technology, Multimedia Communication Group, Alpen-Adria
              Universitaet Klagenfurt, <http://dash.itec.aau.at>.

   [Jacobson09a]
              Jacobson, V., Smetters, D., Briggs, N., Plass, M.,
              Stewart, P., Thornton, J., and R. Braynard, "VoCCN: Voice-
              over Content-Centric Networks", Proceedings of the 2009
              Workshop on Re-architecting the Internet,
              DOI 10.1145/1658978.1658980, December 2009.

   [Jacobson09b]
              Jacobson, V., Smetters, D., Thornton, J., Plass, M.,
              Briggs, N., and R. Braynard, "Networking Named Content",
              Proceedings of the 5th International Conference on
              Emerging Networking Experiments and Technologies (CoNEXT),
              DOI 10.1145/1658939.1658941, December 2009.

   [LeCallet13]
              Le Callet, P., Moeller, S., and A. Perkis, "Qualinet White
              Paper on Definitions of Quality of Experience", European
              Network on Quality of Experience in Multimedia Systems and
              Services, COST Action IC 1003, Version 1.2, March 2013.

   [Lederer13a]
              Lederer, S., Liu, Y., Geurts, J., Point, J., Lederer, S.,
              Mueller, C., Rainer, B., Timmerer, C., and H. Hellwagner,
              "Dynamic Adaptive Streaming over CCN: A Caching and
              Overhead Analysis", 2013 IEEE International Conference on
              Communication (ICC), DOI 10.1109/ICC.2013.6655116, June
              2013.

   [Lederer13b]
              Lederer, S., Mueller, C., Rainer, B., Timmerer, C., and H.
              Hellwagner, "An Experimental Analysis of Dynamic Adaptive
              Streaming over HTTP in Content Centric Networks", 2013
              IEEE International Conference on Multimedia and Expo
              (ICME), DOI 10.1109/ICME.2013.6607500, July 2013.

   [Magharei07]
              Magharei, N., Rejaie, R., and Y. Guo, "Mesh or Multiple-
              Tree: A Comparative Study of Live P2P Streaming
              Approaches", IEEE INFOCOM 2007 - 26th IEEE International
              Conference on Computer Communications,
              DOI 10.1109/INFCOM.2007.168, May 2007.

   [Medard12] Medard, M., Kim, M., Parandeh-Gheibi, M., Zeng, W., and M.
              Montpetit, "Quality of Experience for Multimedia
              Communications: Network Coding Strategies", Laboratory of
              Electronics, Massachusetts Institute of Technology, March
              2012.

   [MEDIEVAL] "MEDIEVAL: MultiMEDia transport for mobIlE Video
              AppLications", 2010, <http://www.ict-medieval.eu>.

   [Montpetit13a]
              Montpetit, M., Holtzman, H., Chakrabarti, K., and M.
              Matijasevic, "Social video consumption: Synchronized
              viewing experiences across devices and networks", 2013
              IEEE International Conference on Communications Workshops
              (ICC), pp. 286-290, DOI 10.1109/ICCW.2013.6649245, 2013.

   [Montpetit13b]
              Montpetit, M., Westphal, C., and D. Trossen, "Network
              Coding Meets Information-Centric Networking: An
              Architectural Case for Information Dispersion Through
              Native Network Coding", Proceedings of the 1st ACM
              Workshop on Emerging Name-Oriented Mobile Networking
              Design-Architecture, Algorithms, and Applications,
              DOI 10.1145/2248361.2248370, June 2013.

   [Mueller12]
              Mueller, C., Lederer, S., and C. Timmerer, "A Proxy Effect
              Analysis and Fair Adaptation Algorithm for Multiple
              Competing Dynamic Adaptive Streaming over HTTP Clients",
              2012 IEEE Visual Communications and Image Processing
              (VCIP), DOI 10.1109/VCIP.2012.6410799, November 2012.

   [NETINF]   "NetInf: Network of Information", <http://www.netinf.org>.

   [Posch13]  Posch, D., Hellwagner, H., and P. Schartner, "On-Demand
              Video Streaming based on Dynamic Adaptive Encrypted
              Content Chunks", Proceedings of the 8th International
              Workshop on Secure Network Protocols (NPSec '13),
              DOI 10.1109/ICNP.2013.6733673, October 2013.

   [RFC7476]  Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G.,
              Tyson, G., Davies, E., Molinaro, A., and S. Eum,
              "Information-Centric Networking: Baseline Scenarios",
              RFC 7476, DOI 10.17487/RFC7476, March 2015,
              <http://www.rfc-editor.org/info/rfc7476>.

   [RFC7846]  Cruz, R., Nunes, M., Xia, J., Huang, R., Ed., Taveira, J.,
              and D. Lingli, "Peer-to-Peer Streaming Tracker Protocol
              (PPSTP)", RFC 7846, DOI 10.17487/RFC7846, May 2016,
              <http://www.rfc-editor.org/info/rfc7846>.

   [Su14]     Su, K. and C. Westphal, "On the Benefit of Information
              Centric Networks for Traffic Engineering", 2014 IEEE
              International Conference on Communications (ICC),
              DOI 10.1109/ICC.2014.6883810, June 2014.

Acknowledgments

   This work was supported in part by the European Community in the
   context of the SocialSensor (FP7-ICT-287975) project and partly
   performed in the Lakeside Labs research cluster at AAU.  SocialSensor
   receives research funding from the European Community's Seventh
   Framework Programme.  The work for this document was also partially
   performed in the context of the FP7/NICT EU-JAPAN GreenICN project,
   <http://www.greenicn.org>.  Apart from this, the European Commission
   has no responsibility for the content of this document.  The
   information in this document is provided as is and no guarantee or
   warranty is given that the information is fit for any particular
   purpose.  The user, thereof, uses the information at its sole risk
   and liability.

Authors' Addresses

   Cedric Westphal (editor)
   Huawei

   Email: Cedric.Westphal@huawei.com


   Stefan Lederer
   Alpen-Adria University Klagenfurt

   Email: stefan.lederer@itec.aau.at


   Daniel Posch
   Alpen-Adria University Klagenfurt

   Email: daniel.posch@itec.aau.at


   Christian Timmerer
   Alpen-Adria University Klagenfurt

   Email: christian.timmerer@itec.aau.at


   Aytac Azgin
   Huawei

   Email: aytac.azgin@huawei.com


   Will (Shucheng) Liu
   Huawei

   Email: liushucheng@huawei.com


   Christopher Mueller
   BitMovin

   Email: christopher.mueller@bitmovin.net


   Andrea Detti
   University of Rome Tor Vergata

   Email: andrea.detti@uniroma2.it

   Daniel Corujo
   Instituto de Telecomunicacoes Aveiro

   Email: dcorujo@av.it.pt


   Jianping Wang
   City University of Hong Kong

   Email: jianwang@cityu.edu.hk


   Marie-Jose Montpetit
   MIT

   Email: marie@mjmontpetit.com


   Niall Murray
   Athlone Institute of Technology

   Email: nmurray@research.ait.ie