PPSP Y. Gu
Internet-Draft Huawei
Intended status: Standards Track David A. Bryan
Expires: September 15, 2011 Cogent Force, LLC
Y. Zhang
H. Liao
China Mobile
March 11, 2011
PPSP Tracker Protocol
draft-gu-ppsp-tracker-protocol-03
Abstract
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.
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 September 15, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
Gu, et al. Expires September 15, 2011 [Page 1]
Internet-Draft PPSP Tracker Protocol March 2011
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Gu, et al. Expires September 15, 2011 [Page 2]
Internet-Draft PPSP Tracker Protocol March 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Document History . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Function Entities . . . . . . . . . . . . . . . . . . . . 6
4.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Bootstrapping . . . . . . . . . . . . . . . . . . . . 8
4.2.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . 9
4.3. Description of the PPSP Tracker Protocol . . . . . . . . . 9
4.4. Responses . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Message Syntax and Processing . . . . . . . . . . . . . . . . 14
5.1. HTTP/XML Encoding . . . . . . . . . . . . . . . . . . . . 14
5.1.1. HTTP Encoding . . . . . . . . . . . . . . . . . . . . 15
5.1.2. Common Message Processing . . . . . . . . . . . . . . 17
5.1.3. CONNECT Messages . . . . . . . . . . . . . . . . . . . 18
5.1.4. DISCONNECT Messages . . . . . . . . . . . . . . . . . 19
5.1.5. JOIN and JOIN_CHUNK Messages . . . . . . . . . . . . . 19
5.1.6. LEAVE Messages . . . . . . . . . . . . . . . . . . . . 22
5.1.7. FIND Messages . . . . . . . . . . . . . . . . . . . . 23
5.1.8. KEEPALIVE Messages . . . . . . . . . . . . . . . . . . 24
5.1.9. STAT Messages . . . . . . . . . . . . . . . . . . . . 25
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
7. Revision History . . . . . . . . . . . . . . . . . . . . . . . 28
7.1. Changes since -02 . . . . . . . . . . . . . . . . . . . . 28
8. Open Issues and TODO . . . . . . . . . . . . . . . . . . . . . 28
9. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Binary Encoding . . . . . . . . . . . . . . . . . . . . . 29
9.1.1. Common Message Header . . . . . . . . . . . . . . . . 30
9.1.2. Timeout and Retransmission . . . . . . . . . . . . . . 32
9.1.3. Fragmentation . . . . . . . . . . . . . . . . . . . . 32
9.1.4. Common Message Processing . . . . . . . . . . . . . . 33
9.1.5. CONNECT Messages . . . . . . . . . . . . . . . . . . . 34
9.1.6. DISCONNECT Messages . . . . . . . . . . . . . . . . . 35
9.1.7. JOIN and JOIN_CHUNK Messages . . . . . . . . . . . . . 35
9.1.8. LEAVE Messages . . . . . . . . . . . . . . . . . . . . 38
9.1.9. FIND Messages . . . . . . . . . . . . . . . . . . . . 38
9.1.10. KEEPALIVE Messages . . . . . . . . . . . . . . . . . . 40
9.1.11. STAT Messages . . . . . . . . . . . . . . . . . . . . 41
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.1. Normative References . . . . . . . . . . . . . . . . . . . 43
10.2. Informative References . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
Gu, et al. Expires September 15, 2011 [Page 3]
Internet-Draft PPSP Tracker Protocol March 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.
[I-D.ietf-ppsp-problem-statement]and [I-D.ietf-ppsp-reqs]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 an HTTP/XML
encoding. This include parameters, methods, and message formats.
Most implemented P2P protocols are proprietary, as introduced in
[I-D.ietf-ppsp-survey]. 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 for more open issues that need
decision from the WG. (Section 8)
Gu, et al. Expires September 15, 2011 [Page 4]
Internet-Draft PPSP Tracker Protocol March 2011
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
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 -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.
Gu, et al. Expires September 15, 2011 [Page 5]
Internet-Draft PPSP Tracker Protocol March 2011
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
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.
Gu, et al. Expires September 15, 2011 [Page 6]
Internet-Draft PPSP Tracker Protocol March 2011
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
Gu, et al. Expires September 15, 2011 [Page 7]
Internet-Draft PPSP Tracker Protocol March 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 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?
Gu, et al. Expires September 15, 2011 [Page 8]
Internet-Draft PPSP Tracker Protocol March 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.
If RELOAD is used as the peer protocol, ICE ([RFC5245]) 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.
Though this draft will not describe NAT Traversal mechanism in PPSP
in detail, it tries to enable flexible NAT Traversal in future.
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).
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:
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.
Gu, et al. Expires September 15, 2011 [Page 9]
Internet-Draft PPSP Tracker Protocol March 2011
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.
Gu, et al. Expires September 15, 2011 [Page 10]
Internet-Draft PPSP Tracker Protocol March 2011
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
Gu, et al. Expires September 15, 2011 [Page 11]
Internet-Draft PPSP Tracker Protocol March 2011
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.
4.4. Responses
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:
Gu, et al. Expires September 15, 2011 [Page 12]
Internet-Draft PPSP Tracker Protocol March 2011
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)
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
Gu, et al. Expires September 15, 2011 [Page 13]
Internet-Draft PPSP Tracker Protocol March 2011
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.
5. Message Syntax and Processing
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.
The authors have quried the WG to provide their opinions on encoding
format, and we got some responses, most of which support Text-based
encoding. And, according to the voice announced from the WG, we
think Text-based encoding will not cost much more bandwidth than
Binary encoding. Hence, in this version, we describe only Text-based
encoding format. But this is not finally decided. If there are more
preference on Binary encoding than on Text encoding, and the reasons
are overwhelming, we can change to Binary encoding, which is also
temprarily moved to Appendix.
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.
5.1. HTTP/XML Encoding
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.
Gu, et al. Expires September 15, 2011 [Page 14]
Internet-Draft PPSP Tracker Protocol March 2011
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
model to be defined later. This basic approach is subject to change.
5.1.1. HTTP Encoding
The format of the shared message XML body is as follows. This is not
a formal XML schema, but will be elaborated to be such at a future
date.
***
***
***
...Method specific xml information...
Figure 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 9.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 9.1.1.1. Only one of Method or
Response will be present in any given method -- the presence of
both constitutes an error. Some responses that are defined as
protocol responses in the binary encoding below are not present
here, as standard HTTP responses are used instead.
Gu, et al. Expires September 15, 2011 [Page 15]
Internet-Draft PPSP Tracker Protocol March 2011
Transaction ID: A unique 64 bit integer that identifies the
transaction and also allows receivers to disambiguate
transactions which are otherwise identical. Responses use the
same Transaction ID as the request they correspond to. It may
be possible to a use native HTTP construct in place of this
value.
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 |
+--------------+----------------------------+
| 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
Gu, et al. Expires September 15, 2011 [Page 16]
Internet-Draft PPSP Tracker Protocol March 2011
+----------------------+---------------------+----------------------+
| 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 | |
+----------------------+---------------------+----------------------+
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 Message Processing
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
Gu, et al. Expires September 15, 2011 [Page 17]
Internet-Draft PPSP Tracker Protocol March 2011
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.3. CONNECT Messages
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).
5.1.3.1. Forming and Sending a CONNECT Message
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:
###
The PeerID of the body MUST be set to the PeerID of the peer. This
reports that the peer is connecting.
Gu, et al. Expires September 15, 2011 [Page 18]
Internet-Draft PPSP Tracker Protocol March 2011
5.1.3.2. Recieving and Processing a CONNECT Message
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.
5.1.4. DISCONNECT Messages
5.1.4.1. Forming and Sending a DISCONNECT Message
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:
###
Figure 4: 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.
5.1.4.2. Recieving and Processing a DISCONNECT Message
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.
5.1.5. JOIN and JOIN_CHUNK Messages
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
Gu, et al. Expires September 15, 2011 [Page 19]
Internet-Draft PPSP Tracker Protocol March 2011
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.
5.1.5.1. Forming and Sending a JOIN Message
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:
###
###
###
Figure 5: 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.
5.1.5.2. Forming and Sending a JOIN_CHUNK Message
To form a JOIN_CHUNK Message, the sender constructs the common
message XML. The sender MUST properly form the XML, set the Method
Gu, et al. Expires September 15, 2011 [Page 20]
Internet-Draft PPSP Tracker Protocol March 2011
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:
###
###
###
###
... more chunk IDs ...
Figure 6: 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)
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.
When implementing JOIN_CHUNK, one may wonder how often shall a peer
Gu, et al. Expires September 15, 2011 [Page 21]
Internet-Draft PPSP Tracker Protocol March 2011
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.
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
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 7: 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.
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_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
Gu, et al. Expires September 15, 2011 [Page 22]
Internet-Draft PPSP Tracker Protocol March 2011
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. FIND Messages
5.1.7.1. Forming and Sending a FIND Message
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:
###
###
###
Figure 8: 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.
Gu, et al. Expires September 15, 2011 [Page 23]
Internet-Draft PPSP Tracker Protocol March 2011
5.1.7.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 (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:
###
Peer list (SEE BELOW)
Figure 9: 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.
5.1.8. KEEPALIVE Messages
Gu, et al. Expires September 15, 2011 [Page 24]
Internet-Draft PPSP Tracker Protocol March 2011
5.1.8.1. Forming and Sending a KEEPALIVE Message
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:
###
Figure 10: 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?
5.1.8.2. Recieving and Processing a KEEPALIVE Message
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?)
5.1.9. 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.9.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. These values are intended as examples for discussion
only.
Gu, et al. Expires September 15, 2011 [Page 25]
Internet-Draft PPSP Tracker Protocol March 2011
+------------------+------------------------------------------------+
| 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?
5.1.9.2. Forming and Sending a STAT_REPORT Message
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:
###
***
... more stats ...
Figure 11: STAT_REPORT Method Specific XML
Gu, et al. Expires September 15, 2011 [Page 26]
Internet-Draft PPSP Tracker Protocol March 2011
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.9.3. Recieving and Processing a STAT_REPORT 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.
5.1.9.4. Forming and Sending a STAT_QUERY Message
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:
... more stats ...
Figure 12: STAT_QUERY Method Specific XML
Each Stat in the StatRequest MUST have the property set as defined in
Table 3 and MUST NOT have any value.
5.1.9.5. Recieving and Processing a STAT_QUERY Message
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:
###
***
... more stats ...
Gu, et al. Expires September 15, 2011 [Page 27]
Internet-Draft PPSP Tracker Protocol March 2011
Figure 13: 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
and an appropriate value provided.
6. Acknowledgments
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, 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].
7. Revision History
7.1. Changes since -02
o Leave HTTP/XML encoding in text and move the Binary encoding to
Appendix.
o Improve HTTP/XML encoding.
o Resolve some Open Issues.
8. Open Issues and TODO
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.
Gu, et al. Expires September 15, 2011 [Page 28]
Internet-Draft PPSP Tracker Protocol March 2011
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.
9. Appendix
9.1. Binary Encoding
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.
Gu, et al. Expires September 15, 2011 [Page 29]
Internet-Draft PPSP Tracker Protocol March 2011
9.1.1. Common Message Header
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 14: 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 9.1.1.1
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 9.1.3.
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.
Gu, et al. Expires September 15, 2011 [Page 30]
Internet-Draft PPSP Tracker Protocol March 2011
9.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 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
Gu, et al. Expires September 15, 2011 [Page 31]
Internet-Draft PPSP Tracker Protocol March 2011
+-------------------------+--------------------+
| 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
9.1.2. Timeout and Retransmission
TODO: A reasonable timeout and retransmission mechanism needs to be
incorporated here.
9.1.3. Fragmentation
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]. 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.
Gu, et al. Expires September 15, 2011 [Page 32]
Internet-Draft PPSP Tracker Protocol March 2011
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.
9.1.4. Common Message Processing
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
Gu, et al. Expires September 15, 2011 [Page 33]
Internet-Draft PPSP Tracker Protocol March 2011
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 9.1.2.
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.
9.1.5. CONNECT Messages
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).
9.1.5.1. Forming and Sending a CONNECT Message
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 15: CONNECT Message Body
The PeerID of the body MUST be set to the PeerID of the peer. This
reports that the peer is connecting.
9.1.5.2. Recieving and Processing a CONNECT Message
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.
Gu, et al. Expires September 15, 2011 [Page 34]
Internet-Draft PPSP Tracker Protocol March 2011
9.1.6. DISCONNECT Messages
9.1.6.1. Forming and Sending a DISCONNECT Message
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 16: 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.
9.1.6.2. Recieving and Processing a DISCONNECT Message
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.
9.1.7. JOIN and JOIN_CHUNK Messages
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
Gu, et al. Expires September 15, 2011 [Page 35]
Internet-Draft PPSP Tracker Protocol March 2011
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.
9.1.7.1. Forming and Sending a JOIN Message
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 17: 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.
9.1.7.2. Forming and Sending a JOIN_CHUNK Message
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 18: 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
Gu, et al. Expires September 15, 2011 [Page 36]
Internet-Draft PPSP Tracker Protocol March 2011
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.
9.1.7.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 5. 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.
Gu, et al. Expires September 15, 2011 [Page 37]
Internet-Draft PPSP Tracker Protocol March 2011
9.1.8. 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.
9.1.8.1. Forming and Sending a LEAVE Message
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 19: 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.
9.1.8.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 5. 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.
9.1.9. FIND Messages
9.1.9.1. Forming and Sending a FIND Message
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
Gu, et al. Expires September 15, 2011 [Page 38]
Internet-Draft PPSP Tracker Protocol March 2011
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 20: 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.
9.1.9.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 5. 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 21: 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
Gu, et al. Expires September 15, 2011 [Page 39]
Internet-Draft PPSP Tracker Protocol March 2011
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.
9.1.10. KEEPALIVE Messages
9.1.10.1. Forming and Sending a KEEPALIVE Message
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 22: 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?
9.1.10.2. Recieving and Processing a KEEPALIVE Message
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
Gu, et al. Expires September 15, 2011 [Page 40]
Internet-Draft PPSP Tracker Protocol March 2011
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?)
9.1.11. 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.
9.1.11.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. 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?
Gu, et al. Expires September 15, 2011 [Page 41]
Internet-Draft PPSP Tracker Protocol March 2011
9.1.11.2. Forming and Sending a STAT_REPORT Message
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 23: 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 24: 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.
9.1.11.3. Recieving and Processing a STAT_REPORT 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.
9.1.11.4. Forming and Sending a STAT_QUERY Message
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:
Gu, et al. Expires September 15, 2011 [Page 42]
Internet-Draft PPSP Tracker Protocol March 2011
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 25: 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?
9.1.11.5. Recieving and Processing a STAT_QUERY Message
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 26: 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 24
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".
Gu, et al. Expires September 15, 2011 [Page 43]
Internet-Draft PPSP Tracker Protocol March 2011
[I-D.ietf-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),
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. and D. Bryan, "Peer Protocol",
draft-gu-ppsp-peer-protocol-01 (work in progress),
October 2010.
Authors' Addresses
Gu Yingjie
Huawei
Phone: +86-25-56624760
Fax: +86-25-56624702
Email: guyingjie@huawei.com
David A. Bryan
Cogent Force, LLC
P.O. Box 6741
Williamsburg, Virginia 23188
United States of America
Phone: +1.571.314.0256
Email: dbryan@ethernot.org
Gu, et al. Expires September 15, 2011 [Page 44]
Internet-Draft PPSP Tracker Protocol March 2011
Zhang Yunfei
China Mobile
Phone:
Email: zhangyunfei@chinamobile.com
Liao Hongluan
China Mobile
Phone:
Email: liaohongluan@chinamobile.com
Gu, et al. Expires September 15, 2011 [Page 45]