PPSP Y. Gu Internet-Draft Huawei Intended status: Informational D. Bryan Expires: April 28, 2011 Cogent Force, LLC / Huawei October 25, 2010 Peer Protocol draft-gu-ppsp-peer-protocol-01 Abstract This document presents a high-level proposal for the PPSP peer protocol. The architecture of the system, requirements for the protocol, example call flow, and open issues are presented. Requirements Language 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]. 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 28, 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 Gu & Bryan Expires April 28, 2011 [Page 1] Internet-Draft Peer Protocol October 2010 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Protocol Architecture . . . . . . . . . . . . . . . . . . 4 3. Requirements on a Peer Protocol . . . . . . . . . . . . . . . 6 3.1. Locating and Connection . . . . . . . . . . . . . . . . . 6 3.2. Information Exchange . . . . . . . . . . . . . . . . . . . 6 3.2.1. Peerlist Sharing . . . . . . . . . . . . . . . . . . . 6 3.2.1.1. Peer Distribution of Peerlists . . . . . . . . . . 7 3.2.1.2. Peerlist Search Parameter . . . . . . . . . . . . 7 3.2.2. Data Availability . . . . . . . . . . . . . . . . . . 7 3.2.3. Property Exchange . . . . . . . . . . . . . . . . . . 8 3.3. Application-level Congestion Control . . . . . . . . . . . 8 3.4. Simultaneous Uploading/Download . . . . . . . . . . . . . 8 3.5. Transportation Negotiation . . . . . . . . . . . . . . . . 9 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Example Call Flow . . . . . . . . . . . . . . . . . . . . . . 10 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Gu & Bryan Expires April 28, 2011 [Page 2] Internet-Draft Peer Protocol October 2010 1. Introduction A full design for a PPSP architecture requires that peers are able to communicate with a tracker to obtain information about the location of peers participating in a particular stream or swarm, but for a number of design reasons also requires that a peer protocol allows for information to be shared directly between peers [I-D.ietf-ppsp-problem-statement]. Among the information that should be exchanged by the peers using this peer protocol includes 1) bitmap indicating which chunks a peer possesses (for the offline case) or swarms they are participating in (for the live streaming case) 2) required chunks IDs or requested streams 3) peer preference indicating what kind of candidate peers a requesting peer may prefer, 4) transport protocol negotiation and 5) information that can help to improve the performance of PPSP. Meanwhile there are some discussions on the mailing list about reusing RELOAD defined in [I-D.ietf-p2psip-base] to implement 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. In this draft we present a skeleton design for how RELOAD could be used to implement a PPSP Peer protocol. In this use, the primary purpose of RELOAD is not to store and exchange the information listed above, but primarily as a mechanism to connect the peers, establish connections across NATs, and for peers to locate each other. This draft does not presently attempt to define the detailed implementation for a PPSP Peer protocol, but rather presents a proposed architecture and discusses the use of RELOAD and the type of messages to be exchanged. Additionally, we present a set of requirements on the detailed protocol to be defined based on this proposal. As time advances, these will be removed, or perhaps migrated to a stand-alone requirements document. In developing this suggest approach, a number of questions arose, and these are documented in an open issues section at the end of the document. Gu & Bryan Expires April 28, 2011 [Page 3] Internet-Draft Peer Protocol October 2010 2. Protocol Overview In this section, we provide an overview of the protocol approach we propose for the PPSP protocol. Please note there are a fairly large number of open issues which we are soliciting conversation on. We intend to take these questions to the list in an attempt to drive consensus, and as consensus is achieved, intend to refine our proposal to conform to the consensus. Please see section FIX for a list of open questions. 2.1. Protocol Architecture The proposed PPSP Peer Protocol uses a newly defined, light weight gossip protocol between the peers to exchange the actual information, but uses the RELOAD [I-D.ietf-p2psip-base] protocol to establish the connections between peers and to locate other peers with which to establish gossip protocol connections. The proposed PPSP Peer Protocol interacts with a tracker protocol, for example the one defined in [I-D.gu-ppsp-tracker-protocol]. This protocol can be used to connect peers that are sharing real-time streams of video or offline video via sets of chunks. There are some minor differences between the details of these two scenarios, but from a high level perspective the overall structure is quite similar. The basic flow of messages for a peer which wishes to participate either in a group of peers live streaming or a group of peers exchanging data for an offline video is as follows: 1. The first step for the peer is to join the RELOAD overlay which connects peers. This requires that the peer obtain the location of a bootstrap peer and (likely) insert itself into the RELOAD overlay. Note that because RELOAD provides significant NAT traversal capabilities, the argument that some devices may not serve as peers, but only clients due to connectivity issues is not compelling, but here may be other reasons why a peer may not be able to participate fully, and may only participate as a RELOAD client. Note further that the tracker may be participate in the overlay as a RELOAD peer itself, providing a well-known stable bootstrap peer, but this is still an open issue. 2. The peer contacts the tracker to obtain a Peerlist containing a list of peers participating in the particular swarm the peer is interested in. * Note that there are other reasons that the peers may exchange information with the tracker, for example to provide updates on connection quality and other factors that may be used to order the Peerlist and assist in selection, but in this Gu & Bryan Expires April 28, 2011 [Page 4] Internet-Draft Peer Protocol October 2010 example we are concerned only with obtaining the Peerlist. * This list does not contain IP addresses, but rather RELOAD Peer-IDs. * The mechanism for obtaining the swarm ID itself is presently out of the scope of this proposal 3. The peer uses the RELOAD protocol to establish a connection to at least one of the peers in the Peerlist, based on the Peer-ID. RELOAD will handle the negotiation of any NAT traversal that may be required to establish the connection between the peer and any peers from the Peerlist. 4. The peer may then optionally use the peer protocol to find a list of further peers to connect to, and can establish these connections if desired. This is performed using the PPSP Peer Protocol. 5. The peer now exchanges chunk lists with other peers, again using the PPSP Peer Protocol. Other information, such as the capabilities of the peers or quality of the files/stream may also be exchanged using the peer protocol, and may be used to decide which peers to actually exchange data/stream data with. 6. After checking the list of peers, the peers negotiate a mechanism to exchange the information. * Note that there are several options here to negotiate the connection model. The Peer Protocol may include new mechanisms to negotiate the protocol used to exchange data, or the offer-answer mechanism in SIP [RFC3261] (the IETF protocol for session establishment) along with SDP [RFC4566] or a lightweight variation thereof, such as the advertisement/ proposal model in [I-D.peterson-sipcore-advprop] could be used. 7. Finally, the peers exchange the actual chunks of data or establish streaming connections between each other, using the mechanism/protocol negotiated in the previous step. * Note that at this time, these mechanisms are not new protocols defined in the PPSP group, but existing protocols, and would differ between offline and live streaming scenarios. Mechanisms such as flow control, signaling of choke status, etc. are handled in the negotiated transfer mechanism, not in the Peer Protocol itself. (although note that application- level congestion control should be provided, see Section 3.3 Gu & Bryan Expires April 28, 2011 [Page 5] Internet-Draft Peer Protocol October 2010 3. Requirements on a Peer Protocol In this section, we present some requirements we believe the peer protocol we define above must meet, and in some cases, explain why the design above meets that requirement. This list is not intended to be exhaustive, but to help frame the problem. 3.1. Locating and Connection Peer Locating is closely related to the Tracker protocol. A peer will get a peerlist from Tracker, with Peer IDs, and may get lists from other peers as well. REQUIREMENTS: Peers SHOULD be able to locate other peers in peerlist and connect to them with minimal or without the Tracker's assistance. Peers MUST be able to operate behind NATs, and connect to other peers that are behind NATs. RATIONALE: Peers must be able to find a path between themselves and a remote peer, on which messages can pass through. Our proposal addresses this by using RELOAD, which offers capabilities to establish connections between peers, including NAT traversal as required. The tracker does not need to be involved in the establishment of these connections (although there does need to be some way for the peers to bootstrap and originally join the RELOAD overlay, and this capability may be provided by the tracker, acting as a RELOAD peer.) 3.2. Information Exchange After an effective connection is established between peers, peers will exchange information that will help them to decide where to download the content. 3.2.1. Peerlist Sharing In many peer to peer streaming protocols such as PPLive and PPStream, clients can obtain peerlist from both Tracker and remote peers. The 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 (or be able) to provide 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, the Tracker will provides a list of reference peers, from which a peer can get request a list of additional peers. Gu & Bryan Expires April 28, 2011 [Page 6] Internet-Draft Peer Protocol October 2010 3.2.1.1. Peer Distribution of Peerlists REQUIREMENT: The Peer Protocol MUST enable a peer to send a request for peerlist to its remote peers for a particular content, e.g. a particular swarm or chunk, and enable peers to return the requested information. (Note this is still an open issue, as discussed in Section 5. The authors personally feel such a capability is essential. RATIONALE : The 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). The protocol should be broadly applicable to many possible architectures, and providing this capability helps assure that is the case. 3.2.1.2. Peerlist Search Parameter REQUIREMENT: The Peer Protocol SHOULD enable peers to provide parameters when requesting peerlists from other peers, such as number of peers to return and capabilities of those peers. RATIONALE: The details of the queries supported (do peers include all peers they know about, allow search capabilities, etc.) is an open question for discussion. The authors advocating a rich set of capabilities. [I-D.gu-ppsp-survey] describes how in some systems 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 enough data source. Additionally, the more peers in peerlist, the more bandwidth is consumed. Therefore the requesting peer should be able to limit the number of peers in the peerlist. 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. Additionally, peers may want to be able to select for various static or dynamic properties of peers such as uptime, capacity, current estimated load, etc. Allowing for parameter-based searches will support this property. Open issue: Should we only for searching for static properties, as the dynamic properties may change too often for peers to have current information, and instead use the information exchange mechanism between peers if this information is requested? 3.2.2. Data Availability REQUIREMENTS: The peer protocol MUST enable peers to request for Data Availability from remote peers. The peer protocol MUST enable peers Gu & Bryan Expires April 28, 2011 [Page 7] Internet-Draft Peer Protocol October 2010 to carry Data Availability about themselves in responses to Data Availability Requests. The peer protocol MUST be extensible and support different data structures to represent data availability for different applications. RATIONALE: The peer Protocol should enable a peer to request Data Availability from a remote peer and the remote peer, should be able to create a response carrying the Data Availability information. Data Availability information could be a Bitmap, where each bit represents a particular block of a chunk. It is an open question if a default, mandatory-to-implement format for the data availability information should be included in this protocol, or if the protocol should simply convey bulk data and various usages of PPSP can define this data. The protocol must support an extensible way to represent the data, as data models for different applications may vary. 3.2.3. Property Exchange REQUIREMENT: The peer protocol SHOULD enable peers to request and exchange peer property information with one another. RATIONALE: As we want to allow for searching based on peer capabilities, some of which may be dynamic (see Section 3.2.1.2), it makes sense that there also be some capability to directly query peers and exchange similar information outside the context of using these properties as a filter when requesting a peerlist. 3.3. Application-level Congestion Control REQUIREMENT: The Peer Protocol SHOULD enable a peer to notify its remote peer whether it it is willing to establish a connection with that peer. RATIONALE: This allows peers to provide meaningful, high-level congestion control. This is especially important when a peer is overloaded. A very popular peer may be distributed in peerlists to multiple requesting peers, and become overloaded with uploading to some remote peers, when a new peer connects to it and request for further action. The peer must have a way of rejecting requests to prevent retransmissions and overload condition. Note that this is prior to negotiating a particular streaming or transfer mechanism, and is not to be used in place of flow control and congestion control mechanisms within the transfer technique. 3.4. Simultaneous Uploading/Download REQUIREMENT: The peer Protocol MUST support simultaneous downloading/ uploading. Gu & Bryan Expires April 28, 2011 [Page 8] Internet-Draft Peer Protocol October 2010 RATIONALE: This requirement means the protocol must support allowing peers to 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. 3.5. Transportation Negotiation REQUIREMENT: The peer protocol MUST be able to negotiate a transportation protocol that both peers can support (assuming the peers share a common protocol). RATIONALE: Multiple 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. (for example SIP with SDP or the advertisement/proposal model suggested in Section 2.1. 3.6. Security NOTE: The authors are aware this section is not well articulated, and needs to be improved. This is a place holder for the better section that is clearly required. REQUIREMENTS: The peer Protocol MUST guarantee peers' privacy. Peers SHOULD be able to verify the identity of the remote peer. RATIONALE: The 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. 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 April 28, 2011 [Page 9] Internet-Draft Peer Protocol October 2010 4. Example Call Flow This is a very high-level example of a session in which a peer joins an overlay, joins a swarm, and retrieves some data (either via blocks or by streaming). The protocol used is indicated for each transaction. *********************** Join Overlay ********************** Requesting Peer Bootstrap Peer |<------------------ Join Sequence (RELOAD) ------------->| ********************** Obtain Peerlist ******************* Requesting Peer Tracker |------------ Request Peerlist (Tracker Protocol) ------->| |<----------- Response (Tracker Protocol) ----------------| ************ Open Connections to Remote Peers ************ Requesting Peer Remote Peers |<------------- Connection Sequence (RELOAD) ------------>| (Repeated for one or more peers) ********* Optionally Obtain Additional Peerlist ********** Requesting Peer Remote Peers |------------ 1. Request Peerlist (Peer Protocol) ------->| |<----------- 2. Response (Peer Protocol) ----------------| (Repeated for one or more peers) ************ Query Peers for Available Data ************** Requesting Peer Remote Peers |------------ 1. Request Data (Peer Protocol) ----------->| |<----------- 2. Response (Peer Protocol) ----------------| (Repeated from one or more peers) ****** Negotiate Transfer Connection and Transfer ******** Requesting Peer Remote Peers |<--------- Handshake Sequence (SIP/SDP, other) --------->| |<----- Data Transfer Sequence (negotiated protocol) ---->| (Repeated with one or more peers) Gu & Bryan Expires April 28, 2011 [Page 10] Internet-Draft Peer Protocol October 2010 5. Open Issues 1. Need to define the mechanism by which the peers are able to initially insert themselves into the RELOAD overlay. One possibility is for the tracker itself to be the bootstrap peer, and to facilitate the connection to the admitting peer. 2. Do we only allow peers to obtain peerlists from the tracker, or do we also allow peers to exchange peerlist information between each other using the peer protocol? 3. Exactly what search capabilities do we want to support for requesting peerlists? In other words, can a peer specify either details about the information to be shared (only want high- definition video, for example) or about the type of peers it would like to connect to (certain bandwidth, topological "closeness", etc.) If these search capabilities are supported and peers can exchange lists directly among themselves, do the search capabilities differ between searching the tracker and searching between peers? 4. Do we need to define some default format for bitmaps, or should the protocol be agnostic to this? May want a shared mandatory to implement version to enable interoperability. 5. We have removed the requirements around jitter and packet loss, primarily because the currently envisioned protocol negotiates connections using an underlying protocol, and that protocol would then be responsible to negotiate such constraints. Should that be included somehow in describing what makes for a good transport, or will that (and perhaps some other requirements) eventually migrate to a different requirements document? 6. While it seems a lightweight gossip protocol is the appropriate type of protocol for this design, it is unclear what the encoding should be. There has been strong interest in an HTTP/XML encoding for the tracker protocol, and the same approach could be used here, or a lightweight binary protocol could be defined. 7. Should we allow peers to include dynamic information in the search parameters when querying other peers for additional peerlists? Do we limit to static properties, as the dynamic properties may change too often for peers to have current information, and instead use the information exchange mechanism between peers if this information is requested? Gu & Bryan Expires April 28, 2011 [Page 11] Internet-Draft Peer Protocol October 2010 6. Security Considerations The security considerations will depend on the eventual design of the PPSP peer protocol. Security will be considered in further version of this draft. 7. IANA Considerations There are presently no IANA considerations with this document. 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 [BitTorrent] "BitTorrent Protocol Specification v1.0, February 2010". Copy available at http://wiki.theory.org/BitTorrentSpecification [I-D.gu-ppsp-survey] Yingjie, G., Zong, N., Zhang, H., Zhang, Y., Lei, J., Camarillo, G., and L. Yong, "Survey of P2P Streaming Applications", draft-gu-ppsp-survey-02 (work in progress), October 2010. [I-D.gu-ppsp-tracker-protocol] Yingjie, G., Bryan, D., Zhang, Y., and H. liao, "Tracker Protocol", draft-gu-ppsp-tracker-protocol-02 (work in progress), October 2010. [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-11 (work in progress), October 2010. [I-D.ietf-ppsp-problem-statement] Zhang, Y., Zong, N., Camarillo, G., Seng, J., and Y. Yang, "Problem Statement of P2P Streaming Protocol (PPSP)", draft-ietf-ppsp-problem-statement-00 (work in progress), Gu & Bryan Expires April 28, 2011 [Page 12] Internet-Draft Peer Protocol October 2010 October 2010. [I-D.ietf-ppsp-reqs] Zong, N., Zhang, Y., Avila, V., Williams, C., and L. Xiao, "P2P Streaming Protocol (PPSP) Requirements", draft-ietf-ppsp-reqs-00 (work in progress), October 2010. [I-D.peterson-sipcore-advprop] Peterson, J. and C. Jennings, "The Advertisement/Proposal Model of Session Description", draft-peterson-sipcore-advprop-00 (work in progress), February 2010. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. Appendix A. Acknowledgments The authors would like to thank Roni Even, Zhang Yunfei and Liao Hongluan for their valuable comments and suggestions. Authors' Addresses Yingjie Gu Huawei No. 101 Software Avenue Nanjing, Jiangsu Province 210012 P.R.China Phone: +86-25-56624760 Email: guyingjie@huawei.com David A. Bryan Cogent Force, LLC / Huawei Email: dbryan@ethernot.org Gu & Bryan Expires April 28, 2011 [Page 13]