PPSP Y. Gu Internet-Draft Huawei Intended status: Standards Track David A. Bryan Expires: March 30, 2012 Polycom L. Deng China Mobile J. Xia Huawei Sep 27, 2011 PPSP Tracker Protocol draft-gu-ppsp-tracker-protocol-05 Abstract This document outlines the functionality required for a P2P streaming Tracker Protocol, including functional entities and architecture, components, encoding format and syntax. The Tracker protocol is an application-level protocol for peers to publish/request content and provide peer status to Trackers. It is also used by trackers to provide peer lists to peers, as well as to send control/management messages to and communicate with other trackers. The PPSP tracker protocol can serve live media and VoD, as well as file sharing applications. 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 March 30, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Gu, et al. Expires March 30, 2012 [Page 1] Internet-Draft PPSP Tracker Protocol Sep 2011 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Document History . . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Function Entities . . . . . . . . . . . . . . . . . . . . 4 4.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Bootstrapping . . . . . . . . . . . . . . . . . . . . 6 4.2.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . 7 4.3. Description of the PPSP Tracker Protocol . . . . . . . . . 7 5. Message Syntax and Processing . . . . . . . . . . . . . . . . 10 5.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1.1. Shared Message Body . . . . . . . . . . . . . . . . . 11 5.1.2. Common Parameters . . . . . . . . . . . . . . . . . . 13 5.1.3. Common Message Processing . . . . . . . . . . . . . . 13 5.1.4. FIND Messages . . . . . . . . . . . . . . . . . . . . 14 5.1.5. JOIN Messages . . . . . . . . . . . . . . . . . . . . 17 5.1.6. LEAVE Messages . . . . . . . . . . . . . . . . . . . . 20 5.1.7. KEEPALIVE Messages . . . . . . . . . . . . . . . . . . 21 5.1.8. STAT Messages . . . . . . . . . . . . . . . . . . . . 22 6. Example Flow . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7.1. Authentication between communicating tracker and peers . . 27 7.2. Signaling protection between communicating tracker and peers . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.3. Content Integrity protection against polluting peers/trackers . . . . . . . . . . . . . . . . . . . . . . 27 7.4. Residual attacks and mitigation . . . . . . . . . . . . . 27 7.5. Pro-incentive parameter trustfulness . . . . . . . . . . . 28 8. Implementation considerations . . . . . . . . . . . . . . . . 28 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Gu, et al. Expires March 30, 2012 [Page 2] Internet-Draft PPSP Tracker Protocol Sep 2011 1. Introduction The P2P Streaming Protocol (PPSP) is composed of two protocols: the PPSP Tracker Protocol and the PPSP Peer Protocol. The PPSP Tracker Protocol provides communication between Trackers and Peers, by which Peers report streaming status to the tracker and request candidate lists from the tracker. [I-D.ietf-ppsp-problem-statement]specifies that the Tracker protocol should standardize format/encoding of information and messages between PPSP peers and PPSP trackers. [I-D.ietf-ppsp-reqs] defines the detailed requirements for Tracker Protocol. This draft presents a proposal for the PPSP Tracker Protocol. We first analyze and present the functional entities involved in Tracker protocol. Following this, a list of functions are introduced. Then we introduce definitions for formal syntax, semantics, and detailed message processing instructions for the PPSP Tracker Protocol, using an HTTP/XML encoding. This include parameters, methods, and message formats. Most implemented P2P protocols are proprietary, as introduced in . This draft intends to extract the fundamental features, functionalities and policies of the proprietary protocols, extend it based on implementation experience, and present an early strawman sketch for an extensible protocol as a way to identify open issues and further discussion in the PPSP WG. [I-D.ietf-ppsp-survey] 2. Terminology 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]. The draft uses the terms defined in[I-D.ietf-ppsp-problem-statement] Additionally, this draft also uses the following terms: Swarm: A swarm is a set of peers who are sharing the same file, live channel or VoD program. Chunk: A chunk is a basic unit of partitioned stream, which is used by a peer for the purpose of storage, advertisement and exchange among peers. Join Time: Join time is the absolute time when a peer registers on a Tracker. This value is recorded by the Tracker and is used to calculate Online Time. Online Time: Online Time shows how long the peer has been in the P2P Gu, et al. Expires March 30, 2012 [Page 3] Internet-Draft PPSP Tracker Protocol Sep 2011 streaming system since it joins. This value indicates the stability of a peer, and it is calculated by Tracker when necessary. Absolute Time: Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps, using UTC (GMT). Fractions of a second may be indicated. Example for November 8, 1996 at 14h37 and 20 and a quarter seconds UTC:19961108T143720.25Z 3. Document History Changes from -03 to -04: Remove Binary encoding, add security considertaitons and make editorial revision. Changes from -02 to -03: The document has been updated to reflect that both Peer-IDs and IP addresses will be returned, rather than only Peer-IDs. Binary encoding is moved to Appendix B. Changes from -01 to -02: The document has been updated to reflect that Peer-IDs will be returned, rather than the open issue on Peer- IDs or IP addresses. Changes from -00 to -01: The operations of the protocol and their names were changed to help clarify the functions and to eliminate confusion. Substantial modifications were made to the proposed protocol. 4. Protocol Overview 4.1. Function Entities There are two primary functional entities involved in the PPSP Tracker Protocol: Trackers and Peers. The tracker is a logical entity storing information about which peers can provide which pieces of information. The tracker may also storing the status of peers, e.g. caching size, which will help the tracker to select appropriate candidate peers for a requesting peer. While a tracker may have an underlying implementation consisting of more than one device, logically the tracker can most simply be thought of as a single element, and in this document, we will treat the tracker as a single logical unit. Trackers store a list of all peers making up a swarm for a particular stream or file, and (particularly in the live streaming case) may also store a list of which chunks each peer stores. The peers are devices actually participating in sharing information Gu, et al. Expires March 30, 2012 [Page 4] Internet-Draft PPSP Tracker Protocol Sep 2011 related to a particular stream or file. Each peer stores some pieces, called chunks, and contacts the tracker to advertise which information is available. When a peer wishes to obtain information, it contacts the tracker to find other peers participating in the swarm. The peers communicate with one another to exchange the actual chunks, and in the case where the tracker stores only the list of peers in the swarm, to exchange the lists of chunks. Peer +-------------------+ |peer signaling | | +===============+ | | | FIND | | | | JOIN | | | | JOIN_CHUNK | | | | LEAVE | | | | KEEPALIVE | | | | STAT_QUERY | | | | STAT_REPORT | | | +===============+ | +-------------------+ ^ -----------*------------- Tracker V +-------------------+ |tracker signaling | | +===============+ | | | FIND | | | | JOIN | | | | JOIN_CHUNK | | | | LEAVE | | | | KEEPALIVE | | | | STAT_QUERY | | | | STAT_REPORT | | | +===============+ | +-------------------+ Figure 1: Tracker Protocol components Gu, et al. Expires March 30, 2012 [Page 5] Internet-Draft PPSP Tracker Protocol Sep 2011 Peer +-------------------+ |Data management | | Swarm ID | | - Chunk ID | | - peer list | | - Buffer map | | | +-------------------+ ^ --------------*----------- Tracker V +----------------------------------------------------------+ | Data management on Tracker | | | | +======================+ +======================+ | | |peer status | |content status | | | | peer ID | | +---------------+ | | | | - online time | | | Swarm ID | | | | | - peer property | | | - Chunk ID | | | | | - link status | | | - peer list| | | | | - etc. | | +---------------+ | | | +======================+ +======================+ | +----------------------------------------------------------+ Figure 2: Data management components in PPSP 4.2. Assumptions 4.2.1. Bootstrapping When a peer wishes to join an existing P2P streaming application, it must first locate a Tracker. Peers may use any method to find a Tracker, for example obtaining it from service provider provisioning mechanisms, from a web page, or via broadcast. Tracker discovery is out of scope of this specification. Similarly, we assume that peers obtain their Peer-IDs and any certificates required for security (i.e. their peer certificates and the tracker certificate) out of band. While this functionality may be incorporated into the tracker, it is not required to do so. The specification of the mechanism used to obtain a Peer-ID and certificates is not discussed in this draft. Both tracker and peer are able to read a certificate to check whether the peer providing the certificate is the real owner of the certificate. Neither tracker nor peer is able to modify a certificate. Gu, et al. Expires March 30, 2012 [Page 6] Internet-Draft PPSP Tracker Protocol Sep 2011 4.2.2. NAT Traversal For simplicity, we assume that all trackers must be in the public Internet and have been placed there deliberately. Issues of NAT traversal required in this scenario are not yet specified. The issues related to any scheme contemplating promotion (i.e. selecting peers be promoted and to serve as a tracker) or implementing a fully distributed tracker are not considered in this version of the draft. Though this draft will not describe NAT Traversal mechanism in PPSP in detail, it tries to enable flexible NAT Traversal in future and will consider the requirements raised by NAT draft. 4.3. Description of the PPSP Tracker Protocol The PPSP Tracker Protocol presented is a request-response protocol. Requests are sent, and responses returned to these requests. While most requests are sent to the tracker from peers requesting information, the tracker may also send messages to the peers to query information. A single request generates a single response (neglecting fragmentation of messages). The specific methods of the protocol are enumerated below. All the methods are mandatory to be support by both peer and tracker. However, not all of them are required in each individual interaction between peer and tracker. FIND: Peers use the FIND method to request that the tracker return lists of peers that can provide specific content or are in a particular swarm. On receiving a FIND message, the tracker finds the candidate peers listed in content status, and returns the list to the requesting peer. To create the peerlist, the tracker may take peer status and peers priority into consideration when it picks the candidate peers to add to this list. Peer priority could be determined by network topology preference (for example the ongoing IETF work in ALTO), operator policy preference, etc. Tracker could also take piece rarity into consideration as introduced in [I-D.zeng-ppsp-protocol-pro-incentive-para-01]. Tracker can return candidate peer list in a single response message, or split the candidate peers into several peer list, to show tracker's preference which could benefit the system for the long run. PPSP can provide provider-friendly traffic direction. E.g., there are 100 peers that have the requested chunks, how should Tracker choose them? One option is to choose peers upon their capability, the other is to find out from ALTO server which peers are more cost effective. But P2P application is much complicate, some existing protocols that only try top N peers of the returned peerlist, while some others randomly choose some Gu, et al. Expires March 30, 2012 [Page 7] Internet-Draft PPSP Tracker Protocol Sep 2011 peers from peerlist. So ALTO may not helpful in this case. In this case, if Tracker can reply in a series of responses containing decreasing priority peer lists, PPSP can guarantee that Peers obey Trackers' choice and make no changes to existing Peers. Hence, in PPSP, we assume that peerlists that is replied in series have decreasing preference for requesting peer to connect. In Live streaming, when receiving a FIND messages, the tracker also updates content status to involve the new peer under a specific channel. JOIN: Peers use JOIN to notify a tracker they wish to participate in a particular swarm or specific chunks. The tracker records the content availability, i.e. adds the peer to the candidate peers list for the notified chunk IDs of a particular swarm. Both a tracker receives a FIND or JOIN message, and the message is the first message that a tracker receives from a peer, the tracker records the peer's information, e.g. peer-ID, Connect-time, peer property, peer link status, etc. Only FIND or JOIN message can be the first mesage communicated between peer and tracker. Any other messgae, e.g. KEEPALIVE or STAT_QUERY, without one of the above message be sent in advance will be regarded as invalid message and dropped. LEAVE: Peers use the LEAVE operation to indicate to the tracker that they no longer are participating in (either sharing or requesting) a particular swarm. The tracker will no longer provide this peer to others when they request to join a swarm. LEAVE message is an optional message. A peer will be kicked away from all the swarms it's participating in when none of KEEPALIVE, JOIN or FIND message is received by tracker before the timer for the specific peer expires. KEEPALIVE: Keepalive messages are periodically sent from peers to the tracker to notify the tracker that the peer is still alive. If a tracker does not receive keep-alive message for some pre- configured time, the tracker will assume that the peer is no longer available and will perform the same logical operations as in Leave. Timer on the tracker can be reset by any other message send from the particular peer to tracker. For example, when a timer on tracker for a particular peer A is going to be aged out and a FIND message is recieved from peer A, the timer on tracker for peer A is reset. Meanwhile the timer on peer A for this transaction is Gu, et al. Expires March 30, 2012 [Page 8] Internet-Draft PPSP Tracker Protocol Sep 2011 also reset. By this way, unnecesary KEEPALIVE messages can be saved. FIND, JOIN and KEEPALIVE can be used beyond their original purpose. Peer can convey peer property or status in these messages. Static property, such as NAT, STUN, TURN, AccessMode and EndDevice, can be ocnveyed by FIND or JOIN message. Dynamic status, such as CachingSize, Bandwidth, LinkNumber, AvailableBattary, ChunkMap, BytesUploaded and BytesDownloaded, can be converyed by KEEPALIVE message. Refer to Table 3 for the detail explanation of each property and status. STAT_QUERY: This method Tracker to request statistical information from a particular peer. STAT_REPORT: This method allows peers to submit statistic data to the tracker to improve system performance. STAT_REPORT is sent only when peer receives STAT_QUERY message. As discussed at WG session and mailing list, a rough consensus is to adopt HTTP protocol to convey tracker protocol. 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. 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: JOIN, FIND, KEEPALIVE and STAT_REPORT return any required status information about the successfully completed operation. FIND returns the list of peers meeting the desired criteria. STAT_QUERY returns the requested statistics in the body of the message. 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 tracker. As an example, some trackers might choose not to Gu, et al. Expires March 30, 2012 [Page 9] Internet-Draft PPSP Tracker Protocol Sep 2011 implement the statistics functions. TEMPORARILY OVERLOADED: The server is unable to process this message at this time. (this may be handled at the HTTP level in the HTTP/XML case) INTERNAL ERROR: The server was unable to process the request due to an internal error. (this may be handled at the HTTP in the HTTP/XML case) MESSAGE FORBIDDEN: The requester is not allowed to make this request. For example. a peer may not be able to query statistical information from a tracker. (this may be handled at the HTTP level in the HTTP/XML case) OBJECT NOT FOUND: The requested object (i.e., a swarm to be joined or a swarm that is being searched for) cannot be found. (this may be handled at the HTTP level in the HTTP/XML case) AUTHENTICATION REQUIRED: Authentication is required to access this information. (this may be handled at the HTTP level in the HTTP/ XML case). PAYMENT REQUIRED: Payment is required to access this service. (this may be handled at the HTTP level in the HTTP/XML case) 5. Message Syntax and Processing 5.1. Syntax 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. As mentioned earlier, the authors hope that an existing XML encoding from another protocol may be able to be used in some places. The authors acknowledge they are not experts in either HTTP or XML, and may have made significant mistakes in this initial encoding attempt. As a result, this section may change dramatically in the next version as the authors continue their research into how to use HTTP/XML. For simplicity, the current proposal uses only HTTP POST as a mechanism. Error codes from HTTP are reused when possible, with the error conveyed in the actual HTTP message. One possible extension would be the use of HTTP CONNECT in connection with the security Gu, et al. Expires March 30, 2012 [Page 10] Internet-Draft PPSP Tracker Protocol Sep 2011 model to be defined later. This basic approach is subject to change. 5.1.1. Shared Message Body The format of the shared message 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 3: 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 Tracker 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 5.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 5.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. 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. Gu, et al. Expires March 30, 2012 [Page 11] Internet-Draft PPSP Tracker Protocol Sep 2011 5.1.1.1. Method Field Encoding As discussed earlier, the PPSP Tracker 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 POST, 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 | | JOIN | JOIN | | LEAVE | LEAVE | | KEEPALIVE | KEEPALIVE | | STAT_QUERY | STAT_QUERY | | STAT_REPORT | STAT_REPORT | +--------------+----------------------------+ 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 | | AUTHENTICATION | 401 Unauthorized | AUTHENTICATION | | REQUIRED | | REQUIRED | | PAYMENT REQUIRED | 402 Payment | PAYMENT REQUIRED | | | Required | | +----------------------+---------------------+----------------------+ Gu, et al. Expires March 30, 2012 [Page 12] Internet-Draft PPSP Tracker Protocol Sep 2011 Table 2: Method Field Encodings for Responses Note that many responses are included in 400 Bad Request bodies, as these are errors within the XML/PPSP protocol messages, not HTTP itself, and as such, responses such as 405 Method Not Allowed are not appropriate. (the device supports POST, but not the particular PPSP XML body included) 5.1.2. Common Parameters 5.1.2.1. Peerlist Definition Peerlist is a list of candidatte peers with both their Peer IDs and Peer IPv4 or IPv6 Addresses. Peer ID is a 128 bit integer that is unique in the P2P streaming system. That's no matter there is a centralized tracker or several distributed trackers in the streaming system, a peer ID should be unique. In response message that need to convey peerlist, peerlist is represented by a series of peer description, each of which has Peer ID and Peer IP Address seperated by comma. For example, a peerlist with 3 peers is respresented as follows. 48482345122344,193.2.2.4 67679906544665765,210.4.12.4 6357906543579087,220.2.13.4 Peerlist Representaiton 5.1.2.2. Buffer Map 5.1.3. Common Message Processing When a PPSP Tracker Protocol message is received, some basic processing is performed, regardless of the message type or the type of receiver (tracker or peer). 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 Gu, et al. Expires March 30, 2012 [Page 13] Internet-Draft PPSP Tracker Protocol Sep 2011 SYNTAX. The common message 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. 5.1.4. FIND Messages 5.1.4.1. Forming and Sending a FIND Message FIND message is sent from peer to tracker. 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 specific XML schema definition of the FIND message takes the form shown below: Gu, et al. Expires March 30, 2012 [Page 14] Internet-Draft PPSP Tracker Protocol Sep 2011 ... ... ... ... Figure 4: 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 tracker 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 tracker to provide. It's set to zero if requesting peer has no preference on peer number. Status MAY be set to indicate the requesting peer's requirements to the property of peers that can share the specific content. One or more Stat attributes are provided, with a property field corresponding to the data as described in . (Table 3) 5.1.4.2. Recieving and Processing a FIND Message When a FIND Message is received, the tracker will process the request. The tracker MAY reject the request using one of the error codes in Table 2. If the tracker 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 tracker 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 Gu, et al. Expires March 30, 2012 [Page 15] Internet-Draft PPSP Tracker Protocol Sep 2011 as the peerlist with ID and IP Addresses of peers that can provide the specific content. If Status filed is indicated, based on peers' property that has been recorded on tracker and the property requiremnts indicated in request message, tracker will choose peers that can provide the specific content and satisfy the property requirement set by requesting peers.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: ... ... ... ... Figure 5: 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. Refer to section Peerlist Definition for the structure of peerlist. Requesting peers can request and obtain specific content from peers listed in peerlist, according to the Peer-IDs or IP addresses. Gu, et al. Expires March 30, 2012 [Page 16] Internet-Draft PPSP Tracker Protocol Sep 2011 5.1.5. JOIN Messages The JOIN message is used by the Peer to inform the Tracker that it would like to participate in a particular swarm, and optionally what portions of that swarm it has available. JOIN is used when the Peer has some chunks or wishes to join a live stream, but does not provide the list of chunks or location in the stream to the tracker (i.e., gossip is used between peers to exchange the chunk list/stream position or it simply joins at the current position). 5.1.5.1. Forming and Sending a JOIN Message JOIN message is sent from peer to tracker. To form a JOIN Message, the sender constructs the common message XML. The sender MUST properly form the XML, set the Method attribute to JOIN, and randomly generate and set the Transaction ID. The method specific XML of the JOIN message takes the form shown below: ... ... ... ... Figure 6: JOIN 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. Expiration Time MAY be set to some non-zero value in seconds, indicating that the peer expects to no longer be participating at the end of the time. If the peer does not wish to set an Expiration Time, this field MUST be set to zero. Gu, et al. Expires March 30, 2012 [Page 17] Internet-Draft PPSP Tracker Protocol Sep 2011 Status MAY be set to indicate the requesting peer's requirements to the property of peers that can share the specific content. One or more Stat attributes are provided, with a property field corresponding to the data as described in Table 3. 5.1.5.2. Forming and Sending a JOIN_CHUNK Message JOIN_CHUNK message is sent from peer to tracker. To form a JOIN_CHUNK Message, the sender constructs the common message XML. The sender MUST properly form the XML, set the Method attribute to JOIN_CHUNK, and randomly generate and set the Transaction ID. When implementing JOIN_CHUNK, one may wonder how often shall a peer notify the tracker of its chunk availability. Shall a peer report every single chunk as soon as it is received, or report periodically? In real-time reporting, both the peer and the tracker will be busy processing JOIN_CHUNK message and responses. In periodic reporting, the period should be configured carefully, or the peer may not operate efficiently. In a VOD swarm or live streaming, a peer will keep receiving continuous chunks of a designated swarm. After a peer JOIN_CHUNKs a first chunk, the tracker can communicate which chunks are currently stored in the peer, according to the caching size and time difference between JOIN_CHUNK and current time. For example, a peer join chunk A, and the join time is time A. The peer won't send any JOIN_CHUNK message afterwards. When other peers want to get chunk B at time B, tracker can calculate by (time B - Time A) /length-of-a-chunk + chunk A. Tracker will know whether the peer has cached chunk B. The calculation mechanism may be different at different application, because applications may have various ways to define chunks. But dynamically JOIN_CHUNK can help to reduce load on tracker and peer. The method specific XML of the JOIN_CHUNK message takes the form shown below: Gu, et al. Expires March 30, 2012 [Page 18] Internet-Draft PPSP Tracker Protocol Sep 2011 ... ... OR ... ... Figure 7: JOIN_CHUNK Method Specific XML As with the JOIN_CHUNK message, 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. Expiration Time MAY be set to some non-zero value in seconds, indicating that the peer expects to no longer be participating at the end of the time. If the peer does not wish to set an Expiration Time, this field MUST be set to zero. Dynamic of the body MAY be set to indicate the peer would share the chunks start with the chunk ID in the message, and won't send JOIN_CHUNK again, but tracker can calculate which chunks the peer can share at a specific time. Systemtime indicates the time the peer gets the start chunk. Caching length indicates the size of cache for this specific swarm on sender. Following these fields, one or more 32 bit ChunkID fields MAY be provided, if the peer would share chunks that are beyond the chunk indicated in Dynamic part of the message. Status MAY be set to indicate the requesting peer's requirements to the property of peers that can share the specific content. One or Gu, et al. Expires March 30, 2012 [Page 19] Internet-Draft PPSP Tracker Protocol Sep 2011 more Stat attributes are provided, with a property field corresponding to the data as described in Table 3. 5.1.5.3. Recieving and Processing a JOIN or JOIN_CHUNK Message When a JOIN or JOIN_CHUNK Message is received, the tracker will process the request. The tracker MAY reject the request using one of the error codes in Table 2. If the tracker accepts the message, it MUST verify the fields are properly formed (including any continuation messages for JOIN_CHUNK messages) 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 tracker enters the information into the internal data store, and respond with an HTTP 200 OK SUCCESS message response with a PPSP XML payload SUCCESSFUL. The response MUST have the same Transaction ID as the request, and MUST not contain any additional body information. 5.1.6. LEAVE Messages The LEAVE message is used by the Peer to inform the Tracker that it no longer wishes to participate in a particular swarm. 5.1.6.1. Forming and Sending a LEAVE Message LEAVE message is sent from peer to tracker. To form a LEAVE Message, the sender constructs the common message XML. The sender MUST properly form the XML, set the Method attribute to LEAVE, and randomly generate and set the Transaction ID. The method specific information formed as discussed below. The method specific XML of the LEAVE message takes the form shown below: Figure 8: LEAVE 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 no longer interested in participating inTable 3. Gu, et al. Expires March 30, 2012 [Page 20] Internet-Draft PPSP Tracker Protocol Sep 2011 5.1.6.2. Recieving and Processing a LEAVE Message When a LEAVE Message is received, the tracker will process the request. The tracker MAY reject the request using one of the error codes in Table 2. If the tracker accepts the message, it MUST verify the fields are properly formed (including any continuation messages for JOIN messages) 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 tracker will remove the peer from the list of peers participating in a particular swarm and will respond with an HTTP 200 OK SUCCESS message response with a PPSP XML payload SUCCESSFUL. The tracker does not notify other peers in the swarm that the peer has left -- this functionality is left for the peer protocol. The response MUST have the same Transaction ID as the request, and MUST not contain any additional body information. 5.1.7. KEEPALIVE Messages 5.1.7.1. Forming and Sending a KEEPALIVE Message KEEPALIVE message is sent from peer to tracker. To form a KEEPALIVE Message, the sender constructs the common message XML. The sender MUST properly form the XML, set the Method attribute to KEEPALIVE, and randomly generate and set the Transaction ID. The method specific XML of the KEEPALIVE message takes the form shown below: ... ... ... ... Gu, et al. Expires March 30, 2012 [Page 21] Internet-Draft PPSP Tracker Protocol Sep 2011 Figure 9: KEEPALIVE Method Specific XML The PeerID of the body MUST be set to the PeerID of the peer. Status MAY be set to indicate the requesting peer's requirements to the property of peers that can share the specific content. One or more Stat attributes are provided, with a property field corresponding to the data as described in 5.1.7.2. Recieving and Processing a KEEPALIVE Message When tracker receives a KEEPALIVE message, it should update an internal timer to indicate that the tracker has heard from the peer. 5.1.8. STAT Messages There are two types of STAT Messages. STAT_REPORT messages are used to report statistics information, and STAT_QUERY messages are used to request information. 5.1.8.1. Property Types for STAT Messages The following statistics are listed as examples of information that might be useful, and we define example type values here. As the protocol firms up, we will likely want to reconsider these and add to them or remove. +------------------+------------------------------------------------+ | 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 | | BytesUploaded | Total amount of data that a reporting peer has | | | uploaded. This is to be reported by a peer to | | | the tracker. | Gu, et al. Expires March 30, 2012 [Page 22] Internet-Draft PPSP Tracker Protocol Sep 2011 | ChunkMAP | Indicates which chunks of a file that a peer | | | has. This is to be reported by a peer to the | | | tracker. | | BytesDownloaded | Total amount of data reported by a peer that | | | has been downloaded from a different peer. | | | Each BytesDownloaded should be paired with a | | | PeerID. This is to be reported by a peer to | | | the tracker. | +------------------+------------------------------------------------+ Table 3: Sample Property Types for STAT messages 5.1.8.2. Forming and Sending a STAT_QUERY Message STAT_REPORT message is sent from peer to tracker. To form a STAT_REPORT Message, the sender constructs the common message XML. The sender MUST properly form the XML, set the Method attribute to STAT_REPORT, and randomly generate and set the Transaction ID. The method specific XML of the STAT_REPORT message takes the form shown below: ... ... ... ... Figure 10: STAT_QUERY 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. Gu, et al. Expires March 30, 2012 [Page 23] Internet-Draft PPSP Tracker Protocol Sep 2011 5.1.8.3. Forming and Sending a STAT_REPORT Message STAT_REPORT message is sent from peer to tracker. To form a STAT_REPORT Message, the sender constructs the common message XML. The sender MUST properly form the XML, set the Method attribute to STAT_REPORT, and randomly generate and set the Transaction ID. The method specific XML of the STAT_REPORT message takes the form shown below: ... ... ... ... Figure 11: STAT_REPORT 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. 5.1.8.4. Recieving and Processing a STAT_QUERY Message In addition to normal processing rules, when a Tracker receives a STAT_REPORT message, it MAY process the message and store the statistical information for future use. The response MUST contain the same Transaction ID as the request. 6. Example Flow Fig. 3 shows a complete interaction between peer and tracker that includes all methods. But some of the methods, labeled as optional, could be replaced or skipped. Gu, et al. Expires March 30, 2012 [Page 24] Internet-Draft PPSP Tracker Protocol Sep 2011 Requesting Peer Tracker |-------------------- FIND ----------------------------->| |<------------------- RESPONSE ---------------------------| |-------------------- JOIN ---------------------------->| |<------------------- RESPONSE ---------------------------| |---------------- KEEPALIVE (OPTIONAL) -------------------| |<------------------- RESPONSE ---------------------------| |<-------------------STAT_QUERY (OPTIONAL)----------------| |--------------------STAT_RESPONSE (OPTIONAL)------------>| |-------------------- LEAVE (OPTIONAL) -------------------| |<------------------- RESPONSE ---------------------------| Figure 12: Example Call Flow The following XML illustrates above example flow in detail: p1 s1 c1 2 cachingSize bandwidth ... ... 123456789 s1 c1 PeerA PeerB Gu, et al. Expires March 30, 2012 [Page 25] Internet-Draft PPSP Tracker Protocol Sep 2011 123456789 p1 s1 1316972264 cachingSize bandwidth ... ... 123456789 p1 cachingSize bandwidth ... ... 123456789 p1 s1 123456789 Figure 13 7. Security Considerations P2P streaming systems are subject to attacks by malicious/unfriendly peers/trackers that may eavesdrop on signaling, forge/deny Gu, et al. Expires March 30, 2012 [Page 26] Internet-Draft PPSP Tracker Protocol Sep 2011 information/knowledge about streaming content and/or its availability, impersonating to be another valid participant, or launch DoS attacks to a chosen victim. No security system can guarantees complete security in an open P2P streaming system where most of its participants are malicious or not cooperating. The goal of security considerations described here is to provide sufficient protection for maintaining some security properties during the tracker-peer communication even in the face of a large number of malicious peers and/or distrustful trackers under the distributed deployment scenario. 7.1. Authentication between communicating tracker and peers To protect signaling from impersonation attackers, who pretend to be another peer rather than their authentic identities, certificates along with TLS/DTLS could be used to ensure that each message is sent from an authorized participant (tracker or peer) of the P2P streaming system. Specifically, when a peer enrolls in the system, a centralized enrollment server can help to issue a valid peer/tracker certificate. The enrollment server is expected to choose a proper PEER_ID for the requestor and certify the provided public key to the chosen PEER_ID in the form of a peer certificate. But the specification of enrollment and PEER_ID and certificate is out of scope in this draft. 7.2. Signaling protection between communicating tracker and peers To prevent signaling eavesdropping and manipulation, each message/ response between a peer and its connected tracker is confidentiality/ integrity protected by symmetric keys negotiated through TLS/DTLS mechanisms. 7.3. Content Integrity protection against polluting peers/trackers Malicious peers may declaim ownership of popular content to the tracker and serve polluted (i.e. decoy content or even virus instead of authentic content) later to other peers. This kind of pollution can be detected by incorporating a checksum distribution scheme for published sharing content. As content chunks of the same content are transferred independently and concurrently, correspondent chunk-level checksums MUST be distributed from an authentic origin. 7.4. Residual attacks and mitigation To mitigate the impact of sybil attacker, impersonating a large number of valid participants by repeatedly acquiring different peer Gu, et al. Expires March 30, 2012 [Page 27] Internet-Draft PPSP Tracker Protocol Sep 2011 certificates, the enrollment server SHOULD carefully regulate the rate of peer/tracker admission. There is no guarantee that a peer honestly report its status to the tracker, or server authentic content to other peers as it claims to the tracker. It is expected that a global trust mechanism, where each peer's credit is accumulated from evaluations for previous transactions and taken into account by other peers when selecting partner for future transactions, is helpful to mitigate the impact of such malicious behaviors. Globally trusted tracker MAY take part of the trust mechanism by collecting evaluations, computing credit values and providing them to joining peers through JOIN responses. 7.5. Pro-incentive parameter trustfulness In section Property types for STAT messages, a set of pro-incentive parameters are introduced, which can enable the tracker to improve the performance of the whole P2P streaming systems. Trustworthiness of these pro-incentive parameters is critical to the effectiveness of the incentive mechanisms. For example, ChunkMap defined above may be essential, and may need to be accurate. The P2P system should be designed in a way such that a peer will have the incentive to report truthfully its ChunkMap (otherwise it may penalize itself, as in the case of under-reporting addressed in [prTorrent]). Furthermore, both the amount of upload and download should be reported to the tracker to allow the tracker to check if there is any inconsistency between the upload and download report, and establish an appropriate credit/ trust system. Alternatively, exchange of cryptographic receipts signed by receiving peers can be used to attest to the upload contribution of a peer to the swarm, as was suggested in [Contracts]. 8. Implementation considerations Tracker protocol allows tracker to request statistics information from peers via STAT_QUERY message. Provided that such STAT_QUERY messages are sent to peers simultaneously or in a very short time frame, a specific situation may occur if the amount of peers is very large in the tracker domain. In such case, the "STAT_QUERY flooding" may induce transient overload on the signaling channel and increase the risk of channel congestion and congestion-caused packet loss. Moreover, the inverse STAT_REPORT messages make above situation worse, and burden the tracker. To address above issue, one potential approach is RECOMMENDED that tracker classes all peers in its domain into several virtual groups (e.g., based the characteristic and performance of peers) and sends STAT_QUERY messages to each group in turn. The STAT_QUERY Gu, et al. Expires March 30, 2012 [Page 28] Internet-Draft PPSP Tracker Protocol Sep 2011 transmission interval for each group depends on several factors such as bandwidth, amount of peers, characteristics of peers and the capability of tracker. The concrete algorithm to calculate the interval is an implementation manner and should be out of scope of this protocol. Similar to above approach used in STAT_QUERY and STAT_REPORT, KEEPALIVE also uses such approach to avoid congestion. The peers in the same virtual group should send KEEPALIVE messages simultaneously or in a short duration, and virtual groups send KEEPALIVE messages periodically and alternately. The KEEPALIVE transmission interval also depends on such factors, e.g., bandwidth, amount of peers etc. Given that some peers may reside behind a NAT and want to the NAT mapping maintain alive, the RECOMMENDED value for KEEPALIVE transmission interval SHOULD NOT exceed 90 seconds. 9. Acknowledgments We would like to acknowledgments to the following for their help and comments: Zhang Yunfei, Liao Hongluan, Roni Even, Bhumip Khasnabish, Wu Yichuan, Peng Jin, Chi Jing, Zong Ning, Song Haibin, Chen wei, Zhijia Chen, Christian Schmidt, Lars Eggert, David Harrington, Henning Schulzrinne, and Kangheng Wu. The fragmentation mechanism used in the binary protocol proposal, and some text describing it, was borrowed from [I-D.ietf-p2psip-base]. 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. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", April 2010. 10.2. Informative References [I-D.ietf-ppsp-problem-statement] Zhang, Y., Zong, N., Camarillo, G., Seng, J., and R. Yang, "PPSP Problem Statement". [I-D.ietf-ppsp-survey] Yingjie, G., Zong, N., Zhang, H., Zhang, Y., Lei, J., Gu, et al. Expires March 30, 2012 [Page 29] Internet-Draft PPSP Tracker Protocol Sep 2011 Camarillo, G., and L. Yong, "Survey of P2P Streaming Applications", draft-gu-ppsp-survey-02 (work in progress), March 2011. [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-12 (work in progress), November 2010. [I-D.ietf-ppsp-reqs] Zong, N., Zhang, Y., Avila, V., Williams, C., and L. Xiao, "P2P Streaming Protocol (PPSP) Requirements", draft-zong-ppsp-reqs-04 (work in progress), February 2011. [I-D.gu-ppsp-peer-protocol] Yingjie, G., Bryan, D., and L. Deng, "Peer Protocol", draft-gu-ppsp-peer-protocol-01 (work in progress), June 2011. [I-D.zeng-ppsp-protocol-pro-incentive-para-01] Zeng, W. and Y. Gu, "pro incentive para", October 2010. [Contracts] Piatek, M., , A., Venkataramani, A., Yang, R., Zhang, D., and A. Jaffe, "Contracts: Practical Contribution Incentives for P2P Live Streaming", April 2010. [prTorrent] Roy, S. and W. Zeng, "prTorrent: On Establishment of Piece Rarity in the BitTorrent Unchoking Algorithm", Sep. 2009. Authors' Addresses Gu Yingjie Huawei Phone: +86-25-56624760 Fax: +86-25-56624702 Email: guyingjie@huawei.com Gu, et al. Expires March 30, 2012 [Page 30] Internet-Draft PPSP Tracker Protocol Sep 2011 David A. Bryan Polycom P.O. Box 6741 Williamsburg, Virginia 23188 United States of America Phone: +1.571.314.0256 Email: dbryan@ethernot.org Deng Lingli China Mobile Phone: Email: denglingli@chinamobile.com Jinwei Xia Huawei Nanjing, Baixia District 210001 China Phone: +86-025-86622310 Email: xiajinwei@huawei.com Gu, et al. Expires March 30, 2012 [Page 31]