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

Versions: 00 01 02 03 04 05 06 draft-ietf-ppsp-problem-statement

PPSP                                                            Y. Zhang
Internet-Draft                                              China Mobile
Intended status: Standards Track                                 N. Zong
Expires: April 23, 2010                              Huawei Technologies
                                                            G. Camarillo
                                                                Ericsson
                                                                 J. Seng
                                                                  PPLive
                                                                 R. Yang
                                                         Yale University
                                                        October 20, 2009


           Problem Statement of P2P Streaming Protocol (PPSP)
                 draft-zhang-ppsp-problem-statement-05

Status of this Memo

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

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

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 23, 2010.



Zhang, et al.            Expires April 23, 2010                 [Page 1]


Internet-Draft                   PPSP PS                    October 2009


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.

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.

































Zhang, et al.            Expires April 23, 2010                 [Page 2]


Internet-Draft                   PPSP PS                    October 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Background . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Research or engineering  . . . . . . . . . . . . . . . . .  5
     1.3.  Objective of the PPSP work . . . . . . . . . . . . . . . .  5
   2.  Terminology and concepts . . . . . . . . . . . . . . . . . . .  5
   3.  Introduction of P2P streaming system . . . . . . . . . . . . .  6
   4.  Incentives for developing standard PPSP  . . . . . . . . . . .  8
     4.1.  P2P streaming and edge cache/CDN support . . . . . . . . .  9
     4.2.  Incentive for ISPs . . . . . . . . . . . . . . . . . . . .  9
   5.  Components of P2P streaming system . . . . . . . . . . . . . . 10
   6.  Scope of PPSP  . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  Protocols to be standardized . . . . . . . . . . . . . . . 11
     6.2.  Service types to be considered . . . . . . . . . . . . . . 13
   7.  Use cases of PPSP  . . . . . . . . . . . . . . . . . . . . . . 13
     7.1.  Worldwide Provision of P2P Streaming Service with PPSP . . 13
     7.2.  Hierarchical P2P Streaming Distribution with PPSP  . . . . 15
     7.3.  Unified client software to watch P2P Streaming Programs  . 15
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     10.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19


























Zhang, et al.            Expires April 23, 2010                 [Page 3]


Internet-Draft                   PPSP PS                    October 2009


1.  Introduction

1.1.  Background

   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 paradigms 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
   historic 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 churn, with
   positive user experiences.

   In light of these technical advantages, P2P streaming is seeing rapid
   deployment.  Large P2P streaming applications such as PPLive
   [PPLive], PPstream [PPstream] and UUSee [UUSee] have each reached a
   number of installations 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 are 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 lack of open standard P2P
   streaming protocol has become 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 a component of a
   global content delivery infrastructure.  For example, proprietary P2P
   streaming protocols do not integrate well with infrastructure devices
   such as caches and other edge devices.







Zhang, et al.            Expires April 23, 2010                 [Page 4]


Internet-Draft                   PPSP PS                    October 2009


1.2.  Research or engineering

   As [P2PStreamingSurvey] identifies, there exist multiple proprietary
   P2P streaming systems including PPLive, PPstream, UUsee, 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 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 is focusing increasingly on
   content.

1.3.  Objective of the PPSP work

   Multiple protocols such as streaming control, resource discovery,
   streaming data transport, etc. are needed to build a P2P streaming
   system [P2PStreamingSurvey].  We call those protocols P2P streaming
   protocols.

   The objective of the PPSP work is 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.  Note that the complete set of standard P2P
   streaming protocols for a whole P2P streaming system could be
   developed following or parallel to the PPSP work.  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 efforts on distributed resource location, traffic
   localization, and streaming control mechanisms.  It allows effective
   integration with edge infrastructures such as cache and mobile edge
   equipment.

   This document describes the terminologies, concepts, incentives, and
   scope of developing PPSP, as well as the use cases of PPSP.  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.  In Section 4, we identify the incentives for
   developing standard P2P streaming protocols.  In Section 5, we
   describe the components of P2P streaming system.  In Section 6, we
   outline the main scope of PPSP.  In Section 7, we list some use cases
   of PPSP.


2.  Terminology and concepts

   Chunk: A chunk is a basic unit of partitioned streaming, which is
   used by a peer for the purpose of storage, advertisement and exchange



Zhang, et al.            Expires April 23, 2010                 [Page 5]


Internet-Draft                   PPSP PS                    October 2009


   among peers [Sigcomm:P2P streaming].

   Content Distribution Network (CDN) node: A CDN node refers to a
   network entity that usually is deployed at the network edge 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.  The lags between the play points
   of the clients and that of the streaming source are 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 multiple
   protocols such as streaming control, resource discovery, streaming
   data transport, etc. which are needed to build a P2P streaming
   system.

   Peer/PPSP peer: A peer/PPSP peer refers to a participant in a P2P
   streaming system.  The participant 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) sharing 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 lists 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 watch
   different parts of the media recorded and stored during past events.


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




Zhang, et al.            Expires April 23, 2010                 [Page 6]


Internet-Draft                   PPSP PS                    October 2009


   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 in which swarm in some
   directory service, a.k.a. tracker.

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

   3) In each swarm, exchange the actual 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 the peers on the
   obtained peer list.

   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 swarms it
   belongs to, plus streaming status and/or content availability.














Zhang, et al.            Expires April 23, 2010                 [Page 7]


Internet-Draft                   PPSP PS                    October 2009


   +----------------------------------------------------+
   |                  +-------------------+             |
   |                  |   Tracker         |             |
   |                  +-------------------+             |
   |                  ^  |             ^                |
   |                  |  |             |swarms,         |
   |            query |  | peer list   |streaming status|
   |                  |  |             |and/or content  |
   |                  |  |             |availability    |
   |                  |  V             |                |
   |         +-------------+         +------------+     |
   |         |    Peer1    |<------->|   Peer 2   |     |
   |         +-------------+ content +------------+     |
   |              ^  ^     availability                 |
   |              *  | content                          |
   |      content *  |availability                      |
   |              *  V                                  |
   |             +------------+                         |
   |             |   Peer 3   |                         |
   |             +------------+                         |
   +----------------------------------------------------+

   Figure 1, Common information flows in P2P streaming system


4.  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 leads to substantial
   difficulties when integrating P2P streaming as an integral component
   of a global content delivery infrastructure.  For example,
   interactions between proprietary P2P streaming protocols and
   infrastructure devices pose substantial problems.  Standard PPSP
   address these problems and thus provide strong incentives.







Zhang, et al.            Expires April 23, 2010                 [Page 8]


Internet-Draft                   PPSP PS                    October 2009


4.1.  P2P streaming and edge cache/CDN support

   In the context of P2P streaming, infrastructure devices such as edge
   caches and CDN nodes are also shown as promising means to both
   improve the performance of P2P streaming (e.g., lower latency) by
   providing more stable "super peers" and reduce traffic in ISP network
   [draft-marocco-alto-problem-statement-03][CDN+P2P].

   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 mostly differing in 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.

   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.

4.2.  Incentive for ISPs

   Mobility and wireless are becoming increasingly important features to
   support in future Internet deployments [GENI], [FIND].  For example,
   China Mobile is developing the Distributed Services Network (DSN)
   strategy to build its mobile Internet
   [draft-zhang-ppsp-dsn-introduction-00].

   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 the 2008 Beijing Olympic Games, more than one million users
   utilize China mobile's mobileTV service.

   Although most current mobile TV deployments are developed in the
   traditional client/server model, there are clear interests in
   integrating streaming systems involving P2P into mobile streaming,
   due to content availability, scalability, and robustness of P2P
   systems.  However, mobile Internet may face more severe bandwidth
   limitations for supporting P2P streaming.  There can be multiple
   bottlenecks where bandwidth can be limited and the transmission cost
   can be quite high: a) between mobile terminals and mobile access
   nodes; b) between mobile access nodes; c) between the mobile network
   and the fixed network.



Zhang, et al.            Expires April 23, 2010                 [Page 9]


Internet-Draft                   PPSP PS                    October 2009


   Standard PPSP can help to address the above challenges.  With PPSP,
   infrastructure devices like mobile gateways and access points can be
   acted as "Super Peers" and deployed to interact with mobile streaming
   applications to substantial reduce bandwidth usage on key
   bottlenecks.

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


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, Components of P2P streaming system

   To organize our efforts, we show the components of a complete P2P
   streaming system in Figure 2.  Note that the components in this
   figure are considered as functional blocks of P2P streaming system.
   The inter-communication between different layers is for further
   study.



Zhang, et al.            Expires April 23, 2010                [Page 10]


Internet-Draft                   PPSP PS                    October 2009


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

   2) Communication layer includes three components:

   2.1) Tracker communication is a component that enables each peer to
   get peer list from the tracker and/or provide content availability to
   the tracker.

   2.2) Peer communication is a component that enables each peer to
   exchange content availability and request other peers for content.

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

   3) 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 regards.

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

   5) 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



Zhang, et al.            Expires April 23, 2010                [Page 11]


Internet-Draft                   PPSP PS                    October 2009


   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 are only a part of P2P streaming protocols.  The complete
   set of standard P2P streaming protocols for a whole P2P streaming
   system could be developed following or parallel to the PPSP work.

   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.

   Therefore, PPSP include 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 to each other, as well as the signaling
   for requesting the chunks among PPSP peers.

   Again, existing protocols should be investigated and evaluated for
   being reused or extended as the messages among peers.  Possible



Zhang, et al.            Expires April 23, 2010                [Page 12]


Internet-Draft                   PPSP PS                    October 2009


   candidates include the use of the HTTP, where the GET method could be
   used to obtain chunk availability, etc.  Considering the potential
   large number of peers, some lightweight (possibly binary) protocols
   could also be good candidates.

6.2.  Service types to be considered

   As stated in Section 1, PPSP will serve as enabling technology and
   tools for building various P2P streaming systems.  We are not
   standardizing certain streaming services.  The reason why we list
   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).  Note the services
   listed in this draft are not exhaustive, and more service types are
   to be involved during the PPSP work.

   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 media
   recorded and stored 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 of P2P Streaming Service with PPSP

   Consider a popular program, for example the Chinese Spring Festival,
   where a P2P streaming provider is providing a live media broadcast
   from China.  With existing deployments today, there is very little
   difficulty in watching the broadcast on the Internet from within
   China - this is already widespread practice.  However if a viewer
   outside of China wants to watch the gala from outside China, they may
   have difficulties with smooth playback because of

   1) Insufficient number of peers outside of China.

   2) Instability of dynamic peers, which makes meeting condition 1 more
   difficult.



Zhang, et al.            Expires April 23, 2010                [Page 13]


Internet-Draft                   PPSP PS                    October 2009


   3) No stable end-to-end bandwidth assurance from the source to peers
   outside China.

   As stated in section 4, the hybrid CDN and P2P architectures can ease
   the above difficulties.  With the help of PPSP, the P2P streaming
   provider can quickly leverage other CDN providers' coverage outside
   its deployment scope.  For instance, it may partner with a US CDN
   provider to provide live streaming to the audience in the USA and may
   partner with yet another provider to provide services outside of that
   service provider's scope [Peering CDN] as shown in Fig3.  PPSP helps
   by ensuring the providers have a common protocol to communicate.
   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 3.

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

   Note that some ISPs have been/are deploying CDN nodes in private
   networks to improve the user experience.  In this sense it's same as
   a CDN vendor.


























Zhang, et al.            Expires April 23, 2010                [Page 14]


Internet-Draft                   PPSP PS                    October 2009


  +-------------------------------------------------------------------+
  |                                                                   |
  |                       +------------------------+                  |
  |        +------------->|   Original Tracker     |<--------+        |
  |        |              +------------------------+         |        |
  |        |                 ^             ^                 |        |
  | Tracker|         Tracker |             | Tracker         |Tracker |
  |Protocol|         Protocol|             | Protocol        |Protocol|
  |        V                 V             V                 V        |
  |  +---------+  Peer    +---------+   +----------+  +---------+     |
  |  |  CDN1   |<-------->|  CDN2   |   |  CDN2    |  |    CDN2 |     |
  |  |  PoP2   | Protocol |  PoP1   |   |  PoP1    |  |    PoP2 |     |
  |  +---------+          +---------+   +----------+  +---------+     |
  |        ^^                                   ^          ^          |
  |  Peer  ||  Peer Protocol      Peer Protocol |          |Peer      |
  |Protocol|+--------------+              +-----+          |Protocol  |
  |        V               V              V                V          |
  |    +-------+  Peer   +------+       +---------+ Peer   +---------+|
  |    |  USA  |<------->| USA  |       |Caribbean|<------>|Caribbean||
  |    | User1 |Protocol | User2|       |   User1 |Protocol| User2   ||
  |    +-------+         +------+       +---------+        +---------+|
  |                                                                   |
  |                                                                   |
  +-------------------------------------------------------------------+

           Figure 3, Worldwide Provision of P2P Streaming Service with PPSP

7.2.  Hierarchical P2P Streaming Distribution with PPSP

   The hierarchical P2P streaming distribution have many advantages over
   non-hierarchical conterparters such as better QoS(start-up latency
   and service interruption reduction[P2broadcast], higher throughput
   and lower packets drop ratio[Hybrid], topology-mismatch reduction and
   better management[AHLSS].

   PPSP is useful for clustering the peers with abundant node
   information and content information exchange to be designed.

   The simplest hierarchical P2P streaming deployment is just similar to
   case 7.1 where CDN nodes are in the higher level.  Note that PPSP can
   be applied both in flat and hierarchical P2P streaming distribution.

7.3.  Unified client software to watch P2P Streaming Programs

   Currently the users have to install different client software in
   order to watch different P2P streaming programs since different
   vendors have generally different programs focus.  For example, when a
   user watches CCTV5 on the Internet, a sports channel with high



Zhang, et al.            Expires April 23, 2010                [Page 15]


Internet-Draft                   PPSP PS                    October 2009


   popularity in Chinese, he may choose PPLive for watching.  And when
   he turns to watch TV series, he tends to use PPStream software.This
   leads to a lot of P2P streaming software installed in the client.
   Things become worse in storage and memory constrained devices like
   mobile handset or TV setbox to install a lot of software.

   With the help of PPSP, a unified client software can understand
   different vendors supporting PPSP.  Note that this won't affect each
   vendor's audience group since a user with a unified client watching
   different vendor's programs is viewed as different users from the
   vendors' point of view.


8.  Security Considerations

   PPSP has a similar assumption in peer privacy as P2PSIP[ID.ietf-
   p2psip-base], i.e., all participants in the system are issued unique
   identities and credentials through some mechanism not in the scope of
   PPSP, such as a centralized server.  Hence PPSP will not attempt a
   solution to these issues for P2P streaming networks in general.
   However PPSP have some unique security issues:

   1) The content published by peers may not be checked by centralized
   certificating server.  Therefore P2P streaming network may have the
   danger of malicious content distribution.

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

   3) Because there is a tracker who is critical to the P2P streaming
   systems.  There is an increased probability that threats may involve
   launching attacks against the tracker.

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


9.  Acknowledgements

   We would like to acknowledge the following who provided feedback or
   suggestions for this document: D. Bryan from Cogent Force; E. Marocco
   from Telecom Italia; V. Gurbani from AT&T; R. Even from Gesher Erove;
   H. Song, Y, Gu, Lucy Yong from Huawei; H. Zhang from NEC Labs, USA;
   C. Schmidt and L. Xiao from NSN; C. Williams from ZTE; V. Pasual from
   Tekelec; X. Zhang from PPlive; H. Deng from China Mobile; and J. Lei
   from Univ. of Goettingen.



Zhang, et al.            Expires April 23, 2010                [Page 16]


Internet-Draft                   PPSP PS                    October 2009


10.  References

10.1.  Normative References

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

10.2.  Informative References

   [Cisco] Approaching the Zettabyte Era by Cisco.

   [PPLive] www.pplive.com

   [PPStream] www.ppstream.com

   [UUSee] www.uusee.com

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

   [draft-marocco-alto-problem-statement-03] Application-Layer Traffic
   Optimization (ALTO) Problem Statement, E. Marocco et al,
   draft-marocco-alto-problem-statement-03

   [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




Zhang, et al.            Expires April 23, 2010                [Page 17]


Internet-Draft                   PPSP PS                    October 2009


   [GENI] www.geni.net

   [FIND] www.nets-find.net

   [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.9ed3d9924aeb0dcd82ccc6716bbe36ec/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.




Zhang, et al.            Expires April 23, 2010                [Page 18]


Internet-Draft                   PPSP PS                    October 2009


Authors' Addresses

   Yunfei Zhang
   China Mobile

   Email: zhangyunfei@chinamobile.com


   Ning Zong
   Huawei Technologies

   Email: zongning@huawei.com


   Gonzalo Camarillo
   Ericsson

   Email: Gonzalo.Camarillo@ericsson.com


   James Seng
   PPLive

   Email: james.seng@pplive.com


   Richard Yang
   Yale University

   Email: yry@cs.yale.edu





















Zhang, et al.            Expires April 23, 2010                [Page 19]


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