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

Versions: 00 01 02 03 04 draft-ietf-ppsp-reqs

PPSP                                                        N. Zong, Ed.
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                                Y. Zhang
Expires: September 6, 2010                    China Mobile Communication
                                                             Corporation
                                                              V. Pascual
                                                                 Tekelec
                                                             C. Williams
                                                              Consultant
                                                                 L. Xiao
                                                  Nokia Siemens Networks
                                                           March 5, 2010


               P2P Streaming Protocol (PPSP) Requirements
                        draft-zong-ppsp-reqs-03

Abstract

   The objective of the PPSP work is to standardize the key signaling
   protocols that apply to tracker and peers in a Peer-to-Peer (P2P)
   streaming system.  These protocols are called PPSP.  This document
   enumerates the requirements for the PPSP, which should be considered
   when designing PPSP.

Status of this Memo

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

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

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

   The list of current Internet-Drafts can be accessed at
   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 September 6, 2010.




Zong, et al.            Expires September 6, 2010               [Page 1]


Internet-Draft              PPSP Requirements                 March 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 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.

























Zong, et al.            Expires September 6, 2010               [Page 2]


Internet-Draft              PPSP Requirements                 March 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Overview of PPSP . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  PPSP Requirements  . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Basic Requirements . . . . . . . . . . . . . . . . . . . .  6
       4.1.1.  Basic Requirements to PPSP Node  . . . . . . . . . . .  6
       4.1.2.  Basic Requirements to PPSP content resource  . . . . .  6
     4.2.  PPSP Tracker Protocol Requirements . . . . . . . . . . . .  7
     4.3.  PPSP Peer Protocol Requirements  . . . . . . . . . . . . .  8
     4.4.  PPSP Error Handling and Overload Protection
           Requirements . . . . . . . . . . . . . . . . . . . . . . .  9
     4.5.  Security Considerations  . . . . . . . . . . . . . . . . . 10
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13































Zong, et al.            Expires September 6, 2010               [Page 3]


Internet-Draft              PPSP Requirements                 March 2010


1.  Introduction

   Peer to Peer (P2P) computing has been successfully used in many
   fields, from one to one communication like Voice over IP (VoIP) and
   Instance Messaging (IM), to one to many communication like streaming,
   file sharing and gaming.  In the streaming area, the popularity of
   P2P real-time and video on demand (VoD) streaming technology has been
   demonstrated by PPlive [WWW.PPLive], PPStream [WWW.PPStream], UUSee
   [WWW.UUSee], Pando [WWW.Pando] etc.  Take PPLive for example, it has
   over 5 million online users at the same time for real-time streaming.
   Also some web2.0 streaming applications such as Youtube
   [WWW.YouTube], Tudou [WWW.Tudou] are reported to use or are preparing
   to use P2P engine to accelerate its downloading rate and cut down the
   transmission cost.  P2P streaming applications account for more and
   more Internet traffic.  According to statistics in a major Chinese
   Internet Service Provider (ISP), the traffic generated by P2P
   streaming applications exceeded 50% of the total backbone traffic
   during peak time in 2008.[PPSPPS]

   Given the increasing integration of P2P streaming into the global
   content delivery infrastructure, the lack of an 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.[PPSPPS]

   The objective of the PPSP work is to standardize the key signaling
   protocols that apply to tracker and peers in a P2P streaming system.
   These protocols are called 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
   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.[PPSPPS]

   This document enumerates the requirements for the PPSP, which should
   be considered when designing PPSP.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119] and



Zong, et al.            Expires September 6, 2010               [Page 4]


Internet-Draft              PPSP Requirements                 March 2010


   indicate requirement levels for compliant implementations.

   This document uses the following PPSP-related terms, which are
   defined in [PPSPPS], including:

   Chunk, Live streaming, Peer/PPSP peer, PPSP, Swarm, Tracker/PPSP
   tracker, Video-on-demand (VoD).

   Furthermore, the following additional terms will be used:

   Peer list: A list of peer ID which are in a same swarm maintained by
   the PPSP tracker.  A peer must fetch the peer list of a swarm from
   the tracker to know which peers have the required content.

   Swarm ID: Identifier for certain swarm.  It is used to describe a
   specific resource shared among peers.

   Usage type: Information used to identify the type of shared content.
   Currently there are two usage types in PPSP: live streaming and VoD.
   PPSP may also be extended to support more usage types, e.g. data
   file.

   Chunk ID: An identifier of a chunk for a certain resource which shows
   the position (or time slot) of the chunk in the whole file (or live
   streaming).  A peer should report to tracker which chunks are
   actively maintained in its buffer by sending the chunk IDs of a file
   for certain swarm.

   Buffer map: A map to indicate which chunks a peer currently has
   buffered and can share with other peers.  The buffer map can include
   the offset (the ID of the first chunk stored by the peer), the length
   of the buffer map, and a string of zeroes and ones indicating which
   chunks are available.  It reflects the content availability of a peer
   in coarse grain.

              <------- Buffer Map Length ------------->
                    +---+---+---+---+---+---+---+---+---+---+
  <---------->| 1 | 1 | 1 | 1 | 0 | 1 | 1 | 0 | 0 | 1 |
           offset   +---+---+---+---+---+---+---+---+---+---+
  |-------------------------------------------------------------------->
                                                          Content Length

                      Figure 1: Buffer Map

   Bitmap: A map of bits to reflect the availability of the smallest
   transmission units in chunks.  It can also be generally described as
   content availability of a peer.  Peers in a swarm need exchange the
   bitmap information to know where to get their interested data units.



Zong, et al.            Expires September 6, 2010               [Page 5]


Internet-Draft              PPSP Requirements                 March 2010


3.  Overview of PPSP

   As described in [PPSPPS], the following components are considered in
   the scope of PPSP:

   1) Tracker communication.  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) Peer communication.  Peer communication is a component that
   enables each peer to exchange content availability and request other
   peers for content.

   3) Report.  Report is a component that enables peers to report
   streaming status to the tracker.  The information may include swarm
   IDs to show swarms that the peer is taking active part in, chunk list
   for each swarm to show the current content availability in the peer,
   inbound/outbound traffic capacity, amount of neighbor peers, peer
   health degree and other streaming parameters.

   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.

   PPSP tracker protocol will define:

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

   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.

   PPSP peer protocol will define:

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

   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.

   This document itemizes requirements for the following aspects of
   PPSP:

   1) Basic requirements to PPSP nodes (peer/tracker) and the content



Zong, et al.            Expires September 6, 2010               [Page 6]


Internet-Draft              PPSP Requirements                 March 2010


   resource.

   2) General requirements to the message format and process flow of
   PPSP tracker protocol.

   3) General requirements to the message format and process flow of
   PPSP peer protocol.

   4) Error handling and overload protection requirements.

   5) Security requirements.


4.  PPSP Requirements

4.1.  Basic Requirements

   In order to make PPSP work, some basic requirements must be
   satisfied, which are necessary preconditions for peers and trackers
   to take part in PPSP services and for content being shared among PPSP
   peers.

4.1.1.  Basic Requirements to PPSP Node

   PPSP.TP.REQ-1: Each peer in PPSP MUST has a unique identifier, i.e.
   peer ID.

   It's a basic requirement for a peer to have an identity in PPSP
   communication that other peers or tracker can refer the ID for the
   peer.

   PPSP.TP.REQ-2: The tracker in PPSP MUST have a public identity that
   can be discovered and accessed by PPSP peers.

   It requires trackers are reachable with identifiers from Internet or
   other IP network.  But how to discover the tracker is not in the
   scope of PPSP.

4.1.2.  Basic Requirements to PPSP content resource

   PPSP.TP.REQ-3: The data resources shared in PPSP services MUST be
   classified and identified by different usage types.

   PPSP is designed for P2P live streaming and VoD.  It also has the
   potential to be used for P2P data file sharing.  These usage types
   have different requirements for truck queries and transmission
   behaviors, e.g. data downloading order and time constraint.
   Therefore, usage types are necessary to guide different content



Zong, et al.            Expires September 6, 2010               [Page 7]


Internet-Draft              PPSP Requirements                 March 2010


   sharing behaviors.

   PPSP.TP.REQ-4: The content in PPSP MUST be identified by swarm ID.

   A swarm refers to a group of peers sharing the same content.  It
   could be a TV Channel, film name or file name.  Swarm ID can be
   looked as a resource ID to denote a specific content.  The swarm ID
   can be used in two cases: 1) a peer requests the tracker for the peer
   list indexed by a swarm ID; 2) a peer tells the tracker about the
   swarms it belongs to.

   PPSP.TP.REQ-5: The content resource shared by a swarm in PPSP MUST
   allow being partitioned into chunks with a standard format.

   A key characteristic of P2P streaming system is allowing the data
   fetching from different peers concurrently.  Therefore, the whole
   content must be partitioned into small peaces, called chunks in PPSP,
   for transmission.  The chunks must be formed and sorted by a standard
   way, so when a peer says it requires some chunks, e.g. 011, 012 and
   013, other peers could understand which peaces wanted by the peer
   exactly.  Also, a normative buffer map can be used to show the chunk
   availability of a peer.

   PPSP.TP.REQ-6: The content resource shared by a swarm in PPSP MUST
   have a standard data format.

   So, the availability of each data unit in a peer can be denoted in a
   normative bitmap structure.  By exchanging the bitmap, peers in a
   swarm can schedule the transmission in the grain of the smallest data
   units.

4.2.  PPSP Tracker Protocol Requirements

   PPSP tracker protocol defines how PPSP peers report and request
   information to/from PPSP trackers and how PPSP trackers reply to the
   requests.  The tracker discovery and the possible communication
   between trackers are out of the scope of the PPSP tracker protocol.

   PPSP.TP.REQ-7: The PPSP trackers MUST implement the PPSP tracker
   protocol, for receiving PPSP tracker queries and periodical peer
   status reports/updates from peers and for sending the corresponding
   replies.

   PPSP.TP.REQ-8: The PPSP peers MUST implement the PPSP tracker
   protocol for sending PPSP tracker queries and periodical peer status
   reports/updates to PPSP tracker and receiving the corresponding
   replies from tracker.




Zong, et al.            Expires September 6, 2010               [Page 8]


Internet-Draft              PPSP Requirements                 March 2010


   PPSP.TP.REQ-9: The tracker request message MUST allow the peer to
   solicit the peer list from tracker with the respect of the specific
   swarm ID.

   PPSP.TP.REQ-10: The tracker request message MAY include parameter of
   requested number of downloading peers or preferred downloading
   bandwidth.

   PPSP.TP.REQ-11: The tracker reply message MUST allow the PPSP tracker
   to offer list of active peers with the respect of the requested
   swarm.

   PPSP.TP.REQ-12: The peer status report (update) message MUST have the
   ability to inform the tracker about the peer!_s activity with the
   swarm and chunk information of the peer.

   PPSP.TP.REQ-13: The PPSP tracker MAY generate the peer list with the
   help of traffic optimization services, e.g.  Alto.

   PPSP.TP.REQ-14: The peer status report (update) message MAY have the
   option to carry streaming status of the peer, including online time,
   link status, peer capability and other streaming parameters of the
   peer.  Therefore, the tracker is able to select better candidate
   peers for streaming without the help of other traffic optimization
   services.

4.3.  PPSP Peer Protocol Requirements

   PPSP peer protocol defines how PPSP peers advertise data availability
   and exchange neighbor peer information.  The protocol will also
   define the requests and responses of data chunks and peer properties
   among PPSP peers.  The transport mechanism and transmission control
   are out of the scope.

   PPSP.TP.REQ-15: The PPSP peers MUST implement the PPSP peer protocol
   to exchange information and negotiate the data chunk requests and
   responses before any content is transmitted.

   PPSP.TP.REQ-16: The content availability request message MUST allow
   the peer to solicit the chunk ID and bitmap information from other
   peers with the respect of the peer list received from tracker.

   PPSP.TP.REQ-17: The content availability reply message MUST allow the
   PPSP peer to offer the list of chunk ID and bitmap of the data in its
   buffer.

   PPSP.TP.REQ-18: The content availability reply message MAY offer
   information of other active peers than that in the peer list with the



Zong, et al.            Expires September 6, 2010               [Page 9]


Internet-Draft              PPSP Requirements                 March 2010


   same swarm ID and required chunks.

   It is possible that a peer may need additional peers for certain
   content.  Therefore, it is allowed that the peer communicates with
   the peers in the current peer list to obtain additional group of
   peers in the swarm.

   PPSP.TP.REQ-19: The content availability update message MUST be
   advertised among swarm peers periodically or on-demand.

   During the content transmission and the dynamic join/leave of peers,
   the content availability information of neighborhoods are changing,
   which requires being updated on time.  A simple way to realize it is
   advertising the chunk availability periodically among peers.
   However, how often the advertisement is an open issue.  Different
   usage types may differ in the requirement.  Too frequent updates
   waste the network resource.  Therefore, the update can be done on
   demand.  When a peer find there are not enough peers with certain
   chunks, it will generate an update request to its neighbors to enrich
   the peer list it maintains.

   PPSP.TP.REQ-20: The peer streaming status update information MAY be
   advertised among peers.

   Streaming status information should be related to the content
   delivery, including online time, link status, peer capability and
   other streaming parameters of the peer.  With this information, a
   peer can select more appropriate peers for content sharing based on
   some content sharing strategies and/or application requirements.

4.4.  PPSP Error Handling and Overload Protection Requirements

   PPSP.TP.REQ-21: The PPSP tracker protocol and peer protocol MUST use
   TCP based transport to ensure the reliability during the signaling
   message transmission.

   PPSP.TP.REQ-22: A peer MUST be able to respond with error information
   to the peers sending PPSP messages, when some information (e.g. peer
   list, chunk expression) cannot be understood in the message.












Zong, et al.            Expires September 6, 2010              [Page 10]


Internet-Draft              PPSP Requirements                 March 2010


     Local Peer                                         Peers/Tracker
         |                                                |
         |                  PPSP Message                  |
         |<-----------------------------------------------|
         |                                                |
         |               Error Information                |
         |----------------------------------------------->|
         |                                                |
         |                                                |

                        Figure 2: Error Handling

   PPSP.TP.REQ-23: A PPSP tracker, which is operating close to its
   capacity limit, MUST be able to inform peers about its impending
   overload situation, and redirect them to another PPSP tracker.

   PPSP.TP.REQ-24: A PPSP tracker, which is operating close to its
   capacity limit, MUST be able to inform peers about its impending
   overload situation, and terminate the conversation with the current
   PPSP tracker.

   PPSP.TP.REQ-25: A PPSP tracker, which is operating close to its
   capacity limit, MUST be able to inform peers about its impending
   overload situation, and reject new conversation attempts.

4.5.  Security Considerations

   The scope of this section is to analyze the security threats and
   provide the requirements for PPSP.  While P2P streaming system
   prevails in recent years, an important but less studied problem is
   security.

   PPSP.SEC.REQ-26: PPSP MUST ensure that only authorized users can
   access the original media in the P2P streaming system.  This can be
   achieved by defining or adopting such mechanisms as user
   authentication and/or key management scheme.

   PPSP.SEC.REQ-27: Confidentiality of the streaming data SHOULD be
   supported and the corresponding key management scheme MUST scale well
   without degrading the system performance.

   PPSP.SEC.REQ-28: PPSP MUST provide an option to encrypt data exchange
   among PPSP entities.

   PPSP.SEC.REQ-29: PPSP MUST prevent stream pollution attacks.  In the
   stream pollution attack, the attacker mixes into the stream bogus
   chunks, or declare the chunks it doesn't have.




Zong, et al.            Expires September 6, 2010              [Page 11]


Internet-Draft              PPSP Requirements                 March 2010


   Such an attack will degrade the quality of the rendered media at the
   receiver.  For example, in a P2P live video streaming system a
   polluter can introduce corrupted chunks.  Each receiver integrates
   into its playback stream the polluted chunks it receives from its
   other neighbors.  Since the peers forwards chunks to other peers, the
   polluted content can potentially spread through much of the P2P
   streaming network.

   PPSP.SEC.REQ-30: PPSP MUST have mechanisms to limit potential damage
   caused by malfunctioning and badly behaving peers in the P2P
   streaming system.  In addition there must be a way to identify badly
   behaving peers, and exclude or reject them from the P2P streaming
   system.

   PPSP.SEC.REQ-31: PPSP MUST prevent peers from exhausting the P2P
   streaming system's available resource, e.g. processing capacity,
   bandwidth, etc.

   Given the prevalence of DoS attacks in the Internet, it is important
   to realize that a similar threat could exist in a large-scale
   streaming system where attackers are capable of consuming a lot of
   resources with just a small amount of effort.

   PPSP.SEC.REQ-32: PPSP SHOULD minimize the dependency on reachability
   of centralized servers.

   PPSP.SEC.REQ-33: PPSP Peers MUST be able to participate in the
   streaming network in private manner without any aspect of the peers
   privacy violated.

   PPSP.SEC.REQ-34: Existing security mechanisms SHOULD be re-used as
   much as possible in PPSP, to avoid developing new security
   mechanisms.

   PPSP.SEC.REQ-35: Security mechanisms of PPSP SHOULD not limit the
   scalability, performance and reliability of the P2P streaming system.


5.  IANA Considerations

   This document presently raises no IANA considerations.


6.  Acknowledgements

   The authors would like to thank many people for discussing P2P
   streaming.  We would particularly like to thank: Haibin Song,
   Xingfeng Jiang from Huawei Technologies, Hui Zhang from NEC Labs, Jun



Zong, et al.            Expires September 6, 2010              [Page 12]


Internet-Draft              PPSP Requirements                 March 2010


   Lei from University of Goettingen, James Seng from PPLive, Das
   Saumitra from Qualcomm, and Christian Schmidt from NSN.


7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

7.2.  Informative References

   [WWW.PPLive]
              "www.pplive.com".

   [WWW.PPStream]
              "www.ppstream.com".

   [WWW.UUSee]
              "www.uusee.com".

   [WWW.Pando]
              "www.pando.com".

   [WWW.YouTube]
              "www.youtube.com".

   [WWW.Tudou]
              "www.tudou.com".

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

   [ProbSta]  Zhang, Y., "Problem Statement of P2P Streaming Protocol
              (PPSP)", IETF PPSP BoF, November 2008.

   [P2PLive]  Guo, Y., Liang, C., and Y. Liu, "Adaptive Queue-based
              Chunk Scheduling for P2P Live Streaming", IFIP
              Networking Proceedings, May 2008.

   [LiveStream]
              Pascual, V., "Live Streaming over P2PSIP", International
              SIP Conference 10th Edition, January 2009.

   [I-D.ietf-p2psip-base]
              Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
              H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)



Zong, et al.            Expires September 6, 2010              [Page 13]


Internet-Draft              PPSP Requirements                 March 2010


              Base Protocol", draft-ietf-p2psip-base-01 (work in
              progress), December 2008.

   [PPSPPS]   Zhang, Y., Zong, N., Camarillo, G., Seng, J., and R. Yang,
              "PPSP Problem Statement",
              draft-zhang-ppsp-problem-statement-05 (work in progress).


Authors' Addresses

   Ning Zong (editor)
   Huawei Technologies

   Phone: +86 25 84565866
   Email: zongning@huawei.com


   Yunfei Zhang
   China Mobile Communication Corporation

   Phone: +86 13601032119
   Email: zhangyunfei@chinamobile.com


   Victor Pascual
   Tekelec

   Email: victor@iptel.org


   Carl Williams
   Consultant
   Palo Alto, California 94306

   Email: carlw@mcsr-labs.org


   Lin Xiao
   Nokia Siemens Networks

   Phone: +86 10 84055824
   Email: lin.xiao@nsn.com









Zong, et al.            Expires September 6, 2010              [Page 14]


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