PPSP Y. Gu
Internet-Draft Huawei
Intended status: Standards Track David A. Bryan
Expires: December 9, 2011 Polycom
June 7, 2011
Peer Protocol
draft-gu-ppsp-peer-protocol-02
Abstract
This document presents the architecture of the PPSP Peer protocol
system, example call flow, and message syntax and processing are
presented.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 9, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Gu & Bryan Expires December 9, 2011 [Page 1]
Internet-Draft Peer Protocol June 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 3
2.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Protocol Architecture . . . . . . . . . . . . . . . . . . 4
3.2. Example Call Flow . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Description of Peer Protocol . . . . . . . . . . . . . . . 7
4.2. Message Syntax and Processing . . . . . . . . . . . . . . 9
5. Security Consideration . . . . . . . . . . . . . . . . . . . . 18
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Normative References . . . . . . . . . . . . . . . . . . . 18
6.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Gu & Bryan Expires December 9, 2011 [Page 2]
Internet-Draft Peer Protocol June 2011
1. Introduction
A full design for a PPSP architecture requires that peers are able to
communicate with a tracker to obtain information about the location
of peers participating in a particular stream or swarm, but for a
number of design reasons also requires that a peer protocol allows
for information to be shared directly between peers
[I-D.ietf-ppsp-problem-statement]. Among the information that should
be exchanged by the peers using this peer protocol includes 1) bitmap
indicating which chunks a peer possesses (for the offline case) or
swarms they are participating in (for the live streaming case) 2)
required chunk IDs or requested streams 3) peer preference indicating
what kind of candidate peers a requesting peer may prefer, 4)
transport protocol negotiation and 5) information that can help to
improve the performance of PPSP.
This is an early strawman draft. There is clearly lots of work left,
and lots of holes. The authors will keep updating the draft and
encourge more discussion at the meeting and on the mailing list.
2. Document Conventions
2.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2.2. Terminology
The draft uses the terms defined in
[I-D.ietf-ppsp-problem-statement]and
[draft-gu-ppsp-tracker-protocol].
3. Protocol Overview
In this section, we provide an overview of the protocol approach we
propose for the PPSP protocol. Please note there are a fairly large
number of open issues which we are soliciting conversation on. We
intend to take these questions to the list in an attempt to drive
consensus, and as consensus is achieved, intend to refine our
proposal to conform to the consensus. As indicated in Introduction,
this is a early strawman draft, and there are still some issues need
to be discussed and decided at the WG. The authors will keep
updating the draft.
Gu & Bryan Expires December 9, 2011 [Page 3]
Internet-Draft Peer Protocol June 2011
3.1. Protocol Architecture
The proposed PPSP Peer Protocol uses a newly defined, light weight
gossip protocol between the peers to exchange the actual information,
but uses the RELOAD [I-D.ietf-p2psip-base] protocol to establish the
connections between peers and to locate other peers with which to
establish gossip protocol connections.
The proposed PPSP Peer Protocol interacts with a tracker protocol,
for example the one defined in [I-D.gu-ppsp-tracker-protocol]. This
protocol can be used to connect peers that are sharing real-time
streams of video or offline video via sets of chunks. There are some
minor differences between the details of these two scenarios, but
from a high level perspective the overall structure is quite similar.
The basic flow of messages for a peer which wishes to participate
either in a group of peers in live streaming or a group of peers
exchanging data for an offline video is as follows:
1. The peer contacts the tracker to obtain a Peerlist containing
a list of peers participating in the particular swarm the peer is
interested in.
* Note that there are other reasons that the peers may exchange
information with the tracker, for example to provide updates on
connection quality and other factors that may be used to order
the Peerlist and assist in selection, but in this example we
are concerned only with obtaining the Peerlist.
* This list could contain IP addresses or Peer-IDs, or both.
* The mechanism for finding out which Tracker to connect to and
for obtaining the swarm ID is presently out of the scope of
this proposal.
2. The peer establishes a connection to at least one of the peers
in the Peerlist, based on the Peer-ID, or Peer IP address. If
using RELOAD to establish a connection to any peers, RELOAD will
handle the negotiation of any NAT traversal that may be required
to establish the connection between the peer and any peers from
the Peerlist. If using Peer IP address, additional NAT traversal
mechanisms should be developed. The NAT traversal mechanism is
out of the scope of this draft.
3. The peer may then optionally use the peer protocol to find a
list of further peers to connect to, and can establish these
connections if desired. This is performed using the PPSP Peer
Protocol.
Gu & Bryan Expires December 9, 2011 [Page 4]
Internet-Draft Peer Protocol June 2011
4. The peer now exchanges chunk lists with other peers, again
using the PPSP Peer Protocol. Other information, such as the
capabilities of the peers or quality of the files/stream may also
be exchanged using the peer protocol, and may be used to decide
which peers to actually exchange data/stream data with.
5. After checking the list of peers, the peers negotiate a
mechanism to exchange the information.
* Note that there are several options here to negotiate the
connection model. The Peer Protocol may include new mechanisms
to negotiate the protocol used to exchange data, or the offer-
answer mechanism in SIP [RFC3261] (the IETF protocol for
session establishment) along with SDP [RFC4566] or a
lightweight variation thereof, such as the advertisement/
proposal model in [I-D.peterson-sipcore-advprop] could be used.
In order to make Peer Protocol be consistent with Tracker
protocol, a new mechanism is defined in this draft.
6. Finally, the peers exchange the actual chunks of data or
establish streaming connections between each other, using the
mechanism/protocol negotiated in the previous step.
* Note that at this time, these mechanisms are not new
protocols defined in the PPSP group, but existing protocols,
and would differ between offline and live streaming scenarios.
Mechanisms such as flow control, signaling of choke status,
etc. are handled in the negotiated transfer mechanism, not in
the Peer Protocol itself.
3.2. Example Call Flow
This is a very high-level example of a session in which a peer joins
a swarm, and retrieves some data (either via blocks or by streaming).
The protocol used is indicated for each transaction. Note that not
all of the communication shown in this figure are in scope of Peer
Protocol, only those request/response followed by Peer Protocol are
in scope.
Gu & Bryan Expires December 9, 2011 [Page 5]
Internet-Draft Peer Protocol June 2011
********************** Obtain Peerlist *******************
Requesting Peer Tracker
|------------ Request Peerlist (Tracker Protocol) ------->|
|<----------- Response (Tracker Protocol) ----------------|
************ Open Connections to Remote Peers ************
Requesting Peer Remote Peers
|<------- Connection (using Peer-ID or IP address) ------>|
(Repeated for one or more peers)
********* Optionally Obtain Additional Peerlist **********
Requesting Peer Remote Peers
|------------ 1. Request Peerlist (Peer Protocol) ------->|
|<----------- 2. Response (Peer Protocol) ----------------|
(Repeated for one or more peers)
******** Optionally Query Peers for Available Data *******
Requesting Peer Remote Peers
|------------ 1. Request Data (Peer Protocol) ----------->|
|<----------- 2. Response (Peer Protocol) ----------------|
(Repeated from one or more peers)
*********** Optionally Query Peers for Property **********
Requesting Peer Remote Peers
|------------ 1. Request Data (Peer Protocol) ----------->|
|<----------- 2. Response (Peer Protocol) ----------------|
(Repeated from one or more peers)
****** Negotiate Transfer Connection and Transfer ********
Requesting Peer Remote Peers
|<--------- Handshake Sequence (SIP/SDP, other) --------->|
|<----- Data Transfer Sequence (negotiated protocol) ---->|
(Repeated with one or more peers)
Figure 1: Example Call Flow
4. Protocol Design
As shown in example call flow, Peer protocol only provides
communication for obtainning additional peerlist (optionally), query
for available data and negotiation for transfer protocol. Peer
Gu & Bryan Expires December 9, 2011 [Page 6]
Internet-Draft Peer Protocol June 2011
protocol may also providing communication for peers to exchange
information that can improve system performance.
As we have encountered in Tracker protocol design, there are also at
least two choices for Peer Protocol encoding, i.e. binary and text
based. Because Peer protocol is regarded as exchange of peerlist and
chunks availability, instead of real streaming or chunks, so the
benefits of binary encoding is not very significant. In order to
make Peer protocol to be consistent with Tracker protocol, we choose
HTTP/XML based encoding for Peer Protocol.
4.1. Description of Peer Protocol
The PPSP Peer Protocol presented is a request-response protocol.
Requests are sent, and responses returned to these requests. A
single request generates a single response (neglecting fragmentation
of messages).
Note that the Peer protocol does not actually exchange any data
between the peers (either streaming in the live streaming case or
chunks data in the file sharing scenario.).
The specific operations of the protocol are:
FIND and FIND_CHUNK: Peers use the FIND or FIND_CHUNK method to
request that the remote peers to return lists of peers that can
provide specific content or are in a particular swarm. The
intention of this FIND/FIND_CHUNK message is similar to the FIND/
FIND_CHUNK message defined in Tracker protocol. On receiving a
FIND/FIND_CHUNK message, the remote peer finds the candidate peers
listed in peer Data Management, shown in Figure 2 in
[draft-gu-ppsp-tracker protocol], and returns the list to the
requesting peer.
CHUNK_AVAILABILITY: Peers use the CHUNK_AVAILABILITY messages to
request the remote peers to return their chunk availability
regarding the desired content. The chunk availability is usually
presented as a bitmap, but this is not mandatory. The format of
chunk availability is not in the scope of peer protocol.
CHUNK_AVAILABILITY is not a mandatory message. In case of live
streaming, peers need not request chunk availability.
PROPERTY_QUERY: Peers use PROPERTY_QUERY message to request remote
peer to return their properties, which can help requesting peers
to make decision whether the remote peers are satisfactory peers
to obtain desired content.
Gu & Bryan Expires December 9, 2011 [Page 7]
Internet-Draft Peer Protocol June 2011
TRANSPORT_NEGOTIATION: This method allows peers to negotiate a
suitable transport protocol that is supported by both peers.
After successful negotiation, peers can transfer real chunks or
streaming using the negotiated transport protocol. This is out of
the scope of peer protocol.
The following part discusses RESPONSE mechanism. The HTTP protocol
itself would handle malformed messages, but incorrectly formatted XML
bodies could generate tracker-protocol level errors, the contents of
which are reported in an HTTP message. These RESPONSE definition is
the same as 4.3.1 in [draft-gu-ppsp-tracker-protocol] with slight
revisions of thes definitions as discussed below.
SUCCESSFUL (OK): Indicates that a message has been processed
properly, and that the desired operation completed. If the
message is a request for information, the body of the message will
also include the requested information. As a result, the
following information is returned for each message:
CHUNK_AVAILABILITY returns bitmaps representing chunk
availability of specific content.
FIND and FIND_CHUNK return the list of peers meeting the
desired criteria.
PROPERTY_QUERY returns peer's parameters on specific properties
requested by requesting peers.
TRANSPORT_NEGOTIATION returns designated transport protocols
that the remote peer would like to use to transfer real chunk
data or live streaming. the designated transport protocols MUST
be originally indicated in the TRANSPORT_NEGORIATION request.
INVALID SYNTAX: Indicates an error in the format of the message/
message body.
VERSION NOT SUPPORTED: Invalid version of the protocol or message
bodies.
MESSAGE NOT SUPPORTED: The particular request is not supported by
this peer.
MESSAGE FORBIDDEN: The requester is not allowed to make this
request.
Gu & Bryan Expires December 9, 2011 [Page 8]
Internet-Draft Peer Protocol June 2011
4.2. Message Syntax and Processing
4.2.1. HTTP/XML Encoding
The current encoding is a very simple strawman encoding. Clearly,
more attention will need to be paid to the proper HTTP messages to
convey information, and to the appropriate way to encode the
information in XML.
For simplicity, the current proposal uses only HTTP GET as a
mechanism. Error codes from HTTP are reused when possible, with the
error conveyed in the actual HTTP message.
4.2.1.1. HTTP Encoding
The format of the shared message XML body is as follows. This is not
a formal XML schema, but will be elaborated to be such at a future
date.
<PPSPPeerProtocol version="***">
<Method>***</Method>
<Response>***</Response>
<TransactionID>***</TransactionID>
...Method specific xml information...
</PPSPPeerProtocol>
Figure 2: Common Message XML Header
In this representation, *** is used to represent data to be inserted.
The fields in the header are:
version: The version of the PPSP Peer Protocol being used in the
form of a fixed point integer between 0.1 and 25.4. For the
version of the protocol described in this document, this field
MUST be set to 0.1.
Method: Indicates the method type for the message. The Method is
encoded as a string, and is case insensitive. The valid
strings are defined in Section 4.2.1.1.1. Only one of Method
or Response will be present in any given method -- the presence
of both constitutes an error.
Response: Indicates the response type for the message. The Response
is encoded as a string, and is case insensitive. The valid
strings are defined in Section 4.2.1.1.1. Only one of Method
or Response will be present in any given method -- the presence
of both constitutes an error. Some responses that are defined
as protocol responses in the binary encoding below are not
present here, as standard HTTP responses are used instead.
Gu & Bryan Expires December 9, 2011 [Page 9]
Internet-Draft Peer Protocol June 2011
Transaction ID: A unique 64 bit integer that identifies the
transaction and also allows receivers to disambiguate
transactions which are otherwise identical. Responses use the
same Transaction ID as the request they correspond to. It may
be possible to a use native HTTP construct in place of this
value.
4.2.1.1.1. Method Field Encoding
The PPSP Peer Protocol uses a request-response approach to protocol
messages. Messages are either a request, asking for an action, or a
response, in reply to a request. Message methods are transmitted
using an HTTP GET, with an appropriate XML body as defined above (and
expanded per message below).
The tables below define the valid string representations for the
requests and responses. These values MUST be treated as case-
insensitive.
+-----------------------+----------------------------+
| PPSP Request | PPSP Request Method String |
+-----------------------+----------------------------+
| FIND | FIND |
| FIND_CHUNK | FIND_CHUNK |
| CHUNK_AVAILABILITY | CHUNK_AVAILABILITY |
| PROPERTY_QUERY | PROPERTY_QUERY |
| TRANSPORT_NEGOTIATION | TRANSPORT_NEGOTIATION |
+-----------------------+----------------------------+
Table 1: Valid Strings for Requests
+----------------------+---------------------+----------------------+
| Response Method Name | HTTP Response | XML Response Value |
| | Mechanism | |
+----------------------+---------------------+----------------------+
| SUCCESSFUL (OK) | 200 OK | OK |
| INVALID SYNTAX | 400 Bad Request | INVALID SYNTAX |
| VERSION NOT | 400 Bad Request | VERSION NOT |
| SUPPORTED | | SUPPORTED |
| MESSAGE NOT | 403 Forbidden | MESSAGE NOT |
| SUPPORTED | | SUPPORTED |
| TEMPORARILY | 503 Service | TEMPORARILY |
| OVERLOADED | Unavailable | OVERLOADED |
| INTERNAL ERROR | 500 Internal Server | INTERNAL ERROR |
| | Error | |
| MESSAGE FORBIDDEN | 403 Forbidden | MESSAGE FORBIDDEN |
| OBJECT NOT FOUND | 404 Not Found | OBJECT NOT FOUND |
Gu & Bryan Expires December 9, 2011 [Page 10]
Internet-Draft Peer Protocol June 2011
| AUTHENTICATION | 401 Unauthorized | AUTHENTICATION |
| REQUIRED | | REQUIRED |
+----------------------+---------------------+----------------------+
Table 2: Method Field Encodings for Responses
4.2.1.2. Common Message Processing
When a PPSP Peer Protocol message is received, some basic processing
is performed.
Upon receiving a message, the message is examined to ensure that the
message is properly formed. The receiver MUST check that the HTTP
message itself is properly formed, and if not appropriate standard
HTTP errors MUST be generated. The receiver must verify that the XML
payload is properly formed. If the message is found to be
incorrectly formed or the length does not match the length encoded in
the common header, the receiver MUST reply with an HTTP 400 response
with a PPSP XML payload with the Response attribute set to INVALID
SYNTAX.
The common message XML MUST be examined to obtain the version number
of the message. In the event that the version number is for a
version the receiver does not support, the receiver MUST reply with
an HTTP 400 response with a PPSP XML payload with the Response
attribute set to VERSION NOT SUPPORTED.
The common message XML MUST be examined to obtain the message type of
the message. In the event the message listed is not supported by the
receiver, the receiver MUST reply with an HTTP 400 response with a
PPSP XML payload with the Response attribute set to MESSAGE NOT
SUPPORTED.
If the receiver is unable to process the message at this time because
it is in an overloaded state, the receiver SHOULD reply with an HTTP
503 response with a PPSP XML payload TEMPORARILY OVERLOADED.
If the receiver encounters an internal error while attempting to
process the message, the receiver MUST generate an HTTP 500 response
with a PPSP XML payload INTERNAL ERROR message indicating this has
occurred.
4.2.1.3. FIND Messages
4.2.1.3.1. Forming and Sending a FIND Message
FIND message is sent from a peer to remote peer or a Tracker. In
this draft, we only consider the case of sending FIND message from a
Gu & Bryan Expires December 9, 2011 [Page 11]
Internet-Draft Peer Protocol June 2011
peer to remote peer. To form a FIND Message, the sender constructs
the common message XML. The sender MUST properly form the XML, set
the Method attribute to FIND, and randomly generate and set the
Transaction ID.
The method specific XML of the FIND message takes the form shown
below:
<PeerID>***</PeerID>
<SwarmID>***</SwarmID>
<ChunkID>***</ChunkID>
<Peernum>***</Peernum>
Figure 3: FIND Method Specific XML
The PeerID of the body MUST be set to the PeerID of the peer, and
SwarmID MUST be set to the SwarmID of the swarm the peer is
interested in obtaining chunks from. Chunk ID MAY be set to a
particular chunk, and if set, the receiver will only return peers
having chunks with this ID and higher value. If the peer is
interested in any chunks, the peer MUST set the value of the Chunk ID
to all zero. Peernum MAY be set to indicate how many peers in the
peerlist the requesting peer would like receiver to provide. It's
set to zero if requesting peer has no preference on peer number.
4.2.1.3.2. Recieving and Processing a FIND Message
When a FIND Message is received, the recevier, i.e. the remote peer,
will process the request. The recevier MAY reject the request using
one of the error codes in Table 2. If the receiver accepts the
message, it MUST verify the fields are properly formed and if not
MUST reject the message with an HTTP 400 response with a PPSP XML
payload INVALID SYNTAX indicating this has occurred. If the message
is well formed and accepted, the receiver will search the internal
data store for the requested data and if found will respond the
requesting peer with an HTTP 200 OK SUCCESS message response with a
PPSP XML payload SUCCESSFUL, as well as the peerlist with ID and IP
Addresses of peers that can provide the specific content. If the
data is not found an HTTP 404 will be generated with the PPSP XML
Response set to OBJECT NOT FOUND.
The response MUST have the same Transaction ID as the request
The FIND response MUST include an XML payload of the form below:
Gu & Bryan Expires December 9, 2011 [Page 12]
Internet-Draft Peer Protocol June 2011
<SwarmID>***</SwarmID>
<ChunkID>***</ChunkID>
<Peers>
Peer list (SEE BELOW)
</Peers>
Figure 4: FIND Response XML
The SwarmID MUST be set to the swarm to which the chunks belong. The
ChunkID MAY be set to indicate the specific chunk. If ChunkID is
set, it means that the peers in the peerlist can provide the specific
chunk.
The peer list consists of a list of peers, identified by <Peer-IDs
and IP addresses> of peers. Requesting peers can request and obtain
specific content from peers listed in peerlist, according to the
Peer-IDs or IP addresses. The peer list defined in Peer protocol is
the same as the one defined in [draft-gu-ppsp-tracker-protocol].
4.2.1.4. CHUNK_AVAILABILITY message
After connected with remote peer, the requesting peer can send
CHUNK_AVAILABILITY request to remote peer to ask for the chunks the
remote peer can provide. In the CHUNK_AVAILABILITY request message,
the requesting peer MAY convey its chunk availability, e.g. bitmap.
4.2.1.4.1. Forming and Sending a CHUNK_AVAILABILITY Message
CHUNK_AVAILABILITY message is sent from peer to remote peer. To form
a CHUNK_AVAILABILITY Message, the sender constructs the common
message XML. The sender MUST properly form the XML, set the Method
attribute to CHUNK_AVAILABILITY, and randomly generate and set the
Transaction ID.
The method specific XML of the CHUNK_AVAILABILITY message takes the
form shown below:
<PeerID>###</PeerID>
<CHUNK>
Chunk Availability
</CHUNK>
Figure 5: CHUNK_AVAILABILITY Method Specific XML
The PeerID of the body MUST be set to the PeerID of the peer.
Gu & Bryan Expires December 9, 2011 [Page 13]
Internet-Draft Peer Protocol June 2011
Following this field, chunk availability information MAY be provided.
Usually, bitmap is used to indicate chunk availability. A certain
PPSP system or a certain swarm may define specific bitmap and the
peers participating in the system are assumed to be able to parse the
specific bitmap. In this draft, we don't define mandatory bitmap
form.
4.2.1.4.2. Recieving and Processing a CHUNK_AVAILABILITY Message
When a CHUNK_AVAILABILITY Message is received, the recevier, i.e. the
remote peer, will process the request. The recevier MAY reject the
request using one of the error codes in Table 2. If the receiver
accepts the message, it MUST verify the fields are properly formed
and MUST reject the message with an HTTP 400 response with a PPSP XML
payload INVALID SYNTAX indicating this has occurred. If the message
is well formed and accepted, the receiver will search the internal
data store for the chunks of the desired swarm it has restored. And
if found will respond the requesting peer with an HTTP 200 OK SUCCESS
message response with a PPSP XML payload SUCCESSFUL, as well as the
bitmap. If the data is not found, e.g. the data has been removed by
the receiver, an HTTP 404 will be generated with the PPSP XML
Response set to OBJECT NOT FOUND.
<PeerID>###</PeerID>
<CHUNK>
Chunk Availability
</CHUNK>
Figure 6: CHUNK_AVAILABILITY Method Specific XML
The PeerID of the body MUST be set to the PeerID of the peer.
Following this field, chunk availability information MAY be provided.
Usually, bitmap is used to indicate chunk availability. A certain
PPSP system or a certain swarm may define specific bitmap and the
peers participating in the system are assumed to be able to parse the
specific bitmap. In this draft, we don't define mandatory bitmap
form.
4.2.1.5. PROPERTY_QUERY message
A requesting peer may have preference when choosing the remote peers
to obtain data. For example, a peer would like to obtain data from a
remote peer with longer online time. The requesting peer can convey
the concerning property in PROPERTY_QUERY message, and the receiver
will response with corresponding parameters to the properties listed
in PROPERTY_QUERY message. The requesting peer can also convey its
Gu & Bryan Expires December 9, 2011 [Page 14]
Internet-Draft Peer Protocol June 2011
connection preference in Tracker protocol, e.g. in FIND or FIND_CHUNK
message. The requesting peer has to be aware that it's not
guaranteed that the parameters provided by remote peers are true.
4.2.1.5.1. Property Types for PROPERTY_QUERY Messages
The property listed here are the same as Sample Property Types for
STAT message defined in [draft-gu-ppsp-tracker-protocol]. For
readers convenience, they are repeated in this draft.
+------------------+------------------------------------------------+
| XML Value | Definitions/Description |
+------------------+------------------------------------------------+
| CachingSize | Caching size: available size for caching |
| Bandwidth | Bandwidth: available bandwidth |
| LinkNumber | Link number: acceptable links for remote peer |
| Certificate | Certificate: certificate of the peer |
| NAT | NAT/Firewall: peer believes it is behind NAT |
| | (Boolean Value) |
| STUN | STUN: peer supports STUN service (Boolean |
| | Value) |
| TURN | TURN: peer supports TURN service (Boolean |
| | Value) |
| SumBytes | Sum Volume: Sum of bytes of data peers |
| | received from the steaming system |
| AccessMode | Access Mode: ADSL/Fiber/GPRS/3G/LTE/WiFi etc. |
| EndDevice | End Device: STB/PC/MobilePhone |
| AvailableBattery | Available Battery Level |
+------------------+------------------------------------------------+
Table 3: Sample Property Types for STAT messages
4.2.1.5.2. Forming and Sending a PROPERTY_QUERY Message
PROPERTY_QUERY message is sent from peer to peer. To form a
PROPERTY_QUERY Message, the sender constructs the common message XML.
The sender MUST properly form the XML, set the Method attribute to
PROPERTY_QUERY, and randomly generate and set the Transaction ID.
The method specific XML of the PROPERTY_QUERY message takes the form
shown below:
<PeerID>###</PeerID>
<StatRequest>
<Stat property="***"></Stat>
... more stats ...
</StatsRequest>
Gu & Bryan Expires December 9, 2011 [Page 15]
Internet-Draft Peer Protocol June 2011
Figure 7: PROPERTY_QUERY Method Specific XML
The PeerID of the body MUST be set to the PeerID of the peer.
Each Stat in the StatRequest MUST have the property set as defined in
Table 3 and MUST NOT have any value.
4.2.1.5.3. Recieving and Processing a PROPERTY_QUERY Message
When a PROPERTY_QUERY message is received by the peer, it MUST
respond, using one of the response codes defined above. The body
contains one value each requested statistic:
<PeerID>###</PeerID>
<Stats>
<Stat property="***">***</Stat>
... more stats ...
</Stats>
Figure 8: PROPERTY_QUERY Response Method Specific XML
The PeerID of the body MUST be set to the PeerID of the peer.
Following this field, one or more Stat attributes are provided, with
a property field corresponding to the data as described in Table 3
and an appropriate value provided.
4.2.1.6. TRANSPORT_NEGOTIATION message
Peer protocol is used for informaiton exchanging and transport
protocol negotiation. We recommend to reuse existing transport
protocol to transfer data.
4.2.1.6.1. Forming and Sending a TRANSPORT_NEGOTIATION Message
TRANSPORT_NEGOTIATION message is sent from peer to remote peer. To
form a TRANSPORT_NEGOTIATION Message, the sender constructs the
common message XML. The sender MUST properly form the XML, set the
Method attribute to TRANSPORT_NEGOTIATION, and randomly generate and
set the Transaction ID.
The method specific XML of the TRANSPORT_NEGOTIATION message takes
the form shown below:
Gu & Bryan Expires December 9, 2011 [Page 16]
Internet-Draft Peer Protocol June 2011
<PeerID>###</PeerID>
<TransProt>
<TProt type="***"></TProt>
... more protocols ...
</TransProt>
Figure 9: TRANSPORT_NEGOTIATION Method Specific XML
The PeerID of the body MUST be set to the PeerID of the peer.
Following this field, a list of transport protocol supported by
requesting peer are provided. Note that NO VALUE is presented. The
tables below define the valid string representations for the
Transport protocols. These values MUST be treated as case-
insensitive. At least one transport protocol are mandatory, that
should be supported by all peers. The authors currently designate
RTP as mandatory tansport protocol, but this is still under
discussion.
+-----------+------------------------------+
| XML Value | Definitions/Description |
+-----------+------------------------------+
| RTP | Real-time transport protocol |
| SIP | Session Initiation Protocol |
+-----------+------------------------------+
Table 4: Sample Transport Protocols
4.2.1.6.2. Recieving and Processing a TRANSPORT_NEGOTIATION Message
When a TRANSPORT_NEGOTIATION message is received by the peer, it MUST
respond, using one of the response codes defined above. The receiver
check the supported transport protocol listed in request message and
find out which transport protocols it supports. The recevicer will
response the requesting peer with an HTTP 200 OK SUCCESS message
response with a PPSP XML payload SUCCESSFUL, as well as the transport
protocols the receiver supports. The designated transport protocols
must be originally listed in TRANSPORT_NEGOTIATION message. If none
of the transport protocol listed in TRANSPORT_NEGOTIATION request is
supported by the receiver, an HTTP 404 will be generated with the
PPSP XML Response set to OBJECT NOT FOUND.The body contains one value
each requested statistic:
Gu & Bryan Expires December 9, 2011 [Page 17]
Internet-Draft Peer Protocol June 2011
<PeerID>###</PeerID>
<TransProt>
<TProt type="***"></TProt>
... more protocols ...
</TransProt>
Figure 10: TRANSPORT_NEGOTIATION Response Method Specific XML
The PeerID of the body MUST be set to the PeerID of the peer.
Following this field, one or more designated transport protocols are
indicated. The designated transport protocols must be orginally
included in TRANSPORT_NEGOTIATION request message. The requesting
peer can choose any of the designated transport protocol to transfer
data of desired content.
5. Security Consideration
As in typical Peer to Peer network, the most significant security
issue is that the peers are untrusted. A peer may announce that it
has a specific content, but the content might be just noise or it
could be poisoned. A peer could also download lots of chunks but
upload very few of them. This problem can be alleviated by incentive
mechanism, the goal of which is to reward honest peers and degrade
dishonest peers. [draft-zeng-ppsp-protocol-pro-incentive-para]
introduces some mechanism. Currently, both Tracker and peer protocol
only define basic methods. When we get consensus on basic methods
and encoding, we will introduce incentive mechanism into the
protocols.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[draft-ietf-p2psip-base-07]
Jennings, C., Lowekamp, B., Ed., Rescorla, E., and H.
Schulzrinne, "draft-ietf-p2psip-base-07", February 2010,
<draft-ietf-p2psip-base-07>.
Gu & Bryan Expires December 9, 2011 [Page 18]
Internet-Draft Peer Protocol June 2011
6.2. Informative References
[I-D.ietf-ppsp-problem-statement]
Zhang, Y., Zong, N., Camarillo, V., Seng, J., and R. Yang,
"Problem Statement of P2P Streaming Protocol (PPSP)",
Januray 2011, <I-D.ietf-ppsp-problem-statement>.
[I-D.ietf-ppsp-reqs]
Zong, N., Zhang, Y., Pascual, V., and C. Williams, "P2P
Streaming Protocol (PPSP) Requirements", February 2011,
<I-D.ietf-ppsp-reqs>.
[I-D.ietf-ppsp-survey]
Gu, Y., Zong, N., Zhang, H., Zhang, Y., Camarillo, G., and
Y. Liu, "Survey of P2P Streaming Applications",
March 2011, <I-D.ietf-ppsp-survey>.
[draft-gu-ppsp-tracker-protocol]
Gu, Y., Bryan, D., Zhang, Y., and H. Liao, "PPSP Tracker
Protocol", March 2011, <draft-gu-ppsp-tracker-protocol>.
[BittorrentSpecification]
"Bittorrent Protocol Specification v1.0", February 2010,
<Bittorrent Specification>.
[I-D.ietf-p2psip-base]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", March 2010, <I-D.ietf-p2psip-base>.
Authors' Addresses
Yingjie Gu
Huawei
No.101 Software Avenue
Nanjing, Jiangsu Province 210012
P.R.China
Phone: +86-25-56622638
Email: guyingjie@huawei.com
Gu & Bryan Expires December 9, 2011 [Page 19]
Internet-Draft Peer Protocol June 2011
David A. Bryan
Polycom
San Jose, CA, USA,
USA
Phone:
Email: dbryan@ethernot.org
Gu & Bryan Expires December 9, 2011 [Page 20]