PPSP                                                             Y.Zhang
Internet Draft                                              China Mobile
Intended status: Informational                                    N.Zong
                                                         Yale University
                                                            July 4, 2011
Expires: January 2012

             Problem Statement of P2P Streaming Protocol (PPSP)

Status of this Memo

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

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November 10,
   2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

   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

Zhang                  Expires January 4, 2012                [Page 1]

Internet-Draft        Problem statement of PPSP              July 2011

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

   This Internet-Draft will expire on January 4, 2009.

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


   P2P streaming systems show more and more popularity in current
   Internet with proprietary protocols. This document identifies
   problems of the proprietary protocols, proposes standard signaling
   protocols called PPSP and discusses the scope and use cases of PPSP.

Zhang                  Expires January 4, 2012                [Page 2]

Internet-Draft        Problem statement of PPSP              July 2011

Table of Contents

   1. Introduction ................................................ 3
   2. Conventions used in this document............................ 5
   3. Problem statement ........................................... 6
      3.1. Difficulties for ISP in deploying P2P caches ........... 6
      3.2. Difficult interactionies in building open streaming delivery
      infrastructure .............................................. 6
      3.3. Difficulties with in mobile and wireless environment.....7
      3.4. Difficulties for resource-constraint tTerminals to run
      different daemons at the same time........................... 8
   4. PPSP:Standard peer to peer streaming protocols ...............9
   5. Use cases of PPSP .......................................... 12
      5.1. Worldwide provision of open P2P live streaming services.12
      5.2. CDN supporting P2P streaming........................... 13
      5.3. PPSP supporting cross-screen streaming in heterogeneous
      environment ................................................ 14
      5.4. Supporting P2P streaming in cellular mobile network.....14
      5.5. Cache service supporting P2P streaming .................15
   6. Security Considerations..................................... 17
      6.1. Tracker Protocol....................................... 17
      6.2. Peer Protocol ......................................... 17
   7. References ................................................. 18
   8. Acknowledgments ............................................ 20

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

Zhang                  Expires January 4, 2012                [Page 3]

Internet-Draft        Problem statement of PPSP              July 2011

   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

   What's more, along with the new players like CDN vendors (e.g.,Akamai
   [Akamai], ChinaCache[ChinaCache]) and ISPs(e.g., ComCast
   [ComCast])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 source, infrastructure
   side, edge delivery side even to the heterogeneous kinds of terminals.

   Given the increasing integration of P2P streaming into the global
   content delivery infrastructure, the lacking of an open, standard P2P
   streaming signaling protocol suite becomes a major missing component
   in the protocol stack. Almost all 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, the open protocols will
   dynamically reduce the complexity of the interaction with different
   P2P streaming applications.

   In this document we propose an open P2P streaming protocol named 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/routers to support P2P
   streaming delivery.

Zhang                  Expires January 4, 2012                [Page 4]

Internet-Draft        Problem statement of PPSP              July 2011

2. Conventions used in this document

   Chunk: A chunk is a basic unit of partitioned streaming. Peers may
   use a chunk as a unit of storage, advertisement and exchange among
   peers [VoD]. Note that a streaming system may use different units for
   advertisement and data exchange, using chunks during data exchange,
   and 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.

   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 P2P 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 clients (i.e., peers) who exchang
   data to distribute the same content (e.g. video/audio program,
   digital file, etc) at a given time.

   Tracker: A tracker refers to a directory server which maintains a
   list of peers storing chunks for a specific channel or streaming file,
   and answers queries from peers for peer lists. The tracker is a logic
   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 content
   during a past event.

Zhang                  Expires January 4, 2012                [Page 5]

Internet-Draft        Problem statement of PPSP              July 2011

3. Problem statement

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

3.1. Difficulties for ISP in deploying P2P caches

   Facing with many P2P streaming applications, ISPs are witnessing a
   big traffic tension on their backbone and inter-networking ports.P2P
   cache is 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 cache can detect P2P streaming applications much
   easier without needing to update its library. This reduces the ISP
   workload to a large extent. Note that using standard PPSP won't hurt
   current P2P streaming vendors : Firstly, the openness of signaling
   interactions makes it easy to integrate them with ISP's caches for
   better user experience, say, smaller delay of the play. Secondly, the
   variation in different P2P streaming systems mainly lies in how the
   chunks are scheduled to transfer rather than how the chunks
   availability information is exchanged. The latter is the core of PPSP,
   which is easiest to be open.

3.2. Difficult interactionies in building open streaming delivery

   The future Internet is content-centric [CCN][DONA]because the vast
   majority of current Internet usage (a "high 90% level of
   traffic"[Van]) consists of data. Most of the content-centric works
   are seeking for building an open global content delivery
   infrastructure,where P2P streaming data delivery is going to 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 vast of same streaming content. This
   brings more burdens for identifying and sharing the same contents,
   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 January 4, 2012                [Page 6]

Internet-Draft        Problem statement of PPSP              July 2011

   Consider a case where source vendors cooperate with 3rd party CDN.
   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 [HTPT]. 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 cache case, 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 source providers and CDN providers. Note
   again that we just focus on the standard data availability
   information interaction between tracker (maybe hosted by the source
   provider) and CDN nodes, among CDN nodes. The scheduling of data
   among CDN nodes keeps intact. The interaction between CDN nodes and
   user peers can be either client/server communication using HTTP or
   peer to peer communication using PPSP.

3.3. Difficulties with in mobile and wireless environment

   Mobility and wireless are becoming increasingly important features in
   future Internet deployments [GENI], [FIND]. 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 [MobileTV]. In Korea the number of mobile
   TV subscriber has reached seventeen millions, 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 more and more studies exploring P2P streaming in mobile and
   wireless networks[Mobile Streaming1] [Mobile Streaming2]

   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 and costly(esp. in uplink). The
   trackers and peers 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

Zhang                  Expires January 4, 2012                [Page 7]

Internet-Draft        Problem statement of PPSP              July 2011

   peers. The new-added information should help the tracker/peer to make
   the decision. Second, current practices often use a "bitmap" message
   to exchange chunk availability among peers/trackers. The message is
   often of some kilobytes size and relatively frequent to exchange. In
   the mobile networks, the bandwidth is scarce and a reasonable
   optimization is to reduce the message size, which maybe requires a
   new expression on "bitmap". Third, mobility issue. If a peer is
   moving from one serving gateway (e.g., GGSN) to another, the  IP
   address will be changed. It may affect the on-going connection and
   transmission between peers. 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-constraint tTerminals to run different
   daemons at the same time

   Private protocols may require a terminal to install multiple software
   at the same time. For example a user installs CBox for CCTV programs
   [CNTV], and PPLive for Japanese and Korean movies [PPLive]. However
   it may be difficult to install multiple clients in one resource
   constraint peer like mobile handsets. The limited CPU, storage and
   memory often limit the total number of installed applications as well
   as concurrent threads and processes. Note that for many client
   software, even it's not used by the users right now, the daemon may
   be invoked to facilitate other peers for free data delivery
   assistance. 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 2 such 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.

   With PPSP,there is possibility to use one client software to support
   different applications because the peers can communicate with
   different trackers/peers with the same protocols and shared
   buffer( memory and storage). Thus even using different applications
   at the same time, resource constraint dilemma is largely reduced. The
   only distinction for different applications lie in different plug-ins
   (e.g., scheduling algorithms).

Zhang                  Expires January 4, 2012                [Page 8]

Internet-Draft        Problem statement of PPSP              July 2011

4. PPSP:Standard peer to peer streaming protocols

   The objective of this working group is to design PPSP, unified peer
   to peer streaming protocols to address the problems discussed in the
   preceding section.

   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 for wanted
   streaming data. The swarm is a mesh topology. Most of the current
   practices are belonging to this genre. The advantages of pull-based
   mode are its robustness to the peer churn and acceptable latency for
   a smooth play.  On the other hand, 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 for its
   location to join and the head node replies with a peer-list(maybe
   with 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. In this sense the
   head node is acting as the tracker. The push mode has the advantages
   of lower latency but the topology is fragile to the peer churn. Few
   practical systems use this mode. A more practical mode is a hybrid
   pull-push mode where the peers exchange content availability with its
   siblings for retrieving unfounded data.

   To sum up, in essence, there are two important entities in P2P
   streaming, i.e., trackers and peers in P2P streaming systems. PPSP is
   targeted to standardize the signaling protocols in this tracker-based
   architectures for supporting both live and VoD streaming.

   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
   known as TSTV (time-shift TV), where the stored media are separated
   into chunks and distributed in a VoD-like manner.

Zhang                  Expires January 4, 2012                [Page 9]

Internet-Draft        Problem statement of PPSP              July 2011

   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.

   In detail, PPSP designs 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.

   What's more, existing protocols should be investigated and evaluated
   for being reused or extended as the proposed protocols, e.g., HTTP.
   Considering that there can be a large number of peers, the protocol
   should consider some lightweight (possibly binary) encoding.

Zhang                  Expires January 4, 2012               [Page 10]

Internet-Draft        Problem statement of PPSP              July 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 January 4, 2012               [Page 11]

Internet-Draft        Problem statement of PPSP              July 2011

5. Use cases of PPSP

5.1. Worldwide provision of open P2P live streaming services

   The cooperative vendors can easily expand the broadcasting scale with
   PPSP. In figure 2 shows the case that vendor A broadcasts the program
   with the help of vendor B and vendor C for a wider coverage. The
   interactions between vendor A's tracker and vendor B and vendor C's
   super-nodes (SN in short) can be normalized using tracker protocol;
   and peer protocol can be used among SNs/peers spread in different

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

Zhang                  Expires January 4, 2012               [Page 12]

Internet-Draft        Problem statement of PPSP              July 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 interactions 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. Also it can talk with
   peers with HTTP if it has complete copy of the requested file. 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 January 4, 2012               [Page 13]

Internet-Draft        Problem statement of PPSP              July 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 networks, their load
   /congestion information, peer abilities and get to know what content
   other peers have (maybe 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 will 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 Interactions 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 P2P
   streaming) 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 except HTTP.

Zhang                  Expires January 4, 2012               [Page 14]

Internet-Draft        Problem statement of PPSP              July 2011

   Note that the mobile terminals are not compulsorily to be peers.
   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 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

   As discussed in the section3, deploying cache nodes in the network
   edges can greatly decrease the inter-network traffic and increase
   user experience in streaming service.

   With PPSP, the cache nodes can identify the P2P streaming genre even
   it may include different applications. When a peer requests the
   streaming data, cache detects the request and requests the frequent
   visited content (or part of) to the original tracker as a normal peer.
   The tracker replies with (outward) peers. After the cache connectes
   with the peers, it can report what it cache to the provider's tracker
   like a normal peer and serve other requesting peers inside to reduce
   the cross-ISP traffic as shown in Figure 5. 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 January 4, 2012               [Page 15]

Internet-Draft        Problem statement of PPSP              July 2011

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

           Figure 5 Cache Service Supporting Streaming with PPSP

Zhang                  Expires January 4, 2012               [Page 16]

Internet-Draft        Problem statement of PPSP              July 2011

6. Security Considerations

   PPSP will not attempt to provide a solution on security and copyright
   issues like malicious content distribution, content pollution and DRM
   for a general P2P streaming system. Instead PPSP security involves
   the security problems related to PPSP protocols. The protocol
   documents will contain a complete description on the security/privacy
   issues relevant to any usage of PPSP.

6.1. Tracker Protocol

   Malicious peers may issue denial of service attack to the trackers by
   sending large amount of requests with tracker protocol. Distributed
   trackers deployment may alleviate the problem.

   On the other hand, malicious peers may report fake information (e.g.,
   cheating trackers and other peers by claiming itself owning some un-
   existing data).

   So it may be optional to realize authentication to the peers before
   accepting the request for the tracker. But this may add up the
   tracker's workload.

   In the above discussion tracker is trustful. Things are worse when
   the malicious peer acts as part of the distributed trackers. The
   malicious acting tracker may reply the peers with fake peer-list.
   Peers may find they cannot find desired data with the fake peer-list.

6.2. Peer Protocol

   Similar to the behavior in the tracker-peer interaction, malicious
   peers may also create fake information on chunk availability and
   exchange it with other peers. Some techniques to check the data
   integrity (e.g., using checksum) may be useful for detecting the data.

Zhang                  Expires January 4, 2012               [Page 17]

Internet-Draft        Problem statement of PPSP              July 2011

7. References

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

   [PPLive] www.pplive.com

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

   [CNN] www.cnn.com

   [PPStream] www.ppstream.com

   [UUSee] www.uusee.com

   [CNTV] www.cntv.com

   [Cirrus] labs.adobe.com/technologies/cirrus/

   [Akamai] Understanding hybrid CDN-P2P: why limelight needs its own
   Red Swoosh, C. Huang et al,Proceedings of the 18th International
   Workshop on Network and Operating Systems Support for Digital Audio
   and Video, May 28-30, 2008, Braunschweig, Germany.



   [CCN] Content-Centric Networking,V. Jacobson,

   [DONA]A Data-Oriented (and Beyond) Network Architecture, T. Koponen
   et al, Sigcomm 2007.

   [Van] A New Way to Look at Networking,Van Jacobson,


Zhang                  Expires January 4, 2012               [Page 18]

Internet-Draft        Problem statement of PPSP              July 2011


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

   [RFC 5693], Application-Layer Traffic Optimization (ALTO) Problem
   Statement, E. Marocco et al, http://datatracker.ietf.org/doc/rfc5693/

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

   [GENI] www.geni.net


   [Statistics] http://labs.chinamobile.com/news/48283

   [P2P CDS] 3GPP TR 22.906, Study on IMS based peer-to-peer content
   distribution services,http://www.3gpp.org/ftp/Specs/html-

   [Mobile Streaming1] Streaming To Mobile Users In A Peer-to-Peer
   Network,Jeonghun Noh et al,MOBIMEDIA '09.

   [Mobile Streaming2] A real-time peer-to-peer streaming system for
   mobile networking environment,J. Peltotalo  et al., "" in Proceedings
   of the INFOCOM and Workshop on Mobile Video Delivery (MoVID '09),
   April 2009.

   [PPLive Design] Challenges, design and analysis of a large-scale p2p-
   vod system, Y. Huang, T. Fu, D. Chiu, J. Lui, and C. Huang. ACM
   SIGCOMM Computer Communication Review, 38(4):375-388, 2008.

Zhang                  Expires January 4, 2012               [Page 19]

Internet-Draft        Problem statement of PPSP              July 2011

8. Acknowledgments

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

Zhang                  Expires January 4, 2012               [Page 20]

Internet-Draft        Problem statement of PPSP              July 2011

   Authors' Addresses

   Yunfei Zhang

   China Mobile Communication Corporation


   Ning Zong

   Huawei Technologies Co., Ltd.


   Gonzalo Camarillo



   James Seng



   Richard Yang

   Yale University


Zhang                  Expires January 4, 2012               [Page 21]