PPSP Y. Gu
Internet-Draft Huawei
Intended status: Informational D. Bryan
Expires: April 28, 2011 Cogent Force, LLC / Huawei
October 25, 2010
Peer Protocol
draft-gu-ppsp-peer-protocol-01
Abstract
This document presents a high-level proposal for the PPSP peer
protocol. The architecture of the system, requirements for the
protocol, example call flow, and open issues are presented.
Requirements Language
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].
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 April 28, 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
Gu & Bryan Expires April 28, 2011 [Page 1]
Internet-Draft Peer Protocol October 2010
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. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Protocol Architecture . . . . . . . . . . . . . . . . . . 4
3. Requirements on a Peer Protocol . . . . . . . . . . . . . . . 6
3.1. Locating and Connection . . . . . . . . . . . . . . . . . 6
3.2. Information Exchange . . . . . . . . . . . . . . . . . . . 6
3.2.1. Peerlist Sharing . . . . . . . . . . . . . . . . . . . 6
3.2.1.1. Peer Distribution of Peerlists . . . . . . . . . . 7
3.2.1.2. Peerlist Search Parameter . . . . . . . . . . . . 7
3.2.2. Data Availability . . . . . . . . . . . . . . . . . . 7
3.2.3. Property Exchange . . . . . . . . . . . . . . . . . . 8
3.3. Application-level Congestion Control . . . . . . . . . . . 8
3.4. Simultaneous Uploading/Download . . . . . . . . . . . . . 8
3.5. Transportation Negotiation . . . . . . . . . . . . . . . . 9
3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Example Call Flow . . . . . . . . . . . . . . . . . . . . . . 10
5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Gu & Bryan Expires April 28, 2011 [Page 2]
Internet-Draft Peer Protocol October 2010
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 chunks 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.
Meanwhile there are some discussions on the mailing list about
reusing RELOAD defined in [I-D.ietf-p2psip-base] to implement 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. In this draft we present a skeleton design for how
RELOAD could be used to implement a PPSP Peer protocol. In this use,
the primary purpose of RELOAD is not to store and exchange the
information listed above, but primarily as a mechanism to connect the
peers, establish connections across NATs, and for peers to locate
each other.
This draft does not presently attempt to define the detailed
implementation for a PPSP Peer protocol, but rather presents a
proposed architecture and discusses the use of RELOAD and the type of
messages to be exchanged.
Additionally, we present a set of requirements on the detailed
protocol to be defined based on this proposal. As time advances,
these will be removed, or perhaps migrated to a stand-alone
requirements document.
In developing this suggest approach, a number of questions arose, and
these are documented in an open issues section at the end of the
document.
Gu & Bryan Expires April 28, 2011 [Page 3]
Internet-Draft Peer Protocol October 2010
2. 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. Please see section FIX for a
list of open questions.
2.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 live streaming or a group of peers
exchanging data for an offline video is as follows:
1. The first step for the peer is to join the RELOAD overlay which
connects peers. This requires that the peer obtain the location
of a bootstrap peer and (likely) insert itself into the RELOAD
overlay. Note that because RELOAD provides significant NAT
traversal capabilities, the argument that some devices may not
serve as peers, but only clients due to connectivity issues is
not compelling, but here may be other reasons why a peer may not
be able to participate fully, and may only participate as a
RELOAD client. Note further that the tracker may be participate
in the overlay as a RELOAD peer itself, providing a well-known
stable bootstrap peer, but this is still an open issue.
2. 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
Gu & Bryan Expires April 28, 2011 [Page 4]
Internet-Draft Peer Protocol October 2010
example we are concerned only with obtaining the Peerlist.
* This list does not contain IP addresses, but rather RELOAD
Peer-IDs.
* The mechanism for obtaining the swarm ID itself is presently
out of the scope of this proposal
3. The peer uses the RELOAD protocol to establish a connection to at
least one of the peers in the Peerlist, based on the Peer-ID.
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.
4. 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.
5. 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.
6. 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.
7. 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. (although note that application-
level congestion control should be provided, see Section 3.3
Gu & Bryan Expires April 28, 2011 [Page 5]
Internet-Draft Peer Protocol October 2010
3. Requirements on a Peer Protocol
In this section, we present some requirements we believe the peer
protocol we define above must meet, and in some cases, explain why
the design above meets that requirement. This list is not intended
to be exhaustive, but to help frame the problem.
3.1. Locating and Connection
Peer Locating is closely related to the Tracker protocol. A peer
will get a peerlist from Tracker, with Peer IDs, and may get lists
from other peers as well.
REQUIREMENTS: Peers SHOULD be able to locate other peers in peerlist
and connect to them with minimal or without the Tracker's assistance.
Peers MUST be able to operate behind NATs, and connect to other peers
that are behind NATs.
RATIONALE: Peers must be able to find a path between themselves and a
remote peer, on which messages can pass through. Our proposal
addresses this by using RELOAD, which offers capabilities to
establish connections between peers, including NAT traversal as
required. The tracker does not need to be involved in the
establishment of these connections (although there does need to be
some way for the peers to bootstrap and originally join the RELOAD
overlay, and this capability may be provided by the tracker, acting
as a RELOAD peer.)
3.2. Information Exchange
After an effective connection is established between peers, peers
will exchange information that will help them to decide where to
download the content.
3.2.1. Peerlist Sharing
In many peer to peer streaming protocols such as PPLive and PPStream,
clients can obtain peerlist from both Tracker and remote peers. The
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 (or be able) to provide 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, the Tracker will
provides a list of reference peers, from which a peer can get request
a list of additional peers.
Gu & Bryan Expires April 28, 2011 [Page 6]
Internet-Draft Peer Protocol October 2010
3.2.1.1. Peer Distribution of Peerlists
REQUIREMENT: The Peer Protocol MUST enable a peer to send a request
for peerlist to its remote peers for a particular content, e.g. a
particular swarm or chunk, and enable peers to return the requested
information. (Note this is still an open issue, as discussed in
Section 5. The authors personally feel such a capability is
essential.
RATIONALE : The 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). The protocol should be
broadly applicable to many possible architectures, and providing this
capability helps assure that is the case.
3.2.1.2. Peerlist Search Parameter
REQUIREMENT: The Peer Protocol SHOULD enable peers to provide
parameters when requesting peerlists from other peers, such as number
of peers to return and capabilities of those peers.
RATIONALE: The details of the queries supported (do peers include all
peers they know about, allow search capabilities, etc.) is an open
question for discussion. The authors advocating a rich set of
capabilities.
[I-D.gu-ppsp-survey] describes how in some systems 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 enough data source. Additionally, the more peers in
peerlist, the more bandwidth is consumed. Therefore the requesting
peer should be able to limit the number of peers in the peerlist.
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.
Additionally, peers may want to be able to select for various static
or dynamic properties of peers such as uptime, capacity, current
estimated load, etc. Allowing for parameter-based searches will
support this property. Open issue: Should we only for searching for
static properties, as the dynamic properties may change too often for
peers to have current information, and instead use the information
exchange mechanism between peers if this information is requested?
3.2.2. Data Availability
REQUIREMENTS: The peer protocol MUST enable peers to request for Data
Availability from remote peers. The peer protocol MUST enable peers
Gu & Bryan Expires April 28, 2011 [Page 7]
Internet-Draft Peer Protocol October 2010
to carry Data Availability about themselves in responses to Data
Availability Requests. The peer protocol MUST be extensible and
support different data structures to represent data availability for
different applications.
RATIONALE: The peer Protocol should enable a peer to request Data
Availability from a remote peer and the remote peer, should be able
to create a response carrying the Data Availability information.
Data Availability information could be a Bitmap, where each bit
represents a particular block of a chunk. It is an open question if
a default, mandatory-to-implement format for the data availability
information should be included in this protocol, or if the protocol
should simply convey bulk data and various usages of PPSP can define
this data. The protocol must support an extensible way to represent
the data, as data models for different applications may vary.
3.2.3. Property Exchange
REQUIREMENT: The peer protocol SHOULD enable peers to request and
exchange peer property information with one another.
RATIONALE: As we want to allow for searching based on peer
capabilities, some of which may be dynamic (see Section 3.2.1.2), it
makes sense that there also be some capability to directly query
peers and exchange similar information outside the context of using
these properties as a filter when requesting a peerlist.
3.3. Application-level Congestion Control
REQUIREMENT: The Peer Protocol SHOULD enable a peer to notify its
remote peer whether it it is willing to establish a connection with
that peer.
RATIONALE: This allows peers to provide meaningful, high-level
congestion control. This is especially important when a peer is
overloaded. A very popular peer may be distributed in peerlists to
multiple requesting peers, and become overloaded with uploading to
some remote peers, when a new peer connects to it and request for
further action. The peer must have a way of rejecting requests to
prevent retransmissions and overload condition. Note that this is
prior to negotiating a particular streaming or transfer mechanism,
and is not to be used in place of flow control and congestion control
mechanisms within the transfer technique.
3.4. Simultaneous Uploading/Download
REQUIREMENT: The peer Protocol MUST support simultaneous downloading/
uploading.
Gu & Bryan Expires April 28, 2011 [Page 8]
Internet-Draft Peer Protocol October 2010
RATIONALE: This requirement means the protocol must support allowing
peers to 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.
3.5. Transportation Negotiation
REQUIREMENT: The peer protocol MUST be able to negotiate a
transportation protocol that both peers can support (assuming the
peers share a common protocol).
RATIONALE: Multiple 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. (for example
SIP with SDP or the advertisement/proposal model suggested in
Section 2.1.
3.6. Security
NOTE: The authors are aware this section is not well articulated, and
needs to be improved. This is a place holder for the better section
that is clearly required.
REQUIREMENTS: The peer Protocol MUST guarantee peers' privacy. Peers
SHOULD be able to verify the identity of the remote peer.
RATIONALE: The 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. 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 April 28, 2011 [Page 9]
Internet-Draft Peer Protocol October 2010
4. Example Call Flow
This is a very high-level example of a session in which a peer joins
an overlay, joins a swarm, and retrieves some data (either via blocks
or by streaming). The protocol used is indicated for each
transaction.
*********************** Join Overlay **********************
Requesting Peer Bootstrap Peer
|<------------------ Join Sequence (RELOAD) ------------->|
********************** Obtain Peerlist *******************
Requesting Peer Tracker
|------------ Request Peerlist (Tracker Protocol) ------->|
|<----------- Response (Tracker Protocol) ----------------|
************ Open Connections to Remote Peers ************
Requesting Peer Remote Peers
|<------------- Connection Sequence (RELOAD) ------------>|
(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)
************ Query Peers for Available Data **************
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)
Gu & Bryan Expires April 28, 2011 [Page 10]
Internet-Draft Peer Protocol October 2010
5. Open Issues
1. Need to define the mechanism by which the peers are able to
initially insert themselves into the RELOAD overlay. One
possibility is for the tracker itself to be the bootstrap peer,
and to facilitate the connection to the admitting peer.
2. Do we only allow peers to obtain peerlists from the tracker, or
do we also allow peers to exchange peerlist information between
each other using the peer protocol?
3. Exactly what search capabilities do we want to support for
requesting peerlists? In other words, can a peer specify either
details about the information to be shared (only want high-
definition video, for example) or about the type of peers it
would like to connect to (certain bandwidth, topological
"closeness", etc.) If these search capabilities are supported
and peers can exchange lists directly among themselves, do the
search capabilities differ between searching the tracker and
searching between peers?
4. Do we need to define some default format for bitmaps, or should
the protocol be agnostic to this? May want a shared mandatory to
implement version to enable interoperability.
5. We have removed the requirements around jitter and packet loss,
primarily because the currently envisioned protocol negotiates
connections using an underlying protocol, and that protocol would
then be responsible to negotiate such constraints. Should that
be included somehow in describing what makes for a good
transport, or will that (and perhaps some other requirements)
eventually migrate to a different requirements document?
6. While it seems a lightweight gossip protocol is the appropriate
type of protocol for this design, it is unclear what the encoding
should be. There has been strong interest in an HTTP/XML
encoding for the tracker protocol, and the same approach could be
used here, or a lightweight binary protocol could be defined.
7. Should we allow peers to include dynamic information in the
search parameters when querying other peers for additional
peerlists? Do we limit to static properties, as the dynamic
properties may change too often for peers to have current
information, and instead use the information exchange mechanism
between peers if this information is requested?
Gu & Bryan Expires April 28, 2011 [Page 11]
Internet-Draft Peer Protocol October 2010
6. Security Considerations
The security considerations will depend on the eventual design of the
PPSP peer protocol. Security will be considered in further version
of this draft.
7. IANA Considerations
There are presently no IANA considerations with this document.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[BitTorrent]
"BitTorrent Protocol Specification v1.0, February 2010".
Copy available at
http://wiki.theory.org/BitTorrentSpecification
[I-D.gu-ppsp-survey]
Yingjie, G., Zong, N., Zhang, H., Zhang, Y., Lei, J.,
Camarillo, G., and L. Yong, "Survey of P2P Streaming
Applications", draft-gu-ppsp-survey-02 (work in progress),
October 2010.
[I-D.gu-ppsp-tracker-protocol]
Yingjie, G., Bryan, D., Zhang, Y., and H. liao, "Tracker
Protocol", draft-gu-ppsp-tracker-protocol-02 (work in
progress), October 2010.
[I-D.ietf-p2psip-base]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-11 (work in
progress), October 2010.
[I-D.ietf-ppsp-problem-statement]
Zhang, Y., Zong, N., Camarillo, G., Seng, J., and Y. Yang,
"Problem Statement of P2P Streaming Protocol (PPSP)",
draft-ietf-ppsp-problem-statement-00 (work in progress),
Gu & Bryan Expires April 28, 2011 [Page 12]
Internet-Draft Peer Protocol October 2010
October 2010.
[I-D.ietf-ppsp-reqs]
Zong, N., Zhang, Y., Avila, V., Williams, C., and L. Xiao,
"P2P Streaming Protocol (PPSP) Requirements",
draft-ietf-ppsp-reqs-00 (work in progress), October 2010.
[I-D.peterson-sipcore-advprop]
Peterson, J. and C. Jennings, "The Advertisement/Proposal
Model of Session Description",
draft-peterson-sipcore-advprop-00 (work in progress),
February 2010.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
Appendix A. Acknowledgments
The authors would like to thank Roni Even, Zhang Yunfei and Liao
Hongluan for their valuable comments and suggestions.
Authors' Addresses
Yingjie Gu
Huawei
No. 101 Software Avenue
Nanjing, Jiangsu Province 210012
P.R.China
Phone: +86-25-56624760
Email: guyingjie@huawei.com
David A. Bryan
Cogent Force, LLC / Huawei
Email: dbryan@ethernot.org
Gu & Bryan Expires April 28, 2011 [Page 13]