PPSP                                                             Y.Zhang
Internet Draft                                              China Mobile
Intended status: Standard track                                   N.Zong
                                                         Yale University
Expires: January 2010                                      July 12, 2009

          Problem Statement of P2P Streaming Protocol (PPSP)

Status of this Memo

   This Internet-Draft is submitted to IETF 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 January 12, 2010.

Copyright Notice

   Copyright (c) 2009 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 (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your
   rights and restrictions with respect to this document.

Zhang                Expires January 12,2010              [Page 1]

Internet-Draft   Problem Statement of P2P Streaming Protocol  July 2009

  We propose to develop an open peer-to-peer (P2P) streaming protocol
  named PPSP. This document describes problems related to PPSP and
  outlines considerations that have to be taken in account when
  arriving at equitable solutions.

Zhang               Expires January 12, 2010             [Page 2]

Internet-Draft   Problem Statement of P2P Streaming Protocol  July 2009

Table of Contents

  1. Introduction.............................................4
     1.1. Research or Engineering.............................4
     1.2. Objective and outline...............................5
  2. Definitions..............................................6
  3. Problem Statement Scope..................................7
     3.1. Proprietary protocols and an open PPSP..............7
     3.2. Integrating cache and CDN into P2P streaming........7
     3.3. Integrating existing protocols into P2P streaming...8
     3.4. Mobility and wireless issue.........................8
       3.4.1. End to end communication is harder..............9
       3.4.2. Limited Bandwidth resource......................9
       3.4.3. Other difference...............................10
  4. Design Issues...........................................11
     4.1. Architecture Choice................................11
     4.2. Integration with existing protocols................11
       4.2.1. Integration with RELOAD........................11
       4.2.2. Integration with ALTO..........................14
       4.2.3. Encapsulating RTSP.............................14
       4.2.4. Edge Device such as Cache Integration..........15
  5. Scope of Work...........................................16
     5.1. Architecture of PPSP...............................16
     5.2. Scope of PPSP......................................18
  6. Security Considerations.................................21
  7. Acknowledgments.........................................21
  8. References..............................................21

Zhang               Expires January 12, 2010             [Page 3]

Internet-Draft   Problem Statement of P2P Streaming Protocol  July 2009

1. Introduction
  Streaming traffic is among the fastest growing traffic on the
  Internet. In a recent white paper, Cisco predicts that by 2012, 90%
  of all Internet traffic will be video [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 [P2PStreamingSurvey]. A particular advantage of the
  P2P paradigm over the client-server paradigm is its scalability. 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 2 million users with only
  a handful of servers. CNN[CNN] reported that P2P streaming by
  Octoshape played a major role in its distribution of the historical
  inauguration address of President Obama.  It is well demonstrated in
  practice that P2P streaming can deliver videos encoded at a rate of
  about 400 Kbps, in the presence of rapid user joins/leaves, with
  positive user experiences.
  With the preceding technical advantages, P2P streaming is seeing
  rapid deployment. Large P2P streaming applications such as PPLive
  [PPLive], PPstream [PPstream] and UUSee [UUSee] each has a user base
  exceeding 100 millions. P2P streaming traffic is becoming a major
  type of Internet traffic in some Internet networks. For example,
  according to the statistics of a major Chinese ISP, the traffic
  generated by P2P streaming applications exceeded 50% of the total
  backbone traffic during peak time in 2008. There were reports that
  major video distributors such as Youtube [youtube] and tudou [tudou]
  are conducting trials of using P2P streaming as a component of their
  delivery infrastructures.
  Given the increasing integration of P2P streaming into the global
  content delivery infrastructure, the lacking of an open, standard P2P
  streaming protocol becomes a major missing component in the Internet
  protocol stack. Multiple, similar but proprietary P2P streaming
  protocols result in repetitious development efforts and lock-in
  effects. More importantly, it leads to substantial difficulties when
  integrating P2P streaming as an integral component of a global
  content delivery infrastructure. For example, proprietary P2P
  streaming protocols do not integrate well with existing cache and
  other edge infrastructures.
1.1. Research or Engineering
  As [P2PStreamSurvey] identifies, there exist multiple proprietary P2P
  streaming systemsincluding PPLive, PPstream, UUsee, Pando, abacast,

Zhang               Expires January 12, 2010             [Page 4]

Internet-Draft   Problem Statement of P2P Streaming Protocol  July 2009

  and Coolstreaming. A natural question to ask is whether the
  development of P2P streaming is mature and ready for standardization.
  We admit that P2P streaming will continue to improve and evolve.
  However, our investigation shows that existing P2P streaming systems
  are largely converging, sharing similar architecture and signaling
  protocols [draft-zhang-ppsp-protocol-comparison-measurement-00]. The
  competition of P2P streaming vendors become increasingly on contents.
1.2. Objective and outline
  Our objective is to develop a standard P2P streaming protocol that
  can operate in both fixed and mobile Internet. The protocol will
  serve as an enabling technology, building on the development
  experiences of existing P2P streaming protocols. It will integrate
  with IETF efforts on distributed resource location, traffic
  localization, and streaming control mechanisms. It allows effective
  integration with edge infrastructures such as cache and mobile edge
  This document provides a problem statement for designing PPSP. The
  rest of the document is organized as follows. In Section 2, we
  introduce terminologies. In Section 3, we identify the current
  problems in providing a scalable and economical streaming system.In
  Section 4, we describe the main issues to consider when designing
  PPSP. In Section 5, we outline the main scope of work.

Zhang               Expires January 12, 2010             [Page 5]

Internet-Draft   Problem Statement of P2P Streaming Protocol  July 2009

2. Definitions
  The following terms have special meaning in the definition of the
  Peer to Peer Streaming Protocol (PPSP) problem.
  Tracker: A dedicated server who is in charge of maintaining peer list
  and replying peer request for peer selection.
  Peer: A peer refers to a participant in a P2P streaming system who
  acts both as "client" and "server".
  Chunk: A chunk is a basic unit of partitioned streaming, which is
  used for the purpose of storage and advertising to neighbors what
  parts of a movie a peer holds [Sigcomm:P2P streaming].
  Bitmap: Bitmap is a table indicating which chunks a peer has.
  Peering networks: Two directly connected Internet Service Providers.
  Apart from infrastructure and operational costs, peering traffic is
  usually free, within the contract of a peering agreement [draft-

Zhang               Expires January 12, 2010             [Page 6]

Internet-Draft   Problem Statement of P2P Streaming Protocol  July 2009

3. Problem Statement Scope
  We perceive a number of problems related to scalable and economical
  streaming on the Internet. The major issues are the following:
   1) The difficulty of an open PPSP due to the existence of many
     proprietary and non-interoperable protocols in current p2p
     streaming applications;
   2) The difficulty of integrating current edge equipments such as
     cache and content distribution network (CDN) nodes into P2P
   3) The difficulty of integrating related protocols into P2P
     streaming, like RELOAD,ALTO,RTSP, which is beyond current P2P
     streaming usage;
   4) The lack of a standard solution for scalable and economical
     streaming signaling interaction suitable both for fixed internet
     and mobile Internet; a related problem is that the difficulty of
     deploying p2p streaming in mobile Internet;
   The subsections below discuss these problems in more detail.

3.1. Proprietary protocols and an open PPSP
  Currently there exist some P2P streaming systems like PPLive,
  PPstream, UUsee, Pando[Pando] and
  Coolstreaming[Coolstreaming].Although using similar system
  architecture as well as signaling interaction processes[draft-zhang-
  ppsp-protocol-comparison-measurement-00], due to their proprietary
  protocols, it's hard to develop an open PPSP protocol without
  checking all the typical P2P streaming systems, identifying the key
  issues and considering all the requirements.

3.2. Integrating cache and CDN into P2P streaming
  To make P2P streaming stable and traffic local enough, cache and
  other edge infrastructure is a very promising means [draft-marocco-
  However there are a few obstacles in deploying P2P caches [HTPT]:
  firstly, P2P caching systems are likely to be very complicated.
  Unlike web traffic standardized in using HTTP transport through few
  dedicated ports like 80, there is no a standard P2P protocol and

Zhang               Expires January 12, 2010             [Page 7]

Internet-Draft   Problem Statement of P2P Streaming Protocol  July 2009

  every P2P protocol uses its own port. Therefore, P2P caching systems
  are forced to take an ad hoc approach by enumerating and handling
  every P2P protocol. Another drawback of this ad hoc approach is the
  requirement of regular update of the P2P cache engines to handle
  newly emerged popular P2P protocols. Secondly, extra, possibly huge,
  investment is required for the equipment and facility purchase and
  also the administrative cost.
  If we can utilize the existing cache and other edge equipments like
  CDN nodes, the cost can be heavily reduced. Meanwhile because it's
  widely used, the performance of P2P streaming can increase much.
  Therefore how to utilize the edge infrastructure is a big issue.
  Current web cache or other widely deployed edge equipments like CDN
  doesn't support P2P streaming yet[HTPT].

3.3. Integrating existing protocols into P2P streaming
  There are several protocols related to p2p streaming having been or
  being defined in IETF, including RELAOD,ALTO,RTSP,etc.., where
  P2PSIP,ALTO and MMusic are most related WGs. Unfortunately there is
  no one protocol above considered by current P2P streaming
  We claim that PPSP is not a stand-alone protocol. It could and should
  integrate with the existing related protocols to the largest extent.
  We analyze several protocols PPSP may relate to in detail in section4.

3.4. Mobility and wireless issue
  Mobility and wireless becomes a very important feather to support in
  future internet [GENI],[FIND]. Some operators have also started
  research projects on mobile and wireless Internet. For example, China
  Mobile came out with its DSN (distributed services network) strategy
  last year to build its mobile Internet [draft-zhang-ppsp-dsn-
  Along with the introduction of mobile and wireless characteristics
  into Internet, mobile streaming will become more and more
  popular[MobileTV].In Korea the mobilTV subscriber is 17 million
  accounting one third of the mobile subscriber. In Italy there are 1
  million mobileTV users. In the period of Beijing Olympic games, there
  are more than 1 million usage of China mobile's mobileTV.
  Most of current mobileTV are developed in client/server model. It's a
  natural idea to increase its scalability and decrease the cost by
  deploying P2P mobile streaming.

Zhang               Expires January 12, 2010             [Page 8]

Internet-Draft   Problem Statement of P2P Streaming Protocol  July 2009

  However there are a lot of differences in mobile/wireless Internet
  compared with fixed Internet environment. This makes it hard to copy
  current P2P streaming protocol in fixed Internet environment.
3.4.1. End to end communication is harder
  Unlike fixed Internet, it's difficult to realize end-to-end
  communication in mobile Internet. Mobile terminals cannot connect
  with each other directly. The connection must be set up by
  mobile/wireless access nodes. Therefore mobile terminals are hard to
  become peers without the cooperation of mobile/wireless access
  equipments. It's obviously a heavy burden for the mobile/wireless
  access points.
  |                                                                   |
  |                                       +-------+                   |
  |                                       | Cache |                   |
  |                                       +-------+                   |
  |                                           ^                       |
  |                                           |                       |
  |     Peerlist                              V                       |
  |  +---------------+      +----+      +-----------+                 |
  |  | Tracker       |<---->|PEER|<---->|    AP     |Bottleneck       |
  |  +---------------+      +----+      +-----------+                 |
  |    ^            ^                    ^         ^                  |
  |    |            |                    |  Low    |                  |
  |    |            |                    |Bandwidth|                  |
  |    V            V                    V         V                  |
  |  +---+ End-end +---+           +------+     +------+              |
  |  |PC |<------> |PC |           |Mobile|<--> |Mobile|              |
  |  |   |  works  |   |           |Phone |  ?  |Phone |              |
  |  +---+   Well  +---+           +------+     +------+              |
  |                                                                   |
  |                                                                   |

              Figure 1   Mobile Internet communication
3.4.2. Limited Bandwidth resource
  Even if end-to-end communication is ensured, there are still problems
  for P2P mobile streaming.As shown in Figure1, the following bandwidth
  is limited and the transmission cost is relatively high:
 a) between mobile terminals and mobile access nodes;

Zhang               Expires January 12, 2010             [Page 9]

Internet-Draft   Problem Statement of P2P Streaming Protocol  July 2009

b) between mobile access node
c) between mobile network to fixed network.
It raises some requirements for PPSP:
  1)The overhead of PPSP cannot be much. Because PPSP is a signaling
    protocol, the overhead refers to the ratio of signaling traffic
    with respect to overall streaming traffic. Different solutions
    have different overhead. [Computer Networks-Traffic]analyzes four
    P2P streaming overhead, namely PPLive,PPStream,SOPCast and
    TVAnts.There is a tradeoff consideration in PPSP. We know that
    frequent exchange in bitmap may cause a big overhead but it also
    enables a small peer cache to keep the smooth play of the program.
    On one hand, the overhead should be minimum to reduce the traffic
    and increase the efficiency so the bitmap exchange frequency
    should be small. On the other hand, a mobile terminal has usually
    small cache size so the bitmap exchange frequency should be large.
    How to solve the conflict and balance between the cache size and
    bitmap exchange frequency is a problem PPSP may face with.
2)  Cross-domain traffic must be reduced. For most mobile Internet
    domains, their network scale is rather smaller compared with the Tier1
    and Tier2 peering networks. Currently peering networks are free from
    the cross-traffic. However the low-tier ISPs have to pay for dual-
    directional traffic fee even it's a traffic initiated from higher tier
    ISPs. It makes mobile Internet provider worse in case  P2P streaming
    applications generate great traffic with a low-cross-domain bandwidth.
3.4.3. Other difference
  Mobility, low battery and capability of mobile terminals make us
  considering more factors in peer selection to ensure smooth streaming.
  A new protocol might therefore allow more information to report for
  trackers to do peer selection.

Zhang               Expires January 12, 2010            [Page 10]

Internet-Draft   Problem Statement of P2P Streaming Protocol  July 2009

4. Design Issues
  This section introduces key issues when designing PPSP.
4.1. Architecture Choice
  There are multiple proposed p2p streaming solutions. Some are used in
  practice and while others are popular in theory. The basic idea of
  P2P streaming is to partition streaming into chunks and peers are
  used in relaying chunk transmission. The solutions can be categorized
  by tree-based and mesh-based [Survey]. The former is "pushing" chunks
  to the audience and the latter is enabling the audience to "pulls" the
  desired chunks from the peers who has.
  In the tree-based p2p streaming, tree construction and maintenance
  can be done in either a centralized or a distributed fashion [Survey].
  In the mesh-based p2p streaming, no specific topology maintenance is
  needed. The task is how to locate and retrieve real-time data from
  multiple sources with different chunks for a streaming. In order to
  realize this, each peer has to actively locate cache and exchange
  chunks from other peers by the guidance of the tracker.
  The biggest challenge in tree-based p2p streaming is two-fold: First,
  tree-based streaming still cannot recovery fast enough to handle
  frequent peer churn[Mesh and Multi-tree comparison].Second, peers at
  the higher level of the tree are required to have sufficient upload
  capacity to support the streaming of their children peers. If it
  were not the case, the performance will dramatically be deteriorated.
  On the contrary mesh-based p2p streaming is widely used to overcome
  these drawbacks for real deployment, like pplive, ppstream,
  coolstreaming, etc,..
4.2. Integration with existing protocols
  PPSP will not be a stand-alone protocol. A major advantage of a
  standard protocol is that we can explicit consider its interactions
  with other protocols, and design for an integrated system.
  In particular, we identify that PPSP will interact with the following
  protocols: RELAOD, ALTO, and RTSP, where P2PSIP, ALTO and MMusic are
  the most related WGs.
4.2.1. Integration with RELOAD
  RELOAD defined by P2PSIP deals with resource location in end to end
  commutation. The iterative and recursive routing process in RELOAD is
  shown in Fig4, which is different from PPSP. That is, the data stored
  in RELOAD is user profile data and the requester knows exactly what

Zhang               Expires January 12, 2010            [Page 11]

Internet-Draft   Problem Statement of P2P Streaming Protocol  July 2009

  the data is (e.g., the location of Alice is 5678). While in PPSP,
  there are many peers storing different data pieces of "CNN Live". The
  only thing a peer must know is the metadata of the movie. A gossip
  protocol to communicate with other peers is needed to get the real
  data quickly.
     The P2PSIP routing clarification is to state that it may don't
  suit with tracker based topology(tree or meshed).So we draw both
   |                  +------------------------+
   |                  |   P2PSIP DHT overlay   |
   |                  |        (RELOAD)        |
   |  FetchReq(Alice) |     +---------------+  |
   |----------------->|---->|      Peer     |  |
   |                  |  +--|               |  |
   |                  |  |  +---------------+  |
   |                  |  |     ^         ^     |
   |                  |  |    1|2       3|4    |
   |                  |  |     V         V     |
   |                  |  |   +----+   +----+   |
   |                  |  |   |Peer|   |Peer|   |
   |                  |  |   +----+   +----+   |
   |  FetchAns(1234)  |  |                     |
   |<-----------------|<-+                     |
   |                  |                        |          Bob
   | AppAttach(1234)  |                        |        (1234)
   |----------------->| -- -- -- -- -- -- -- --| --------> |
   |<-----------------| -- -- -- -- -- -- -- --| <-------- |
   |                  +------------------------+           |
   |                                                       |
   | <------------------ ICE Checks ------------------->   |
   |  INVITE ------------------------------------------->  |

Zhang               Expires January 12, 2010            [Page 12]

Internet-Draft   Problem Statement of P2P Streaming Protocol  July 2009

   |                  +------------------------+
   |                  |   P2PSIP DHT overlay   |
   |                  |        (RELOAD)        |
   |  FetchReq(Alice) |     +---------------+  |
   |----------------->|---->|      Peer     |  |
   |                  |  +--|               |  |
   |                  |  |  +---------------+  |
   |                  |  |     |         |     |
   |                  |  |    1|         |3    |
   |                  |  |     V         V     |
   |                  |  |   +----+ 2 +----+   |
   |                  |  |   |Peer|-->|Peer|   |
   |                  |  |   +----+   +----+   |
   |  FetchAns(1234)  |  |                     |
   |<-----------------|<-+                     |
   |                  |                        |          Bob
   | AppAttach(1234)  |                        |        (1234)
   |----------------->| -- -- -- -- -- -- -- --| --------> |
   |<-----------------| -- -- -- -- -- -- -- --| <-------- |
   |                  +------------------------+           |
   |                                                       |
   | <------------------ ICE Checks ------------------->   |
   |  INVITE ------------------------------------------->  |

                    Figure 2   P2PSIP process
  The biggest difference between P2PSIP and PPSP lies in their
  different search efficiency requirements. PPSP requires retrieving
  real-time/para real-time data with strict timeline. DHT based
  topology supported in RELAOD may not be suitable for peer information
  storage and retrival.There are some reasons as follows:
  First, the amount of registered chunks at the same time is great,
  e.g., several hundred chunks in the cache. Therefore too frequent PUT
  operations occur in each peer.
  Second, the stored chunk information will be invalid very quick, e.g.,
  several minutes in live streaming. Different from VoD streaming,
  chunk information is of no use if the requested time is too late to
  exceed the threshold of the cached content time-out.If every peer
  continuously publishes the dynamic changed chunk information, a big
  burden will be generated.
  Although P2PSIP doesn't fit for streaming peer organization, it can
  be deployed in PPSP environment to some extent.

Zhang               Expires January 12, 2010            [Page 13]

Internet-Draft   Problem Statement of P2P Streaming Protocol  July 2009

  First, the topology organization of DHT defined in RELOAD can be used
  to organize multiple trackers. Due to the large population, some
  trackers may cooperatively serve a channel/file. Considering the
  great amount of channels, there are many trackers in practice.
  Because the search time of which channel/file the tracker stores
  accounts small percentage in the whole searching procedure, DHT can
  be used to query for peer list in case of thousand of channels or
  million of files which are hard to use one tracker.
  Second, there is a detailed solution for Firewall/NAT transversal in
  in RELOAD. PPSP faces with the same problem, although not as serious
  as RELAOD because there are lots of peer candidates with public
  addresses. But we can definitely reuse RELAOD in case of NAT/Firewall
  transversal which may occur in mobile environment.
4.2.2. Integration with ALTO
  ALTO is to define a protocol realizing local traffic mostly for P2P
  applications. The goal of an ALTO solution would be to help peers to
  find the best sources and the best destinations for media flows they
  receive and relay. In [draft-marocco-alto-problem-statement-03], the
  authors mentioned p2p live streaming that can benefit from ALTO
  As we have seen in Section 1, P2P streaming traffic account much on
  the Internet backbone. PPSP has to consider operator-friendly ways to
  reduce the cross-backbone traffic in order to control the
  transmission cost. ALTO is a good candidate to do so.
  ALTO provides a 3rd party to provide peer locality information based
  on the premise that the 3rd party has the knowledge of the network
  topology. In addition there may have extra traffic localization means,
  e.g., in [draft-zhang-alto-traceroute-00], peers can cluster the
  nearby peers by simple and lightweight measurements. We can use this
  mechanism in peer selection to further reduce the traffic.
4.2.3. Encapsulating RTSP
  At a first sight, the function of PPSP protocol is similar to
  traditional client/server streaming control protocols, RTSP. But in
  fact RTSP don't involve the problems PPSP has.
  In RTSP, the focus is to control the streaming, like PLAY, PAUSE;
  however PPSP focuses on signaling peers for real-time resource
  discovery, merge and synchronization instead of how to realize
  streaming control.

Zhang               Expires January 12, 2010            [Page 14]

Internet-Draft   Problem Statement of P2P Streaming Protocol  July 2009

  On the other hand, considering the prevalence of RTSP, it can also be
  reused in clients without installing PPSP-compatible software to use
  P2P streaming service.
  The basic idea in that is to set up a proxy node (e.g., using a cache)
  which can act as a RTSP server who is actually a peer of PPSP.
4.2.4. Edge Device such as Cache Integration
  As stated in Section 3, if the widely deployed web cache and CDN
  nodes can be reused in p2p streaming, the video quality, local
  traffic and some security problems may be better solved.[HTPT]
  proposes a solution similar to what we propose in section 4.5 to
  encapsulate and transport them using the HTTP protocol so that they
  are cacheable.

Zhang               Expires January 12, 2010            [Page 15]

Internet-Draft   Problem Statement of P2P Streaming Protocol  July 2009

5. Scope of Work
  We propose to develop an open peer to peer streaming protocol, namely
  PPSP. The basic task of PPSP is to define a protocol of locating and
  transmitting real-time data efficiently from multiple sources with
  different pieces in peer to peer environment.

5.1 Architecture of PPSP
  PPSP focuses on how to negotiate with un-preassigned peers for needed
  chunks. Therefore, PPSP is mainly a signaling protocol and the
  protocol stack of PPSP is shown in Figure 3.
  | +---------------------------------------------------------------+ |
  | |                   Application Layer                           | |
  | +---------------------------------------------------------------+ |
  | Play-out Layer                                                    |
  |       +---------+        +----------+       +----------+          |
  |       | Start   |        |  Pause   |       |  Stop    |          |
  |       +---------+        +----------+       +----------+          |
  | Information Layer                                                 |
  |       +-------------+    +----------+       +------------+        |
  |       |Registration |    | Report   |       | Statistics |        |
  |       +-------------+    +----------+       +------------+        |
  | Communication Layer                                               |
  |    +-----------------------+  +-------------------------------+   |
  |    |  Topology creation    |  |Head Node/Tracker Communication|   |
  |    +-----------------------+  +-------------------------------+   |
  |    +-----------------------+  +-------------------------------+   |
  |    |Neighbour Communication|  |          Bootstrap            |   |
  |    +-----------------------+  +-------------------------------+   |
  | +---------------------------------------------------------------+ |
  | |                  Transport Layer                              | |
  | +---------------------------------------------------------------+ |

             Figure 3   PPSP Position in Protocol Stack
  It can be divided into 5 layers:
  1) Transport Layer is responsible for data transmission between peers,
  UDP,TCP or other protocols can be used;
  2) Communication layer is the key layer in PPSP, including four

Zhang               Expires January 12, 2010            [Page 16]

Internet-Draft   Problem Statement of P2P Streaming Protocol  July 2009

     a)Topology creation is a component each peer has to request to
  join the overlay, like tree or mesh;
     b)Head Node/Tracker Communication is a component each peer
  continually to get peer list or peer information report to the
  tracker or tree maintenance by the head node.
     c)Neighbor Communication is a component that peers exchange
  bitmap in mesh or other neighbor availability information for loop
  avoidance in tree.
     d)Bootstrap is a component to introduce a newly joined node to
  get the tracker or head node information since there may be multiple
  trackers or head nodes. It keeps monitoring the trackers and head
  3) Information layer is a layer for peer and content information
  collection and management, which helps to improve the system
  performance from the global view of point.
     a)Registration is a component that enables nodes register to the system,
  publish the contents it wants to broadcast through the P2P streaming
  system.The information may include but not limit the scope of the
  following items: the content description, content type, creation time,
  the node information such as physical location, IP address and network
  condition as well as program advertisment  policies.
     b)Report is a component that enables peers to report their useful
  information to the head node or tracker. These information exclude
  those basic message between peers and head nodes or trackers in the
  communication layer. The information may include peer inbound and
  outbound traffic, amount of neighbor peers,peer health degree as well
  as the video quality parameters.
    c)Statistics is a component that enables the tracker or head node to
  manage the aggregated system information for global control in upload
  bandwidth consumption,overhead consumption and other regards.
  4) Play-out layer is a layer to control the action of the media
  brower/player just like RTSP.One point needed to notice is that in
  tracker-based ppsp applications, there is a local media player to
  control the program play. The content is locally cached. Therefore no
  network related commands like RTSP is needed.
  5) Application layer is the top layer in the ISO/OSI model,where PPSP
  application exists.

Zhang               Expires January 12, 2010            [Page 17]

Internet-Draft   Problem Statement of P2P Streaming Protocol  July 2009

5.2 Scope of PPSP

  In order to locate real-time data efficiently from multiple sources
  with different pieces, we have to solve the following problems:
  1) To standardize the architecture for locating the data efficiently.
  Tracker-based structure is widely used in current p2p streaming
  practice. However some tracker-less structures like DHT peer
  management solutions are also proposed. We need to explore the bast
  practice for p2p streaming;
  2) To standardize the signaling interaction process.
  In this part we actually want to standardize client registration
  process (analogous to TCP 3-way handshake procedure), client
  information exchange process (analogous to SIP session setup process)
  and client report process.
  The current tracker-based means is a two-step searching, i.e., peer
  reporting to tracker coarse information about it has. Once the
  tracker is asked, it informs peer of the coarse information; the
  grain information is achieved by peers exchanging bitmap each other.
  Some other means, e.g., peer reporting to tracker grain information
  directly and tracker informs peer of the exact information or DHT
  based searching, should be evaluated. In each proposal we also need
  to define the message format in the interactions.
  We draw a protocol interaction based on the proposed component
  architecture with different types of nodes in tracker-based PPSP
  The figure is as follows:

Zhang               Expires January 12, 2010            [Page 18]

Internet-Draft   Problem Statement of P2P Streaming Protocol  July 2009

  |                                                                   |
  |                 +-------+Bootstrap(http)+---------+     +--------+|
  |                 | Peer1 |-------------->|Bootstrap|     |Content ||
  |                 +-------+<------+       +---------+     |Provider||
  | |     |         ^     ^         |                       +--------+|
  | |     |         |     |         |             Registration(http)^ |
  | |     |         |     |         |                  +------------+ |
  | |Chunk| Topology|     |Topology |PeerRequest(http) |              |
  | |-----| creation|     |creation +----------------+ |              |
  | |Chunk| (PPSP)  |     | (PPSP)  PeerReport(http) V V              |
  | |-----|         |     |                  +---------+     +-------||
  | |Chunk|         |     |                  | Tracker/|-----|Tracker||
  | |-----|Neighbour|     |Neighbour         |Head Node|<--+ +-------+|
  | |     |Communication  Communication      +---------+   |  ^       |
  | |     | (PPSP)  |     |(PPSP)              | ^         |  |(RELOAD)
  | |     |         |     |                    | |Statistic|  |       |
  |                 V     V                    | +---------+  V       |
  |            +-----+   +-----+             +------------------+     |
  |            |Peer2|   |Peer2|             |    Tracker       |     |
  |            +-----+   +-----+             +------------------+     |
  |                                                                   |
  |                                                                   |
  |                                                                   |

               Figure 4: Protocol interaction of PPSP systems
   At a primary consideration, some existing and developing protocols
  can be reused in some of the interactions ,e.g, HTTP in content
  registration and RELAOD in multiple trackers topology orgnization.
  And other interactions like topology creation and neighbor
  communication, need PPSP to support.This is the initial step we need
  to develop in PPSP.
  Other interactions, like peer and tracker communication, may reuse
  http or develop new PPSP protocols after evaluating the efficiency in
  PPSP scenarios.
  3) To discuss how to incorporate other node information such as
  online time, link status, node capability, battery information and
  some application requirements parameters into the protocol to expand
  the peer selection.

Zhang               Expires January 12, 2010            [Page 19]

Internet-Draft   Problem Statement of P2P Streaming Protocol  July 2009

  In this part, we actually want to expand to standardize PPSP message
  headers (analogous to IP header definition) and PPSP metadata format
  (analogous to SIP header definition).

Zhang               Expires January 12, 2010            [Page 20]

Internet-Draft   Problem Statement of P2P Streaming Protocol  July 2009

6. Security Considerations
  PPSP has a similar assumption in peer privacy as P2PSIP, i.e., all
  participants in the system are issued unique identities and
  credentials through some mechanism not in the scope of this working
  group, such as a centralized server. Hence the WG will not attempt a
  solution to these issues for P2P streaming networks in general.
  However PPSP has some unique privacy issue different from P2PSIP:
  1) The content published by peers may not be checked by centralized
  certificating server because of the high amount. Therefore P2P
  streaming network faces with more serious malicious content
  distribution danger than P2PSIP.
  2) Content Pollution is a phenomenon P2PSIP may not meet with. But
  these is a common problem faced by P2P streaming and file sharing.
  It's recorded that there are about 50% of the content is polluted in
  file sharing applications. Although it's not as serious as file
  sharing content pollution, it's still a big issue P2P streaming
  applications face with.
  3) Because there is a tracker server who is critical to the P2P
  streaming systems. It has more probability to launch attacks to the
  PPSP may include some security mechanisms to prevent malicious nodes
  to pollute or launch attacks to the tracker. Security issues in PPSP
  need to be further investigated.
7. Acknowledgments
  We have to acknowledge many people. For the record: D.Bryan from
  SIPeerior;E.Marocco from TI;V.Gurbani from AT&T;R.Even from
  Huawei;H.Zhang from NEC Labs,USA;C.Schmidt and L.Xiao from
  NSN;C.Williams from ZTE;V.Pasualfrom Tekelec; X.Zhang from PPlive;
  H.Deng from China Mobile;and J.Lei from Univ. of Goettingen.
8. References
  [Cisco] Approaching the Zettabyte Era by Cisco.
  [PPLive] www.pplive.com
  [PPStream] www.ppstream.com
  [UUSee] www.uusee.com

Zhang               Expires January 12, 2010            [Page 21]

Internet-Draft   Problem Statement of P2P Streaming Protocol  July 2009

  [youtube] www.youtube.com
  [tudou] www.tudou.com
  [CNN] www.cnn.com
  [Octoshape] www.octoshape.com
  [Sigcomm:P2P streaming]Challenges, Design and Analysis of a Large-
  scale P2P-VoD System,Yan Huang et al, Sigcomm08.
  [draft-marocco-alto-problem-statement-03], Application-Layer Traffic
  Optimization (ALTO) Problem Statement, E. Marocco et al, draft-
  [CoolStreaming] CoolStreaming/DONet: A Data-Driven Overlay Network
  for Efficient Live Media Streaming, Xinyan Zhang et al,
  [HPTP] HPTP: Relieving the Tension between ISPs and P2P, Guobin Shen
  et al,
  [GENI] www.geni.net
  [MobileTV] MobileTV,Turning in or switching off, Arthur D. Little
  [Computer Networks:Traffic] Traffic analysis of peer-to-peer IPTV
  communities, Thomas Silverston et al, Computer Networks, 53 (2009)
  [Survey]A survey on peer-to-peer video streaming systems,Yong Liu et
  al, Peer-to-Peer Netw Appl (2008) 1:18-28,Springer.

Zhang               Expires January 12, 2010            [Page 22]

Internet-Draft   Problem Statement of P2P Streaming Protocol  July 2009

  [draft-zhang-alto-traceroute-00] www.ietf.org/internet-draft/draft-
  [Mesh and Muti-tree comparison] Source vs Data-driven Approach for Live
  P2P Streaming.Thomas Silverston and Olivier Fourmaux.Proceedings of the
  international Conference on Networking,international Conference on Systems,
  and international Conference on Mobile Communications and Learning

Author's Addresses
  Yunfei Zhang
  China Mobile Communication Corporation

  Ning Zong
  Huawei Technologies Co., Ltd.

  Gonzalo Camarillo

  James Seng

  Richard Yang
  Yale University

Zhang               Expires January 12, 2010            [Page 23]