PPSP Y. Gu Internet-Draft Huawei Intended status: Standards Track David A. Bryan Expires: January 6, 2011 Cogent Force, LLC / Huawei July 5, 2010 Peer Protocol draft-gu-ppsp-peer-protocol-00 Abstract This document defines the architecture of peer communication, and enumerate requirements for peer protocol. The document also tries to reuse RELOAD [draft-p2psip-base] to realize peer protocol. 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 January 6, 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 (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. Gu & Bryan Expires January 6, 2011 [Page 1] Internet-Draft Peer Protocol July 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 3 2.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Architecture and Function Entities . . . . . . . . . . . . 4 4. Peer Protocol Requirements . . . . . . . . . . . . . . . . . . 5 4.1. Locating and Connection . . . . . . . . . . . . . . . . . 5 4.2. Information Exchange . . . . . . . . . . . . . . . . . . . 6 4.3. Connection Status . . . . . . . . . . . . . . . . . . . . 9 4.4. Real-time Features . . . . . . . . . . . . . . . . . . . . 10 4.5. Transportation Negotiation . . . . . . . . . . . . . . . . 11 4.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Example Flow . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Peer Locating Protocol . . . . . . . . . . . . . . . . . . . . 12 6.1. General Comments . . . . . . . . . . . . . . . . . . . . . 13 6.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 13 7. Peer Signalling Protocol (New Protocol) . . . . . . . . . . . 14 7.1. Options . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Binary Protocol . . . . . . . . . . . . . . . . . . . . . 14 7.3. HTTP-Based Protocol . . . . . . . . . . . . . . . . . . . 15 8. Security Consideration . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Gu & Bryan Expires January 6, 2011 [Page 2] Internet-Draft Peer Protocol July 2010 1. Introduction As one of the important protocol components of PPSP, Peer protocol is required by[draft-zhang-ppsp-problem-statement]to standardize format/ encoding/messages of information between PPSP peers. The information may at least includes: 1) bitmap indicating which chunks a peer possesses, 2) required chunks IDs, 3) peer preference indicating what kind of candidate peers a requesting peer may prefer, 4) transport protocol negotiation and 5) some information that can help to improve the performance of PPSP. Meanwhile there are some discussions on the mailing list about reusing RELOAD defined in [draft-p2psip-base] to realize peer protocol. RELOAD is the core effort of P2PSIP working group, which is a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that can be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others. [draft-p2psip-base-08] The IETF encourages technology sharing among WGs, which will save unnecessary repeated work in the IETF. Therefore, before we decide to define a new signaling protocol for PPSP, we should at least try to find out whether RELOAD is suitable for PPSP network. The draft is organized in the following structure. In section 3, we introduce the protocol overview. In section 4, we enumerate detail requirements for Peer protocol, which will be the baseline for peer protocol. In section 5, we enumerate respective message flows for possible peer protocols that can fulfill requirements listed in section 4. 2. Document Conventions 2.1. Notational Conventions 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 [RFC2119]. Gu & Bryan Expires January 6, 2011 [Page 3] Internet-Draft Peer Protocol July 2010 2.2. Terminology The draft uses the terms defined in [draft-zhang-ppsp-problem-statement]and . [draft-gu-ppsp-tracker-protocol] This draft also uses some new terms. We list the relevant terms as following. Candidate peer: Peers that can provide a particular content. These peers will be recorded on Tracker and may appear in Peerlist. Block: A block is a portion of data that a peer may request. Two or more blocks make up a whole Chunk. 3. Protocol Overview 3.1. Architecture and Function Entities After obtaining the peerlist, either from Trackers, remote peers or by other means, a peer can communicate with its remote peers. The only participant in Peer protocol is peer. The information exchanged among peers is used to help peers to get desired content and will be defined in detail in section 4. This architecture shows all possible communication methods and kinds of information between peers, however this doesn't mean all of them are in scope of PPSP. If, eventually, we ascertain that some of the methods can be performed by an existing protocol, we will reuse them instead of defining a new one. Peer Peer +-------------------+ +-----------------+ |Peer Protocol |-------------------+ locating | Peer Protocol | | |Data management |<------------->| | | Tracker protocol | +===============+ | | Tracker protocol| | | |Swarm ID | | | | | | | - Chunk ID | | | | | | | - peer list | | signalling | | +-------------------+ | - Buffer map| |<------------->+-----------------+ | +===============+ | (overlay mant., info. exchange, Data Transport) | | +---------------------+ Fig 1 Function Entities of PPSP Tracker Communication A general message flow of Peer Protoco is as follows. A peer gets a peerlist from the Tracker, and then chooses some candidate peers in the peerlist to request for additional peers. The peers exchange Gu & Bryan Expires January 6, 2011 [Page 4] Internet-Draft Peer Protocol July 2010 Data Availability with some remote peers to find out whether these peers own the desired content, e.g. chunks. How a peer choose remote peers is out of the scope of Peer Protocol. According to Data Availability, the peer chooses remote peers that contain the desired content and sends Downloading requests to the remote peers. If the remote peers feedback positive response, which means the remote peers would like to provide the desired content, the peer tries to set up a transport connection with the remote peers, through which the data will be transported. After downloading, the connection may be closed. This process will be repeated until the peer gets all the content it desires. Peer Protocol can be split into 2 parts. The first part is Peer locating, named Peer Locating protocol, which means the requesting peer needs a mechanism to connect with remote peers in the peerlist. This part is closely related to Tracker protocol. Regarding different Peer identities indicated in the Peerlist, the locating mechanism and corresponding protocol will be different. For example, if Peer IDs are included in Peerlist, Peer Locating Protocol may reuse Reload protocol or design a new Peer to Peer locating protocol. If URIs are used, Peer Locating Protocol may reuse SIP or a similar mechanism to locate and establish sessions with other peers. The second part of Peer Protocol is Peer Signalling Protocol, by which peers can exchange information, such as bitmap and additional peerlist, and negotiate transport protocols, and ask for desired chunks or swarm. Both parts are important components of Peer protocol. Peer Locating Protocol has many options, while Peer Signaling Protocol needs new messages encoding. The purpose of distinct Peer Locating Protocol and Peer Signaling Protocol is to make sure that the two parts can be developed synchronously and efficiently. Before the detail message flow introduction, several general requirements are enumerated. No matter which option or combination of options is choosen as the final decision, these general requirements MUST be fulfilled by Peer Protocol. Rationale is given for some of the requirements helping to understand the requirement. 4. Peer Protocol Requirements 4.1. Locating and Connection Peer Locating is closely related to the Tracker protocol. A peer will get a peerlist from Tracker, with Peer IDs ,Peer IP Addresses or other peer identities, the form of which will influence the locating Gu & Bryan Expires January 6, 2011 [Page 5] Internet-Draft Peer Protocol July 2010 mechanism. The requirements in this section will not take any specific peerlist data structure into account, but give some general requirements that should be fulfilled. 4.1.1. Requirement Client SHOULD be able to locate peers in peerlist and connect to them with minimal or without the Tracker's assistance. 4.1.2. Rationale By 'Locating', we mean a peer can find a path between itself and the remote peer, on which messages can pass through. No matter which information is included in Peerlist: Peer ID, Peer IP Address or other, a peer should be able to use the respective mechanism to locate its remote peers with little or even without the Tracker's assistance. We should recognize that While trackers with a public address may help a peer to locate and transfer message to remote Peers by serving as proxies. This will increase the burden on Tracker and will possibly make Tracker the bottleneck of the whole system, So we do not encourage location to generally require and send message through Tracker. Several ways can be utilized by peer to locate and send message to remote peers without Tracker's assistance. For example, if Peer IP Addresses, which represents the location of a node in regular network context, are included in peerlist, a peer can try to establish a connection with the remote peers by the IP Addresses. However we must be ready to resolve the complicated problem arising when peers are behind different NATs. If Peer IDs are used in the peerlist, a peer may use typical p2p overlay locating method to connect, directly or indirectly, with the remote peers, e.g. RELOAD. In this case, the overlay will be responsible for NAT traversal. 4.1.3. Requirement Peer Protocol MUST provide a mechanism for peers behind different NAT/Firewall to connect with each other. 4.2. Information Exchange After effective connection is established between peers, peers will exchange some information that will help them to decide where to download the content. 4.2.1. Peerlist Sharing In many peer to peer streaming protocols such as PPLive and PPStream, client can obtain peerlist from both Tracker and remote peers. The Gu & Bryan Expires January 6, 2011 [Page 6] Internet-Draft Peer Protocol July 2010 tracker's main function is to record all peers in a particular swarm. However, in practice, Trackers know all the candidate peers in a particular swarm but they may not want to reply to a client with all the candidate peers in a swarm, especially when there are too many peers in a swarm. In many cases the Peer does not want to receive all the candidate peers; In some cases, Tracker just provides a list of reference peers, from which a peer can get more peerlist, if it wants to. 4.2.1.1. Peerlist Request 4.2.1.1.1. Requirment Peer Protocol MUST enable a peer to send request for peerlist to its remote peers for a particular content, e.g. a particular swarm or chunk. 4.2.1.1.2. Rationale Peer protocol should grant client this ability, even though client may not request peerlist from its remote peers (i.e., may rely strictly on lists from the tracker). 4.2.1.2. Peerlist Response 4.2.1.2.1. Requirement Peer Protocol MUST be able to create a response carrying a peerlist. 4.2.1.2.2. Rationale When receiving 'Peerlist Request', a remote peer will pick out candidate peers from local peerlist and encapsule them in 'Peerlist Response'. The most direct and effective way to transport the 'Peerlist Response' is through Peer protocol. 4.2.1.3. Peerlist Parameter 4.2.1.3.1. Requirement Peer Protocol SHOULD enable peers to indicate the number of peers in peerlist when requesting peerlist from remote peers. 4.2.1.3.2. Rationale According to [draft-gu-ppsp-survey], not all of the peers on the peerlist are connected by the requesting peer. In fact, a peer will first try some remote peers and will stop requesting if it finds Gu & Bryan Expires January 6, 2011 [Page 7] Internet-Draft Peer Protocol July 2010 enough data source. Besides, the more peers in peerlist, the more bandwidth is consumed. So it will be good for requesting peer to limit the number of peers in the peerlist, from bandwidth perspective. Another reason is that a requesting peer may already have large number of candidate peers, and it only want to get a low number of additional candidate peers from remote peers. 4.2.1.3.3. Requirement Peer Protocol SHOULD enable peer to indicate its own property when request for peerlists from remote peers. 4.2.1.3.4. Rationale PPSP is a system supporting a diversity of possible end hosts, mobile and fixed, different bandwidth, different online time, various link property and other performance factors. In regular P2P applications, the dynamic status of peers makes it difficult to choose candidate peers, this makes the static property of peers as the main input when choosing candidate peers. For example, a peer with 100M uplink bandwidth is much more popular than a peer with 10M uplink bandwidth, i.e. more peers choose the first peer as a downloading peer because they believe they can be served better. The result of this blind popularity is that the first peer will be overloaded while the second peer is idle. To make the whole system more effective and reach a higher performance, we should try to take full advantage of the low performance peers, as well as the high performance ones. Therefore a peer can indicate its own property and the remote peers then choose the similar peers into the response peerlist. For example, a peer notifies the remote peer that it's an ADSL access node, then the remote peer will try to choose some candidate peers with the same its property. 4.2.2. Data Availability 4.2.2.1. Requirement Peer protocol MUST enable peers to request for Data Availability from remote peers. 4.2.2.2. Requirement Peer protocol MUST enable peers to carry Data Availability on themselves in responses to Data Availability Request. Gu & Bryan Expires January 6, 2011 [Page 8] Internet-Draft Peer Protocol July 2010 4.2.2.3. Rationale Peer Protocol should enable a peer to request Data Availability from a remote peer and the remote peer, , should be able to carry the Data Availability in the response. Data Availability can be embodied in multiple form. For example it can be a Bitmap, where each bit represents a particular block of a chunk. This draft will not define a specification for Bitmap or other kind of Data Availability description file. We will use Bitmap to represent the Data Availability description file in the following part of the draft, however it does not mean we propose to use Bitmap in PPSP. If we decide not to use Bitmap to indicate data availability, we need to define a data structure for that purpose. The Bitmap exchanged between peers can contain the Data Availability of at least one Chunk. 4.2.2.4. Requirement Peer protocol MUST be able to carry different data structures for different applications. 4.2.2.5. Rationale The data model of different applications might be different. For example, Data Availability is presented by bitmap in some applications, while we cannot make sure that all applications use bitmap to exchange chunks availability. Peerlist exchanged among peers may also be different. Peer Protocol must be agnostic of the specification of different applications. 4.2.3. Property Exchange 4.2.3.1. Requirement Peer protocol SHOULD enable peers to exchange peer property. 4.2.3.2. Rationale This requirement is due to the same reason described in the above requirement, which enable peer to indicate its property when request for peerlist. With this functionality, a peer can exchange property with the candidate peers it obtains from Tracker or remote peers. 4.3. Connection Status These requirements are influenced by [BittorrentSpecification]. Gu & Bryan Expires January 6, 2011 [Page 9] Internet-Draft Peer Protocol July 2010 4.3.1. Application-level Congestion Control Peer Protocol should enable a peer to notify its remote peer whether it would like to upload content to the remote peer. 4.3.2. Rationale This is especially meaningful when a peer is overloaded. The peer, which is very popular and is distributed in the response peerlist to multiple requesting peers, is now busy with uploading to some remote peers, when a new peer connects to it and request for further action. If the peer makes no feedback, the requesting peer may ask again and again, based on the application configuration. As an example, in BitTorrent, a peer may respond with a Choked tag, which means 'I have recorded your request. Never send request to me until I send an UnChoked message to you'. The choked remote peer could wait for the peer's unchoked message, or just try other peers. 4.4. Real-time Features 4.4.1. Requirement Peer Protocol MUST support synchronous downloading/uploading. 4.4.2. Rationale This requirement means a peer can download from multiple peers, or upload to multiple peers at the same time. There are various situations that Peer Protocol is required to support multiple streams. 1) The audio and video streaming of the application are separated. In this case, a peer must download audio and video from different peers at the same time to play the stream locally. 2) A peer need to download from multiple peers to satisfy the playback rate and the quality. E.g. some low bandwidth peers are organized together to provide data downloading for a peer. Or a peer has very high bandwidth, so it can download from multiple regular peers in order to get the whole stream faster. Similarly, if a layered codec is used, the layers may be obtained from different locations. Note that this requirement may be satisfied by reusing an existing IETF protocol providing these capabilities. 4.4.3. Requirement Peer protocol MUST provide corresponding mechanism to eliminate or decrease the influence of Jitter and packet loss. Gu & Bryan Expires January 6, 2011 [Page 10] Internet-Draft Peer Protocol July 2010 4.4.4. Rationale Since streaming applications are extremely sensitive to jitter and packet loss, which degrades Quality of Experience remarkably, Peer protocol must take these features into consideration and provide a mechanism for peers to reduce the influence of jitter and packet loss and guarantee the streaming quality. Note that this requirement may be satisfied by reusing an existing IETF protocol providing these capabilities. 4.5. Transportation Negotiation 4.5.1. Requirement Peer protocol MUST be able to negotiate a transportation protocol that both peers can support. 4.5.2. Rationale Muptiple Transportation protocol can be used to transport a streaming content, e.g. RTP, RTSP, FTP, UDP, TCP, MSRP, etc.. So peers must try to negotiate a transportation protocol and then exchange signaling messages to set up a transportation connection between them. Note that this requirement may be satisfied by reusing an existing IETF protocol providing these capabilities. 4.6. Security 4.6.1. Requirement Peer Protocol MUST guarantee peers' privacy. 4.6.2. Rationale Peer Protocol must guarantee that a peer's request can only be received by the targeted remote peers. That means Peer Protocol must prevent the message from being wire tapped or changed by a man in the middle 4.6.3. Requirement Peer SHOULD be able to verify the identity of the remote peer. 4.6.4. Rationale Attackers may pretend to be someone else and ask peers to send data to innocent peers. This is a normal kind of attack in P2P overlay. Peer Protocol should provide a mechanism to avoid such attack. Gu & Bryan Expires January 6, 2011 [Page 11] Internet-Draft Peer Protocol July 2010 5. Example Flow In this section, we introduce general example flow of Peer protocol. Requesting Peer Remote Peers *******************Begin Locating (Optional)*************** (IP Addresses in Peerlist) No Locating (IDs in Peerlist) Reload (URLs in Peerlist) SIP *******************Finish Locating (Optional)*************** *******************Begin Information Exchange*************** |----------------1. Request Peerlist(Optional)----------->| |<---------------2. Response with peerlist (Optional)-----| (1 and 2 is not mandatory.) (Locally choose remote peers to request Data Availability) |---------3. Request Data Availability (Optional)-------->| |<--------4. Response with Data Availability (Optional)---| (No 3 and 4 in Live streaming) (Locally choose remote peers with desired data, out of scope) *******************Finish Information Exchange*************** *******************Begin Transport Negotiation (Optional)**** |<-5. Report own Transport Protocol Types and Port Numbers->| |--6. Requesting Peer decides which protocol(Port numbers)->| | are used to transfer data | *******************Finish Transport Negotiation (Optional)*** *******************Begin Transportation********************** |----------------7. Desired Chunks (Optional)------------->| (Desired Chunks or streaming are transferred, using existing protocl) *******************Finish Transportation********************* Fig. 2 Example Flow 6. Peer Locating Protocol Three options for the Peer Locating Protocol have been proposed, Gu & Bryan Expires January 6, 2011 [Page 12] Internet-Draft Peer Protocol July 2010 Reload, SIP and a new Protocol. The decision of Identity type included in peerlist in Tracker protocol will decide the choice of Peer Locating Protocol. Meanwhile, the effectiveness of these options as analysed in this draft will influence the decision of Tracker protocol. Up to now, we have not make decision on which protocol should be used, [Reload], SIP, other existing protocol or a new protocol. We will leave this as an open issuse for the WG to discuss. 6.1. General Comments From a Bandwidth perspective, SIP is heavier than RELOAD. A new protocol could be either lighter or heavier - depending on the specific encoding of the protocol. From a signaling delay point of view, RELOAD may be less effective in locating peers, as the messages has to transfered through intermediate peers before it finally get to the destination peer. In practice, this may not be an important issue. A potentially bigger issue in the use of RELOAD is that the swarm is likely to be a loosely organized, unstructured collection of peers (using a gossip protocol), rather than a structured DHT, and RELOAD may potentially be too heavy for this application. One alternative is that peers are connected in a DHT, and the DHT is used to locate peers, which then establish direct connections to communicate (perhaps using SIP) SIP may provide additional advantages when negotiating the connection (see below), as it is intended for this very purpose. SIP provides many capabilities that would not be used in this context, however, and a discussion of how to limit the capabilities in order to keep complexity to a minimum would be required. 6.2. NAT Traversal NAT Traversal is an unavoidable issue in Peer protocol. Peers may reside behind various kinds of NAT/Firewall, which will make the issue more complicate. In NAT Traversal aspect, Peer protocol need to cooperate with Tracker protocol closely. Instead of abiding Tracker protocol's decision, the designing of Peer protocol will significantly influence the decision of Tracker protocol. Several kinds of peer identity are mentioned to be likely included in Peerlists in response to Peer's request for desired chunks or swarms, Peer ID, Peer IP Address and Peer URL. In this section we will describe how NAT Traversal will work for each distinct peer identity, without invloving detail protocol. Gu & Bryan Expires January 6, 2011 [Page 13] Internet-Draft Peer Protocol July 2010 6.2.1. Peer ID in Peerlist If Peer IDs are included in Peerlist, the requesting peer needs a way to locate peers that the peer IDs represent. [Reload] introduce a method to locate and establish connection with remote peers by Peer IDs. [TODO: Detailed explanation] Essentially, by returning peerIDs and using an overlay protocol, one relies on the overlay to provide NAT traversal capabilities. 6.2.2. Peer IP Address in Peerlist If Peer Addresses are used to indicate peers' identity, the requesting peer can quickly locate the remote peer, which is must faster than [Reload] in which messages need to be transferred through an overlay path. However, the shortcoming of using Peer Address is very significant. If one or both communicating peers are behind NAT, peers can not connect with each other easily. Typically, they need an entity with public Address and can be connected by both peers. In PPSP system, a natural Public entity for this purpose is Tracker. As described in Tracker Protocol, Tracker should have public address and each peer has to connect with Tracker before they can join any swarm. As a result, the tracker can serve to help establish a direct connection between peers, serving as a relay if required. 6.2.3. URI in Peerlist If SIP is reused, a SIP URL may be included in peerlist. Then we can use ICE to traverse NAT, again using the tracker as a proxy/relay as required. 7. Peer Signalling Protocol (New Protocol) 7.1. Options With regard to a new Peer Protocol, if we choose this path we also have two options, Binary encoding and ASCII encoding. According to [draft-gu-ppsp-survey], most peer to peer applications choose Binary protocol. In this draft, we leave this as an open issue for WG to discuss. If there is interest in a new protocol, we will introduce example message encoding of Peer Protocol in both Binary and HTTP. 7.2. Binary Protocol Gu & Bryan Expires January 6, 2011 [Page 14] Internet-Draft Peer Protocol July 2010 7.2.1. Common Header To Be Added 7.2.2. Information Exchange To Be Added 7.2.3. Transport protocol negotiation To Be Added 7.2.4. Data Request To Be Added 7.3. HTTP-Based Protocol 7.3.1. Common Header To Be Added 7.3.2. Information Exchange To Be Added 7.3.3. Transport protocol negotiation To Be Added 7.3.4. Data Request To Be Added 8. Security Consideration The security considerations are highly dependent upon the protocol selected to transfer messages for PPSP. Security will be considered in further version of this draft. 9. Acknowledgments We give our achnoledgement to Roni Even, Zhang Yunfei and Liao Hongluan for them valuable comments and suggestions. Gu & Bryan Expires January 6, 2011 [Page 15] Internet-Draft Peer Protocol July 2010 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [draft-ietf-p2psip-base-07] Jennings, C., Lowekamp, B., Ed., Rescorla, E., and H. Schulzrinne, "draft-ietf-p2psip-base-07", February 2010, . 10.2. Informative References [draft-zhang-ppsp-problem-statement] Zhang, Y., Zong, N., Camarillo, V., Seng, J., and R. Yang, "Problem Statement of P2P Streaming Protocol (PPSP)", October 2009, . [draft-zong-ppsp-reqs] Zong, N., Zhang, Y., Pascual, V., and C. Williams, "P2P Streaming Protocol (PPSP) Requirements", October 2009, . [draft-gu-ppsp-survey] Gu, Y., Zong, N., Zhang, H., Zhang, Y., Camarillo, G., and Y. Liu, "Survey of P2P Streaming Applications", October 2009, . [draft-gu-ppsp-tracker-protocol] Gu, Y., Bryan, D., Zhang, Y., and H. Liao, "PPSP Tracker Protocol", March 2010, . [BittorrentSpecification] "Bittorrent Protocol Specification v1.0", February 2010, . [draft-ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", March 2010, . Gu & Bryan Expires January 6, 2011 [Page 16] Internet-Draft Peer Protocol July 2010 Authors' Addresses Yingjie Gu Huawei No.101 Software Avenue Nanjing, Jiangsu Province 210012 P.R.China Phone: +86-25-56622638 Email: guyingjie@huawei.com David A. Bryan Cogent Force, LLC / Huawei Williamsburg, Virginia, USA Phone: Email: dbryan@ethernot.org Gu & Bryan Expires January 6, 2011 [Page 17]