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