PPSP N. Zong, Ed. Internet-Draft Huawei Technologies Intended status: Standards Track Y. Zhang Expires: September 4, 2009 China Mobile Communication Corporation V. Pascual Tekelec March 3, 2009 P2P Streaming Protocol (PPSP) Requirements draft-zong-ppsp-reqs-00 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 4, 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. Zong, et al. Expires September 4, 2009 [Page 1] Internet-Draft PPSP Requirements March 2009 Abstract The Peer to Peer Streaming Protocol (PPSP) is a distributed real-time data retrieval protocol in one-to-many communication. This document describes the requirements for the PPSP. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. P2P Streaming Problem Statement . . . . . . . . . . . . . . . 3 3.1. Motivation for P2P Streaming Protocol . . . . . . . . . . 4 3.2. Definition and Scope of P2P Streaming Protocol . . . . . . 4 3.3. Related Work in IETF . . . . . . . . . . . . . . . . . . . 6 3.3.1. P2PSIP . . . . . . . . . . . . . . . . . . . . . . . . 6 4. P2P Streaming Protocol Requirements . . . . . . . . . . . . . 6 4.1. PPSP General Requirements . . . . . . . . . . . . . . . . 6 4.2. PPSP Signaling Requirements . . . . . . . . . . . . . . . 6 4.3. PPSP Transmission Requirements . . . . . . . . . . . . . . 9 4.4. PPSP Error Handling Requirements . . . . . . . . . . . . . 9 4.5. PPSP Security Requirements . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 11 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Zong, et al. Expires September 4, 2009 [Page 2] Internet-Draft PPSP Requirements March 2009 1. Requirements Notation 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 indicate requirement levels for compliant implementations. 2. 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, especially in the winter of the financal crisis which is being felt all over the world. P2P streaming applications account for more and more Internet traffic. According to statistics in a major Chinese Internet Service Provider (ISP), PPlive accounts 10% of the total Internet backbone traffic. In contrast, Bittorrent's traffic share is about 8% in the ISP's backbone. Internet streaming is a blooming technology. To accomodate resource consumption, several architectures based on P2P principles exist. An important drawback is their incompatibility with standards. Therefore, it is impossible for various applications (e.g. web services, IPTV, content distribution, etc) to reuse all or parts of their components to implement decentralized streaming. Therefore, it's time to draw up an open and standard P2P Streaming Protocol (PPSP) in the IETF to achieve broader adoption of P2P streaming and regulate its behavior from the broader Internet point of view. Note that the PPSP is in fact at its early stage and there is still a lot of work to be done in the near future. This version of PPSP requirements is just a start point and people are kindly invited to enhance and expand it. 3. P2P Streaming Problem Statement Zong, et al. Expires September 4, 2009 [Page 3] Internet-Draft PPSP Requirements March 2009 3.1. Motivation for P2P Streaming Protocol P2P streaming applications attract more and more users to consume video content online [WWW.PPLive][WWW.PPStream]. In the case of VoD, different users watch different parts of the video content so that a peer normally maintains a buffer to share video content with other peers. In the case of live content, because all peers are mostly interested in what is actually happens "now", one possible role of a peer is to request video content from a live source and then forward the content to more peers, hence reducing the work load of the live source [WWW.PPLive]. P2P streaming applications adopt a decentralized streaming architecture where the media content is shared among peers who not only download but also upload media content to each other. The advantages of this decentralized streaming architecture include less workload (hence reduced cost) on streaming servers, and better streaming scalability for a large number of users. However, most current P2P streaming applications make use of proprietary protocols, making it impossible for various applications (e.g. web services, IPTV, content distribution, etc) to reuse all or part of their components to implement decentralized streaming. Therefore, an open and standard protocol for P2P Streaming Protocol (PPSP) defined in the IETF would greatly benefit many applications through a decentralized streaming architecture which enables reduced infrastructure cost on infrastructure (e.g. media servers) and better scalability for an increased number of users. 3.2. Definition and Scope of P2P Streaming Protocol Based on the overview of P2P streaming systems [Survey][ProbSta], the basic role of PPSP is to define a protocol of locating and transmitting real-time/VoD data efficiently from multiple sources with different pieces in peer to peer environment. Therefore PPSP can be divided into PPSP signaling protocol and transmission protocol where PPSP signaling protocol will address the issue of distributed data location. The common process of P2P streaming applications includes: a) Peer sends content request/or registration to some centralized directory server (a.k.a. Tracker) and the server return with a peer list in which the peer are sharing the requested content. This step is currently implemented by different P2P applications as private protocols. It may either be done by P2PSIP RELOAD [I-D.ietf-p2psip-base] because Dynamic Hash Table (DHT) can manage the peer list and return the peer list to the requestor. b) Peer communicate with the peers in the obtained peer list to Zong, et al. Expires September 4, 2009 [Page 4] Internet-Draft PPSP Requirements March 2009 exchange the chunk description, i.e. which chunks are located in which peers, as well as additional peer list having been learned by other peers. This step should be done by PPSP signaling protocol. c) Chunk is scheduled, i.e. which chunks are to be transmitted from which peers. This step is based on internal algorithm (e.g. rarest first) which should be performed by P2P applications themselves and thus outof the scope of PPSP signaling protocol. d) Chunk is transmitted among peers. This step should be done by PPSP transmission protocol. Therefore, the core part of PPSP signaling protocol is a set of messages between peers for: o the chunk description of each peer (e.g. buffer map); o list of additional peers to aggregate more peers; o additional peer status information related to content delivery. +---------------+ ------------>| Tracker/DHT |<--------------------------- | +---------------+ | | | | | | Content Request/Registration | | | (may be done by P2PSIP RELOAD) | | | | | | | | V V | +--------+ PPSP Signaling +--------+ | | |<------------------------------->| | | | Peer | | Peer | | | |<--------------------- | | | +--------+ | +--------+ | PPSP Signaling | V (Chunk Description, | +--------+ Peer List, | | | Peer Status, Etc.) ------------------------->| Peer | | | +--------+ More Peers ... ... Figure 1: PPSP Signaling Core Zong, et al. Expires September 4, 2009 [Page 5] Internet-Draft PPSP Requirements March 2009 [TODO: Introduce the core part of PPSP transmission protocol] 3.3. Related Work in IETF 3.3.1. P2PSIP P2PSIP is an IETF WG focusing on the protocols for distributed resource location [I-D.ietf-p2psip-base]. However, in P2P streaming, the chunk description of each peer (e.g. buffer map) is highly dynamic and real-time, which means that simply maintaining this highly dynamic information in the P2PSIP overlay network may cause overload of the peers. Therefore, in P2P streaming, it is better to keep the chunk description locally in distributed peers and use PPSP signaling to discover which peer has which content. 4. P2P Streaming Protocol Requirements 4.1. PPSP General Requirements REQ 1: PPSP MUST be able to support streaming services when the number of users keeps growing, i.e. scale to very large audiences. Internet video streaming, if it is to compete with classical TV broadcasting, has to scale to very large audiences (large scale: hundreds of thousands of users) [LiveStream]. PPSP adopts a decentralized streaming architecture where the media content is shared among peers who not only download but also upload media content to each other. REQ 2: PPSP MUST be self-adaptive to a large numbers of dynamically joining and leaving users, i.e. robust to peer churn. The robustness of a streaming system is required when a large number of customers dynamically join and leave the system, specially if some form of video relaying or forwarding for bandwidth saving is employed. In PPSP, a peer simultaneously contacts with more than one peer to share media content, thus reducing the impact of peer churn. 4.2. PPSP Signaling Requirements REQ.1: PPSP signaling MUST be able to carry chunk description (e.g. buffer map) of the peers. In order to share content among peers, peers must be able to tell each other which chunks reside in which peers. That is, PPSP signaling must carry chunk description of the peers. Zong, et al. Expires September 4, 2009 [Page 6] Internet-Draft PPSP Requirements March 2009 Local Peer Peers | | | Chunk Description | |<---------------------------------------------->| | | Figure 2: Exchange Chunk Description One common type of chunk description is called a buffer map, indicating 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 (starting with the chunk designated by the offset). <------- Buffer Map Length -------------> +---+---+---+---+---+---+---+---+---+---+ <---------->| 1 | 1 | 1 | 1 | 0 | 1 | 1 | 0 | 0 | 1 | offset +---+---+---+---+---+---+---+---+---+---+ |--------------------------------------------------------------------> Content Length Figure 3: Buffer Map After a peer receives a buffer map from other peers, the peer can request one or more chunks that other peers have advertised in the buffer map. REQ.2: PPSP signaling MUST be able to negotiate the semantics of chunk description. In order for every peer to know the exact meaning of each part of the chunk description, it is necessary for peers to negotiate the semantics of chunk description. For instance, the size of each chunk represented by the buffer map. Note that although the semantics of chunk description can be specified in a standard manner, it is useful to apply such negotiation to allow for more flexible interaction between different applications. For example, some P2P streaming application schedulers are based on chunks corresponding to size of mili-seconds while other schedulers are based on the size of seconds. Local Peer Peers | | | Negotiate Chunk Description | |<---------------------------------------------->| | | Figure 4: Negotiaion Zong, et al. Expires September 4, 2009 [Page 7] Internet-Draft PPSP Requirements March 2009 Only when these semantic of chunk description are negotiated and decided among all the peers will every peer be able to share chunk information with each other, i.e., which chunks are stored in which peers. REQ.3: PPSP signaling May carry additional peer list. Note that the tracker/DHT only return an initial list of peers to new peer. Some peers may need more peers to connect with and share content. In order for each peer to know more peers sharing the same content, it is possible that the peer communicates with the peers in the current peer list to obtain additional lists which it aggregates with the current peer list. In this manner, each peer maintains a list of other peers sharing the same content. Local Peer Peers | | | Additional Peer List | |<---------------------------------------------->| | | Figure 5: Exchange Peer List REQ.4: PPSP signaling May carry peer status for content delivery (e.g. bandwidth, work load of the peers). In addition to the chunk description, peers may want to know other status information for content delivery. Such status information should be related to the content delivery, including the peers' access type, bandwidth, storage, work load, etc. With this information, a peer can select more appropriate peers for content sharing based on some content sharing strategies and/or application requirements. For some peers deployed by ISP such as those comprising Content Distribution Network (CDN), PPSP signaling MUST be able to carry peer information. In this way, CDN will announce its capabilities for providing streaming content to the peers. Local Peer Peers | | | Peer Status for content delivery | |<---------------------------------------------->| | | Figure 6: Exchange Peer Status Zong, et al. Expires September 4, 2009 [Page 8] Internet-Draft PPSP Requirements March 2009 4.3. PPSP Transmission Requirements REQ 1: PPSP transmission MUST be able to support limited start-up delay and limited latency between the broadcasting time and the audience view time [LiveStream]. REQ 2: PPSP transmission MAY support efficient one-to-many data transport with some extent of fairness assurance and balance between self-constraint and aggression for network bandwidth. [TODO: Expand this section] 4.4. PPSP Error Handling Requirements REQ.1: A peer MUST be able to respond with error information to peers sending chunk description messages when some information (e.g. chunk ID) cannot be understood in the message. In this case, the sending peer may start a negotiation flow to negotiate the semantics of chunk description. Local Peer Peers | | | Chunk Description | |<-----------------------------------------------| | | | Error Information | |----------------------------------------------->| | | | Negotiate Chunk Description | |<---------------------------------------------->| | | Figure 7: Error Handling 4.5. PPSP Security Requirements REQ 1: PPSP MUST be able to provide mechanisms to prevent peers from distributing wrong information, such as claiming they have the chunks that they don't, or sending out false peer status information. [TODO: Expand this section] 5. IANA Considerations This document presently raises no IANA considerations. Zong, et al. Expires September 4, 2009 [Page 9] Internet-Draft PPSP Requirements March 2009 6. Security Considerations Building a P2P streaming system has many security considerations, many of which we have only begun to consider. [TODO: Expand this section] 7. 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 Lei from University of Goettingen, James Seng from PPLive, Das Saumitra from Qualcomm, Lin Xiao and Christian Schmidt. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.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 Zong, et al. Expires September 4, 2009 [Page 10] Internet-Draft PPSP Requirements March 2009 (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) Base Protocol", draft-ietf-p2psip-base-01 (work in progress), December 2008. Appendix A. Change Log New Document Appendix B. Open Issues [TODO: Fill in] Authors' Addresses Ning Zong (editor) Huawei Technologies 10F, Huihong Mansion, No.91 Baixia Road Nanjing 210001 China Phone: +86 25 84565866 Email: zongning@huawei.com Yunfei Zhang China Mobile Communication Corporation Phone: +86 13601032119 Email: zhangyunfei@chinamobile.com Zong, et al. Expires September 4, 2009 [Page 11] Internet-Draft PPSP Requirements March 2009 Victor Pasual Tekelec Am Borsigturm 11 Berlin D-13507 Germany Email: victor@iptel.org Zong, et al. Expires September 4, 2009 [Page 12]