From: http://www.ietf.org/internet-drafts/draft-ietf-ppsp-reqs-00.txt Title: P2P Streaming Protocol (PPSP) Requirements Reference: draft-ietf-ppsp-reqs-00 Date: October 15, 2010 Data Tracker: https://datatracker.ietf.org/doc/draft-ietf-ppsp-reqs/ Tracker Listing: http://ietfreport.isoc.org/idref/draft-ietf-ppsp-reqs/ Tools: http://tools.ietf.org/html/draft-ietf-ppsp-reqs-00 (HTML) Announced: http://www.ietf.org/mail-archive/web/i-d-announce/current/msg33742.html See also: IETF Peer to Peer Streaming Protocol (PPSP) Working Group http://datatracker.ietf.org/wg/ppsp/charter/ Peer to Peer Streaming Protocol Working Group Status Pages http://datatracker.ietf.org/wg/ppsp/ PPSP Working Group Discussion List and Archives https://www.ietf.org/mailman/listinfo/ppsp http://www.ietf.org/mail-archive/web/ppsp/ =============================================================================== PPSP N. Zong, Ed. Internet-Draft Huawei Technologies Intended status: Standards Track Y. Zhang Expires: April 18, 2011 China Mobile Communication Corporation V. Pascual C. Williams Consultant L. Xiao Nokia Siemens Networks October 15, 2010 P2P Streaming Protocol (PPSP) Requirements draft-ietf-ppsp-reqs-00 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 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. 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 Zong, et al. Expires April 18, 2011 [Page 1] Internet-Draft PPSP Requirements October 2010 (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. Zong, et al. Expires April 18, 2011 [Page 2] Internet-Draft PPSP Requirements October 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of PPSP . . . . . . . . . . . . . . . . . . . . . . . 6 4. PPSP Requirements . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Basic Requirements . . . . . . . . . . . . . . . . . . . . 7 4.1.1. Basic Requirements to PPSP Node . . . . . . . . . . . 7 4.1.2. Basic Requirements to PPSP content resource . . . . . 7 4.1.3. Other General Requriements . . . . . . . . . . . . . . 8 4.2. PPSP Tracker Protocol Requirements . . . . . . . . . . . . 9 4.3. PPSP Peer Protocol Requirements . . . . . . . . . . . . . 9 4.4. PPSP Error Handling and Overload Protection Requirements . . . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Zong, et al. Expires April 18, 2011 [Page 3] Internet-Draft PPSP Requirements October 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 Zong, et al. Expires April 18, 2011 [Page 4] Internet-Draft PPSP Requirements October 2010 document are to be interpreted as described in RFC 2119 [RFC2119] and 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 Zong, et al. Expires April 18, 2011 [Page 5] Internet-Draft PPSP Requirements October 2010 bitmap information to know where to get their interested data units. 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 Zong, et al. Expires April 18, 2011 [Page 6] Internet-Draft PPSP Requirements October 2010 PPSP: 1) Basic requirements to PPSP nodes (peer/tracker) and the content 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.REQ-1: Each peer in PPSP MUST has a unique identifier, i.e. peer ID. It's a basic requirement for a peer to be uniquely identified in the PPSP overlay that other peers or tracker can refer the ID for the peer. The peer ID may be generated from IP address or SIP URI which can distinguish this peer with the others. But if IP address is used as peer ID, the ID may be unstable as IP address may change while peer moving. PPSP.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.REQ-3: The data resources shared in PPSP services MUST be classified and identified by different usage types. Zong, et al. Expires April 18, 2011 [Page 7] Internet-Draft PPSP Requirements October 2010 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 sharing behaviors. PPSP.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.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.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.1.3. Other General Requriements PPSP.REQ-7: The Tracker Protocol and Peer Protocol SHOULD enable peers to receive streaming data within the time constraints required by specific content items. PPSP.REQ-8: The Tracker Protocol and Peer Protocol are Recommended to be carried over TCP (or UDP, when delivery requirements cannot be met by TCP). Zong, et al. Expires April 18, 2011 [Page 8] Internet-Draft PPSP Requirements October 2010 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-1: 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-2: 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. PPSP.TP.REQ-3: 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-4: The tracker request message MAY include parameter of requested number of downloading peers or preferred downloading bandwidth. PPSP.TP.REQ-5: 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-6: 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-7: The PPSP tracker MAY generate the peer list with the help of traffic optimization services, e.g. Alto. PPSP.TP.REQ-8: 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 Zong, et al. Expires April 18, 2011 [Page 9] Internet-Draft PPSP Requirements October 2010 among PPSP peers. The transport mechanism and transmission control are out of the scope. PPSP.PP.REQ-1: 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.PP.REQ-2: 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.PP.REQ-3: 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.PP.REQ-4: The content availability reply message MAY offer information of other active peers than that in the peer list with the 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.PP.REQ-5: The dynamic content availability information MUST be updated among swarm peers. Due to the dynamic change of the buffered content in each peer and the frequent join/leave of peers to the swarm, the content availability among neighbourhoods are always changing,which requires being updated on time. This update should be done at least on demand, which means when a peer requires finding more peers with certain chunks, it send a message to all peer in the swarm for content availability update. Or each peer in the swarm can advertise its content availability periodically, which make all the peers in the swarm keep the latest content availability information. However, how often the advertisement is an open issue. Different usage types may differ in the requirement. Too frequent updates waste the network resource. PPSP.PP.REQ-6: 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. Zong, et al. Expires April 18, 2011 [Page 10] Internet-Draft PPSP Requirements October 2010 4.4. PPSP Error Handling and Overload Protection Requirements PPSP.ERR.REQ-1: 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. Local Peer Peers/Tracker | | | PPSP Message | |<-----------------------------------------------| | | | Error Information | |----------------------------------------------->| | | | | Figure 2: Error Handling PPSP.ERR.REQ-2: 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.ERR.REQ-3: 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.ERR.REQ-4: 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. 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-1: 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-2: Confidentiality of the streaming data SHOULD be supported and the corresponding key management scheme MUST scale well without degrading the system performance. Zong, et al. Expires April 18, 2011 [Page 11] Internet-Draft PPSP Requirements October 2010 PPSP.SEC.REQ-3: PPSP MUST provide an option to encrypt data exchange among PPSP entities. PPSP.SEC.REQ-4: 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. 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-5: 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-6: 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-7: PPSP SHOULD minimize the dependency on reachability of centralized servers. PPSP.SEC.REQ-8: Existing security mechanisms SHOULD be re-used as much as possible in PPSP, to avoid developing new security mechanisms. PPSP.SEC.REQ-9: Security mechanisms of PPSP SHOULD not limit the scalability, performance and reliability of the P2P streaming system. 6. IANA Considerations This document presently raises no IANA considerations. Zong, et al. Expires April 18, 2011 [Page 12] Internet-Draft PPSP Requirements October 2010 7. Acknowledgements The authors would like to thank many people for discussing P2P streaming. We would particularly like to thank: Yingjie Gu, 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, and Christian Schmidt from NSN. 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 (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 Zong, et al. Expires April 18, 2011 [Page 13] Internet-Draft PPSP Requirements October 2010 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. [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 56624760 Email: zongning@huawei.com Yunfei Zhang China Mobile Communication Corporation Phone: +86 13601032119 Email: zhangyunfei@chinamobile.com Victor Pascual Consultant Email: victor.pascual.avila@gmail.com Carl Williams Consultant Palo Alto, California 94306 Email: carlw@mcsr-labs.org Lin Xiao Nokia Siemens Networks Phone: +86 10 84358977 Email: lin.xiao@nsn.com Zong, et al. Expires April 18, 2011 [Page 14]