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


   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",
   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 .

   This draft also uses some new terms.  We list the relevant terms as

   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

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.  Peerlist Request  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.  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).  Peerlist Response  Requirement

   Peer Protocol MUST be able to create a response carrying a peerlist.  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.  Peerlist Parameter  Requirement

   Peer Protocol SHOULD enable peers to indicate the number of peers in
   peerlist when requesting peerlist from remote peers.  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.  Requirement

   Peer Protocol SHOULD enable peer to indicate its own property when
   request for peerlists from remote peers.  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

4.2.2.  Data Availability  Requirement

   Peer protocol MUST enable peers to request for Data Availability from
   remote peers.  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  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.  Requirement

   Peer protocol MUST be able to carry different data structures for
   different applications.  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  Requirement

   Peer protocol SHOULD enable peers to exchange peer property.  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

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

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

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.

              Jennings, C., Lowekamp, B., Ed., Rescorla, E., and H.
              Schulzrinne, "draft-ietf-p2psip-base-07", February 2010,

10.2.  Informative References

              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>.

              Zong, N., Zhang, Y., Pascual, V., and C. Williams, "P2P
              Streaming Protocol (PPSP) Requirements", October 2009,

              Gu, Y., Zong, N., Zhang, H., Zhang, Y., Camarillo, G., and
              Y. Liu, "Survey of P2P Streaming Applications",
              October 2009, <draft-gu-ppsp-survey>.

              Gu, Y., Bryan, D., Zhang, Y., and H. Liao, "PPSP Tracker
              Protocol", March 2010, <draft-gu-ppsp-tracker-protocol>.

              "Bittorrent Protocol Specification v1.0", February 2010,
              <Bittorrent Specification>.

              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
   No.101 Software Avenue
   Nanjing, Jiangsu Province  210012

   Phone: +86-25-56622638
   Email: guyingjie@huawei.com

   David A. Bryan
   Cogent Force, LLC / Huawei
   Williamsburg, Virginia,

   Email: dbryan@ethernot.org

Gu & Bryan               Expires January 6, 2011               [Page 17]