PPSP Y. Gu Internet-Draft Huawei Intended status: Standards Track David A. Bryan Expires: December 9, 2011 Polycom June 7, 2011 Peer Protocol draft-gu-ppsp-peer-protocol-02 Abstract This document presents the architecture of the PPSP Peer protocol system, example call flow, and message syntax and processing are presented. 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 December 9, 2011. Copyright Notice Copyright (c) 2011 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 December 9, 2011 [Page 1] Internet-Draft Peer Protocol June 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 3 2.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Protocol Architecture . . . . . . . . . . . . . . . . . . 4 3.2. Example Call Flow . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Description of Peer Protocol . . . . . . . . . . . . . . . 7 4.2. Message Syntax and Processing . . . . . . . . . . . . . . 9 5. Security Consideration . . . . . . . . . . . . . . . . . . . . 18 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Normative References . . . . . . . . . . . . . . . . . . . 18 6.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Gu & Bryan Expires December 9, 2011 [Page 2] Internet-Draft Peer Protocol June 2011 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 chunk 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. This is an early strawman draft. There is clearly lots of work left, and lots of holes. The authors will keep updating the draft and encourge more discussion at the meeting and on the mailing list. 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]. 2.2. Terminology The draft uses the terms defined in [I-D.ietf-ppsp-problem-statement]and [draft-gu-ppsp-tracker-protocol]. 3. 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. As indicated in Introduction, this is a early strawman draft, and there are still some issues need to be discussed and decided at the WG. The authors will keep updating the draft. Gu & Bryan Expires December 9, 2011 [Page 3] Internet-Draft Peer Protocol June 2011 3.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 in live streaming or a group of peers exchanging data for an offline video is as follows: 1. 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 example we are concerned only with obtaining the Peerlist. * This list could contain IP addresses or Peer-IDs, or both. * The mechanism for finding out which Tracker to connect to and for obtaining the swarm ID is presently out of the scope of this proposal. 2. The peer establishes a connection to at least one of the peers in the Peerlist, based on the Peer-ID, or Peer IP address. If using RELOAD to establish a connection to any peers, 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. If using Peer IP address, additional NAT traversal mechanisms should be developed. The NAT traversal mechanism is out of the scope of this draft. 3. 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. Gu & Bryan Expires December 9, 2011 [Page 4] Internet-Draft Peer Protocol June 2011 4. 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. 5. 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. In order to make Peer Protocol be consistent with Tracker protocol, a new mechanism is defined in this draft. 6. 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. 3.2. Example Call Flow This is a very high-level example of a session in which a peer joins a swarm, and retrieves some data (either via blocks or by streaming). The protocol used is indicated for each transaction. Note that not all of the communication shown in this figure are in scope of Peer Protocol, only those request/response followed by Peer Protocol are in scope. Gu & Bryan Expires December 9, 2011 [Page 5] Internet-Draft Peer Protocol June 2011 ********************** Obtain Peerlist ******************* Requesting Peer Tracker |------------ Request Peerlist (Tracker Protocol) ------->| |<----------- Response (Tracker Protocol) ----------------| ************ Open Connections to Remote Peers ************ Requesting Peer Remote Peers |<------- Connection (using Peer-ID or IP address) ------>| (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) ******** Optionally Query Peers for Available Data ******* Requesting Peer Remote Peers |------------ 1. Request Data (Peer Protocol) ----------->| |<----------- 2. Response (Peer Protocol) ----------------| (Repeated from one or more peers) *********** Optionally Query Peers for Property ********** 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) Figure 1: Example Call Flow 4. Protocol Design As shown in example call flow, Peer protocol only provides communication for obtainning additional peerlist (optionally), query for available data and negotiation for transfer protocol. Peer Gu & Bryan Expires December 9, 2011 [Page 6] Internet-Draft Peer Protocol June 2011 protocol may also providing communication for peers to exchange information that can improve system performance. As we have encountered in Tracker protocol design, there are also at least two choices for Peer Protocol encoding, i.e. binary and text based. Because Peer protocol is regarded as exchange of peerlist and chunks availability, instead of real streaming or chunks, so the benefits of binary encoding is not very significant. In order to make Peer protocol to be consistent with Tracker protocol, we choose HTTP/XML based encoding for Peer Protocol. 4.1. Description of Peer Protocol The PPSP Peer Protocol presented is a request-response protocol. Requests are sent, and responses returned to these requests. A single request generates a single response (neglecting fragmentation of messages). Note that the Peer protocol does not actually exchange any data between the peers (either streaming in the live streaming case or chunks data in the file sharing scenario.). The specific operations of the protocol are: FIND and FIND_CHUNK: Peers use the FIND or FIND_CHUNK method to request that the remote peers to return lists of peers that can provide specific content or are in a particular swarm. The intention of this FIND/FIND_CHUNK message is similar to the FIND/ FIND_CHUNK message defined in Tracker protocol. On receiving a FIND/FIND_CHUNK message, the remote peer finds the candidate peers listed in peer Data Management, shown in Figure 2 in [draft-gu-ppsp-tracker protocol], and returns the list to the requesting peer. CHUNK_AVAILABILITY: Peers use the CHUNK_AVAILABILITY messages to request the remote peers to return their chunk availability regarding the desired content. The chunk availability is usually presented as a bitmap, but this is not mandatory. The format of chunk availability is not in the scope of peer protocol. CHUNK_AVAILABILITY is not a mandatory message. In case of live streaming, peers need not request chunk availability. PROPERTY_QUERY: Peers use PROPERTY_QUERY message to request remote peer to return their properties, which can help requesting peers to make decision whether the remote peers are satisfactory peers to obtain desired content. Gu & Bryan Expires December 9, 2011 [Page 7] Internet-Draft Peer Protocol June 2011 TRANSPORT_NEGOTIATION: This method allows peers to negotiate a suitable transport protocol that is supported by both peers. After successful negotiation, peers can transfer real chunks or streaming using the negotiated transport protocol. This is out of the scope of peer protocol. The following part discusses RESPONSE mechanism. The HTTP protocol itself would handle malformed messages, but incorrectly formatted XML bodies could generate tracker-protocol level errors, the contents of which are reported in an HTTP message. These RESPONSE definition is the same as 4.3.1 in [draft-gu-ppsp-tracker-protocol] with slight revisions of thes definitions as discussed below. SUCCESSFUL (OK): Indicates that a message has been processed properly, and that the desired operation completed. If the message is a request for information, the body of the message will also include the requested information. As a result, the following information is returned for each message: CHUNK_AVAILABILITY returns bitmaps representing chunk availability of specific content. FIND and FIND_CHUNK return the list of peers meeting the desired criteria. PROPERTY_QUERY returns peer's parameters on specific properties requested by requesting peers. TRANSPORT_NEGOTIATION returns designated transport protocols that the remote peer would like to use to transfer real chunk data or live streaming. the designated transport protocols MUST be originally indicated in the TRANSPORT_NEGORIATION request. INVALID SYNTAX: Indicates an error in the format of the message/ message body. VERSION NOT SUPPORTED: Invalid version of the protocol or message bodies. MESSAGE NOT SUPPORTED: The particular request is not supported by this peer. MESSAGE FORBIDDEN: The requester is not allowed to make this request. Gu & Bryan Expires December 9, 2011 [Page 8] Internet-Draft Peer Protocol June 2011 4.2. Message Syntax and Processing 4.2.1. HTTP/XML Encoding The current encoding is a very simple strawman encoding. Clearly, more attention will need to be paid to the proper HTTP messages to convey information, and to the appropriate way to encode the information in XML. For simplicity, the current proposal uses only HTTP GET as a mechanism. Error codes from HTTP are reused when possible, with the error conveyed in the actual HTTP message. 4.2.1.1. HTTP Encoding The format of the shared message XML body is as follows. This is not a formal XML schema, but will be elaborated to be such at a future date. *** *** *** ...Method specific xml information... Figure 2: Common Message XML Header In this representation, *** is used to represent data to be inserted. The fields in the header are: version: The version of the PPSP Peer Protocol being used in the form of a fixed point integer between 0.1 and 25.4. For the version of the protocol described in this document, this field MUST be set to 0.1. Method: Indicates the method type for the message. The Method is encoded as a string, and is case insensitive. The valid strings are defined in Section 4.2.1.1.1. Only one of Method or Response will be present in any given method -- the presence of both constitutes an error. Response: Indicates the response type for the message. The Response is encoded as a string, and is case insensitive. The valid strings are defined in Section 4.2.1.1.1. Only one of Method or Response will be present in any given method -- the presence of both constitutes an error. Some responses that are defined as protocol responses in the binary encoding below are not present here, as standard HTTP responses are used instead. Gu & Bryan Expires December 9, 2011 [Page 9] Internet-Draft Peer Protocol June 2011 Transaction ID: A unique 64 bit integer that identifies the transaction and also allows receivers to disambiguate transactions which are otherwise identical. Responses use the same Transaction ID as the request they correspond to. It may be possible to a use native HTTP construct in place of this value. 4.2.1.1.1. Method Field Encoding The PPSP Peer Protocol uses a request-response approach to protocol messages. Messages are either a request, asking for an action, or a response, in reply to a request. Message methods are transmitted using an HTTP GET, with an appropriate XML body as defined above (and expanded per message below). The tables below define the valid string representations for the requests and responses. These values MUST be treated as case- insensitive. +-----------------------+----------------------------+ | PPSP Request | PPSP Request Method String | +-----------------------+----------------------------+ | FIND | FIND | | FIND_CHUNK | FIND_CHUNK | | CHUNK_AVAILABILITY | CHUNK_AVAILABILITY | | PROPERTY_QUERY | PROPERTY_QUERY | | TRANSPORT_NEGOTIATION | TRANSPORT_NEGOTIATION | +-----------------------+----------------------------+ Table 1: Valid Strings for Requests +----------------------+---------------------+----------------------+ | Response Method Name | HTTP Response | XML Response Value | | | Mechanism | | +----------------------+---------------------+----------------------+ | SUCCESSFUL (OK) | 200 OK | OK | | INVALID SYNTAX | 400 Bad Request | INVALID SYNTAX | | VERSION NOT | 400 Bad Request | VERSION NOT | | SUPPORTED | | SUPPORTED | | MESSAGE NOT | 403 Forbidden | MESSAGE NOT | | SUPPORTED | | SUPPORTED | | TEMPORARILY | 503 Service | TEMPORARILY | | OVERLOADED | Unavailable | OVERLOADED | | INTERNAL ERROR | 500 Internal Server | INTERNAL ERROR | | | Error | | | MESSAGE FORBIDDEN | 403 Forbidden | MESSAGE FORBIDDEN | | OBJECT NOT FOUND | 404 Not Found | OBJECT NOT FOUND | Gu & Bryan Expires December 9, 2011 [Page 10] Internet-Draft Peer Protocol June 2011 | AUTHENTICATION | 401 Unauthorized | AUTHENTICATION | | REQUIRED | | REQUIRED | +----------------------+---------------------+----------------------+ Table 2: Method Field Encodings for Responses 4.2.1.2. Common Message Processing When a PPSP Peer Protocol message is received, some basic processing is performed. Upon receiving a message, the message is examined to ensure that the message is properly formed. The receiver MUST check that the HTTP message itself is properly formed, and if not appropriate standard HTTP errors MUST be generated. The receiver must verify that the XML payload is properly formed. If the message is found to be incorrectly formed or the length does not match the length encoded in the common header, the receiver MUST reply with an HTTP 400 response with a PPSP XML payload with the Response attribute set to INVALID SYNTAX. The common message XML MUST be examined to obtain the version number of the message. In the event that the version number is for a version the receiver does not support, the receiver MUST reply with an HTTP 400 response with a PPSP XML payload with the Response attribute set to VERSION NOT SUPPORTED. The common message XML MUST be examined to obtain the message type of the message. In the event the message listed is not supported by the receiver, the receiver MUST reply with an HTTP 400 response with a PPSP XML payload with the Response attribute set to MESSAGE NOT SUPPORTED. If the receiver is unable to process the message at this time because it is in an overloaded state, the receiver SHOULD reply with an HTTP 503 response with a PPSP XML payload TEMPORARILY OVERLOADED. If the receiver encounters an internal error while attempting to process the message, the receiver MUST generate an HTTP 500 response with a PPSP XML payload INTERNAL ERROR message indicating this has occurred. 4.2.1.3. FIND Messages 4.2.1.3.1. Forming and Sending a FIND Message FIND message is sent from a peer to remote peer or a Tracker. In this draft, we only consider the case of sending FIND message from a Gu & Bryan Expires December 9, 2011 [Page 11] Internet-Draft Peer Protocol June 2011 peer to remote peer. To form a FIND Message, the sender constructs the common message XML. The sender MUST properly form the XML, set the Method attribute to FIND, and randomly generate and set the Transaction ID. The method specific XML of the FIND message takes the form shown below: *** *** *** *** Figure 3: FIND Method Specific XML The PeerID of the body MUST be set to the PeerID of the peer, and SwarmID MUST be set to the SwarmID of the swarm the peer is interested in obtaining chunks from. Chunk ID MAY be set to a particular chunk, and if set, the receiver will only return peers having chunks with this ID and higher value. If the peer is interested in any chunks, the peer MUST set the value of the Chunk ID to all zero. Peernum MAY be set to indicate how many peers in the peerlist the requesting peer would like receiver to provide. It's set to zero if requesting peer has no preference on peer number. 4.2.1.3.2. Recieving and Processing a FIND Message When a FIND Message is received, the recevier, i.e. the remote peer, will process the request. The recevier MAY reject the request using one of the error codes in Table 2. If the receiver accepts the message, it MUST verify the fields are properly formed and if not MUST reject the message with an HTTP 400 response with a PPSP XML payload INVALID SYNTAX indicating this has occurred. If the message is well formed and accepted, the receiver will search the internal data store for the requested data and if found will respond the requesting peer with an HTTP 200 OK SUCCESS message response with a PPSP XML payload SUCCESSFUL, as well as the peerlist with ID and IP Addresses of peers that can provide the specific content. If the data is not found an HTTP 404 will be generated with the PPSP XML Response set to OBJECT NOT FOUND. The response MUST have the same Transaction ID as the request The FIND response MUST include an XML payload of the form below: Gu & Bryan Expires December 9, 2011 [Page 12] Internet-Draft Peer Protocol June 2011 *** *** Peer list (SEE BELOW) Figure 4: FIND Response XML The SwarmID MUST be set to the swarm to which the chunks belong. The ChunkID MAY be set to indicate the specific chunk. If ChunkID is set, it means that the peers in the peerlist can provide the specific chunk. The peer list consists of a list of peers, identified by of peers. Requesting peers can request and obtain specific content from peers listed in peerlist, according to the Peer-IDs or IP addresses. The peer list defined in Peer protocol is the same as the one defined in [draft-gu-ppsp-tracker-protocol]. 4.2.1.4. CHUNK_AVAILABILITY message After connected with remote peer, the requesting peer can send CHUNK_AVAILABILITY request to remote peer to ask for the chunks the remote peer can provide. In the CHUNK_AVAILABILITY request message, the requesting peer MAY convey its chunk availability, e.g. bitmap. 4.2.1.4.1. Forming and Sending a CHUNK_AVAILABILITY Message CHUNK_AVAILABILITY message is sent from peer to remote peer. To form a CHUNK_AVAILABILITY Message, the sender constructs the common message XML. The sender MUST properly form the XML, set the Method attribute to CHUNK_AVAILABILITY, and randomly generate and set the Transaction ID. The method specific XML of the CHUNK_AVAILABILITY message takes the form shown below: ### Chunk Availability Figure 5: CHUNK_AVAILABILITY Method Specific XML The PeerID of the body MUST be set to the PeerID of the peer. Gu & Bryan Expires December 9, 2011 [Page 13] Internet-Draft Peer Protocol June 2011 Following this field, chunk availability information MAY be provided. Usually, bitmap is used to indicate chunk availability. A certain PPSP system or a certain swarm may define specific bitmap and the peers participating in the system are assumed to be able to parse the specific bitmap. In this draft, we don't define mandatory bitmap form. 4.2.1.4.2. Recieving and Processing a CHUNK_AVAILABILITY Message When a CHUNK_AVAILABILITY Message is received, the recevier, i.e. the remote peer, will process the request. The recevier MAY reject the request using one of the error codes in Table 2. If the receiver accepts the message, it MUST verify the fields are properly formed and MUST reject the message with an HTTP 400 response with a PPSP XML payload INVALID SYNTAX indicating this has occurred. If the message is well formed and accepted, the receiver will search the internal data store for the chunks of the desired swarm it has restored. And if found will respond the requesting peer with an HTTP 200 OK SUCCESS message response with a PPSP XML payload SUCCESSFUL, as well as the bitmap. If the data is not found, e.g. the data has been removed by the receiver, an HTTP 404 will be generated with the PPSP XML Response set to OBJECT NOT FOUND. ### Chunk Availability Figure 6: CHUNK_AVAILABILITY Method Specific XML The PeerID of the body MUST be set to the PeerID of the peer. Following this field, chunk availability information MAY be provided. Usually, bitmap is used to indicate chunk availability. A certain PPSP system or a certain swarm may define specific bitmap and the peers participating in the system are assumed to be able to parse the specific bitmap. In this draft, we don't define mandatory bitmap form. 4.2.1.5. PROPERTY_QUERY message A requesting peer may have preference when choosing the remote peers to obtain data. For example, a peer would like to obtain data from a remote peer with longer online time. The requesting peer can convey the concerning property in PROPERTY_QUERY message, and the receiver will response with corresponding parameters to the properties listed in PROPERTY_QUERY message. The requesting peer can also convey its Gu & Bryan Expires December 9, 2011 [Page 14] Internet-Draft Peer Protocol June 2011 connection preference in Tracker protocol, e.g. in FIND or FIND_CHUNK message. The requesting peer has to be aware that it's not guaranteed that the parameters provided by remote peers are true. 4.2.1.5.1. Property Types for PROPERTY_QUERY Messages The property listed here are the same as Sample Property Types for STAT message defined in [draft-gu-ppsp-tracker-protocol]. For readers convenience, they are repeated in this draft. +------------------+------------------------------------------------+ | XML Value | Definitions/Description | +------------------+------------------------------------------------+ | CachingSize | Caching size: available size for caching | | Bandwidth | Bandwidth: available bandwidth | | LinkNumber | Link number: acceptable links for remote peer | | Certificate | Certificate: certificate of the peer | | NAT | NAT/Firewall: peer believes it is behind NAT | | | (Boolean Value) | | STUN | STUN: peer supports STUN service (Boolean | | | Value) | | TURN | TURN: peer supports TURN service (Boolean | | | Value) | | SumBytes | Sum Volume: Sum of bytes of data peers | | | received from the steaming system | | AccessMode | Access Mode: ADSL/Fiber/GPRS/3G/LTE/WiFi etc. | | EndDevice | End Device: STB/PC/MobilePhone | | AvailableBattery | Available Battery Level | +------------------+------------------------------------------------+ Table 3: Sample Property Types for STAT messages 4.2.1.5.2. Forming and Sending a PROPERTY_QUERY Message PROPERTY_QUERY message is sent from peer to peer. To form a PROPERTY_QUERY Message, the sender constructs the common message XML. The sender MUST properly form the XML, set the Method attribute to PROPERTY_QUERY, and randomly generate and set the Transaction ID. The method specific XML of the PROPERTY_QUERY message takes the form shown below: ### ... more stats ... Gu & Bryan Expires December 9, 2011 [Page 15] Internet-Draft Peer Protocol June 2011 Figure 7: PROPERTY_QUERY Method Specific XML The PeerID of the body MUST be set to the PeerID of the peer. Each Stat in the StatRequest MUST have the property set as defined in Table 3 and MUST NOT have any value. 4.2.1.5.3. Recieving and Processing a PROPERTY_QUERY Message When a PROPERTY_QUERY message is received by the peer, it MUST respond, using one of the response codes defined above. The body contains one value each requested statistic: ### *** ... more stats ... Figure 8: PROPERTY_QUERY Response Method Specific XML The PeerID of the body MUST be set to the PeerID of the peer. Following this field, one or more Stat attributes are provided, with a property field corresponding to the data as described in Table 3 and an appropriate value provided. 4.2.1.6. TRANSPORT_NEGOTIATION message Peer protocol is used for informaiton exchanging and transport protocol negotiation. We recommend to reuse existing transport protocol to transfer data. 4.2.1.6.1. Forming and Sending a TRANSPORT_NEGOTIATION Message TRANSPORT_NEGOTIATION message is sent from peer to remote peer. To form a TRANSPORT_NEGOTIATION Message, the sender constructs the common message XML. The sender MUST properly form the XML, set the Method attribute to TRANSPORT_NEGOTIATION, and randomly generate and set the Transaction ID. The method specific XML of the TRANSPORT_NEGOTIATION message takes the form shown below: Gu & Bryan Expires December 9, 2011 [Page 16] Internet-Draft Peer Protocol June 2011 ### ... more protocols ... Figure 9: TRANSPORT_NEGOTIATION Method Specific XML The PeerID of the body MUST be set to the PeerID of the peer. Following this field, a list of transport protocol supported by requesting peer are provided. Note that NO VALUE is presented. The tables below define the valid string representations for the Transport protocols. These values MUST be treated as case- insensitive. At least one transport protocol are mandatory, that should be supported by all peers. The authors currently designate RTP as mandatory tansport protocol, but this is still under discussion. +-----------+------------------------------+ | XML Value | Definitions/Description | +-----------+------------------------------+ | RTP | Real-time transport protocol | | SIP | Session Initiation Protocol | +-----------+------------------------------+ Table 4: Sample Transport Protocols 4.2.1.6.2. Recieving and Processing a TRANSPORT_NEGOTIATION Message When a TRANSPORT_NEGOTIATION message is received by the peer, it MUST respond, using one of the response codes defined above. The receiver check the supported transport protocol listed in request message and find out which transport protocols it supports. The recevicer will response the requesting peer with an HTTP 200 OK SUCCESS message response with a PPSP XML payload SUCCESSFUL, as well as the transport protocols the receiver supports. The designated transport protocols must be originally listed in TRANSPORT_NEGOTIATION message. If none of the transport protocol listed in TRANSPORT_NEGOTIATION request is supported by the receiver, an HTTP 404 will be generated with the PPSP XML Response set to OBJECT NOT FOUND.The body contains one value each requested statistic: Gu & Bryan Expires December 9, 2011 [Page 17] Internet-Draft Peer Protocol June 2011 ### ... more protocols ... Figure 10: TRANSPORT_NEGOTIATION Response Method Specific XML The PeerID of the body MUST be set to the PeerID of the peer. Following this field, one or more designated transport protocols are indicated. The designated transport protocols must be orginally included in TRANSPORT_NEGOTIATION request message. The requesting peer can choose any of the designated transport protocol to transfer data of desired content. 5. Security Consideration As in typical Peer to Peer network, the most significant security issue is that the peers are untrusted. A peer may announce that it has a specific content, but the content might be just noise or it could be poisoned. A peer could also download lots of chunks but upload very few of them. This problem can be alleviated by incentive mechanism, the goal of which is to reward honest peers and degrade dishonest peers. [draft-zeng-ppsp-protocol-pro-incentive-para] introduces some mechanism. Currently, both Tracker and peer protocol only define basic methods. When we get consensus on basic methods and encoding, we will introduce incentive mechanism into the protocols. 6. References 6.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, . Gu & Bryan Expires December 9, 2011 [Page 18] Internet-Draft Peer Protocol June 2011 6.2. Informative References [I-D.ietf-ppsp-problem-statement] Zhang, Y., Zong, N., Camarillo, V., Seng, J., and R. Yang, "Problem Statement of P2P Streaming Protocol (PPSP)", Januray 2011, . [I-D.ietf-ppsp-reqs] Zong, N., Zhang, Y., Pascual, V., and C. Williams, "P2P Streaming Protocol (PPSP) Requirements", February 2011, . [I-D.ietf-ppsp-survey] Gu, Y., Zong, N., Zhang, H., Zhang, Y., Camarillo, G., and Y. Liu, "Survey of P2P Streaming Applications", March 2011, . [draft-gu-ppsp-tracker-protocol] Gu, Y., Bryan, D., Zhang, Y., and H. Liao, "PPSP Tracker Protocol", March 2011, . [BittorrentSpecification] "Bittorrent Protocol Specification v1.0", February 2010, . [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", March 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 Gu & Bryan Expires December 9, 2011 [Page 19] Internet-Draft Peer Protocol June 2011 David A. Bryan Polycom San Jose, CA, USA, USA Phone: Email: dbryan@ethernot.org Gu & Bryan Expires December 9, 2011 [Page 20]