[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: Standard track                                   N.Zong
                                                              HuaweiTech
                                                             G.Camarillo
                                                                Ericsson
                                                                  J.seng
                                                                  PPlive
                                                                  R.Yang
                                                         Yale University
Expires: April 18, 2011                                 October 18, 2010





             Problem Statement of P2P Streaming Protocol (PPSP)
                 draft-ietf-ppsp-problem-statement-00.txt


Abstract

   We propose to standardize the key signaling protocols among various
   P2P streaming system components including the tracker and the peers.
   These protocols, called PPSP, are a part of P2P streaming protocols.
   This document describes the terminologies, concepts, incentives, and
   scope of developing PPSP, as well as the use cases 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 April 18, 2011.





Zhang                  Expires April 18,2011                 [Page 1]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010



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.

   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.








Zhang                  Expires April 18, 2011                 [Page 2]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010


Table of Contents


   1. Introduction ................................................ 4
      1.1. Background ............................................. 4
      1.2. Research or Engineering ................................ 5
      1.3. Objective and outline................................... 5
   2. Terminology and concepts .................................... 6
   3. Introduction of P2P streaming system ........................ 8
   4. Problem of proprietary protocols and incentives for developing
   standard PPSP .................................................. 9
      4.1. Proprietary signaling leads to difficult interactions in case
      of multiple parties involved in the delivery ................ 10
      4.2. Proprietary signaling leads to multiple client software in a
      terminal .................................................... 11
      4.3. Proprietary signaling leads to low network resource
      utilization ................................................. 11
      4.4. Proprietary signaling doesn't handle well with mobile and
      wireless environment......................................... 11
   5. Components of P2P streaming system........................... 13
   6. Scope of PPSP ............................................... 14
      6.1. Protocols to be standardized............................ 14
      6.2. Service types to be considered ..........................15
   7. Use cases of PPSP ........................................... 16
      7.1. Worldwide Provision by cooperative P2P Streaming vendors with
      PPSP......................................................... 16
      7.2. Three Screen P2P streaming in heterogeneous environment using
      PPSP  ....................................................... 17
      7.3. CDN supporting streaming ............................... 18
      7.4. Hierarchical P2P Streaming Distribution with PPSP ...... 19
      7.5. Serving Gatwway/GGSN acting as Super Nodes assisting P2P
      streaming delivery in Cellular mobile environment ........... 20
   8. Security Considerations ..................................... 22
   9. Acknowledgments ............................................. 22
   10. Informative References...................................... 23













Zhang                  Expires April 18, 2011                 [Page 3]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010


1. Introduction

    1.1. Background

   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
   2010, and the percentage is expected to rise to as high as 91% of the
   total Internet traffic in 2014.

   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 and
   its 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 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 at least 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 the peak time in 2008. In early 2010, CNTV,
   China National Network Television for CCTV, launched its software
   named CBox, which supports P2P-based live and VoD programs. The user
   base of CBox has increased rapidly. During the opening of 2010 FIFA
   World Cup, the user base of CBox increased 5 times, reaching 3
   million online users a day and altogether 350 million times view. It
   is reported that CNTV can support 10 million simultaneous user visits
   [CNTV]. The latest release of Adobe Flash, a major platform of
   streaming distribution in the Internet, has introduced Stratus, a
   client-to-client data exchange mode. There were reports that other
   major video distributors such as Youtube [youtube] and tudou [tudou]
   are also conducting trials of using P2P streaming as a component of
   their delivery infrastructures.




Zhang                  Expires April 18, 2011                 [Page 4]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010


   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. On the other hand, we observe a recent trend that more
   participants beyond traditional P2P streaming vendors are joining the
   efforts in the development of P2P streaming. Some of these additional
   participants include infrastructure vendors as Akamai [Akamai],
   ChinaCache, and ISPs like ComCast [ComCast]. That is, the P2P
   streaming ecosystem is becoming an increasingly diverse industry with
   participants from the source, infrastructure (in P2P mode although
   all the peers are super nodes), delivery and local P2P distribution
   to the terminals.

   We argue that proprietary P2P streaming protocols lead 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.2. Research or Engineering

   As [P2PStreamSurvey] identifies, there exist multiple proprietary P2P
   streaming systems including PPLive, PPstream, UUsee, Pando, abacast,
   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 also shows that existing P2P streaming
   systems are largely converging, sharing similar architecture and
   signaling protocols [draft-zhang-ppsp-protocol-comparison-
   measurement-00].

   The role of standardization in P2P streaming systems is to 1)
   decouple the information exchange with the data delivery so that some
   most common functions of P2P streaming can use a generic and open
   protocol;

   2) standardize the information exchange message so that network and
   service equipments from different providers can interact with each
   other to produce a complete P2P streaming system.

    1.3. Objective and outline

   Multiple protocols such as streaming control, resource discovery,
   streaming data transport, etc. are needed to build a P2P streaming



Zhang                  Expires April 18, 2011                 [Page 5]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010


   system [P2PStreamingSurvey]. We call those protocols P2P streaming
   protocols.

   The objective of PPSP(Peer to Peer Streaming Protocol) is to
   standardize the key signaling protocols among various P2P streaming
   system components, including the tracker and the peers. Note that the
   complete set of standard P2P streaming protocols for a complete P2P
   streaming system could be developed following or in parallel to the
   development of PPSP.

   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. Regarding to the components it involves,
   PPSP allows effective integration between the peer index server named
   tracker and different kinds of peers including edge infrastructure
   nodes such as cache, gateway and CDN nodes who can act as super peers
   and ordinary peers.

   This document describes the terminologies, concepts and common
   architecture for P2P streaming systems, problems without standardized
   PPSP (i.e., incentives to standardize PPSP), scope of PPSP as well as
   its use cases.

   The rest of this document is organized as follows. In Section 2, we
   introduce some common terminologies and concepts. In Section 3, we
   introduce P2P streaming system architecture. In Section 4, we
   identify the problems without standardized protocols and incentives
   for developing PPSP protocols. In Section 5 and 6, we describe the
   software architecture and functional components of P2P streaming
   systems in order to present the position and scope of PPSP. In
   Section 7, we list some PPSP use cases.



      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 [Sigcomm:P2P streaming]. 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) node: A CDN node refers to a
   network entity that is deployed in the network (e.g., at the network


Zhang                  Expires April 18, 2011                 [Page 6]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010


   edge or data centers) to store content provided by the original
   servers, and serves content to the clients located nearby
   topologically.

   Live streaming: The 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.

   P2P streaming protocols: P2P streaming protocols refer to protocols
   such as streaming control, resource discovery, streaming data
   transport, etc. P2P streaming protocols are needed to build a
   complete P2P streaming system.

   Peer/PPSP peer: A peer/PPSP 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: PPSP refer to the key signaling protocols among various P2P
   streaming system components, including the tracker and peer. PPSP are
   a part of P2P streaming protocols.

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

   Tracker/PPSP tracker: A tracker/PPSP tracker refers to a directory
   service which maintains a list of peers/PPSP peers storing chunks for
   a specific channel or streaming file, and answers queries from
   peers/PPSP peers for peer lists.

   Video-on-demand (VoD): The scenario where different clients may watch
   different parts of the same recorded media content during a past
   event.










Zhang                  Expires April 18, 2011                 [Page 7]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010


3. Introduction of P2P streaming system

   There are multiple available P2P streaming solutions. Some are
   deployed solutions, while others are still under active study. A
   survey of existing solutions can be found in [Survey].

   In P2P streaming system, there are various swarms with each swarm
   containing a group of clients sharing same streaming content (e.g.
   channel, streaming file, etc) at a given time. These clients are
   called peers, as each client not only receives streaming content, but
   also stores and uploads streaming content to other clients. In a
   broad sense of global content delivery infrastructure, peers can
   include multiple types of entities such as end user applications,
   caches, CDN nodes, and/or other edge devices. Therefore, the basic
   functions of a P2P streaming system involve:

   1) Maintaining information about which peers are in which swarms
      using some directory service, a.k.a. tracker.

   2) In each swarm, exchanging information about content availability
      (e.g. which chunks stored by a peer) among peers, or between
      tracker and peers.

   3) In each swarm, exchange of the actual data content among peers.

   As shown in Figure 1, common information flows in a P2P streaming
   system include:

   1) When a peer wants to receive streaming content:

   1.1) Peer acquires a list of peers in the swarm from the tracker. A
   swarm can be indexed by a channel ID, streaming file ID, etc.

   1.2) Peer exchanges its content availability with other peers that
   are its neighbors.

   1.3) Peer identifies the peers with desired content and requests for
   the content from the identified peers.

   2) When a peer wants to share streaming content with others:

   2.1) Peer sends information to the tracker about the swarm it belongs
   to, plus streaming status and/or content availability.






Zhang                  Expires April 18, 2011                 [Page 8]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010


         +-------------------------------------------------------+
         |                  +-------------------+                |
         |                  |   Tracker         |                |
         |                  +-------------------+                |
         |                   ^  |             ^                  |
         |                   |  |             |swarms,           |
         |             query |  | peer list   |streaming status  |
         |                   |  |             |and/or content    |
         |                   |  |             |availability      |
         |                   |  V             |                  |
         |        +-------------+         +------------+         |
         |        |    Peer1    |<------->|   Peer 2   |         |
         |        +-------------+ content +------------+         |
         |                 ^  ^     availability                 |
         |                 *  | content                          |
         |         content *  |availability                      |
         |                 V  V                                  |
         |             +------------+                            |
         |             |   Peer 3   |                            |
         |             +------------+                            |
         +-------------------------------------------------------+
         Figure 1 Common information flows in P2P streaming system



      4. Problem of proprietary protocols and incentives for developing
         standard PPSP

   We start by considering the success of the Web. It is the standard
   HTTP protocol that makes it possible to deploy the global content
   distribution eco-system that consists of not only end devices such as
   Web servers and Web clients, but also infrastructure devices such as
   Web caches and CDN nodes. All of these devices communicate through
   standard protocols and provide substantial benefits to the consumers,
   the content publishers, and the network infrastructure.

   As we discussed in Section 1, given the increasing integration of P2P
   streaming into the global content delivery infrastructure,
   proprietary P2P streaming protocols not only result in repetitious
   development efforts and lock-in effect, but also lead to substantial
   difficulties when integrating P2P streaming as an integral component
   of a global content delivery infrastructure. The explicit incentives
   to get rid of the proprietary protocols can be seen from the talks of
   Johan Pouwelse, scientific director of P2P Next: "?broadcasters from
   the BBC to Germany's ARD just seem to love the idea of ditching their
   proprietary platforms [Johan Pouwelse]."



Zhang                  Expires April 18, 2011                 [Page 9]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010


   Let's take a look of several cases for further problem identification.

    4.1. Proprietary signaling leads to difficult interactions when
       multiple parties are involved in the delivery

   Consider a simplest case. In an open P2P streaming industrial
   environment, it is possible for different streaming vendors (esp.
   spread in different regions) to cooperatively deliver a broadcasting
   event. Suppose PPLive broadcasts live Chinese spring festival gala
   for American Chinese by Pando networks. At a first sight, this seems
   reasonable because there are relatively few American Chinese PPLive
   users. Therefore it can be challenging to achieve efficient P2P
   delivery by PPLive alone. Utilizing peer resources from a partner
   such as Pando may achieve higher efficiency. However, different
   messages and interaction semantics  between the two existing systems
   can lead to challenges in achieving interoperability among PPLive
   peers and Pando peers.

   Consider a more complex case where P2P streaming vendors cooperate
   with CDN providers. Such integration is already practiced by systems
   such as UUSee, RayV and Forthtech. For P2P streaming, it has been
   shown that infrastructure devices such as edge caches and CDN nodes
   can improve the performance of P2P streaming (e.g., lower latency) by
   providing more stable "super peers" and reduce traffic in ISP network
   [CDN+P2P] [RFC 5693].

   However, there can be substantial obstacles in deploying
   infrastructure edge devices supporting proprietary P2P streaming
   protocols [HTPT]. Unlike the Web with the standard HTTP protocol, the
   current P2P streaming landscape consists of multiple, proprietary P2P
   streaming protocols differing in their signaling transactions.
   Consequently, in order to support P2P streaming, the infrastructure
   devices need to understand and keep updated with various proprietary
   P2P streaming protocols. This introduces complexity and deployment
   cost of infrastructure devices.

   The setting can become more challenging if there are M P2P streaming
   vendors and N CDN providers for possible cooperative combination. How
   does a specific CDN node identify different private systems and
   report to different trackers with proprietary protocols? It seems
   there are no good ways to address this. The CDN node has to update
   its protocol through case-by-case negotiations.

   With standard PPSP, edge caches and CDN nodes can be designed to
   inter-operate with only the standard protocols, reducing the
   complexity and cost to support streaming involving P2P.



Zhang                  Expires April 18, 2011                [Page 10]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010


    4.2. Proprietary signaling leads to multiple client software in a
       terminal

   Because of private protocols, although there can be much commonality
   among many applications, application developers cannot share common
   development efforts, leading to repeated efforts and thus wasting
   work.

   This may require that a terminal install multiple different software
   systems for different purposes. For example a user installs CBox for
   CCTV programming, and PPLive for Japanese and Korean movies. This
   brings two problems:

   1) Due to terminal limitations, it may not be possible to install
   many clients in one machine, esp. for mobile terminals. The limited
   CPU, storage and cache often limit the concurrent threads and
   processes.

   2) Different, independent software system may conduct vicious
   competitions. In the past, we have even seen that competitors delete
   each other's software when automatically running a software program.
   Standard protocols and common components can lead to better co-use.

    4.3. Proprietary signaling leads to low network resource utilization

   From the network resource utilization perspective, if we have no
   standard protocols in designating the resource availability (which is
   a PPSP task) and every application uses its proprietary protocol for
   storage and bandwidth usage, then for the same content, many on-the-
   way data in different applications have to be cached/stored and
   transferred repeatedly. This wastes storage and causes possible
   congestion in the network.

    4.4. Proprietary signaling doesn't handle well with 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. By the
   end of 2009, there are 233 million mobile users in China [CNNIC].

   Along with the introduction of mobile and wireless capabilities into
   the Internet, mobile streaming is becoming a key offered service
   [MobileTV]. In Korea the number of mobile TV subscriber has reached
   seventeen millions, accounting for one third of the mobile
   subscribers. In Italy, there are one million mobile TV users. During



Zhang                  Expires April 18, 2011                [Page 11]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010


   the 2008 Beijing Olympic Games, more than one million users utilized
   China mobile's mobile TV service.

   Considering that the mobile and wireless nodes have better CPU,
   memory and storage and the mobile network has better network
   bandwidth (esp. there are more uplink bandwidth which is wasted for
   transferring little data in current practice) than before, there is a
   possibility for the mobile and wireless node to be peers supporting
   P2P streaming.

   However, mobile peers may face bigger challenges for supporting P2P
   streaming with unsteady network connections, less steady power and
   different media coding for mobile devices. Current proprietary
   protocols are designed mainly for the fixed Internet and do not
   address these challenges. We may therefore raise such a question:
   Shall we let these private protocols to fit in mobile environment
   system-by-system independently or solve these problems in the design
   of an open PPSP protocol suite?

   The answer is obviously clear. It is worth mentioning that the
   development of PPSP should consider the specific requirements of
   mobile Internet. For example, the overhead of PPSP should be small in
   low bandwidth mobile Internet. Also, information exchange in PPSP
   should support mobility, low battery usage and heterogeneous
   capabilities of mobile terminals. Systematic requirements on the
   development of PPSP will be addressed in the requirements documents.






















Zhang                  Expires April 18, 2011                [Page 12]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010


5. Components of P2P streaming system

         +---------------------------------------------------+
         |                  Application Layer                |
         |---------------------------------------------------|
         |                 Play-out Layer                    |
         | +----------+  +------------+   +-----------+      |
         | |start/stop|  |pause/resume|   | FF/rewind |      |
         | +----------+  +------------+   +-----------+      |
         |-------------------------------------------------- |
         |                Information Layer                  |
         | +------------+   +------+   +-----------+         |
         | |registration|   |report|   | statistics|         |
         | +------------+   +------+   +-----------+         |
         |---------------------------------------------------|
         |                Communication Layer                |
         | +---------------------+   +------------------+    |
         | |tracker communication|   |peer communication|    |
         | +---------------------+   +------------------+    |
         |           +-------------+                         |
         |           | bootstrap   |                         |
         |           +-------------+                         |
         |---------------------------------------------------|
         |           Transport Layer                         |
         +---------------------------------------------------+
           Figure 2. Major components of a P2P streaming system.

   To organize our efforts, we show the components of a complete P2P
   streaming system in Figure 2.

   1) The Transport Layer is responsible for data transmission among
   peers. UDP, TCP or other protocols can be used.

   2) The Communication Layer includes three components:

   2.1) Tracker communication is a component that enables each peer to
   get peer list from the tracker. It may also allow a peer to report
   content availability to the tracker.

   2.2) Peer communication is a component that enables each peer to
   exchange content availability and neighbor peer information as well
   as send requests other peers for content.

   2.3) Bootstrap is a component that enables newly joined nodes to
   obtain tracker information.




Zhang                  Expires April 18, 2011                [Page 13]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010


   3) The Information Layer is responsible for peer and content
   information collection and management.

   3.1) Registration is a component that enables nodes to register to
   the system, and publish the content information. The information may
   include but is not limited to: content description, content type,
   creation time, node information such as physical location, IP address.

   3.2) Report is a component that enables peers to report streaming
   status to the tracker. The information may include peer
   inbound/outbound traffic, amount of neighbor peers, peer health
   degree and other streaming parameters.

   3.3) Statistics is a component that enables trackers to manage the
   aggregated system information for global control in upload bandwidth
   consumption, overhead consumption and other tasks.

   4) The Play-out Layer is responsible for controlling the action of
   media play (e.g., start, pause, resume, stop, fast-forward, and
   rewind).

   5) The Application Layer is the top layer for streaming applications.

      6. Scope of PPSP

    6.1. Protocols to be standardized

   We propose to standardize protocols in PPSP which enable the tracker
   communication and the peer communication components in the
   communication layer, as well as the report component in the
   information layer. These protocols, called PPSP, are key mechanisms
   involving two important roles - tracker and peer in P2P streaming
   processes, as addressed in Section 3. These signaling protocols, in
   essence, aim at standardizing the content information exchange
   mechanisms among different devices in P2P streaming systems. Note
   that PPSP is only a part of P2P streaming protocols. The complete set
   of standard P2P streaming protocols for a complete P2P streaming
   system could be developed following or in parallel to the PPSP
   development.

   Because bootstrap, registration and statistics components are out-of-
   band mechanisms for streaming processes, they are not in current
   scope of PPSP. Both transport, play-out and application layers in P2P
   streaming system are also beyond the current scope of PPSP.





Zhang                  Expires April 18, 2011                [Page 14]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010


   Therefore, PPSP includes the PPSP tracker protocol - a signaling
   protocol between PPSP trackers and PPSP peers, and the PPSP peer
   protocol - a signaling protocol among PPSP peers.

   1) PPSP tracker protocol

   This protocol will define:

   1.1) Standard format/encoding of information between PPSP peers and
   PPSP trackers, such as peer list, content availability, streaming
   status including online time, link status, node capability and other
   streaming parameters.

   1.2) Standard messages between PPSP peers and PPSP trackers defining
   how PPSP peers report streaming status and request to PPSP trackers,
   as well as how PPSP trackers reply to the requests.

   Note that existing protocols should be investigated and evaluated for
   being reused or extended as the messages between tracker and peer.
   Possible candidates include the use of the HTTP, where the GET method
   could be used to obtain peer lists, the POST method used for
   streaming status reports, etc.

   2) PPSP peer protocol

   This protocol will define:

   2.1) Standard format/encoding of information among PPSP peers, such
   as chunk description.

   2.2) Standard messages among PPSP peers defining how PPSP peers
   advertise chunk availability and their neighbor peers information to
   each other, as well as the signaling for requesting chunks among PPSP
   peers.

   Again, existing protocols should be investigated and evaluated for
   being reused or extended as the messages among peers. Possible
   candidates include the use of the HTTP, where the GET method could be
   used to obtain chunk availability, etc. Considering that there can be
   a large number of peers, the protocol should consider some
   lightweight (possibly binary) protocols.

    6.2. Service types to be considered

   As stated in Section 1, PPSP will serve as an enabling technology and
   provide tools for building multiple P2P streaming systems. We are not
   standardizing certain streaming services. The reason that  we list


Zhang                  Expires April 18, 2011                [Page 15]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010


   service types here is to show we would consider the properties of
   these services as the requirements for PPSP design.

   Common service types supported by current P2P streaming systems
   include live streaming and video-on-demand (VoD).

   In live streaming, all PPSP peers are interested in the media coming
   from an ongoing event, which means that all PPSP peers share nearly
   the same streaming content at a given point of time. In live
   streaming, some PPSP 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 PPSP peers watch different parts of the recorded
   media content during a past event. In this case, each PPSP peer keeps
   asking other PPSP peers which media chunks are stored in which PPSP
   peers, and then pulls the required media from some selected PPSP
   peers.

      7. Use cases of PPSP

    7.1. Worldwide Provision by cooperative P2P Streaming vendors with
       PPSP

   As stated in section 4.1, the cooperation of P2P Streaming vendors
   can easily expand the broadcasting scale with standard PPSP. The
   interactions between cooperative P2P streaming provider A's tracker
   server and P2P streaming provider B and C's SuperNodes is shown in
   Figure 3.


















Zhang                  Expires April 18, 2011                [Page 16]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010


   +-------------------------------------------------------------------+
   |                                                                   |
   |                          +------------------+                     |
   |            +------------>| 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 3 Cooperative Vendors Interactions

    7.2. Three Screen P2P streaming in heterogeneous environment using
       PPSP

   This is a use case where PC, Setbox/TV and mobile terminals from both
   fixed Internet and mobile Internet to construct a peer overlay for
   streaming content distribution. Using PPSP protocols, peers from
   different kinds of networks can share and download what they have
   from each other to form a 3-screen streaming system.








Zhang                  Expires April 18, 2011                [Page 17]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010


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

    7.3. CDN supporting streaming

   This scenario is similar to use case 1 except that this is more like
   an M to N mapping while use case 1 is more often to be a case by case
   mapping. This reduces the case by case negotiation between the
   original provider and multiple CDN providers if otherwise proprietary
   protocols are used makes it easier for both sides to interoperate.

   The interactions between the P2P streaming provider's tracker server
   and CDN surrogates as well as interactions between CDN surrogates are
   the same as a normal peer as shown in Figure 4.

   PPSP can be used in:

   1) Interface between CDN nodes and tracker. This is very useful for a
   small streaming provider who has no its own CDN surrogates and much
   money to distribute its stream worldwide.

   2) New construction of CDN systems by PPSP. This can often occur for
   an operator or CDN vendor to build a P2P CDN system supporting
   streaming or file sharing applications with low cost.





Zhang                  Expires April 18, 2011                [Page 18]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010


   +-------------------------------------------------------------------+
   |                                                                   |
   |                          +------------------+                     |
   |              +------------>| Original Tracker |<----------+         |
   |            |             +------------------+           |         |
   |     Tracker|                ^              ^            |         |
   |    Protocol|         Tracker|              |Tracker     |Tracker  |
   |            |        Protocol|              |Protocol    |Protocol |
   |            |                |              |            |         |
   |            |                |              |            |         |
   |            v                v              v            v         |
   |      +------+ Peer    +------+            +------+    +------+    |
   |      | CDN1 |<------->| CDN1 |            | CDN2 |    | CND2 |    |
   |      | POP2 |Protocol | POP1 |            | POP1 |    | POP2 |    |
   |      +------+         +------+            +------+    +------+    |
   |         ^  ^                                           ^ ^        |
   |         |  |                                           | |        |
   |         |  | Peer Protocol                Peer Protocol| |        |
   | Peer    |  +-------------+                +--------------+ |Peer    |
   | Procotol|                |             |                |protocol|
   |         |                |             |                |        |
   |         |                |             |                |        |
   |         |                |             |                |        |
   |         v                v             v                v        |
   |      +------+ Peer    +------+    +---------+  Peer   +---------+ |
   |      | USA  |<------> | USA  |   |Caribbean|<------> |Caribbean| |
   |      | User1|Protocol | User2|    | User1   |Protocol | User2   | |
   |      +------+         +------+    +---------+         +---------+ |
   |                                                                   |
   +-------------------------------------------------------------------+
             Figure 5 CDN Supporting P2P Streaming with PPSP

    7.4. Hierarchical P2P Streaming Distribution with PPSP

   Hierarchical P2P streaming has many advantages over non-hierarchical
   streaming such as providing better QoS, e.g., lower start-up latency
   and service interruption [P2broadcast], higher throughput and lower
   packets drop ratio [Hybrid], topology-mismatch reduction and better
   management [AHLSS].

   PPSP is useful for clustering the peers because there are abundant
   node information and content information exchange fetched in the
   message.






Zhang                  Expires April 18, 2011                [Page 19]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010


    7.5. Serving Gatwway/GGSN acting as Super Nodes assisting P2P
       streaming delivery in Cellular mobile environment

   In a cellular mobile environment, with the increase in bandwidth and
   mobile terminal capabilities, P2P streaming is better to be realized
   than before. Note that we don't have compulsory mobile peers. The
   network peers and WIFI peers are easier selected. Serving
   gateway/GGSN, as the gateway for the cellular network to Internet, is
   more and more viewed as a promising place to add the cache
   functionality assisting P2P streaming services. Because it's deployed
   by the operators, the stability and storage size are better
   guaranteed than ordinary PC. Thus, it is desirable to to select
   serving gateway/GGSN as the super nodes assisting delivery. The
   interactions between serving gateway/GGSN and tracker, among serving
   gateways/GGSNs, and between serving gateway/GGSN and mobile terminal
   are shown in Figure 6. We name these kinds of serving gateway/GGSN as
   Mobile Supporting Super Nodes (MSSN). Note that if mobile terminals
   are not eligible to be a peer, it can use client/server streaming, by
   simply taking GGSN as a source.

   There are two basic scenarios in cellular networks:

   1) Self operational P2P streaming services for mobile operators: PPSP
   is a suitable protocol for tracker-GGSN and GGSN-mobile nodes
   interaction. GGSN can be both a super node and a proxy for different
   mobile terminals with different capabilities.

   2) Third-party P2P streaming services with optimized localization by
   GGSN. When introducing a popular P2P streaming application like PPLive in  a mobile network, GGSN can coordinate with the third part trackers to cache the content without needing continuous update of  the third party protocols.
















Zhang                  Expires April 18, 2011                [Page 20]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010


   +-------------------------------------------------------------------+
   |                                                                   |
   |                            Peer Protocol                          |
   |                         +-------------------+                     |
   |                         |                   |                     |
   |            ,--?.        |      ,--?.        |     ,--?.         |
   |          .'       '.    |    .'       '.    |   .'        '.      |
   |         /           \   V   /           \   V  /            \     |
   |        '  Cellular  +------+  Internet  +------+  Cellular   |    |
   |       |    Access   | MSSN |            | MSSN |   Access    /    |
   |       \   Network   +------+            +------+  Networks   /    |
   |       '              /^  ^ \             /     \            .'    |
   |       '.            / |  | '            /      '           .'     |
   |         '.        .'  |  |  '.+-------+'        '.       .'       |
   |           '------'    |  |    |Tracker|           '-----'         |
   |         Peer Protocol/|  |    +-------+                           |
   |  +------+     HTTP    |  | Tracker ^Protocol                      |
   |  |Mobile|<------------+  +---------+                              |
   |  |Phone |<-------------------------+                              |
   |  +------+    (Tracker Protocol)                                   |
   +-------------------------------------------------------------------+

     Figure 6 Serving Gateway/GGSN assisting P2P streaming delivery

    7.6. Cache Service Supporting Streaming

   Deploying cache nodes in the network edges can greatly decrease the
   inter-network traffic and increase user experience in streaming
   service. However, the cache nodes deployed by operators have to
   execute DPI(deep packet inspection) and update their matching library
   constantly to support more and more proprietary P2P streaming
   protocols along with the increase of such applications. It increases
   the operator's cost dramatically.

   If PPSP were used in the cache nodes as well as the applications,
   cache nodes can spend less cost to support more applications.

   After the cache gets the content, it can reports to the P2P streaming
   provider's tracker server just like as a normal peer and serves other
   peers as shown in Figure 7.








Zhang                  Expires April 18, 2011                [Page 21]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010


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

                Figure 7 Cache Service Supporting Streaming



      8. Security Considerations

   PPSP has similar assumptions regarding peer privacy as P2PSIP
   [ID.ietf-p2psip-base];that is,  all participants in the system are
   issued unique identities and credentials through some mechanism not
   in the scope of PPSP. One possibility is a centralized server. Hence
   PPSP will not attempt a solution to these issues for P2P streaming in
   general. However PPSP has some unique security issues:

   1) The content published by peers may not be checked by a centralized
   certificating server. Consequently, P2P streaming may conduct
   malicious content distribution.

   2) Content pollution is another common problem faced by P2P streaming.

   3) Because we focus on P2P streaming with a tracker who is critical
   to the P2P streaming system, there may be a higher probability that
   attacks are launched against the tracker.

   PPSP may include some mechanisms to prevent malicious nodes from
   polluting the streaming content or launching attacks on the tracker.
   The protocol documents will contain a complete description on the
   security/privacy concerns of PPSP.

      9. Acknowledgments

   We would like to acknowledge the following people who provided
   feedback and suggestions to this document: D. Bryan from Cogent Force;
   E. Marocco from Telecom Italia; V. Gurbani from Bell Labs/ /Alcatel-


Zhang                  Expires April 18, 2011                [Page 22]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010


   Lucent; R. Even from Huawei; H. Zhang from NEC Labs, USA; C. Schmidt
   and L. Xiao from NSN; C. Williams from ZTE; V. Pasual from Tekelec; D.
   Zhang from PPlive; H. Deng from China Mobile; and J. Lei from Univ.
   of Goettingen.

      10. Informative References

   [Cisco] Approaching the Zettabyte Era by Cisco.

   [PPLive] www.pplive.com

   [PPStream] www.ppstream.com

   [UUSee] http://newteevee.com/2008/09/14/p2p-is-coming-to-youtube/

   [youtube] www.youtube.com

   [tudou] www.tudou.com

   [CNN] www.cnn.com

   [Octoshape] www.octoshape.com

   [ATT]http://mobile.sooyuu.com/Article/content/200905/217315094629281_
   1.shtml

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

   [RFC 5693], Application-Layer Traffic Optimization (ALTO) Problem
   Statement, E. Marocco et al, draft-ietf-alto-problem-statement-04

   [Pando]www.pando.com

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

   [draft-zhang-ppsp-protocol-comparison-measurement-
   00]www.ietf.org/internet-drafts/draft-zhang-ppsp-protocol-comparison-
   measurement-00.txt

   [GENI] www.geni.net

   [FIND]www.nets-find.net


Zhang                  Expires April 18, 2011                [Page 23]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010


   [draft-zhang-ppsp-dsn-introduction-00]www.ietf.org/internet-
   draft/draft-zhang-ppsp-dsn-introduction-00.txt

   [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)
   470-484

   [Survey]A survey on peer-to-peer video streaming systems Yong Liu et
   al, Peer-to-Peer Netw Appl (2008) 1:18-28,Springer.

   [draft-zhang-alto-traceroute-00] www.ietf.org/internet-draft/draft-
   zhang-alto-traceroute-00.txt

   [P2PStreamingSurvey] Zong, N. and X. Jiang, "Survey of P2P Streaming",
   IETF PPSP BoF, November 2008.

   [Challenge] Peer-to-Peer Live Video Streaming on the Internet: Issues,
   Existing Approaches, and Challenges, Bo Li et al, IEEE Communications
   Magazine, June 2007(94-99).

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

   [Peering CDN] A Case for Peering of Content Delivery Networks,
   Rajkumar Buyya1 et al,
   http://dsonline.computer.org/portal/site/dsonline/menuitem.9ed3d9924a
   eb0dcd82ccc6716bbe36ec/index.jsp?&pName=dso_level1&path=dsonline/2006
   /10&file=o10003.xml&xsl=article.xsl&.

   [P2broadcast] P2broadcast: a hierarchical clustering live video
   streaming system for P2P networks, De-kai Liu et al,International
   Journal of Communication Systems,Volume 19,Issue 6.

   [Hybrid]Hybrid Overlay Networks Management for Real-Time Multimedia
   Streaming over P2P Networks, Mubashar Mushtaq et al, Lecture Notes in
   Computer Science, Volume 4787/2007.

   [AHLSS]AHLSS: A Hierarchical, Adaptive, Extendable P2P Live Streaming
   System, Runzhi Li et al, International Journal of Distributed Sensor
   Networks, Volume 5, Issue 1 January 2009.

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



Zhang                  Expires April 18, 2011                [Page 24]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010


   [Johan Pouwelse]http://newteevee.com/2008/07/24/open-source-p2p-
   streaming-getting-ready-to-disrupt-cdn-business-models/

   [CNTV] news.xinhuanet.com/2010-06/30/c_12281703.htm

   [CNNIC] http://it.sohu.com/s2010/cnnic25/

   [ID.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., Baset,
   S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)Base
   Protocol", draft-ietf-p2psip-base-08.

   [Akamai] Cheng Huang , Angela Wang , Jin Li , Keith W. Ross,
   Understanding hybrid CDN-P2P: why limelight needs its own Red Swoosh,
   Proceedings of the 18th International Workshop on Network and
   Operating Systems Support for Digital Audio and Video, May 28-30,
   2008, Braunschweig, Germany .

Author's Addresses

   Yunfei Zhang

   China Mobile Communication Corporation

   zhangyunfei@chinamobile.com



   Ning Zong

   Huawei Technologies Co., Ltd.

   zongning@huawei.com



   Gonzalo Camarillo

   Ericsson

   Gonzalo.Camarillo@ericsson.com



   James Seng

   PPLive



Zhang                  Expires April 18, 2011                [Page 25]


Internet-Draft  Problem Statement of P2P Streaming Protocol October 2010


   james.seng@pplive.com



   Richard Yang

   Yale University

   yry@cs.yale.edu







































Zhang                  Expires April 18, 2011                [Page 26]


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