PPSP Y. Gu
Internet-Draft Huawei
Intended status: Standards Track David A. Bryan
Expires: January 6, 2011 Cogent Force, LLC / Huawei
July 5, 2010
Peer Protocol
draft-gu-ppsp-peer-protocol-00
Abstract
This document defines the architecture of peer communication, and
enumerate requirements for peer protocol. The document also tries to
reuse RELOAD [draft-p2psip-base] to realize peer protocol.
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 January 6, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Gu & Bryan Expires January 6, 2011 [Page 1]
Internet-Draft Peer Protocol July 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 3
2.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Architecture and Function Entities . . . . . . . . . . . . 4
4. Peer Protocol Requirements . . . . . . . . . . . . . . . . . . 5
4.1. Locating and Connection . . . . . . . . . . . . . . . . . 5
4.2. Information Exchange . . . . . . . . . . . . . . . . . . . 6
4.3. Connection Status . . . . . . . . . . . . . . . . . . . . 9
4.4. Real-time Features . . . . . . . . . . . . . . . . . . . . 10
4.5. Transportation Negotiation . . . . . . . . . . . . . . . . 11
4.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Example Flow . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Peer Locating Protocol . . . . . . . . . . . . . . . . . . . . 12
6.1. General Comments . . . . . . . . . . . . . . . . . . . . . 13
6.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 13
7. Peer Signalling Protocol (New Protocol) . . . . . . . . . . . 14
7.1. Options . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Binary Protocol . . . . . . . . . . . . . . . . . . . . . 14
7.3. HTTP-Based Protocol . . . . . . . . . . . . . . . . . . . 15
8. Security Consideration . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Gu & Bryan Expires January 6, 2011 [Page 2]
Internet-Draft Peer Protocol July 2010
1. Introduction
As one of the important protocol components of PPSP, Peer protocol is
required by[draft-zhang-ppsp-problem-statement]to standardize format/
encoding/messages of information between PPSP peers. The information
may at least includes: 1) bitmap indicating which chunks a peer
possesses, 2) required chunks IDs, 3) peer preference indicating what
kind of candidate peers a requesting peer may prefer, 4) transport
protocol negotiation and 5) some information that can help to improve
the performance of PPSP. Meanwhile there are some discussions on the
mailing list about reusing RELOAD defined in [draft-p2psip-base] to
realize peer protocol. RELOAD is the core effort of P2PSIP working
group, which is a peer-to-peer (P2P) signaling protocol for use on
the Internet. A P2P signaling protocol provides its clients with an
abstract storage and messaging service between a set of cooperating
peers that form the overlay network. RELOAD is designed to support a
P2P Session Initiation Protocol (P2PSIP) network, but can be utilized
by other applications with similar requirements by defining new
usages that specify the kinds of data that can be stored for a
particular application. RELOAD defines a security model based on a
certificate enrollment service that provides unique identities. NAT
traversal is a fundamental service of the protocol. RELOAD also
allows access from "client" nodes that do not need to route traffic
or store data for others. [draft-p2psip-base-08]
The IETF encourages technology sharing among WGs, which will save
unnecessary repeated work in the IETF. Therefore, before we decide
to define a new signaling protocol for PPSP, we should at least try
to find out whether RELOAD is suitable for PPSP network.
The draft is organized in the following structure. In section 3, we
introduce the protocol overview. In section 4, we enumerate detail
requirements for Peer protocol, which will be the baseline for peer
protocol. In section 5, we enumerate respective message flows for
possible peer protocols that can fulfill requirements listed in
section 4.
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].
Gu & Bryan Expires January 6, 2011 [Page 3]
Internet-Draft Peer Protocol July 2010
2.2. Terminology
The draft uses the terms defined in
[draft-zhang-ppsp-problem-statement]and .
[draft-gu-ppsp-tracker-protocol]
This draft also uses some new terms. We list the relevant terms as
following.
Candidate peer: Peers that can provide a particular content. These
peers will be recorded on Tracker and may appear in Peerlist.
Block: A block is a portion of data that a peer may request. Two or
more blocks make up a whole Chunk.
3. Protocol Overview
3.1. Architecture and Function Entities
After obtaining the peerlist, either from Trackers, remote peers or
by other means, a peer can communicate with its remote peers. The
only participant in Peer protocol is peer. The information exchanged
among peers is used to help peers to get desired content and will be
defined in detail in section 4. This architecture shows all possible
communication methods and kinds of information between peers, however
this doesn't mean all of them are in scope of PPSP. If, eventually,
we ascertain that some of the methods can be performed by an existing
protocol, we will reuse them instead of defining a new one.
Peer Peer
+-------------------+ +-----------------+
|Peer Protocol |-------------------+ locating | Peer Protocol |
| |Data management |<------------->| |
| Tracker protocol | +===============+ | | Tracker protocol|
| | |Swarm ID | | | |
| | | - Chunk ID | | | |
| | | - peer list | | signalling | |
+-------------------+ | - Buffer map| |<------------->+-----------------+
| +===============+ | (overlay mant., info. exchange, Data Transport)
| |
+---------------------+
Fig 1 Function Entities of PPSP Tracker Communication
A general message flow of Peer Protoco is as follows. A peer gets a
peerlist from the Tracker, and then chooses some candidate peers in
the peerlist to request for additional peers. The peers exchange
Gu & Bryan Expires January 6, 2011 [Page 4]
Internet-Draft Peer Protocol July 2010
Data Availability with some remote peers to find out whether these
peers own the desired content, e.g. chunks. How a peer choose remote
peers is out of the scope of Peer Protocol. According to Data
Availability, the peer chooses remote peers that contain the desired
content and sends Downloading requests to the remote peers. If the
remote peers feedback positive response, which means the remote peers
would like to provide the desired content, the peer tries to set up a
transport connection with the remote peers, through which the data
will be transported. After downloading, the connection may be
closed. This process will be repeated until the peer gets all the
content it desires.
Peer Protocol can be split into 2 parts. The first part is Peer
locating, named Peer Locating protocol, which means the requesting
peer needs a mechanism to connect with remote peers in the peerlist.
This part is closely related to Tracker protocol. Regarding
different Peer identities indicated in the Peerlist, the locating
mechanism and corresponding protocol will be different. For example,
if Peer IDs are included in Peerlist, Peer Locating Protocol may
reuse Reload protocol or design a new Peer to Peer locating protocol.
If URIs are used, Peer Locating Protocol may reuse SIP or a similar
mechanism to locate and establish sessions with other peers.
The second part of Peer Protocol is Peer Signalling Protocol, by
which peers can exchange information, such as bitmap and additional
peerlist, and negotiate transport protocols, and ask for desired
chunks or swarm.
Both parts are important components of Peer protocol. Peer Locating
Protocol has many options, while Peer Signaling Protocol needs new
messages encoding. The purpose of distinct Peer Locating Protocol
and Peer Signaling Protocol is to make sure that the two parts can be
developed synchronously and efficiently.
Before the detail message flow introduction, several general
requirements are enumerated. No matter which option or combination
of options is choosen as the final decision, these general
requirements MUST be fulfilled by Peer Protocol. Rationale is given
for some of the requirements helping to understand the requirement.
4. Peer Protocol Requirements
4.1. Locating and Connection
Peer Locating is closely related to the Tracker protocol. A peer
will get a peerlist from Tracker, with Peer IDs ,Peer IP Addresses or
other peer identities, the form of which will influence the locating
Gu & Bryan Expires January 6, 2011 [Page 5]
Internet-Draft Peer Protocol July 2010
mechanism. The requirements in this section will not take any
specific peerlist data structure into account, but give some general
requirements that should be fulfilled.
4.1.1. Requirement
Client SHOULD be able to locate peers in peerlist and connect to them
with minimal or without the Tracker's assistance.
4.1.2. Rationale
By 'Locating', we mean a peer can find a path between itself and the
remote peer, on which messages can pass through. No matter which
information is included in Peerlist: Peer ID, Peer IP Address or
other, a peer should be able to use the respective mechanism to
locate its remote peers with little or even without the Tracker's
assistance. We should recognize that While trackers with a public
address may help a peer to locate and transfer message to remote
Peers by serving as proxies. This will increase the burden on
Tracker and will possibly make Tracker the bottleneck of the whole
system, So we do not encourage location to generally require and send
message through Tracker. Several ways can be utilized by peer to
locate and send message to remote peers without Tracker's assistance.
For example, if Peer IP Addresses, which represents the location of a
node in regular network context, are included in peerlist, a peer can
try to establish a connection with the remote peers by the IP
Addresses. However we must be ready to resolve the complicated
problem arising when peers are behind different NATs. If Peer IDs
are used in the peerlist, a peer may use typical p2p overlay locating
method to connect, directly or indirectly, with the remote peers,
e.g. RELOAD. In this case, the overlay will be responsible for NAT
traversal.
4.1.3. Requirement
Peer Protocol MUST provide a mechanism for peers behind different
NAT/Firewall to connect with each other.
4.2. Information Exchange
After effective connection is established between peers, peers will
exchange some information that will help them to decide where to
download the content.
4.2.1. Peerlist Sharing
In many peer to peer streaming protocols such as PPLive and PPStream,
client can obtain peerlist from both Tracker and remote peers. The
Gu & Bryan Expires January 6, 2011 [Page 6]
Internet-Draft Peer Protocol July 2010
tracker's main function is to record all peers in a particular swarm.
However, in practice, Trackers know all the candidate peers in a
particular swarm but they may not want to reply to a client with all
the candidate peers in a swarm, especially when there are too many
peers in a swarm. In many cases the Peer does not want to receive
all the candidate peers; In some cases, Tracker just provides a list
of reference peers, from which a peer can get more peerlist, if it
wants to.
4.2.1.1. Peerlist Request
4.2.1.1.1. Requirment
Peer Protocol MUST enable a peer to send request for peerlist to its
remote peers for a particular content, e.g. a particular swarm or
chunk.
4.2.1.1.2. Rationale
Peer protocol should grant client this ability, even though client
may not request peerlist from its remote peers (i.e., may rely
strictly on lists from the tracker).
4.2.1.2. Peerlist Response
4.2.1.2.1. Requirement
Peer Protocol MUST be able to create a response carrying a peerlist.
4.2.1.2.2. Rationale
When receiving 'Peerlist Request', a remote peer will pick out
candidate peers from local peerlist and encapsule them in 'Peerlist
Response'. The most direct and effective way to transport the
'Peerlist Response' is through Peer protocol.
4.2.1.3. Peerlist Parameter
4.2.1.3.1. Requirement
Peer Protocol SHOULD enable peers to indicate the number of peers in
peerlist when requesting peerlist from remote peers.
4.2.1.3.2. Rationale
According to [draft-gu-ppsp-survey], not all of the peers on the
peerlist are connected by the requesting peer. In fact, a peer will
first try some remote peers and will stop requesting if it finds
Gu & Bryan Expires January 6, 2011 [Page 7]
Internet-Draft Peer Protocol July 2010
enough data source. Besides, the more peers in peerlist, the more
bandwidth is consumed. So it will be good for requesting peer to
limit the number of peers in the peerlist, from bandwidth
perspective. Another reason is that a requesting peer may already
have large number of candidate peers, and it only want to get a low
number of additional candidate peers from remote peers.
4.2.1.3.3. Requirement
Peer Protocol SHOULD enable peer to indicate its own property when
request for peerlists from remote peers.
4.2.1.3.4. Rationale
PPSP is a system supporting a diversity of possible end hosts, mobile
and fixed, different bandwidth, different online time, various link
property and other performance factors. In regular P2P applications,
the dynamic status of peers makes it difficult to choose candidate
peers, this makes the static property of peers as the main input when
choosing candidate peers. For example, a peer with 100M uplink
bandwidth is much more popular than a peer with 10M uplink bandwidth,
i.e. more peers choose the first peer as a downloading peer because
they believe they can be served better. The result of this blind
popularity is that the first peer will be overloaded while the second
peer is idle. To make the whole system more effective and reach a
higher performance, we should try to take full advantage of the low
performance peers, as well as the high performance ones. Therefore a
peer can indicate its own property and the remote peers then choose
the similar peers into the response peerlist. For example, a peer
notifies the remote peer that it's an ADSL access node, then the
remote peer will try to choose some candidate peers with the same its
property.
4.2.2. Data Availability
4.2.2.1. Requirement
Peer protocol MUST enable peers to request for Data Availability from
remote peers.
4.2.2.2. Requirement
Peer protocol MUST enable peers to carry Data Availability on
themselves in responses to Data Availability Request.
Gu & Bryan Expires January 6, 2011 [Page 8]
Internet-Draft Peer Protocol July 2010
4.2.2.3. Rationale
Peer Protocol should enable a peer to request Data Availability from
a remote peer and the remote peer, , should be able to carry the Data
Availability in the response. Data Availability can be embodied in
multiple form. For example it can be a Bitmap, where each bit
represents a particular block of a chunk. This draft will not define
a specification for Bitmap or other kind of Data Availability
description file. We will use Bitmap to represent the Data
Availability description file in the following part of the draft,
however it does not mean we propose to use Bitmap in PPSP. If we
decide not to use Bitmap to indicate data availability, we need to
define a data structure for that purpose. The Bitmap exchanged
between peers can contain the Data Availability of at least one
Chunk.
4.2.2.4. Requirement
Peer protocol MUST be able to carry different data structures for
different applications.
4.2.2.5. Rationale
The data model of different applications might be different. For
example, Data Availability is presented by bitmap in some
applications, while we cannot make sure that all applications use
bitmap to exchange chunks availability. Peerlist exchanged among
peers may also be different. Peer Protocol must be agnostic of the
specification of different applications.
4.2.3. Property Exchange
4.2.3.1. Requirement
Peer protocol SHOULD enable peers to exchange peer property.
4.2.3.2. Rationale
This requirement is due to the same reason described in the above
requirement, which enable peer to indicate its property when request
for peerlist. With this functionality, a peer can exchange property
with the candidate peers it obtains from Tracker or remote peers.
4.3. Connection Status
These requirements are influenced by [BittorrentSpecification].
Gu & Bryan Expires January 6, 2011 [Page 9]
Internet-Draft Peer Protocol July 2010
4.3.1. Application-level Congestion Control
Peer Protocol should enable a peer to notify its remote peer whether
it would like to upload content to the remote peer.
4.3.2. Rationale
This is especially meaningful when a peer is overloaded. The peer,
which is very popular and is distributed in the response peerlist to
multiple requesting peers, is now busy with uploading to some remote
peers, when a new peer connects to it and request for further action.
If the peer makes no feedback, the requesting peer may ask again and
again, based on the application configuration. As an example, in
BitTorrent, a peer may respond with a Choked tag, which means 'I have
recorded your request. Never send request to me until I send an
UnChoked message to you'. The choked remote peer could wait for the
peer's unchoked message, or just try other peers.
4.4. Real-time Features
4.4.1. Requirement
Peer Protocol MUST support synchronous downloading/uploading.
4.4.2. Rationale
This requirement means a peer can download from multiple peers, or
upload to multiple peers at the same time. There are various
situations that Peer Protocol is required to support multiple
streams. 1) The audio and video streaming of the application are
separated. In this case, a peer must download audio and video from
different peers at the same time to play the stream locally. 2) A
peer need to download from multiple peers to satisfy the playback
rate and the quality. E.g. some low bandwidth peers are organized
together to provide data downloading for a peer. Or a peer has very
high bandwidth, so it can download from multiple regular peers in
order to get the whole stream faster. Similarly, if a layered codec
is used, the layers may be obtained from different locations. Note
that this requirement may be satisfied by reusing an existing IETF
protocol providing these capabilities.
4.4.3. Requirement
Peer protocol MUST provide corresponding mechanism to eliminate or
decrease the influence of Jitter and packet loss.
Gu & Bryan Expires January 6, 2011 [Page 10]
Internet-Draft Peer Protocol July 2010
4.4.4. Rationale
Since streaming applications are extremely sensitive to jitter and
packet loss, which degrades Quality of Experience remarkably, Peer
protocol must take these features into consideration and provide a
mechanism for peers to reduce the influence of jitter and packet loss
and guarantee the streaming quality. Note that this requirement may
be satisfied by reusing an existing IETF protocol providing these
capabilities.
4.5. Transportation Negotiation
4.5.1. Requirement
Peer protocol MUST be able to negotiate a transportation protocol
that both peers can support.
4.5.2. Rationale
Muptiple Transportation protocol can be used to transport a streaming
content, e.g. RTP, RTSP, FTP, UDP, TCP, MSRP, etc.. So peers must
try to negotiate a transportation protocol and then exchange
signaling messages to set up a transportation connection between
them. Note that this requirement may be satisfied by reusing an
existing IETF protocol providing these capabilities.
4.6. Security
4.6.1. Requirement
Peer Protocol MUST guarantee peers' privacy.
4.6.2. Rationale
Peer Protocol must guarantee that a peer's request can only be
received by the targeted remote peers. That means Peer Protocol must
prevent the message from being wire tapped or changed by a man in the
middle
4.6.3. Requirement
Peer SHOULD be able to verify the identity of the remote peer.
4.6.4. Rationale
Attackers may pretend to be someone else and ask peers to send data
to innocent peers. This is a normal kind of attack in P2P overlay.
Peer Protocol should provide a mechanism to avoid such attack.
Gu & Bryan Expires January 6, 2011 [Page 11]
Internet-Draft Peer Protocol July 2010
5. Example Flow
In this section, we introduce general example flow of Peer protocol.
Requesting Peer Remote Peers
*******************Begin Locating (Optional)***************
(IP Addresses in Peerlist) No Locating
(IDs in Peerlist) Reload
(URLs in Peerlist) SIP
*******************Finish Locating (Optional)***************
*******************Begin Information Exchange***************
|----------------1. Request Peerlist(Optional)----------->|
|<---------------2. Response with peerlist (Optional)-----|
(1 and 2 is not mandatory.)
(Locally choose remote peers to request Data Availability)
|---------3. Request Data Availability (Optional)-------->|
|<--------4. Response with Data Availability (Optional)---|
(No 3 and 4 in Live streaming)
(Locally choose remote peers with desired data, out of scope)
*******************Finish Information Exchange***************
*******************Begin Transport Negotiation (Optional)****
|<-5. Report own Transport Protocol Types and Port Numbers->|
|--6. Requesting Peer decides which protocol(Port numbers)->|
| are used to transfer data |
*******************Finish Transport Negotiation (Optional)***
*******************Begin Transportation**********************
|----------------7. Desired Chunks (Optional)------------->|
(Desired Chunks or streaming are transferred, using existing protocl)
*******************Finish Transportation*********************
Fig. 2 Example Flow
6. Peer Locating Protocol
Three options for the Peer Locating Protocol have been proposed,
Gu & Bryan Expires January 6, 2011 [Page 12]
Internet-Draft Peer Protocol July 2010
Reload, SIP and a new Protocol. The decision of Identity type
included in peerlist in Tracker protocol will decide the choice of
Peer Locating Protocol. Meanwhile, the effectiveness of these
options as analysed in this draft will influence the decision of
Tracker protocol.
Up to now, we have not make decision on which protocol should be
used, [Reload], SIP, other existing protocol or a new protocol. We
will leave this as an open issuse for the WG to discuss.
6.1. General Comments
From a Bandwidth perspective, SIP is heavier than RELOAD. A new
protocol could be either lighter or heavier - depending on the
specific encoding of the protocol.
From a signaling delay point of view, RELOAD may be less effective in
locating peers, as the messages has to transfered through
intermediate peers before it finally get to the destination peer. In
practice, this may not be an important issue. A potentially bigger
issue in the use of RELOAD is that the swarm is likely to be a
loosely organized, unstructured collection of peers (using a gossip
protocol), rather than a structured DHT, and RELOAD may potentially
be too heavy for this application. One alternative is that peers are
connected in a DHT, and the DHT is used to locate peers, which then
establish direct connections to communicate (perhaps using SIP)
SIP may provide additional advantages when negotiating the connection
(see below), as it is intended for this very purpose. SIP provides
many capabilities that would not be used in this context, however,
and a discussion of how to limit the capabilities in order to keep
complexity to a minimum would be required.
6.2. NAT Traversal
NAT Traversal is an unavoidable issue in Peer protocol. Peers may
reside behind various kinds of NAT/Firewall, which will make the
issue more complicate. In NAT Traversal aspect, Peer protocol need
to cooperate with Tracker protocol closely. Instead of abiding
Tracker protocol's decision, the designing of Peer protocol will
significantly influence the decision of Tracker protocol.
Several kinds of peer identity are mentioned to be likely included in
Peerlists in response to Peer's request for desired chunks or swarms,
Peer ID, Peer IP Address and Peer URL. In this section we will
describe how NAT Traversal will work for each distinct peer identity,
without invloving detail protocol.
Gu & Bryan Expires January 6, 2011 [Page 13]
Internet-Draft Peer Protocol July 2010
6.2.1. Peer ID in Peerlist
If Peer IDs are included in Peerlist, the requesting peer needs a way
to locate peers that the peer IDs represent. [Reload] introduce a
method to locate and establish connection with remote peers by Peer
IDs. [TODO: Detailed explanation] Essentially, by returning peerIDs
and using an overlay protocol, one relies on the overlay to provide
NAT traversal capabilities.
6.2.2. Peer IP Address in Peerlist
If Peer Addresses are used to indicate peers' identity, the
requesting peer can quickly locate the remote peer, which is must
faster than [Reload] in which messages need to be transferred through
an overlay path.
However, the shortcoming of using Peer Address is very significant.
If one or both communicating peers are behind NAT, peers can not
connect with each other easily. Typically, they need an entity with
public Address and can be connected by both peers. In PPSP system, a
natural Public entity for this purpose is Tracker. As described in
Tracker Protocol, Tracker should have public address and each peer
has to connect with Tracker before they can join any swarm. As a
result, the tracker can serve to help establish a direct connection
between peers, serving as a relay if required.
6.2.3. URI in Peerlist
If SIP is reused, a SIP URL may be included in peerlist. Then we can
use ICE to traverse NAT, again using the tracker as a proxy/relay as
required.
7. Peer Signalling Protocol (New Protocol)
7.1. Options
With regard to a new Peer Protocol, if we choose this path we also
have two options, Binary encoding and ASCII encoding. According to
[draft-gu-ppsp-survey], most peer to peer applications choose Binary
protocol. In this draft, we leave this as an open issue for WG to
discuss. If there is interest in a new protocol, we will introduce
example message encoding of Peer Protocol in both Binary and HTTP.
7.2. Binary Protocol
Gu & Bryan Expires January 6, 2011 [Page 14]
Internet-Draft Peer Protocol July 2010
7.2.1. Common Header
To Be Added
7.2.2. Information Exchange
To Be Added
7.2.3. Transport protocol negotiation
To Be Added
7.2.4. Data Request
To Be Added
7.3. HTTP-Based Protocol
7.3.1. Common Header
To Be Added
7.3.2. Information Exchange
To Be Added
7.3.3. Transport protocol negotiation
To Be Added
7.3.4. Data Request
To Be Added
8. Security Consideration
The security considerations are highly dependent upon the protocol
selected to transfer messages for PPSP. Security will be considered
in further version of this draft.
9. Acknowledgments
We give our achnoledgement to Roni Even, Zhang Yunfei and Liao
Hongluan for them valuable comments and suggestions.
Gu & Bryan Expires January 6, 2011 [Page 15]
Internet-Draft Peer Protocol July 2010
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.
[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>.
10.2. Informative References
[draft-zhang-ppsp-problem-statement]
Zhang, Y., Zong, N., Camarillo, V., Seng, J., and R. Yang,
"Problem Statement of P2P Streaming Protocol (PPSP)",
October 2009, <draft-zhang-ppsp-problem-statement>.
[draft-zong-ppsp-reqs]
Zong, N., Zhang, Y., Pascual, V., and C. Williams, "P2P
Streaming Protocol (PPSP) Requirements", October 2009,
<draft-zong-ppsp-reqs>.
[draft-gu-ppsp-survey]
Gu, Y., Zong, N., Zhang, H., Zhang, Y., Camarillo, G., and
Y. Liu, "Survey of P2P Streaming Applications",
October 2009, <draft-gu-ppsp-survey>.
[draft-gu-ppsp-tracker-protocol]
Gu, Y., Bryan, D., Zhang, Y., and H. Liao, "PPSP Tracker
Protocol", March 2010, <draft-gu-ppsp-tracker-protocol>.
[BittorrentSpecification]
"Bittorrent Protocol Specification v1.0", February 2010,
<Bittorrent Specification>.
[draft-ietf-p2psip-base]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", March 2010, <draft-ietf-p2psip-base>.
Gu & Bryan Expires January 6, 2011 [Page 16]
Internet-Draft Peer Protocol July 2010
Authors' Addresses
Yingjie Gu
Huawei
No.101 Software Avenue
Nanjing, Jiangsu Province 210012
P.R.China
Phone: +86-25-56622638
Email: guyingjie@huawei.com
David A. Bryan
Cogent Force, LLC / Huawei
Williamsburg, Virginia,
USA
Phone:
Email: dbryan@ethernot.org
Gu & Bryan Expires January 6, 2011 [Page 17]