[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-zhang-ppsp-problem-statement) 00 01 02 03 04 05 06 07 08 09 10 11 13 14 15 RFC 6972

PPSP                                                            Y. Zhang
Internet Draft                                              China Mobile
Intended status: Informational                                    N.Zong
                                                              HuaweiTech
                                                             G.Camarillo
                                                                Ericsson
                                                                  J.seng
                                                                  PPlive
                                                                  R.Yang
                                                         Yale University
Expires: July 16, 2011                                  January 16, 2011



             Problem Statement of P2P Streaming Protocol (PPSP)
                 draft-ietf-ppsp-problem-statement-01


Abstract

   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 case of PPSP.




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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on July 16, 2011.



Zhang                   Expires July 16, 2011                 [Page 1]


Internet-Draft        Problem Statement of PPSP           January 2011


Copyright Notice

   Copyright (c) 2010 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.




































Zhang                  Expires July 16, 2011                 [Page 2]


Internet-Draft        Problem Statement of PPSP           January 2011


Table of Contents


   1. Introduction ................................................. 4
   2. Terminology and concepts ..................................... 6
   3. Problem statement ............................................ 7
      3.1. ISP's difficulties in deploying P2P caches .............. 7
      3.2. Difficulties in building open streaming delivery
      infrastructure ............................................... 7
      3.3. Difficulties in mobile and wireless environment...........8
      3.4. Terminal physical resource starvation ................... 9
   4. PPSP:Standard peer to peer streaming protocols .............. 10
   5. Use cases of PPSP ........................................... 13
      5.1. Worldwide provision of open P2P live streaming services. 13
      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..... 15
      5.5. Cache service supporting P2P streaming ................. 16
   6. Security Considerations ..................................... 17
      6.1. Tracker Protocol ....................................... 17
      6.2. Peer Protocol .......................................... 17
   7. Acknowledgements ............................................ 18
   8. References .................................................. 19























Zhang                  Expires July 16, 2011                 [Page 3]


Internet-Draft        Problem Statement of PPSP           January 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 global 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. Almost all these systems use their proprietary signaling
   protocols and standard data delivery protocols (like UDP and TCP).

   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 P2P streaming delivery game, the P2P
   streaming ecosystem is becoming more complex with participants from
   the source, infrastructure side, edge delivery even to the terminals.

   Given the above 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 Internet protocol stack. Multiple, similar
   but proprietary signaling protocols result in repetitious development
   efforts for new systems, and the lock-in effects lead to substantial
   difficulties in the 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 for information exchange. The problems of proprietary



Zhang                  Expires July 16, 2011                 [Page 4]


Internet-Draft        Problem Statement of PPSP           January 2011


   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
   a streaming delivery infrastructure.







































Zhang                  Expires July 16, 2011                 [Page 5]


Internet-Draft        Problem Statement of PPSP           January 2011


2. Terminology and concepts

   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 July 16, 2011                 [Page 6]


Internet-Draft        Problem Statement of PPSP           January 2011


3. Problem statement

   Let's take a look what problems proprietary signaling brings out for
   P2P streaming applications.

3.1. ISP's difficulties 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). It's often deployed in the edge or inter-networking
   places of the network. 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. This reduces the ISP workload to a large extent.

3.2. Difficulties in building open streaming delivery infrastructure

   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. In content-centric networks there is no doubt that
   P2P streaming data is going to account for a large portion. If
   current multiple proprietary protocols continue to work, there will
   exist lots of specific and independent systems to deliver vast
   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 and
   for the same content, many on-the-way data spread over the Internet.
   All these will definitely increase the cost of streaming distribution
   and causes possible congestion in the network.

   In an open P2P streaming delivery infrastructure, It must involve
   different participants in the distribution chain ranging from the
   source (or current P2P streaming vendors) , infrastructure (e.g, CDN)
   and delivery side(caches or terminal peers).

   Let's first consider a simplest open P2P streaming environment where
   different source vendors spread in different regions cooperatively
   deliver a broadcasting event. Suppose PPLive cooperatively broadcasts
   live Chinese spring festival gala for American Chinese with Pando


Zhang                  Expires July 16, 2011                 [Page 7]


Internet-Draft        Problem Statement of PPSP           January 2011


   networks. At a first sight, this is reasonable because PPlive has
   relatively few users in USA and Utilizing Pando's peer resources can
   help to realize efficient streaming delivery. However, different
   messages and interaction semantics  between the two systems is a big
   challenge for the cooperative delivery.

   Consider a more complex case where source vendors cooperate with CDN
   providers. Such integration is already practiced by UUSee[UUSee],
   RayV[RayV] and Forcetech[Forcetech]. The effect of the involvement of
   infrastructure devices such as CDN nodes 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 in ISP network
   [CDN+P2P] [RFC 5693].However, there are substantial obstacles in
   deploying infrastructure nodes supporting proprietary P2P streaming
   protocols [HTPT]. Unlike the Web who has already equipped with the
   standard HTTP protocol and all kinds of the infrastructure devices
   support the protocol, in order to support P2P streaming, the
   infrastructure devices need to understand and keep updated with
   various protocols to take part in the delivery. Similar to the cache
   case, this introduces complexity and deployment cost for the
   infrastructure devices.

   With PPSP, CDN nodes can be designed to inter-operate with only the
   standard protocols, reducing the case by case negotiation between the
   source providers and multiple CDN providers.

3.3. Difficulties in mobile and wireless environment

   Mobility and wireless are becoming increasingly important features to
   support in future Internet deployments [GENI], [FIND]. Currently
   there are more and more mobile and wireless Internet users. 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].

   Along with this trend, mobile streaming is 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.

   Although mobile handsets are more eligible to be peers with much
   better bandwidth and higher CPU frequency, larger storage and memory
   than several years ago, mobile and wireless peers may face bigger
   challenges for supporting P2P streaming with unsteady and relatively
   lower (esp. in uplink) network connections, less steady power than
   PCs. And what are worse, current protocols are designed mainly for
   the fixed Internet and do not address these challenges.


Zhang                  Expires July 16, 2011                 [Page 8]


Internet-Draft        Problem Statement of PPSP           January 2011


   In what kinds of network dynamical conditions, what kinds of mobile
   nodes can act as peers should be investigated to reflect in the
   standard protocols from the beginning of the design.

3.4. Terminal physical resource starvation

   Private protocols may require a terminal to install multiple
   different 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 or Pads. 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.

   Standard protocols reduce the complexity of coexisting multiple
   closed systems and create possibilities to use one client software
   accommodating different systems.




























Zhang                  Expires July 16, 2011                 [Page 9]


Internet-Draft        Problem Statement of PPSP           January 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 connection 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.

   As discussed above, in essence, there are two important entities in
   P2P streaming, i.e., trackers and peers. PPSP is targeted to
   standardize the signaling protocols in 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


Zhang                  Expires July 16, 2011                [Page 10]


Internet-Draft        Problem Statement of PPSP           January 2011


   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.

   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 protocols among peers, e.g., HTTP.
   Considering that there can be a large number of peers, the protocol
   should consider some lightweight (possibly binary) encoding.





















Zhang                  Expires July 16, 2011                [Page 11]


Internet-Draft        Problem Statement of PPSP           January 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 July 16, 2011                [Page 12]


Internet-Draft        Problem Statement of PPSP           January 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 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 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 Interactions

5.2. CDN supporting P2P streaming

   This scenario is similar to use case 1 but it involves more kinds of
   participants: besides P2P streaming vendors, non-P2P streaming
   vendors and CDN providers are also involved in the delivery.


Zhang                  Expires July 16, 2011                [Page 13]


Internet-Draft        Problem Statement of PPSP           January 2011


   The CDN surrogates can act as the super-nodes of different P2P
   streaming vendors with PPSP. The interactions among these network
   entities are the same as shown in Figure 2. The P2P streaming vendors
   can rent CDN resources to provide better QoS assured services for VIP
   users than services provides by only ordinary peers.

   Another case is that the CDN providers offer P2P streaming
   distribution with PPSP. This often occurs for an operator or CDN
   vendor to build a new CDN system supporting streaming applications
   with low cost. This service is very useful for a small streaming
   provider who has no much money to distribute its stream worldwide. It
   can also be used by an operator to launch self-operating streaming
   service from the beginning.

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 work together sharing the content they
   store/cache and finishing the streaming delivery.

   Using PPSP, peers can identify the types of networks, peer abilities
   and 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 3.
   This will play an important role on the sharing among heterogeneous
   peers.






















Zhang                  Expires July 16, 2011                [Page 14]


Internet-Draft        Problem Statement of PPSP           January 2011


   +-------------------------------------------------------------------+
   |                                                                   |
   |      Tracker Protocol  +---------+   Tracker Protocol             |
   |        +-------------> | Tracker |<------------------+            |
   |        |               +---------+                   |            |
   |        |                    ^                        |            |
   |        |                    |                        |            |
   |        |                    |                        |            |
   |        V                    |                        V            |
   |    +------+                 |                +------------+       |
   |    |  STB |           Tracker Protocol       |Mobile Phone|       |
   |    +------+                 |                +------------+       |
   |        ^                    |                        ^            |
   |        |                    |                        |            |
   |        |                    |                        |            |
   |        |                    V                        |            |
   |        |Peer Protocol  +---------+    Peer Protocol  |            |
   |        +-------------> |    PC   |<------------------+            |
   |                        +---------+                                |
   |                                                                   |
   +-------------------------------------------------------------------+
        Figure 3 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 streaming is
   easier to be realized than before. 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
   often selected. For example, in 3GPP, there is a P2P CDS work item 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.

   In this case the PPSP tracker protocol will identify the network
   types and dynamics as well as the terminal types and return super-
   peers in the peer-list to these super-peers and normal mobile peers.
   If mobile terminals are not eligible to be peers, they can simply
   receive data from these super-peers without contributing any data to
   others.





Zhang                  Expires July 16, 2011                [Page 15]


Internet-Draft        Problem Statement of PPSP           January 2011


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, cache the frequent visited
   content (or part of) and report what they cache to the provider's
   tracker like a normal peer and serve other requesting peers in
   sharing data as shown in Figure 4. The cache nodes needn't update
   their library when new applications are introduced, which enable the
   cache nods spend less cost to support more applications.

   +-------------------------------------------------------------------+
   |                                                                   |
   |      Tracker Protocol  +---------+   Tracker Protocol             |
   |        +-------------> | Tracker |<--------------------+          |
   |        |               +---------+                     |          |
   |        |                                               |          |
   |        |                                               |          |
   |        |                                               |          |
   |        V                                               V          |
   |    +-----------+           Peer Protocol         +------------+   |
   |    |  Cache    |<------------------------------->|   Peer     |   |
   |    +-----------+                                 +------------+   |
   +-------------------------------------------------------------------+

           Figure 4 Cache Service Supporting Streaming with PPSP



















Zhang                  Expires July 16, 2011                [Page 16]


Internet-Draft        Problem Statement of PPSP           January 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
   considerations involve the security problems related to PPSP
   protocols.

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
   unexisting data).

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

   In the above discussion tracker is trustful. Things are worse when
   the malicious peer acts as part of the distributed trackers, who is
   untrustful with much possibility. 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.
   But this part is out of scope of PPSP.

   The protocol documents will contain a complete description on the
   security/privacy issues relevant to any usage of PPSP.







Zhang                  Expires July 16, 2011                [Page 17]


Internet-Draft        Problem Statement of PPSP           January 2011


7. Acknowledgements

   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 July 16, 2011                [Page 18]


Internet-Draft        Problem Statement of PPSP           January 2011


8. References

   [Cisco] Cisco Visual Networking Index: Forecast and Methodology,
   2009-2014,
   http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns7
   05/ns827/white_paper_c11-
   481360_ns827_Networking_Solutions_White_Paper.html

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

   [ChinaCache]www.chinacache.com

   [ComCast]http://www.afterdawn.com/news/article.cfm/2008/05/20/comcast
   _invests_in_p2p_streaming_startup

   [CCN] Content-Centric Networking,V. Jacobson,
   https://wiki.tools.isoc.org/@api/deki/files/2634//=1.vj.isoc.mar10.pd
   f

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

   [Van] A New Way to Look at Networking,Van Jacobson,
   http://video.google.com/videoplay?docid=-6972678839686672840

   [RayV]www.rayv.com



Zhang                  Expires July 16, 2011                [Page 19]


Internet-Draft        Problem Statement of PPSP           January 2011


   [Forcetech]http://www.forcetech.net/english/solutions

   [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

   [FIND]www.nets-find.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-
   info/22906.htm


Author's Addresses

   Yunfei Zhang

   China Mobile Communication Corporation

   zhangyunfei@chinamobile.com



   Ning Zong

   Huawei Technologies Co., Ltd.

   zongning@huawei.com



   Gonzalo Camarillo

   Ericsson


Zhang                  Expires July 16, 2011                [Page 20]


Internet-Draft        Problem Statement of PPSP           January 2011


   Gonzalo.Camarillo@ericsson.com



   James Seng

   PPLive

   james.seng@pplive.com



   Richard Yang

   Yale University

   yry@cs.yale.edu































Zhang                  Expires July 16, 2011                [Page 21]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/