Skip to main content

Problem Statement of Peer-to-Peer Streaming Protocol (PPSP)

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 6972.
Authors Yunfei Zhang , Gonzalo Camarillo , Y. Richard Yang
Last updated 2011-12-16 (Latest revision 2011-11-15)
Replaces draft-zhang-ppsp-problem-statement
RFC stream Internet Engineering Task Force (IETF)
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 6972 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Needs a YES.
Responsible AD Wesley Eddy
IESG note
Send notices to,
PPSP                                                           Y. Zhang
Internet Draft                                             China Mobile
                                                        Yale University
Intended status: Informational                         November 14, 2011
Expires: May 2012

        Problem Statement of Peer-to-Peer Streaming Protocol (PPSP)


   Peer-to-Peer(P2P for short) streaming systems show more and more
   popularity in current Internet with proprietary protocols. This
   document identifies problems of the proprietary protocols, proposes a
   Peer to Peer Streaming Protocol(PPSP) including tracker and peer
   signaling components, and discusses the scope and uses cases of PPSP.

zhang                   Expires May 14, 2012                  [Page 1]
Internet-Draft        Problem Statement of PPSP          November 2011

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on May 7, 2012.

Copyright Notice

   Copyright (c) 2011 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
   ( 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. Code Components extracted from this document must include
   Simplified BSD License text as described in Section 4.e of the Trust
   Legal Provisions and are provided without warranty as described in
   the Simplified BSD License.

zhang                   Expires May 14, 2012                  [Page 2]
Internet-Draft        Problem Statement of PPSP          November 2011

Table of Contents

   1. Introduction ................................................ 4
   3. Problem statement ........................................... 8
      3.1. Difficulties for ISPs in deploying P2P caches ...........8
      3.2. Difficulties in building open streaming delivery
      infrastructure .............................................. 8
      3.3. Difficulties in mobile and wireless environment..........9
      3.4. Difficulties for resource-constrained terminals to run
      multiple background programs at the same time ............... 10
   4. PPSP:Standard peer to peer streaming protocols .............. 11
   5. Use cases of PPSP ........................................... 14
      5.1. Worldwide provision of open P2P live streaming services. 14
      5.2. CDN supporting P2P streaming ........................... 15
      5.3. PPSP supporting cross-screen streaming in heterogeneous
      environment ................................................. 16
      5.4. Supporting P2P streaming in cellular mobile network..... 16
      5.5. Cache service supporting P2P streaming ................. 17
   6. Security Considerations ..................................... 19
   7. IANA Considerations ......................................... 20
   8. Acknowledgments ............................................. 21
   9. Informative References ...................................... 22

zhang                   Expires May 14, 2012                  [Page 3]
Internet-Draft        Problem Statement of PPSP          November 2011

1. Introduction

   Streaming traffic is among the fastest growing traffic on the
   Internet. As Cisco Visual Network Traffic index measured, video
   streaming already generates the largest volume of Internet traffic in
   the year of 2010, and the percentage is expected to rise to as high
   as 91% of the total Internet traffic by 2014[Cisco].

   There are two basic architectures for delivering streaming traffic on
   the Internet: the client-server paradigm and the Peer-to-Peer (P2P)
   paradigm [Survey]. The basic advantage of the P2P paradigm is its
   scalability and fault tolerance against failures of centralized
   infrastructures. As an example, PPLive [PPLive], one of the largest
   P2P streaming vendors, is able to distribute large-scale, live
   streaming programs such as the CCTV Spring Festival Gala to more than
   3 million users with only a handful of servers. It can also deliver
   VoD streaming to a scale of some hundred of thousands simultaneous
   users using the same structure and similar protocols [VoD]. The
   effect of P2P technologies is also well demonstrated in delivering
   real and VoD streaming effectively in current practice like CNN [CNN],
   PPstream [PPStream],UUSee [UUSee]and CNTV[CNTV]. The latest release
   of Adobe Flash, a major platform of streaming distribution in the
   Internet, has also introduced Cirrus [Cirrus], a peer assisted data
   exchange mode. One point that should also be noted is that P2P
   approach requires more resources and computational power on the
   clients (when compared to client-server architecture), as well as a
   lot of clients to participate in the P2P network for low-lantency,
   high transmission efficiency and low load on servers.

   What's more, along with the new players like CDN providers
   (e.g.,AkamaiNetSession [Akamai], ChinaCache[ChinaCache]) joining in
   the effort of using P2P streaming delivery in providing their content,
   the P2P streaming ecosystem is becoming more complex with diverse
   players varying from the media source, infrastructure side, edge
   delivery side even to the heterogeneous types of peer or client
   device platforms..

   Given the increasing integration of P2P streaming into the global
   content delivery infrastructure, the lack of an open, standard P2P
   streaming signaling protocol suite becomes a major missing component
   in the protocol stack. Almost all of these systems use their
   proprietary signaling protocols. Multiple, similar but proprietary
   signaling protocols result in repetitious development efforts for new
   systems, and the lock-in effects lead to substantial difficulties in
   their integration. For example, in the enhancement of existing caches
   and CDN systems to support P2P streaming, open protocols may reduce

zhang                   Expires May 14, 2012                  [Page 4]
Internet-Draft        Problem Statement of PPSP          November 2011

   the complexity of the interaction with different P2P streaming

   In this document we propose an open P2P Streaming Protocol, which is
   defined as PPSP, to standardize signaling operations on two important
   components, peer and tracker in P2P streaming systems for information
   exchange. The problems of proprietary signaling protocols and benefit
   of PPSP are explained further in section 3.

   PPSP will serve as an enabling technology, building on the
   development experiences of existing P2P streaming systems. Its design
   will allow it to integrate with IETF protocols on distributed
   resource location, traffic localization, and streaming control and
   data transfer mechanisms for building a complete streaming system or
   updating /integrating existing cache/CDN to support P2P streaming

zhang                   Expires May 14, 2012                  [Page 5]
Internet-Draft        Problem Statement of PPSP          November 2011

2. Terminology and concepts

   Chunk: A chunk is a basic unit of data block organized in P2P
   streaming for storage, scheduling, advertisement and exchange among
   peers [VoD]. A chunk size varies from several KB to several MB in
   different systems. In case of MB size chunk scenario, a sub-chunk
   structure named piece is often defined to fit in a single transmitted
   packet. A streaming system may use different granularities for
   different usage, e.g., using chunks during data exchange, and using a
   larger unit such as a set of chunks during advertisement.

   Content Distribution Network (CDN): A CDN node refers to a network
   entity that is deployed in the network (e.g., at the network edge or
   data centers) to store content provided by the original servers, and
   serves content to the clients located nearby topologically.

   Client: A client refers to the service requester in client/server
   computing paradigm. In this draft a client refers to a participant in
   a P2P streaming system that only receives streaming content. In some
   cases the node is not eligible to be a peer without enough computing
   and storage capability is acting as a client. It can be viewed as a
   specific kind of peer.

   Live streaming: It refers to a scenario where all clients receive
   streaming content for the same ongoing event. It is desired that the
   lags between the play points of the clients and that of the streaming
   source be small.

   P2P cache: A P2P cache refers to a network entity that caches P2P
   traffic in the network, and either transparently or explicitly as a
   peer distributes content to other peers.

   Peer: A peer refers to a participant in a P2P streaming system that
   not only receives streaming content, but also stores and uploads
   streaming content to other participants.

   PPSP: The abbreviation of Peer-to-Peer Streaming Protocols. PPSP
   refer to the key signaling protocols among various P2P streaming
   system components, including the tracker and the peer.

   Swarm: A swarm refers to a group of peers who exchange data to
   distribute chunks of the same content(e.g. video/audio program,
   digital file, etc) at a given time.

zhang                   Expires May 14, 2012                  [Page 6]
Internet-Draft        Problem Statement of PPSP          November 2011

   Tracker: A tracker refers to a directory server which maintains a
   list of peers which participate in a specific video channel or in the
   distribution of a streaming file, and answers queries from peers for
   peer lists. The tracker is a logical component which can be
   centralized or distributed.

   Video-on-demand (VoD): It refers to a scenario where different
   clients may watch different parts of the same recorded media with
   downloaded content.

zhang                   Expires May 14, 2012                  [Page 7]
Internet-Draft        Problem Statement of PPSP          November 2011

3. Problem statement

   The problems imposed by proprietary signaling for P2P streaming
   applications are listed as follows.

3.1. Difficulties for ISPs in deploying P2P caches

   Facing with many P2P streaming applications, ISPs are witnessing a
   big traffic tension on their backbone and inter-networking points.P2P
   caches are used to reduce the traffic by dynamically storing the
   frequently accessed streaming content (maybe in chunk or in file
   granularity). However, the cache nodes need to execute DPI (deep
   packet inspection) for identifying different P2P streaming systems.
   Multiple ever changing proprietary P2P streaming protocols require
   the P2P cache updating its matching library constantly which
   increases the operator's cost dramatically.

   With PPSP, P2P caches should be able to detect P2P streaming
   applications much easier without needing to update its library, as
   there should be only a single protocol to be detected and not a
   potentially unknown set of proprietary P2P protocols. This would
   reduce the ISP workload to a large extent. Note that using standard
   PPSP would not hurt current P2P streaming providers: Firstly, the
   openness of signaling interaction would make it easy to integrate
   them with ISP's caches for better user experience, say, smaller delay
   of the play. Secondly, different applications could use PPSP for
   signaling, but implement something system specific on top of that.
   That is to say, different P2P streaming systems compete on "on top"
   things, like scheduling algorithms, which is independent of how the
   peers exchange chunk availability. In other words, different systems
   should be able to have quite different scheduling algorithms with
   same tracker/peer protocol, which is easier to be open.

3.2. Difficulties in building open streaming delivery infrastructure

   More and more efforts are seeking for building an open global
   streaming delivery infrastructure, where systems using P2P account
   for a large portion. However if current multiple proprietary
   protocols continue to work, there will exist lots of specific and
   independent systems to deliver vastlythe same streaming content. This
   brings more burdens for identifying and sharing the same contents,
   and increases the storage, forwarding and maintenance cost in the
   intermediate nodes for repeated content. This will definitely
   increase the cost of streaming distribution and causes possible
   congestion in the network.

zhang                   Expires May 14, 2012                  [Page 8]
Internet-Draft        Problem Statement of PPSP          November 2011

   Consider a case where source vendors cooperate with 3rd party CDN
   providers. Such integration is already practiced by UUSee[UUSee],
   RayV[RayV] and Forcetech[Forcetech]. The effect has been verified to
   improve the total performance of P2P streaming (e.g., with lower
   latency) by providing more stable "super peers" and reduce traffic
   for ISP [CDN+P2P] [RFC 5693].However, there are substantial obstacles
   for CDN nodes supporting proprietary P2P streaming protocols [HPTP].
   Unlike the Web where all kinds of the infrastructure devices have
   been already equipped with standard HTTP protocol, an open CDN
   supporting various P2P streaming applications need to understand and
   keep updated on various protocols. Similar to the caching case in
   Section 3.1, this introduces complexity and deployment cost.

   With PPSP, CDN nodes can be designed to inter-operate with other
   devices by only standard protocols, reducing the case by case
   negotiation between the P2P streaming providers and CDN providers.On
   the other side, the interface between CDN nodes and user peers could
   be via something like traditional HTTP requests, or could be via PPSP
   for streaming setup.

3.3. Difficulties in mobile and wireless environment

   Mobility and wireless are becoming increasingly important features in
   today's Internet. It is predicted that by the end of 2012, the number
   of mobile Internet users will surpass that of fixed Internet users in
   China [Statistics]. Mobile streaming has becoming a key offering. In
   Korea the number of mobile TV subscriber has reached seventeen
   million, accounting for one third of the mobile subscribers. During
   the 2008 Beijing Olympic Games, more than one million users enjoyed
   mobile TV service. There are multiple prior studies exploring P2P
   streaming in mobile and wireless networks [Mobile Streaming1] [Mobile

   However it's difficult to copy current P2P streaming protocols in
   mobile and wireless networks. Current protocols are designed mainly
   for fixed Internet. Although smart handsets are more eligible to be
   peers with much better bandwidth and higher CPU frequency, larger
   storage and memory than before, peer selection is more challenging
   which needs more information to exchange during the tracker/peer and
   peer/peer communications: First, in mobile and wireless networks, the
   connections are unsteady, lower rate, and costly in terms of energy
   consumption and transmission(esp. in uplink). The trackers and peers
   may need more information, compared to fixed Internet, like packet
   loss rate, peer battery status and processing capability for peer
   selection. Note that not all mobile nodes are eligible to be peers.
   Second, current practices often use a "bitmap" message to exchange
   chunk availability among peers/trackers. The message is often of some

zhang                   Expires May 14, 2012                  [Page 9]
Internet-Draft        Problem Statement of PPSP          November 2011

   kilobytes size and exchanged relatively frequently. In the mobile
   networks, the bandwidth is scarce and a reasonable optimization is to
   reduce the message size, whichmay require alternative methods for
   expressing and distributing bitmap information. Third, mobility issue.
   When a peer is moving and the IP address changes, the on-going
   connection and transmission between peers may be affected. Therefore
   such information should be reported in time, which is not addressed
   in current practices.

   PPSP should investigate these factors for a practical converged
   network from the beginning of the design.

3.4. Difficulties for resource-constrained terminals to run multiple
   background programs at the same time

   Private protocols may require a terminal to install different
   software for different applications. Note that for many client
   software, even it's not used by the users right now, the background
   program may be invoked to facilitate other peers for free data
   delivery assistance. In other words, there will be multiple
   background programs running at the same time. However it may be
   difficult to invoke multiple programs in a resource constraint peer
   like mobile handsets or settop boxes (STBs). The limited CPU, storage
   and memory often limit the total number of concurrent threads and
   processes. Taking storage for example, according to
   [PPStream][UUSee][PPLive Design], the buffer of each peer's hard disk
   contributed to the system is at least 1GB. If each mobile peer, like
   iPhone (version 1) runs two such background applications at the same
   time, the storage cannot be shared for different applications and it
   will consume one fourth of all its storage (8 GB), leaving other data
   with fewer storage.

   PPSP can help to reduce the resource consumption like RAM usage on
   resource constraint devices, such as STBs or mobile phones, by
   reusing a PPSP base library and potentially other optimizations.

zhang                   Expires May 14, 2012                 [Page 10]
Internet-Draft        Problem Statement of PPSP          November 2011

4. PPSP:Standard peer to peer streaming protocols

   The objective of the PPSP working group is to design a unified peer-
   to-peer streaming protocol (PPSP) to address the problems discussed
   in the preceding sections.

   There are basically two kinds of P2P streaming systems, pull-based
   and push-based.

   In pull-based P2P streaming systems, a centralized tracker or
   distributed trackers maintains information about which peers are in
   which swarms and answers the peers' query on such information with a
   peer-list. After receiving the message, the peer can connect with the
   candidates in a swarm, exchange its content availability in its
   memory or storage (depending on it's real-time or VoD streaming) with
   other peers and then retrieve the wanted streaming data. The swarm is
   a mesh topology. Most of the current practices belong to this genre.
   The advantages of pull-based mode are its robustness to the peer
   churn and acceptable latency for a smooth play.

   In push-based P2P streaming systems, there is a head node maintaining
   the topology, e.g., a tree. The peers in this topology share the same
   interest on content. The signaling and data distribution are both
   based on this topology. For one program or video file, the peer
   queries the head node by offline or pre-set head node address
   information for its location to join and the head node replies with a
   peer-list(potentially in a recommended order). After receiving this
   peer-list, the peer can connect with the candidates for being a node
   in certain place of the topology and receive the data along this
   topology without the need of exchanging content availability with its
   siblings, as done in pull-based mode. In this sense the head node is
   acting as the tracker in the pull-based mode. The push mode has the
   advantages of lower latency but the topology is fragile to the peer
   churn. Few commercially deployed systems use this mode.

   A more practical mode is a hybrid pull-push mode where the peers join
   the system in the same way as in push-based mode while also exchange
   content availability with its siblings for retrieving requsted data,
   just like pull-based mode.

   In live streaming, all peers are interested in the media coming from
   an ongoing event, which means that all peers share nearly the same
   streaming content at a given point of time. In live streaming, some
   peers may store the live media for further distribution, which is

zhang                   Expires May 14, 2012                 [Page 11]
Internet-Draft        Problem Statement of PPSP          November 2011

   known as TSTV (time-shift TV), where the stored media are separated
   into chunks and distributed in a VoD-like manner.

   In VoD, different peers watch different parts of the recorded media
   content during a past event. In this case, each peer keeps asking
   other peers which media chunks are stored in which peers, and then
   gets the required media from certain/selected peers.

   To sum up, in essence, there are two important entities in P2P
   streaming, i.e., trackers and peers in P2P streaming systems. PPSP
   includes standard signaling protocols for tracker-based architectures
   that support either live or offline streaming.

   The PPSP design includes a protocol for signaling between trackers
   and peers (the PPSP "tracker protocol") and a signaling protocol for
   communication among the peers (the PPSP "peer protocol") as shown in
   Figure 1.The two protocols enable peers to receive streaming data
   within the time constraints required by specific content items. The
   tracker protocol handles the initial and periodic exchange of meta
   information between trackers and peers, such as peer-list and content
   information. The peer protocol controls the advertising and exchange
   of media data between the peers.

   Note that in the pull mode and hybrid pull-push mode, both tracker
   protocol and peer protocol can be used; while in the push mode, only
   tracker protocol is used.

zhang                   Expires May 14, 2012                 [Page 12]
Internet-Draft        Problem Statement of PPSP          November 2011

             |                                                |
             |     +--------------------------------+         |
             |     |            Tracker(Head Node)  |         |
             |     +--------------------------------+         |
             |        |     ^                   ^             |
             |Tracker |     | Tracker           |Tracker      |
             |Protocol|     | Procotol          |Protocol     |
             |        |     |                   |             |
             |        V     |                   |             |
             |     +---------+    Peer     +---------+        |
             |     |   Peer  |<----------->|   Peer  |        |
             |     +---------+   Protocol  +---------+        |
             |       | ^                                      |
             |       | |Peer                                  |
             |       | |Protocol                              |
             |       V |                                      |
             |     +---------------+                          |
             |     |      Peer     |                          |
             |     +---------------+                          |
             |                                                |
             |                                                |
                     Figure 1 PPSP System Architecture

zhang                   Expires May 14, 2012                 [Page 13]
Internet-Draft        Problem Statement of PPSP          November 2011

5. Use cases of PPSP

5.1. Worldwide provision of open P2P live streaming services

   The cooperative content providers can easily expand the broadcasting
   scale with PPSP. In figure 2 shows the case that provider A
   broadcasts the program with the help of provider B and C for a wider
   coverage. The content providers often deploy in-network peers called
   super-nodes (SN for short) with better stability and higher storage
   and bandwidth compared with user peers for better QoS.  The
   interaction between A's tracker and vendor B and vendor C's SNs can
   be normalized using tracker protocol; and peer protocol can be used
   among SNs/peers spread in different vendors.

   |                                                                   |
   |                          +------------------+                     |
   |            +------------>| A's      Tracker |<----------+         |
   |            |             +------------------+           |         |
   |     Tracker|                ^              ^            |         |
   |    Protocol|         Tracker|              |Tracker     |Tracker  |
   |            |        Protocol|              |Protocol    |Protocol |
   |            |                |              |            |         |
   |            |                |              |            |         |
   |            v                v              v            v         |
   |      +------+ Peer    +------+            +------+    +------+    |
   |      | B's  |<------->| B's  |            | C's  |    | C's  |    |
   |      | SN1  |Protocol | SN2  |            | SN1  |    | SN2  |    |
   |      +------+         +------+            +------+    +------+    |
   |         ^  ^                                           ^ ^        |
   |         |  |                                           | |        |
   |         |  | Peer Protocol                Peer Protocol| |        |
   | Peer    |  +-------------+              +--------------+ |Peer    |
   | Procotol|                |              |                |protocol|
   |         |                |              |                |        |
   |         |                |              |                |        |
   |         |                |              |                |        |
   |         v                v              v                v        |
   |      +------+ Peer    +------+    +---------+  Peer   +---------+ |
   |      | A's  |<------> | B's  |    |A's      |<------> |C's      | |
   |      | User1|Protocol | User2|    | User1   |Protocol | User2   | |
   |      +------+         +------+    +---------+         +---------+ |
   |                                                                   |
                 Figure 2 Cooperative Vendors Interaction

zhang                   Expires May 14, 2012                 [Page 14]
Internet-Draft        Problem Statement of PPSP          November 2011

5.2. CDN supporting P2P streaming

   This scenario is similar to use case 1 except that the intermediate
   SNs are replaced by 3rd party CDN surrogates with PPSP. The P2P
   streaming vendors A and B can rent CDN surrogates to provide higher
   QoS services for VIP users than services provides by only ordinary
   peers. The interaction among these network entities are shown in
   Figure 3. The CDN nodes talk with the different trackers and peers
   with the uniform Tracker and peer protocols. It can also communicate
   with end users using HTTP for legacy equipments. The internal
   interaction of CDN nodes can be executed by either original internal
   protocol or new peer protocol. The latter is used when building a new
   CDN system supporting streaming applications with low cost deploying
   P2P delivery inside the network.

   |                                                                   |
   |                   +-------------+    +--------------+             |
   |            +----->| A's Tracker |    |  B's Tracker |<---+        |
   |            |      +-------------+    +--------------+    |        |
   |     Tracker|              ^  ^        ^    ^             |        |
   |    Protocol|       Tracker|  |Tracker |    |Tracker      |Tracker |
   |            |      Protocol|  |Protocol|    |Protocol     |Protocol|
   |            |              |  |        |    |             |        |
   |            |              |  |        |    |             |        |
   |            v              v  |        |    v             v        |
   |      +------+ Peer   +------+|        |  +------+Internal+------+ |
   |      | CDN  |<------>| CDN  ||        |  | CDN  |<-----> | CDN  | |
   |      | Node1|Protocol| Node2||        |  | Node3|Protocol| Node4| |
   |      +------+        +------+|        |  +------+        +------+ |
   |         ^  ^                 |        |        ^         ^        |
   |         |  |                 |        |        |         |        |
   |         |  | Peer Protocol   |        |   HTTP |         |        |
   | Peer    |  +-------------+   |        | +------+         | Peer   |
   | Procotol|                |   |        | | Protocol       |protocol|
   |         |                | +-+        | |                |        |
   |         |                | |          | |                |        |
   |         |                | |          | |                |        |
   |         v                v v          v v                v        |
   |      +------+ Peer    +------+    +---------+  Peer   +---------+ |
   |      | A's  |<------> | A's  |    |B's      |<------> |B's      | |
   |      | User1|Protocol | User2|    | User3   |Protocol | User4   | |
   |      +------+         +------+    +---------+         +---------+ |
   |                                                                   |
                   Figure 3 CDN Supporting P2P Streaming

zhang                   Expires May 14, 2012                 [Page 15]
Internet-Draft        Problem Statement of PPSP          November 2011

5.3. PPSP supporting cross-screen streaming in heterogeneous environment

   In this scenario PC, Setbox/TV and mobile terminals from both fixed
   network and mobile network share the content they store/cache. Peers
   from heterogeneous networks

   With PPSP,peers can identify the types of access networks, average
   load, peer abilities and get to know what content other peers have
   (potentially with the conversion of the content availability
   expression in different networks) even in different network
   conditions as shown in Figure 4. These information will play an
   important role on selecting suitable peers, e.g., a PC or STB node is
   more likely to be selected to provide stable content for mobile nodes;
   a mobile peer within a high-load base station is unlikely to be
   selected, which may lead to higher load on the base station.

   |                                                                   |
   |      Tracker Protocol  +---------+   Tracker Protocol             |
   |        +-------------> | Tracker |<------------------+            |
   |        |               +---------+                   |            |
   |        |                    ^                        |            |
   |        |                    |                        |            |
   |        |                    |                        |            |
   |        V                    |                        V            |
   |    +------+                 |                +------------+       |
   |    |  STB |           Tracker Protocol       |Mobile Phone|       |
   |    +------+                 |                +------------+       |
   |        ^                    |                        ^            |
   |        |                    |                        |            |
   |        |                    |                        |            |
   |        |                    V                        |            |
   |        |Peer Protocol  +---------+    Peer Protocol  |            |
   |        +-------------> |    PC   |<------------------+            |
   |                        +---------+                                |
   |                                                                   |
         Figure 4 Heterogeneous P2P Streaming Interaction with PPSP

5.4. Supporting P2P streaming in cellular mobile network

   In a cellular mobile environment like 3G or 4G, with the increase in
   bandwidth and smart mobile terminal capabilities, P2P (including

zhang                   Expires May 14, 2012                 [Page 16]
Internet-Draft        Problem Statement of PPSP          November 2011

   P2Pstreaming ) is easier to be realized than before. In a provincial
   network of China Mobile, P2P has accounted for more than 30
   percentage of the traffic, ranked second.

   Note that the mobile terminals are not compulsorily to be peers. Here
   they act as clients. Network peers who are deployed by the ISPs or
   operators and mobile peers with WiFi connections are more likely to
   be selected. For example, in 3GPP, there is a P2P Content
   Distribution Service (P2P CDS) work item working on the requirement
   of mobile operators to prefer use deployed network-side equipments
   (e.g., serving gateways or GGSNs, one access point from cellular
   mobile network to the Internet) to act as super-peers when there are
   no enough eligible peers to realize P2P streaming[P2P CDS]. Because
   they are deployed by the operators, the stability and storage size
   are better guaranteed than ordinary peers.

   Similar with case 5.3, PPSP tracker protocol will help to identify
   and return the super-peers in the peer-list with preference. If
   mobile terminals are not eligible to be peers, they can simply
   receive data from these super-peers without contributing any data to

5.5. Cache service supporting P2P streaming

   To greatly decrease the inter-network traffic and increase user
   experience in P2P streaming services, an ISP may deploy cache service
   in its network.

   In Figure 5, When peers request the P2P streaming data, the cache
   nodes intercept the requests and ask for the frequently visited
   content (or part of) on behalf of the user peers. To do this, it
   requests peer-list to the tracker and the tracker replies with
   (outward) peers. After the cache nodes exchange data with these peers,
   it can report what it cache to the tracker like a normal peer and
   serve other requesting peers inside.

   The cache nodes needn't update their library when new applications
   supporting PPSP are introduced, which enable the cache nodes spend
   less cost to support more applications.

zhang                   Expires May 14, 2012                 [Page 17]
Internet-Draft        Problem Statement of PPSP          November 2011

   |                                                                |
   |  0:Tracker Protocol +---------+                                |
   |  +----------------> | Tracker |                                |
   |  |                  +---------+                                |
   |  |                       ^                                     |
   |  |                       |                                     |
   |  |                    2: | Tracker Protocol                    |
   |  |                       |                                     |
   |  |                       |                                     |
   |  |             +---------|-------------------------------------|
   |  |             |         V                                     |
   |  |             |     +---------+                               |
   |  |  +----------|---> | Cache   |<-------------------+          |
   |  |  |          |     +---------+   1,4: Tracker/Peer|          |
   |  |  |3: Peer   |                       Protocol     |          |
   |  |  | Protocol |                                    |          |
   |  |  |          |                                    |          |
   |  |  |          |                                    |          |
   |  V  V          |                                    V          |
   |  +-----------+ |        ISP Domain             +------------+  |
   |  |  Outward  | |                               |   Inside   |  |
   |  |  Peer     | |                               |   Peer     |  |
   |  +-----------+ |                               +------------+  |

           Figure 5 Cache Service Supporting Streaming with PPSP

zhang                   Expires May 14, 2012                 [Page 18]
Internet-Draft        Problem Statement of PPSP          November 2011

6. Security Considerations

   This document discusses the problem statement around Peer-to-Peer
   streaming protocols without specifying the protocols. The protocol
   specification is deferred to other documents under development in the
   PPSP working group. However we believe it is important for the reader
   to understand areas of security caused by the P2P nature of the
   proposed solution. The main issue is the usage of untrusted entities
   (peers) for service provisioning.

   Malicious peers may, for example:

   - Issue denial of service (DOS) attacks to the trackers by sending
   large amount of requests with the tracker protocol;

   - Issue fake information on behalf of other peers;

   - Issue fake information about available content;

   - Issue fake information about chunk availability;

   Malicious peers/trackers may, for example:

   - Issue reply instead of the regular tracker (man in the middle

   The PPSP protocol specifications, e.g., the tracker protocol and the
   peer protocol, will document the expected threats and how they will
   be mitigated for each protocol, but also considerations on threats
   and mitigations when combining both protocols in an application. This
   will include privacy of the users, protection of the content
   distribution, but not protection of the content by Digital Rights
   Management (DRM).

zhang                   Expires May 14, 2012                 [Page 19]
Internet-Draft        Problem Statement of PPSP          November 2011

7. IANA Considerations

   This document has no actions for IANA.

zhang                   Expires May 14, 2012                 [Page 20]
Internet-Draft        Problem Statement of PPSP          November 2011

8. Acknowledgments

   We would like to acknowledge the following people who provided review,
   feedback and suggestions to this document: M. Stiemerling; C. Schmidt;
   D. Bryan; E. Marocco; V. Gurbani; R. Even; H. Zhang; L. Xiao; C.
   Williams; V. Pasual; D. Zhang; J. Lei.

   This document was prepared using

zhang                   Expires May 14, 2012                 [Page 21]
Internet-Draft        Problem Statement of PPSP          November 2011

9. Informative References

   [RFC 5693] Application-Layer Traffic Optimization (ALTO) Problem
             Statement, E. Marocco et al,

   [Cisco] Cisco Visual Networking Index: Forecast and Methodology,


   [VoD] Yan Huang et al,Challenges, "Design and Analysis of a Large-
             scale P2P-VoD System", Sigcomm08.





   [Cirrus] Cirrus, Use RTMFP for developing real-time collaboration

   [Akamai] Peer-to-Peer Systems, Rodrigo Rodrigues et al,
             Communications of the ACM,Vol. 53,No. 10, Pages 72-82.

   [ChinaCache] RawFlow partners with ChinaCache: Creating Asia's
                 largest P2P powered live media delivery network,

   [Survey] Yong Liu et al,"A survey on Peer-to-Peer video streaming
             systems", Peer to Peer Networking and Applications,Volume 1,
             Number 1,18-28,Springer,2008.


zhang                   Expires May 14, 2012                 [Page 22]
Internet-Draft        Problem Statement of PPSP          November 2011


   [CDN+P2P] H. Jiang et al,"Efficient Large-scale Content Distribution
             with Combination of CDN and P2P Networks", International
             Journal of Hybrid Information Technology, Vol.2, No.2,
             April, 2009.

   [HPTP] HPTP: Relieving the Tension between ISPs and P2P, Guobin Shen
             et al, IPTPS 2007.

   [Statistics] China's mobile Internet users to surpass Internet users
                 in 2012,

   [P2P CDS] 3GPP TR 22.906, Study on IMS based Peer-to-Peer content
             distribution services,

   [Mobile Streaming1] Streaming to Mobile Users in a Peer-to-Peer
                        Network,Jeonghun Noh et al,MOBIMEDIA '09.

   [Mobile Streaming2] J. Peltotaloet al.,"A real-time Peer-to-Peer
                        streaming system for mobile networking environment",
                        MoVID '09.
   [PPLive Design] Y. Huang et al ,"Challenges, design and analysis of a 
                    large-scale P2P-vod system", ACM SIGCOMM Computer 
                    Communication Review,38(4):375-388, 2008.

zhang                   Expires May 14, 2012                 [Page 23]
Internet-Draft        Problem Statement of PPSP          November 2011

Authors' Addresses

   Yunfei Zhang
   China Mobile Communication Corporation

   Huawei Technologies Co., Ltd.

   Gonzalo Camarillo

   James Seng

   Richard Yang
   Yale University

zhang                   Expires May 14, 2012                 [Page 24]