| TOC |
|
This document outlines the functionality required for a P2P streaming Tracker Protocol, including functional entities and architecture, and components. Additionally, it provides two strawman proposals for encoding the tracker information -- first using a binary protocol, and using an HTTP/XML based encoding.
This Tracker protocol is an application-level protocol for peers to register, 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.
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 (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1.
Introduction
2.
Document Conventions
2.1.
Notational Conventions
2.2.
Terminology
3.
Document History
4.
Protocol Overview
4.1.
Functional Entities
4.2.
Assumptions
4.2.1.
Bootstrapping
4.2.2.
NAT Traversal
4.3.
Description of the PPSP Tracker Protocol
4.3.1.
PPSP Tracker Protocol Methods
4.4.
Responses
4.4.1.
Response Bodies
5.
Message Syntax and Processing
5.1.
HTTP/XML Encoding
5.1.1.
Use of HTTP
5.1.2.
HTTP Encoding
5.1.2.1.
Method Field Encoding
5.1.3.
Common Message Processing
5.1.4.
CONNECT Messages
5.1.4.1.
Forming and Sending a CONNECT Message
5.1.4.2.
Recieving and Processing a CONNECT
Message
5.1.5.
DISCONNECT Messages
5.1.5.1.
Forming and Sending a DISCONNECT Message
5.1.5.2.
Recieving and Processing a DISCONNECT Message
5.1.6.
JOIN and JOIN_CHUNK Messages
5.1.6.1.
Forming and Sending a JOIN Message
5.1.6.2.
Forming and Sending a JOIN_CHUNK Message
5.1.6.3.
Recieving and Processing a JOIN or JOIN_CHUNK Message
5.1.7.
LEAVE Messages
5.1.7.1.
Forming and Sending a LEAVE Message
5.1.7.2.
Recieving and Processing a LEAVE Message
5.1.8.
FIND Messages
5.1.8.1.
Forming and Sending a FIND Message
5.1.8.2.
Recieving and Processing a FIND Message
5.1.9.
KEEPALIVE Messages
5.1.9.1.
Forming and Sending a KEEPALIVE Message
5.1.9.2.
Recieving and Processing a KEEPALIVE Message
5.1.10.
STAT Messages
5.1.10.1.
Property Types for STAT Messages
5.1.10.2.
Forming and Sending a STAT_REPORT Message
5.1.10.3.
Recieving and Processing a STAT_REPORT Message
5.1.10.4.
Forming and Sending a STAT_QUERY Message
5.1.10.5.
Recieving and Processing a STAT_QUERY Message
5.2.
Binary Encoding
5.2.1.
Common Message Header
5.2.1.1.
Method Field Encoding
5.2.2.
Timeout and Retransmission
5.2.3.
Fragmentation
5.2.4.
Common Message Processing
5.2.5.
CONNECT Messages
5.2.5.1.
Forming and Sending a CONNECT Message
5.2.5.2.
Recieving and Processing a CONNECT
Message
5.2.6.
DISCONNECT Messages
5.2.6.1.
Forming and Sending a DISCONNECT Message
5.2.6.2.
Recieving and Processing a DISCONNECT Message
5.2.7.
JOIN and JOIN_CHUNK Messages
5.2.7.1.
Forming and Sending a JOIN Message
5.2.7.2.
Forming and Sending a JOIN_CHUNK Message
5.2.7.3.
Recieving and Processing a JOIN or JOIN_CHUNK Message
5.2.8.
LEAVE Messages
5.2.8.1.
Forming and Sending a LEAVE Message
5.2.8.2.
Recieving and Processing a LEAVE Message
5.2.9.
FIND Messages
5.2.9.1.
Forming and Sending a FIND Message
5.2.9.2.
Recieving and Processing a FIND Message
5.2.10.
KEEPALIVE Messages
5.2.10.1.
Forming and Sending a KEEPALIVE Message
5.2.10.2.
Recieving and Processing a KEEPALIVE Message
5.2.11.
STAT Messages
5.2.11.1.
Property Types for STAT Messages
5.2.11.2.
Forming and Sending a STAT_REPORT Message
5.2.11.3.
Recieving and Processing a STAT_REPORT Message
5.2.11.4.
Forming and Sending a STAT_QUERY Message
5.2.11.5.
Recieving and Processing a STAT_QUERY Message
6.
Acknowledgments
7.
Revision History
7.1.
Changes since -00
8.
Open Issues and TODO
9.
References
9.1.
Normative References
9.2.
Informative References
§
Authors' Addresses
| TOC |
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. [TODO: Link to PPSP Problem Statement, currently expired] specifies that the Tracker protocol should standardize format/encoding of information and messages between PPSP peers and PPSP trackers. [I‑D.ietf‑ppsp‑reqs] (Zong, N., Zhang, Y., Avila, V., Williams, C., and L. Xiao, “P2P Streaming Protocol (PPSP) Requirements,” October 2010.) 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. [TODO: Link to to PPSP Problem Statement, currently expired] and [I‑D.ietf‑ppsp‑reqs] (Zong, N., Zhang, Y., Avila, V., Williams, C., and L. Xiao, “P2P Streaming Protocol (PPSP) Requirements,” October 2010.) describe a basic set of functions and high-level requirements, however, this draft introduces more detailed and specific ones. The signaling/control path corresponding to the functions is defined as well.
The main part of the draft is an abstract description of the operations required for a PPSP tracker protocol, as well as definitions for formal syntax, semantics, and detailed message processing instructions for the PPSP Peer Protocol, using two encodings -- a binary encoding and an HTTP/XML encoding. This include parameters, methods, and message formats. Most implemented P2P protocols are proprietary, as introduced in [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,” October 2010.) 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.
At present, this draft attempts to allow for both a BitTorrent style offline and real-time streaming protocol, but may currently be biased a bit toward the offline approach, since the decision of the WG is to use BitTorrent as a reference. Additionally, it currently attempts to support both a BitTorrent style gossip only approach (i.e., the tracker only knows about which peers are in a swarm, not which chunks they have) and a more centralized approach (where the tracker knows which chunks each peer stores. All these issues are for open discussion.
Please read the open issues in Section 8 (Open Issues and TODO) PRIOR to reading this draft, as it identifies a number of very critical open issues (and explains some of the numerous holes currently in this draft.)
| TOC |
| TOC |
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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
The draft uses the terms defined in [TODO: Link to PPSP Problem Statement, currently expired]
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 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
| TOC |
Changes from -01 to -02: The document has been updated to reflect that Peer-IDs will be returned, rather than the open issue of Peer-IDs or IP addresses. This is compatible with the proposal for a peer protocol in [I‑D.gu‑ppsp‑peer‑protocol] (Yingjie, G. and D. Bryan, “Peer Protocol,” July 2010.) that uses RELOAD for a mechanism for organizing peers and establishing connections. As RELOAD has solved the location and NAT traversal, this seems an appropriate design decision and reuse.
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.
| TOC |
| TOC |
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 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, and potentially to obtain a list of peers with the chunks they can provide. 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 |
| +===============+ |
| | CONNECT | |
| | DISCONNECT | |
| | JOIN | |
| | JOIN_CHUNK | |
| | LEAVE | |
| | FIND | |
| | KEEPALIVE | |
| | STAT_REPORT | |
| +===============+ |
+-------------------+
^
-----------*-------------
Tracker V
+-------------------+
|tracker signaling |
| |
| (JOIN/LEAVE/ |
| KEEPALIVE/PUT/ |
| GET/STAT_QUERY/ |
| STAT_REPORT) |
+-------------------+
| Figure 1: Tracker Protocol components |
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 |
| TOC |
| TOC |
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 require to do so. The specification of the mechanism used to obtain a Peer-ID and certificates is currently not discussed in this draft. OPEN ISSUE: Should we include a way to ask for a Peer-ID and/or certificates in the join request?
| TOC |
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. If RELOAD is used as the peer protocol, ICE ([RFC5245] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” April 2010.)) capabilities are included in peers, and either the RELOAD connection establishment mechanisms, or ICE by itself may be used for NAT traversal, if required, to reach trackers. Details of how this would be acomplished are well understood, and will be included in a future draft.
| TOC |
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).
Note that the tracker protocol does not actually exchange any data between the peers (either streaming of information in the live streaming case or offline information in the time shifted scenario.). Instead, the tracker maintains a list of peers participating in particular stream or having chunks of a particular session, and shares this information. Exchange of the data is negotiated and performed by the peer protocol.
The specific operations of the protocol are:
| TOC |
- CONNECT: Connect is the first method a peer performs. There is no relationship between peer and tracker before the CONNECT operation completes. Trackers will never serve a peer that has not connected. When a peer connects, the tracker records the peer's information, e.g. peer-ID, Connect-time, peer property, peer link status, etc. After connecting, the peer may send additional requests to the tracker to publish content availability, or obtain lists of peers with specific content from the tracker. A peer will first obtain a peer-ID and any required security certificates from an offline enrollment server prior to performing a CONNECT operation.
- OPEN ISSUE: Should we enable CONNECT to return a Peer-ID/certificates for those cases where the ID is not obtained out of band and we wish to have the tracker serve as the enrollment server?
- The CONNECT message should support passing a certificate that asserts the ownership of the ID, if an ID has already been issued. Until the group reaches consensus on a mechanism for the certificates, this has not yet been included in the encodings.
- The CONNECT message may need to contain information about support for caching (and later messages must be able to pass this information) The peer needs some way to indicate that the peer supports local caching and can provide uploading for other peers. (Open Question: Do we more detail about caching? What is cached? How does this work? Question of reachability for peers providing cache support to other peers.)
- DISCONNECT: When peer intends to leave the system and no longer will be participating, it sends a DISCONNECT message to the tracker. The tracker deletes the corresponding records related to the peer, including those in peer status and content status. After disconnecting, a peer can no longer make requests to the tracker, except to connect again, and information about the peer will not be provided to other peers.
- JOIN and JOIN_CHUNK: Peers use JOIN to notify a tracker they wish to participate in a particular swarm, but do not indicate particular chunks they possess. This may be used if the peer intends to use the peer protocol to convey the chunks, or because this is a live-streaming scenario. JOIN_CHUNK performs the same function, but with specific chunks listed, specifying which chunks of which swarms it presently stores. 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.
- 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. Note that this does NOT notify all peers that are currently connected to the peer -- this is an operation for the peer protocol. Additionally, note that a DISCONNECT implicitly leaves all swarms the peer is currently participating in -- there is no need for a peer that sends a DISCONNECT to send a separate LEAVE to the tracker for each swarm in which they are participating.
- 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. 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. In Live streaming, when receiving a FIND messages, the tracker also updates content status to involve the new peer under a specific channel. The FIND operation may specify a particular location within a stream and/or chunks that the peer is interested in.
- OPEN ISSUE: Should we have a FIND_CHUNK for this operation, for symmetry with the JOIN operations?
- Tracker can return candidate peer list in a single response message, or split the candidate peers into several peer list. Here is the consideration. 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 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.
- While the tracker protocol tries to make as few assumptions about the peer protocol as possible, in this location there is a need to understand some properties of the peer protocol. If a true peer protocol (for example RELOAD) is used, then the list of peers returned by the tracker will consist of peer-IDs. If a casual, unstructured protocol (for example a BitTorrent-like gossip protocol) is used, then returning IP addresses will be required. Note that this also has implications about the possible NAT traversal role that a tracker may need to perform.
- OPEN ISSUE: In BitTorrent, metadata about the particular file of information/swarm is encoded in a torrent file, which also provides information about the location of the tracker. This mechanism is NOT likely to be reused in this protocol, since we wish to allow various mechanisms for bootstrapping/locating the tracker. As a result, we must also pass the appropriate meta information about a swarm to the peers from the tracker. Should that be handled here, in the FIND operation (and perhaps passed back at the same time as the peerlist) or in a separate operation? If we want peers to be able to make multiple FIND calls for one swarm, the overhead of passing the metadata multiple times may imply we want a separate message.
- 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.
- STAT_REPORT: This method works in two directions. One is from Peer to Tracker which allows peers to submit statistic data to the tracker improve system performance. The other is from Tracker to Peer to notify the general information of the the whole PPSP system, e.g. the rarest chunks, the average downloading bandwidth, etc..
- STAT_QUERY: This method works in two directions. One is from Peer to Tracker which allows peers to query statistical information about the status of the system (and possibly about particular peers?) The other is from Tracker to Peers to request statistical information from a particular peer.
- Open Issue: How often shall the peer report its status? When make the decision, we should take the status updated through PUT and Keepalive message into account.
- STAT_QUERY: This method allows trackers to collect statistic data to improve system performance. STAT_QUERY is an optional method.
| TOC |
To correspond with the requests above, there are a number of logical responses to the messages that may be returned. For the binary encoding proposal, this would include malformed messages and requests/bodies. In the case of the HTTP/XML proposal, 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:
CONNECT, DISCONNECT, JOIN, JOIN_CHUNK, KEEPALIVE and STAT_REPORT return any required status information about the successfully completed operation.
FIND returns the list of peers meeting the desired criteria. Additionally, metadata about the swarm may be returned as described above.
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 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)
| TOC |
Responses may contain peer lists, statistical information, and meta data. At the current time, the authors have not defined a specific format for this information, but expect that a reasonable encoding format may be XML. As a result, It may be possible to reuse encodings, particularly for statistical information and metadata, from other protocols or standards organizations.
TO DO: Define detailed formats for the payload of responses.
| TOC |
There are two options to encode a PPSP Tracker Protocol: a binary encoding or some sort of ASCII encoding such as XML bodies conveyed in HTTP. Both have pros and cons. ASCII is easier for people to understand, but requires more space and bandwidth. Binary protocols are lighter in both bandwidth and processing, though are sometimes considered more difficult to understand.
Note: this is an open issue for the WG to discuss and make a determination. No matter which one is chosen, many of the basic design principles, including communication methods and terminology presented in this draft may be applicable.
These encodings are currently rather skeletal. For example, while we offer mechanisms to encode particular chunks, we do not currently define a mechanism to encode the position (offset) for a stream. Until the WG has made more decisions about specific encoding, these encodings/processing rules are provided primarily to provide a starting point for discussion, and as such are missing some essential features. The authors will extend (and prune, in the case of two encodings) and refine the protocol as the WG makes specific decisions about design of the protocol.
| TOC |
Retransmission and fragmentation are handled by HTTP, and are not defined discussed in the HTTP encoding.
The current encoding is a very, 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.
| TOC |
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 model to be defined later. This basic approach is subject to change.
| TOC |
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.
<PPSPTrackerProtocol version="***"> <Method>***</Method> <Response>***</Response> <TransactionID>***</TransactionID> ...Method specific xml information... </PPSPTrackerProtocol>
| 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.2.1.1 (Method Field Encoding). 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.2.1.1 (Method Field Encoding). 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.
| TOC |
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. Note that currently, the strings for each request are identical to the name of the operation defined in Section 4.3.1 (PPSP Tracker Protocol Methods)
| PPSP Request | PPSP Request Method String |
|---|---|
| CONNECT | CONNECT |
| DISCONNECT | DISCONNECT |
| JOIN | JOIN |
| JOIN_CHUNK | JOIN_CHUNK |
| LEAVE | LEAVE |
| FIND | FIND |
| KEEPALIVE | KEEPALIVE |
| STAT_QUERY | STAT_QUERY |
| STAT_REPORT | STAT_REPORT |
| Table 1: Valid Strings for Requests |
| Response Method Name | HTTP Response Mechanism | XML Response Value |
|---|---|---|
| SUCCESSFUL (OK) | 200 OK | OK |
| INVALID SYNTAX | 400 Bad Request | INVALID SYNTAX |
| VERSION NOT SUPPORTED | 400 Bad Request | VERSION NOT SUPPORTED |
| MESSAGE NOT SUPPORTED | 403 Forbidden | MESSAGE NOT SUPPORTED |
| TEMPORARILY OVERLOADED | 503 Service Unavailable | TEMPORARILY OVERLOADED |
| INTERNAL ERROR | 500 Internal Server Error | INTERNAL ERROR |
| MESSAGE FORBIDDEN | 403 Forbidden | MESSAGE FORBIDDEN |
| OBJECT NOT FOUND | 404 Not Found | OBJECT NOT FOUND |
| AUTHENTICATION REQUIRED | 401 Unauthorized | AUTHENTICATION REQUIRED |
| PAYMENT REQUIRED | 402 Payment Required | PAYMENT REQUIRED |
| 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)
| TOC |
When a PPSP Peer 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 received 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.
| TOC |
The CONNECT message is sent when a peer wishes to join a system and connect to the tracker. Note that a peer must have obtained a Peer-ID via an out-of-band mechanism. The CONNECT procedure follows the general rules described below:
- 1)
- A CONNECT message is sent from the new peer to the tracker, indicating the desire to connect;
- 2)
- A response is generated by the tracker indicating success, failure, or some condition that must be satisfied to succeed (for example, providing credentials).
| TOC |
To form a CONNECT Message, the sender constructs the common message XML. The sender MUST properly form the XML, set the Method attribute to CONNECT, and randomly generate and set the Transaction ID. The method specific information formed as discussed below.
The method specific XML of the CONNECT message takes the form shown below:
<PeerID>###</PeerID>
| Figure 4: CONNECT Method
Specific XML |
The PeerID of the body MUST be set to the PeerID of the peer. This reports that the peer is connecting.
| TOC |
TODO: There will be extensive processing to be performed here, but this is largely tied to the security and authentication model, which is TBD by the WG.
| TOC |
| TOC |
To form a DISCONNECT Message, the sender constructs the common message XML. The sender MUST properly form the XML, set the Method attribute to DISCONNECT, and randomly generate and set the Transaction ID. The method specific information formed as discussed below.
The method specific XML of the DISCONNECT message takes the form shown below:
<PeerID>###</PeerID>
| Figure 5: DISCONNECT Method
Specific XML |
The PeerID of the body MUST be set to the PeerID of the peer. This reports that the peer is disconnecting, and implicitly informs the tracker that the peer is no longer involved in any swarms.
| TOC |
Upon receiving a DISCONNECT message, the tracker MUST remove the peer from the peer list. It will honor no more requests from the peer unless the peer CONNECTs again. In addition, it will not provide the peer in response to GETs in the future. The tracker MUST remove the peer from all swarms as if a LEAVE was received for each swarm in which the peer is currently participating.
Open Issue / Implementation Detail: One consequence of this design is that you will need to have a mapping of what swarms the peer is in, so that you can remove it from all those swarm lists (assuming that a local index of swarms->peers is stored, which for fast lookup seems essential.
| TOC |
The JOIN messages (JOIN and JOIN_CHUNK) are 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). JOIN_CHUNK is used when the peer wishes to provide a detailed list of chunks or a position in the stream to the tracker.
TODO: We do not yet have a mechanism to represent a position in a stream, but currently only encode chunks. This gives an idea of what the protocol would look like, but a more detailed version encoding position will also be required.
| TOC |
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 information formed as discussed below.
The method specific XML of the JOIN message takes the form shown below:
<PeerID>###</PeerID> <SwarmID>###</SwarmID> <ExpireTime>###</ExpireTime>
| 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.
Open Issue: Do we want/need to specify something here specifying how much of the swarm we have downloaded, akin to the "uploaded" "downloaded" and "left" fields in BitTorrent? If so, have to consider what the meaning of these fields are in a streaming context, where one would potentially have a sliding window of chunks.
| TOC |
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. The method specific information formed as discussed below.
The method specific XML of the JOIN_CHUNK message takes the form shown below:
<PeerID>###</PeerID>
<SwarmID>###</SwarmID>
<ExpireTime>###</ExpireTime>
<Chunks>
<ChunkID>###<ChunkID>
... more chunk IDs ...
</Chunks>
| Figure 7: JOIN_CHUNK Method Specific XML |
As with a JOIN 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.
Following these fields, one or more 32 bit ChunkID fields are provided. (Note that in the binary encoding only 30 bits are available for actual ChunkID, but in this case, all 32 bits are available)
| TOC |
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 (Method Field Encodings for Responses). 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.
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. An alternative way is for Tracker to dynamically communicate a candidate peers' chunk availability. In a VOD swarm, 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.
| TOC |
The LEAVE message is used by the Peer to inform the Tracker that it no longer wishes to participate in a particular swarm.
| TOC |
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:
<PeerID>###</PeerID> <SwarmID>###</SwarmID>
| 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 in.
| TOC |
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 (Method Field Encodings for Responses). 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 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.
| TOC |
| TOC |
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 information formed as discussed below.
The method specific XML of the FIND message takes the form shown below:
<PeerID>###</PeerID> <SwarmID>###</SwarmID> <ChunkID>###</ChunkID>
| Figure 9: 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 or a higher value. If the peer is interested in any chunks, the peer MUST set the value of the Chunk ID to all zero.
Open Issue: Using the chunkID this way (return if equal or higher) implicitly assumes that ChunkIDs are increasing. Is this a valid assumption? Additionally, support must be added for location in a stream, as well as chunks.
Open Issue: Do we want to have a number of peers to request, as in Bit Torrent?
Open Issue: We need some mechanism to specify a peer property of some sort. For example, peers with a particular bandwidth (obtained by the tracker from an ALTO server), processing power, etc.
| TOC |
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 (Method Field Encodings for Responses). 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 will search the internal data store for the requested data and if found will respond with an HTTP 200 OK SUCCESS message response with a PPSP XML payload SUCCESSFUL. 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:
<SwarmID>###</SwarmID>
<Peers>
Peer list (SEE BELOW)
</Peers>
| Figure 10: FIND Response XML |
The SwarmID MUST be set to the swarm to which the chunks belong.
The peer list consists of a list of one or more Peer-IDs, based on RELOAD. The requesting peer can find and establish connection with the candidate peers by routing through the overlay, using mechanisms built into RELOAD.
Open issue: Which information beyond simply the Peer-ID is included in the Peerlist? Likely want to optionally be able to carry additional information that can be used to decide which peers to connect to.
Open Issue: Do we need an expiry time? If peers will share peer lists with one another, this could be useful, but of course, there is no way the tracker can really know this -- i.e., a peer could leave at any time.
| TOC |
| TOC |
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 information formed as discussed below.
The method specific XML of the KEEPALIVE message takes the form shown below:
<PeerID>###</PeerID>
| Figure 11: KEEPALIVE Method
Specific XML |
The PeerID of the body MUST be set to the PeerID of the peer
Open Issue: Need to set congestion state and link status here. Should we use the same XML structure used below for STATS? Can we send additional information besides this?
| TOC |
TODO: What is the behavior on getting back a KEEPALIVE? Obviously we should update an internal timer that we have heard from the peer, but do we stop sending the peer out as a suggestion if it reports congestion? Is this an attack for leeches (In other words, can I report I am in congestion and keep others from using me to obtain data?)
| TOC |
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.
| TOC |
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. These values are intended as examples for discussion only.
| 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 |
Open Issue: Also need to define a content description -- i.e., a way to prompt to peer to send a list of the chunks it stores. Do we do this with values, or specify that if a stat request for that is received, it causes the peer to generates JOIN_CHUNK messages?
| TOC |
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 information formed as discussed below.
The method specific XML of the STAT_REPORT message takes the form shown below:
<PeerID>###</PeerID>
<Stats>
<Stat property="***">***</Stat>
... more stats ...
</Stats>
| Figure 12: 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 (Sample Property Types for STAT messages) and an appropriate value provided.
| TOC |
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.
| TOC |
To form a STAT_QUERY Message, the sender constructs the common message XML. The sender MUST properly form the XML, set the Method attribute to STAT_QUERY, and randomly generate and set the Transaction ID. The method specific information formed as discussed below.
The method specific XML of the STAT_QUERY message takes the form shown below:
<StatRequest>
<Stat property="***"></Stat>
... more stats ...
</Stats>
| Figure 13: STAT_QUERY Method
Specific XML |
Each Stat in the StatRequest MUST have the property set as defined in Table 3 (Sample Property Types for STAT messages) and MUST NOT have any value.
| TOC |
When a STAT_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:
<PeerID>###</PeerID>
<Stats>
<Stat property="***">***</Stat>
... more stats ...
</Stats>
| Figure 14: STAT_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 (Sample Property Types for STAT messages) and an appropriate value provided.
| TOC |
Considering that peers may communicate with the tracker frequently, and that streaming applications are sensitive to delay, we also present a binary encoding when designing the PPSP Tracker protocol.
This section provides detailed a normative definition of the binary encoding of the messages. All messages are encoded using a binary encoding. All integers are represented in network byte order and are presented in base 10, decimal, unless otherwise noted in this draft.
Tracker protocol messages are comprised of two parts: a shared, fixed length message header, and message bodies, which differ for each type of message.
Message header: contains information common to all messages: the protocol token, protocol version, length, fragmentation header, transaction ID, and method. The header is fixed in length and has fixed locations for the fields, allowing messages to be quickly processed without examining the message contents.
Message body: Message body is not in a fixed format, but varies for each message type. Interpreting the body requires knowing the message type, obtained from the message header.
| TOC |
The format of the shared message header is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPSP Tracker Protocol Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved | Method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragmentation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 15: Common Message Header |
The fields in the header are:
- PPSP Tracker Protocol Token:
- A fixed token indicating to the receiver this message is a PPSP Tracker Protocol message. The token field is four bytes long. This value MUST be set to 0xd0505374, the string "PPSt" with the highest order bit of the first byte set. (OPEN ISSUE: If the peer protocol uses the same encoding, this should be set to just PPSP or something else more generic.)
- 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. The version field is one byte long.
- Method:
- Indicates the method type for the message. The Method field is two bytes long. Method types are defined below in Section 5.2.1.1 (Method Field Encoding)
- Transaction ID:
- A unique 64 bit number 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. Transaction IDs are also used for fragment reassembly.
- Fragmentation:
- The fragmentation mechanism is described in more detail in Section 5.2.3 (Fragmentation).
- Message Length:
- The length of the message, including header, in bytes. The length field is four bytes long. Note if the message is fragmented, this is the length of this message, not the total length of all assembled fragments.
- Reserved:
- Not to be assigned. Reserved values are held for special uses, such as to extend the namespace when it become exhausted. Reserved values are not available for general assignment.
| TOC |
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 encoded in a one byte field in the message header. The first bit of this field indicates if the message is a request (first byte set to 0) or response (first byte set to 1). The next three bits in the first byte are presently reserved and MUST be set to 0, and the following four bytes are set to binary 1000 to indicate the message is a tracker protocol message. (NOTE: May wish to use this to encode peer protocol messages later) As a result, the first byte of all requests MUST be 0x08 and the first byte of all responses MUST be 0x88.The remaining byte in the field is used to indicate which request or response method is being used.
The tables below define the method field encodings for the requests and responses. OPEN QUESTION: Do we want to encode more information into the bits? In other words, do we want the first two bit of the response to indicate success/provisional/fail or the first two of the request to indicate category, or something similar? Currently, this is done in the responses -- 880? for success, 88F? for errors, 881? For non-error responses
| Request Method Name | Method Field Value |
|---|---|
| CONNECT | 0x0800 |
| DISCONNECT | 0x0801 |
| JOIN | 0x0802 |
| JOIN_CHUNK | 0x0803 |
| LEAVE | 0x0804 |
| FIND | 0x0805 |
| KEEPALIVE | 0x0806 |
| STAT_QUERY | 0x0807 |
| STAT_REPORT | 0x0808 |
| Table 4: Method Field Encodings for Requests |
| Response Method Name | Method Field Value |
|---|---|
| SUCCESSFUL (OK) | 0x8800 |
| INVALID SYNTAX | 0x88F0 |
| VERSION NOT SUPPORTED | 0x88F1 |
| MESSAGE NOT SUPPORTED | 0x88F2 |
| TEMPORARILY OVERLOADED | 0x88F3 |
| INTERNAL ERROR | 0x88F4 |
| MESSAGE FORBIDDEN | 0x8810 |
| OBJECT NOT FOUND | 0x8811 |
| AUTHENTICATION REQUIRED | 0x8812 |
| PAYMENT REQUIRED | 0x8813 |
| Table 5: Method Field Encodings for Responses |
| TOC |
TODO: A reasonable timeout and retransmission mechanism needs to be incorporated here.
| TOC |
OPEN ISSUE: We have borrowed the RELOAD fragmentation for now, but this is up for debate. Currently, there is no fragment-by-fragment retransmission, and no way to know in advance how many fragments there are (although the offset allows detection of missing fragments). Additionally, if these messages are not used for peer traffic, an end-to-end PMTU discovery might make sense to determine total fragment length. Similarly, need to decide on an optimal retransmission time for this protocol. Finally, with this approach, messages are effectively limited to 2^24 + (PMTU - 32), which may be insufficient. While it seems likely, we may want to discuss if this is sufficient in this context.
As messages transmitted by the PPSP Tracker Protocol can be very large, and may be transported over unreliable transports, a robust fragmentation mechanism is required. We have opted to reuse the mechanism described in [I‑D.ietf‑p2psip‑base] (Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, “REsource LOcation And Discovery (RELOAD) Base Protocol,” October 2010.). Portions of the processing description in this section were borrowed from this document.
Any message sent MAY be fragmented. Each message that is fragmented MUST include a full copy of the shared message header. Each fragment When a message must be fragmented, it SHOULD be split into equal-sized fragments that are no larger than the PMTU of the next network link minus 32 bytes.
Upon receipt of a fragmented message by the intended peer, the peer holds the fragments in a holding buffer until the entire message has been received. The message is then reassembled into a single message and processed. In order to mitigate denial of service attacks, receivers SHOULD time out incomplete fragments after maximum request lifetime (15 seconds). (OPEN ISSUE: Timeout is borrowed from RELOAD, see comment above) If the receiver runs out of buffer space to reassemble the messages it MUST drop the message.
When a message is fragmented, the fragment offset value is stored in the lower 24 bits of the fragment field of the shared header. The offset is the number of bytes between the end of the forwarding header and the start of the data. The first fragment therefore has an offset of 0. The first and last bit indicators MUST be appropriately set. If the message is not fragmented, then both the first and last fragment are set to 1 and the offset is 0 resulting in a fragment value of 0xC0000000.
After fully assembling the message, processing occurs normally, as described below.
| TOC |
When a PPSP Peer 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 initial check MUST verify that the common header is properly formed and that the message length matches the length encoded in the common message header. 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 INVALID SYNTAX response.
The common message header 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 a VERSION NOT SUPPORTED message.
The common message header 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 a MESSAGE NOT SUPPORTED message.
If the receiver is unable to process the message at this time because it is in an overloaded state, a TEMPORARILY OVERLOADED message SHOULD be returned to the sender, indicating that the message is not able to be processed at this time. Note that a server may not be able to generate such a message if it is truly overloaded, so senders MUST also rely on the timeout mechanisms described in Section 5.2.2 (Timeout and Retransmission).
If the receiver encounters an internal error while attempting to process the message, the receiver MUST generate an INTERNAL ERROR message indicating this has occurred.
| TOC |
The CONNECT message is sent when a peer wishes to join a system and connect to the tracker. Note that a peer must have obtained a Peer-ID via an out-of-band mechanism. The CONNECT procedure follows the general rules described below:
- 1)
- A CONNECT message is sent from the new peer to the tracker, indicating the desire to connect;
- 2)
- A response is generated by the tracker indicating success, failure, or some condition that must be satisfied to succeed (for example, providing credentials).
| TOC |
To form a CONNECT Message, the sender constructs the common message header. The sender MUST properly set the PPSP Tracker Protocol Token and Version fields. The sender MUST set the Method field to CONNECT, and randomly generate and set the Transaction ID. The body of the message is then formed as discussed below, and the Message Length and Fragmentation (if required) fields set.
The body of the CONNECT message takes the form shown below:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PeerID (160 bits...) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 16: CONNECT Message Body |
The PeerID of the body MUST be set to the PeerID of the peer. This reports that the peer is connecting.
| TOC |
TODO: There will be extensive processing to be performed here, but this is largely tied to the security and authentication model, which is TBD by the WG.
| TOC |
| TOC |
To form a DISCONNECT Message, the sender constructs the common message header. The sender MUST properly set the PPSP Tracker Protocol Token and Version fields. The sender MUST set the Method field to DISCONNECT, and randomly generate and set the Transaction ID. The body of the message is then formed as discussed below, and the Message Length and Fragmentation (if required) fields set.
The body of the DISCONNECT message takes the form shown below:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PeerID (160 bits...) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 17: DISCONNECT Message Body |
The PeerID of the body MUST be set to the PeerID of the peer. This reports that the peer is disconnecting, and implicitly informs the tracker that the peer is no longer involved in any swarms.
| TOC |
Upon receiving a DISCONNECT message, the tracker MUST remove the peer from the peer list. It will honor no more requests from the peer unless the peer CONNECTs again. In addition, it will not provide the peer in response to GETs in the future. The tracker MUST remove the peer from all swarms as if a LEAVE was received for each swarm in which the peer is currently participating.
Open Issue / Implementation Detail: One consequence of this design is that you will need to have a mapping of what swarms the peer is in, so that you can remove it from all those swarm lists (assuming that a local index of swarms->peers is stored, which for fast lookup seems essential.
| TOC |
The JOIN messages (JOIN and JOIN_CHUNK) are 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). JOIN_CHUNK is used when the peer wishes to provide a detailed list of chunks or a position in the stream to the tracker.
TODO: We do not yet have a mechanism to represent a position in a stream, but currently only encode chunks. This gives an idea of what the protocol would look like, but a more detailed version encoding position will also be required.
| TOC |
To form a JOIN Message, the sender constructs the common message header. The sender MUST properly set the PPSP Tracker Protocol Token and Version fields. The sender MUST set the Method field to JOIN, and randomly generate and set the Transaction ID. The body of the message is then formed as discussed below, and the Message Length and Fragmentation (if required) fields set.
The body of the JOIN message takes the form shown below:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PeerID (160 bits...) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SwarmID (128 bits...) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Expiration Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 18: JOIN Message Body |
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.
Open Issue: Do we want/need to specify something here specifying how much of the swarm we have downloaded, akin to the "uploaded" "downloaded" and "left" fields in BitTorrent? If so, have to consider what the meaning of these fields are in a streaming context, where one would potentially have a sliding window of chunks.
| TOC |
To form a JOIN_CHUNK Message, the sender constructs the common message header. The sender MUST properly set the PPSP Tracker Protocol Token and Version fields. The sender MUST set the Method field to JOIN_CHUNK, and randomly generate and set the Transaction ID. The body of the message is then formed as discussed below, and the Message Length and Fragmentation (if required) fields set.
The body of the JOIN message takes the form shown below:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PeerID (160 bits...) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SwarmID (128 bits...) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Expiration Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NumChunks | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk ID | S | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Additional Chunk IDs ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 19: JOIN_CHUNK Message Body |
As with a JOIN 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.
Following these fields, one or more 32 bit ChunkID fields are encoded. Prior to the list of chunks, the 16 bit NumChunks field MUST be set to how many chunks follow (not the length in bytes of the chunk list). For each ChunkID, The first 30 bits of each ChunkID is a numerical value indicating each chunk's ID. The method of assigning these (starting at zero, continuous or random) is left to the implementation. The final two bits are used to indicate continuation, used as a compact notation to indicate a sequence of chunks. If the chunkID does not represent a range, but only a single chunk, this field MUST be set to 00. If the chunkID is the beginning of a range, this field MUST be set to 01, and if it is the end of a range, this field MUST be set to 10. Ranges MUST be specified in pairs. That is, a range MUST consist of two ChunkIDs, the first with 01 and the second with 10. Ranges MUST be continuous and increasing.
| TOC |
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 5 (Method Field Encodings for Responses). 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 INVALID syntax response if the message is malformed. If the message is well formed and accepted, the tracker enters the information into the internal data store, and respond with a SUCCESSFUL message response.
The response MUST have the same Transaction ID as the request, and MUST not contain any additional body information.
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. An alternative way is for Tracker to dynamically communicate a candidate peers' chunk availability. In a VOD swarm, 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.
| TOC |
The LEAVE message is used by the Peer to inform the Tracker that it no longer wishes to participate in a particular swarm.
| TOC |
To form a LEAVE Message, the sender constructs the common message header. The sender MUST properly set the PPSP Tracker Protocol Token and Version fields. The sender MUST set the Method field to LEAVE, and randomly generate and set the Transaction ID. The body of the message is then formed as discussed below, and the Message Length and Fragmentation (if required) fields set.
The body of the LEAVE message takes the form shown below:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PeerID (160 bits...) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SwarmID (128 bits...) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 20: LEAVE Message Body |
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 in.
| TOC |
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 5 (Method Field Encodings for Responses). If the tracker accepts the message, it MUST verify the fields are properly formed and MUST reject the message with an INVALID syntax response if the message is malformed. 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 a SUCCESSFUL message response. 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.
| TOC |
| TOC |
To form a FIND Message, the sender constructs the common message header. The sender MUST properly set the PPSP Tracker Protocol Token and Version fields. The sender MUST set the Method field to FIND, and randomly generate and set the Transaction ID. The body of the message is then formed as discussed below, and the Message Length and Fragmentation (if required) fields set.
The body of the FIND message takes the form shown below:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PeerID (160 bits...) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SwarmID (128 bits...) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 21: FIND Message Body |
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 or a higher value. If the peer is interested in any chunks, the peer MUST set the value of the Chunk ID to all zero.
Open Issue: Using the chunkID this way (return if equal or higher) implicitly assumes that ChunkIDs are increasing. Is this a valid assumption? Additionally, support must be added for location in a stream, as well as chunks.
Open Issue: Do we want to have a number of peers to request, as in Bit Torrent?
Open Issue: We need some mechanism to specify a peer property of some sort. For example, peers with a particular bandwidth (obtained by the tracker from an ALTO server), processing power, etc.
| TOC |
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 5 (Method Field Encodings for Responses). If the tracker accepts the message, it MUST verify the fields are properly formed and MUST reject the message with an INVALID syntax response if the message is malformed. If the message is well formed and accepted, the tracker will search the internal data store and return a match if found, and respond with a SUCCESSFUL message response.
The response MUST have the same Transaction ID as the request
The FIND response MUST include a body of the form below:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SwarmID (128 bits...) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NumPeers | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer List (SEE BELOW) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 22: FIND Response Body |
The SwarmID MUST be set to the swarm to which the chunks belong, and NumPeers MUST be set to the number of Peers being returned (NOT the length of the list). If no peers are in the swarm, this length MUST be set to zero and no peers will follow in the list.
The peer list consists of a list of one or more RELOAD Peer-IDs, based on RELOAD. The requesting peer can find and establish connection with the candidate peers by routing through the overlay, using mechanisms built into RELOAD.
Open issue: Which information beyond simply the Peer-ID is included in the Peerlist? Likely want to optionally be able to carry additional information that can be used to decide which peers to connect to.
Open Issue: Do we need an expiry time? If peers will share peer lists with one another, this could be useful, but of course, there is no way the tracker can really know this -- i.e., a peer could leave at any time.
Open issue: Which information should be carried as Peer List, Peer Address or Peer ID? This issue has close relationship with Peer Protocol.
| TOC |
| TOC |
To form a KEEPALIVE Message, the sender constructs the common message header. The sender MUST properly set the PPSP Tracker Protocol Token and Version fields. The sender MUST set the Method field to KEEPALIVE, and randomly generate and set the Transaction ID. The body of the message is then formed as discussed below, and the Message Length and Fragmentation (if required) fields set.
The body of the KEEPALIVE message takes the form shown below:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PeerID (160 bits...) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 23: KEEPALIVE Message Body |
The PeerID of the body MUST be set to the PeerID of the peer
Open Issue: Need to set congestion state and link status here. Should we use the same Property type TLV structure used below for STATS? Can we send additional information besides this?
| TOC |
TODO: What is the behavior on getting back a KEEPALIVE? Obviously we should update an internal timer that we have heard from the peer, but do we stop sending the peer out as a suggestion if it reports congestion? Is this an attack for leeches (In other words, can I report I am in congestion and keep others from using me to obtain data?)
| TOC |
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.
| TOC |
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. These values are intended as examples for discussion only.
| P-Type | Definitions/Description |
|---|---|
| 0x0000 | Caching size: available size for caching |
| 0x0001 | Bandwidth: available bandwidth |
| 0x0002 | Link numbers: acceptable links for remote peer |
| 0x0003 | Certificate: certificate of the peer |
| 0x0004 | NAT/Firewall: peer believes it is behind NAT (Property Value field is empty) |
| 0x0005 | STUN: peer supports STUN service (Property Value is empty) |
| 0x0006 | TURN: peer supports TURN service (Property Value is empty) |
| 0x0007 | Sum Volume: Sum of bytes of data peers received from the steaming system |
| 0x0008 | Access Mode: ADSL/Fiber/GPRS/3G/LTE/WiFi etc. |
| 0x0009 | End Device: STB/PC/MobilePhone |
| 0x000A | Available Battery Level |
| Table 6: Sample Property Types for STAT messages |
If the Property Value is Empty, the value is a boolean flag, the presence of which indicates true.
Open Issue: Also need to define a content description -- i.e., a way to prompt to peer to send a list of the chunks it stores. Do we do this with values, or specify that if a stat request for that is received, it causes the peer to generates JOIN_CHUNK messages?
| TOC |
To form a STAT_REPORT Message, the peer constructs the common message header. The sender MUST properly set the PPSP Tracker Protocol Token and Version fields. The sender MUST set the Method field to STAT_REPORT, and randomly generate and set the Transaction ID. The body of the message is then formed as discussed below, and the Message Length and Fragmentation (if required) fields set.
The body of the STAT_REPORT message takes the form shown below:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PeerID (160 bits...) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NumStats | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | STAT TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Additional STAT TLVs ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 24: STAT_REPORT Message Body |
The PeerID of the body MUST be set to the PeerID of the peer. Following this field, NumStats reports on the number of STAT TLV structures (NOT the length of them) to follow, followed by zero or more variable length STAT TLV structures follow. The structure of the STAT TLVs is as follows:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P_Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Property Value . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 25: TLV Format of Peer Property |
The value of P_TYPE is as defined above, and the length is the length of the Property Value in bits (limiting values to 8K). For P_TYPES where value field is defined as empty, the length is set to zero
The peer creates a list of properties it wishes to share with the tracker, assembles them into a message and transmits the message to the tracker.
| TOC |
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.
| TOC |
To form a STAT_QUERY Message, the tracker constructs the common message header. The sender MUST properly set the PPSP Tracker Protocol Token and Version fields. The sender MUST set the Method field to STAT_QUERY, and randomly generate and set the Transaction ID. The body of the message is then formed as discussed below, and the Message Length and Fragmentation (if required) fields set.
The body of the STAT_QUERY message takes the form shown below:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NumP_Types | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P_Type | ... Additional P_Types ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Additional P_Types ... | Reserved (for odd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 26: STAT_QUERY Message Body |
NumP_Types encodes the number of P_Types NOT the length of them to follow. Following this, zero or more P_Types that the tracker would like the peer to report on are listed. Note that since these are requests, these are not TLVs, but simply a list of the Parameter types the tracker is requesting information on. If the number of P_Types requested is odd, a reserved empty field is included at the end of the list to preserve 32 bit alignment. OPEN ISSUE: This is the only place in the protocol where we don't have alignment at 32 bit intervals. Should we have a reserved field after each P_type? Is there a need to actually included the reserved field?
| TOC |
When a STAT_QUERY message is received by the peer, it MUST respond, using one of the response codes defined above. The body contains one TLV for each requested statistic:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PeerID (160 bits...) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NumStats | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | STAT TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Additional STAT TLVs ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 27: STAT_QUERY Response Body |
The PeerID of the body MUST be set to the PeerID of the peer. Following this field, NumStats reports on the number of STAT TLV structures (NOT the length of them) to follow, followed by zero or more variable length STAT TLV structures follow. The structure of the STAT TLVs is as defined in Figure 25 (TLV Format of Peer Property)
| TOC |
We would like to acknowledgments to the following for their help and comments: Roni Even, Bhumip Khasnabish, Wu Yichuan, Peng Jin, Chi Jing, Zong Ning, Song Haibin, Zhijia Chen, Christian Schmidt, Kangheng Wu, Henning Schulzrinne and Lars Eggert.
The fragmentation mechanism used in the binary protocol proposal, and some text describing it, was borrowed from [I‑D.ietf‑p2psip‑base] (Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, “REsource LOcation And Discovery (RELOAD) Base Protocol,” October 2010.).
| TOC |
| TOC |
| TOC |
Need to decide if an HTTP/XML or a binary encoding the optimal encoding for this protocol.
Do we want a mechanism to obtain Peer-IDs in join? Details would need to be specified
Need to expand NAT traversal section, documenting how ICE and/or the RELOAD connect mechanism would be used.
Need to better decide and address issue of tracker promotion and distributed tracker
Need to decide what additional information may be needed in the Peerlist, and how to encode this information.
Need to document the retransmission mechanism for the binary protocol.
Need to determine the correct encoding for the metadata, and determine if this should be returned within the FIND message, or if it should instead be returned in a new message.
Security (i.e., how to verify you are really a participant, securing the messages, etc.) is not currently covered. It is anticipated that a public certificate scheme will be used, but this must be properly specified in a final protocol.
Bit Torrent uses a Tracker ID as well, but it isn't clear if one is needed here. Comments on this would be appreciated.
Do we need to handle wrapping of chunk IDs? Discussion of global/local uniqueness of these IDs.
Need to define timeout and expire, discuss how KEEPALIVE or periodic PUTs address this.
| TOC |
| TOC |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC5245] | Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” RFC 5245, April 2010 (TXT). |
| TOC |
| [I-D.gu-ppsp-peer-protocol] | Yingjie, G. and D. Bryan, “Peer Protocol,” draft-gu-ppsp-peer-protocol-00 (work in progress), July 2010 (TXT). |
| [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 (TXT). |
| [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 (TXT). |
| [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 (TXT). |
| TOC |
| Yingjie Gu | |
| Huawei | |
| Baixia Road No. 91 | |
| Nanjing, Jiangsu Province 210001 | |
| P.R.China | |
| Phone: | +86-25-84565868 |
| Email: | guyingjie@huawei.com |
| David A. Bryan | |
| Cogent Force, LLC / Huawei | |
| P.O. Box 6741 | |
| Williamsburg, Virginia 23188 | |
| United States of America | |
| Phone: | +1.571.314.0256 |
| Email: | dbryan@ethernot.org |
| Zhang Yunfei | |
| China Mobile | |
| Phone: | |
| Email: | zhangyunfei@chinamobile.com |
| Liao Hongluan | |
| China Mobile | |
| Phone: | |
| Email: | liaohongluan@chinamobile.com |