tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7574

 Errata 
Proposed STD
Pages: 85
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: PPSP

Peer-to-Peer Streaming Peer Protocol (PPSPP)

Part 1 of 4, p. 1 to 21
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                         A. Bakker
Request for Comments: 7574                  Vrije Universiteit Amsterdam
Category: Standards Track                                    R. Petrocco
ISSN: 2070-1721                                           V. Grishchenko
                                           Technische Universiteit Delft
                                                               July 2015


              Peer-to-Peer Streaming Peer Protocol (PPSPP)

Abstract

   The Peer-to-Peer Streaming Peer Protocol (PPSPP) is a protocol for
   disseminating the same content to a group of interested parties in a
   streaming fashion.  PPSPP supports streaming of both prerecorded (on-
   demand) and live audio/video content.  It is based on the peer-to-
   peer paradigm, where clients consuming the content are put on equal
   footing with the servers initially providing the content, to create a
   system where everyone can potentially provide upload bandwidth.  It
   has been designed to provide short time-till-playback for the end
   user and to prevent disruption of the streams by malicious peers.
   PPSPP has also been designed to be flexible and extensible.  It can
   use different mechanisms to optimize peer uploading, prevent
   freeriding, and work with different peer discovery schemes
   (centralized trackers or Distributed Hash Tables).  It supports
   multiple methods for content integrity protection and chunk
   addressing.  Designed as a generic protocol that can run on top of
   various transport protocols, it currently runs on top of UDP using
   Low Extra Delay Background Transport (LEDBAT) for congestion control.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7574.

Page 2 
Copyright Notice

   Copyright (c) 2015 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.

Table of Contents

   1. Introduction ....................................................5
      1.1. Purpose ....................................................5
      1.2. Requirements Language ......................................6
      1.3. Terminology ................................................6
   2. Overall Operation ...............................................9
      2.1. Example: Joining a Swarm ...................................9
      2.2. Example: Exchanging Chunks ................................10
      2.3. Example: Leaving a Swarm ..................................10
   3. Messages .......................................................11
      3.1. HANDSHAKE .................................................11
           3.1.1. Handshake Procedure ................................12
      3.2. HAVE ......................................................14
      3.3. DATA ......................................................15
      3.4. ACK .......................................................15
      3.5. INTEGRITY .................................................15
      3.6. SIGNED_INTEGRITY ..........................................16
      3.7. REQUEST ...................................................16
      3.8. CANCEL ....................................................16
      3.9. CHOKE and UNCHOKE .........................................17
      3.10. Peer Address Exchange ....................................17
           3.10.1. PEX_REQ and PEX_RES Messages ......................17
      3.11. Channels .................................................19
      3.12. Keep Alive Signaling .....................................20
   4. Chunk Addressing Schemes .......................................21
      4.1. Start-End Ranges ..........................................21
           4.1.1. Chunk Ranges .......................................21
           4.1.2. Byte Ranges ........................................21
      4.2. Bin Numbers ...............................................22
      4.3. In Messages ...............................................23
           4.3.1. In HAVE Messages ...................................23
           4.3.2. In ACK Messages ....................................24

Top      ToC       Page 3 
   5. Content Integrity Protection ...................................24
      5.1. Merkle Hash Tree Scheme ...................................25
      5.2. Content Integrity Verification ............................26
      5.3. The Atomic Datagram Principle .............................27
      5.4. INTEGRITY Messages ........................................28
      5.5. Discussion and Overhead ...................................28
      5.6. Automatic Detection of Content Size .......................29
           5.6.1. Peak Hashes ........................................29
           5.6.2. Procedure ..........................................31
   6. Live Streaming .................................................32
      6.1. Content Authentication ....................................32
           6.1.1. Sign All ...........................................33
           6.1.2. Unified Merkle Tree ................................33
                  6.1.2.1. Signed Munro Hashes .......................34
                  6.1.2.2. Munro Signature Calculation ...............36
                  6.1.2.3. Procedure .................................37
                  6.1.2.4. Secure Tune In ............................37
      6.2. Forgetting Chunks .........................................38
   7. Protocol Options ...............................................38
      7.1. End Option ................................................39
      7.2. Version ...................................................39
      7.3. Minimum Version ...........................................40
      7.4. Swarm Identifier ..........................................40
      7.5. Content Integrity Protection Method .......................41
      7.6. Merkle Tree Hash Function .................................41
      7.7. Live Signature Algorithm ..................................42
      7.8. Chunk Addressing Method ...................................42
      7.9. Live Discard Window .......................................43
      7.10. Supported Messages .......................................44
      7.11. Chunk Size ...............................................44
   8. UDP Encapsulation ..............................................45
      8.1. Chunk Size ................................................45
      8.2. Datagrams and Messages ....................................46
      8.3. Channels ..................................................47
      8.4. HANDSHAKE .................................................47
      8.5. HAVE ......................................................48
      8.6. DATA ......................................................48
      8.7. ACK .......................................................49
      8.8. INTEGRITY .................................................50
      8.9. SIGNED_INTEGRITY ..........................................51
      8.10. REQUEST ..................................................52
      8.11. CANCEL ...................................................52
      8.12. CHOKE and UNCHOKE ........................................53
      8.13. PEX_REQ, PEX_RESv4, PEX_RESv6, and PEX_REScert ...........53
      8.14. KEEPALIVE ................................................55
      8.15. Flow and Congestion Control ..............................56
      8.16. Example of Operation .....................................57
   9. Extensibility ..................................................61

Top      ToC       Page 4 
      9.1. Chunk Picking Algorithms ..................................61
      9.2. Reciprocity Algorithms ....................................62
   10. IANA Considerations ...........................................62
      10.1. PPSPP Message Type Registry ..............................62
      10.2. PPSPP Option Registry ....................................62
      10.3. PPSPP Version Number Registry ............................62
      10.4. PPSPP Content Integrity Protection Method Registry .......62
      10.5. PPSPP Merkle Hash Tree Function Registry .................63
      10.6. PPSPP Chunk Addressing Method Registry ...................63
   11. Manageability Considerations ..................................63
      11.1. Operations ...............................................63
           11.1.1. Installation and Initial Setup ....................63
           11.1.2. Migration Path ....................................64
           11.1.3. Requirements on Other Protocols and
                   Functional Components .............................64
           11.1.4. Impact on Network Operation .......................64
           11.1.5. Verifying Correct Operation .......................65
           11.1.6. Configuration .....................................65
      11.2. Management Considerations ................................66
           11.2.1. Management Interoperability and Information .......67
           11.2.2. Fault Management ..................................67
           11.2.3. Configuration Management ..........................67
           11.2.4. Accounting Management .............................68
           11.2.5. Performance Management ............................68
           11.2.6. Security Management ...............................68
   12. Security Considerations .......................................68
      12.1. Security of the Handshake Procedure ......................68
           12.1.1. Protection against Attack 1 .......................69
           12.1.2. Protection against Attack 2 .......................70
           12.1.3. Protection against Attack 3 .......................70
      12.2. Secure Peer Address Exchange .............................71
           12.2.1. Protection against the Amplification Attack .......71
           12.2.2. Example: Tracker as Certification Authority .......72
           12.2.3. Protection against Eclipse Attacks ................73
      12.3. Support for Closed Swarms ................................73
      12.4. Confidentiality of Streamed Content ......................74
      12.5. Strength of the Hash Function for Merkle Hash Trees ......74
      12.6. Limit Potential Damage and Resource Exhaustion by
            Bad or Broken Peers ......................................74
           12.6.1. HANDSHAKE .........................................75
           12.6.2. HAVE ..............................................75
           12.6.3. DATA ..............................................75
           12.6.4. ACK ...............................................75
           12.6.5. INTEGRITY and SIGNED_INTEGRITY ....................76
           12.6.6. REQUEST ...........................................76
           12.6.7. CANCEL ............................................76
           12.6.8. CHOKE .............................................77
           12.6.9. UNCHOKE ...........................................77

Top      ToC       Page 5 
           12.6.10. PEX_RES ..........................................77
           12.6.11. Unsolicited Messages in General ..................77
      12.7. Exclude Bad or Broken Peers ..............................77
   13. References ....................................................78
      13.1. Normative References .....................................78
      13.2. Informative References ...................................79
   Acknowledgements ..................................................84
   Authors' Addresses ................................................85

1.  Introduction

1.1.  Purpose

   This document describes the Peer-to-Peer Streaming Peer Protocol
   (PPSPP), designed for disseminating the same content to a group of
   interested parties in a streaming fashion.  PPSPP supports streaming
   of both prerecorded (on-demand) and live audio/video content.  It is
   based on the peer-to-peer paradigm where clients consuming the
   content are put on equal footing with the servers initially providing
   the content, to create a system where everyone can potentially
   provide upload bandwidth.

   PPSPP has been designed to provide short time-till-playback for the
   end user and to prevent disruption of the streams by malicious peers.
   Central in this design is a simple method of identifying content
   based on self-certification.  In particular, content in PPSPP is
   identified by a single cryptographic hash that is the root hash in a
   Merkle hash tree calculated recursively from the content [MERKLE]
   [ABMRKL].  This self-certifying hash tree allows every peer to
   directly detect when a malicious peer tries to distribute fake
   content.  The tree can be used for both static and live content.
   Moreover, it ensures only a small amount of information is needed to
   start a download and to verify incoming chunks of content, thus
   ensuring short start-up times.

   PPSPP has also been designed to be extensible for different
   transports and use cases.  Hence, PPSPP is a generic protocol that
   can run directly on top of UDP, TCP, or other protocols.  As such,
   PPSPP defines a common set of messages that make up the protocol,
   which can have different representations on the wire depending on the
   lower-level protocol used.  When the lower-level transport allows,
   PPSPP can also use different congestion control algorithms.

   At present, PPSPP is set to run on top of UDP using LEDBAT for
   congestion control [RFC6817].  Using LEDBAT enables PPSPP to serve
   the content after playback (seeding) without disrupting the user who
   may have moved to different tasks that use its network connection.

Top      ToC       Page 6 
   PPSPP is also flexible and extensible in the mechanisms it uses to
   promote client contribution and prevent freeriding, that is, how to
   deal with peers that only download content but never upload to
   others.  It also allows different schemes for chunk addressing and
   content integrity protection, if the defaults are not fit for a
   particular use case.  In addition, it can work with different peer
   discovery schemes, such as centralized trackers or fast Distributed
   Hash Tables [JIM11].  Finally, in this default setup, PPSPP maintains
   only a small amount of state per peer.  A reference implementation of
   PPSPP over UDP is available [SWIFTIMPL].

   The protocol defined in this document assumes that a peer has already
   discovered a list of (initial) peers using, for example, a
   centralized tracker [PPSP-TP].  Once a peer has this list of peers,
   PPSPP allows the peer to connect to other peers, request chunks of
   content, and discover other peers disseminating the same content.

   The design of PPSPP is based on our research into making BitTorrent
   [BITTORRENT] suitable for streaming content [P2PWIKI].  Most PPSPP
   messages have corresponding BitTorrent messages and vice versa.
   However, PPSPP is specifically targeted towards streaming audio/video
   content and optimizes time-till-playback.  It was also designed to be
   more flexible and extensible.

1.2.  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 RFC 2119 [RFC2119].

1.3.  Terminology

   message
       The basic unit of PPSPP communication.  A message will have
       different representations on the wire depending on the transport
       protocol used.  Messages are typically multiplexed into a
       datagram for transmission.

   datagram
       A sequence of messages that is offered as a unit to the
       underlying transport protocol (UDP, etc.).  The datagram is
       PPSPP's Protocol Data Unit (PDU).

   content
       Either a live transmission or a prerecorded multimedia file.

Top      ToC       Page 7 
   chunk
       The basic unit in which the content is divided.  For example, a
       block of N kilobytes.  A chunk may be of variable size.

   chunk ID
       Unique identifier for a chunk of content (e.g., an integer).  Its
       type depends on the chunk addressing scheme used.

   chunk specification
       An expression that denotes one or more chunk IDs.

   chunk addressing scheme
       Scheme for identifying chunks and expressing the chunk
       availability map of a peer in a compact fashion.

   chunk availability map
       The set of chunks a peer has successfully downloaded and checked
       the integrity of.

   bin
       A number denoting a specific binary interval of the content
       (i.e., one or more consecutive chunks) in the bin numbers chunk
       addressing scheme (see Section 4).

   content integrity protection scheme
       Scheme for protecting the integrity of the content while it is
       being distributed via the peer-to-peer network.  That is, methods
       for receiving peers to detect whether a requested chunk has been
       modified, either maliciously by the sending peer or accidentally
       in transit.

   hash
       The result of applying a cryptographic hash function, more
       specifically a Modification Detection Code (MDC) [HAC01], such as
       SHA-256 [FIPS180-4], to a piece of data.

   Merkle hash tree
       A tree of hashes whose base is formed by the hashes of the chunks
       of content, and its higher nodes are calculated by recursively
       computing the hash of the concatenation of the two child hashes
       (see Section 5.1).

   root hash
       The root in a Merkle hash tree calculated recursively from the
       content (see Section 5.1).

Top      ToC       Page 8 
   munro hash
       The hash of a subtree that is the unit of signing in the Unified
       Merkle Tree content authentication scheme for live streaming (see
       Section 6.1.2.1).

   swarm
       A group of peers participating in the distribution of the same
       content.

   swarm ID
       Unique identifier for a swarm of peers, in PPSPP a sequence of
       bytes.  For video on demand with content integrity protection
       enabled, the identifier is the so-called root hash of a Merkle
       hash tree over the content.  For live streaming, the swarm ID is
       a public key.

   tracker
       An entity that records the addresses of peers participating in a
       swarm, usually for a set of swarms, and makes this membership
       information available to other peers on request.

   choking
       When Peer A is choking Peer B, it means that A is currently not
       willing to accept requests for content from B.

   seeding
       Peer A is said to be seeding when A has downloaded a static
       content file completely and is now offering it for others to
       download.

   leeching
       Peer A is said to be leeching when A has not completely
       downloaded a static content file yet or is not offering to upload
       it to others.

   channel
       A logical connection between two peers.  The channel concept
       allows peers to use the same transport address for communicating
       with different peers.

   channel ID
       Unique, randomly chosen identifier for a channel, local to each
       peer.  So the two peers logically connected by a channel each
       have a different channel ID for that channel.

   heavy payload
       A datagram has a heavy payload when it contains DATA messages,
       SIGNED_INTEGRITY messages, or a large number of smaller messages.

Top      ToC       Page 9 
   In this document the prefixes kilo-, mega-, etc., denote base 1024.

2.  Overall Operation

   The basic unit of communication in PPSPP is the message.  Multiple
   messages are multiplexed into a single datagram for transmission.  A
   datagram (and hence the messages it contains) will have different
   representations on the wire depending on the transport protocol used
   (see Section 8).

   The overall operation of PPSPP is illustrated in the following
   examples.  The examples assume that the content distributed is
   static, UDP is used for transport, the Merkle Hash Tree scheme is
   used for content integrity protection, and that a specific policy is
   used for selecting which chunks to download.

2.1.  Example: Joining a Swarm

   Consider a user who wants to watch a video.  To play the video, the
   user clicks on the play button of a HTML5 <video> element shown in
   his PPSPP-enabled browser.  Imagine this element has a PPSPP URL (to
   be defined elsewhere) identifying the video as its source.  The
   browser passes this URL to its peer-to-peer streaming protocol
   handler.  Let's call this protocol handler Peer A.  Peer A parses the
   URL to retrieve the transport address of a peer-to-peer streaming
   protocol tracker and swarm metadata of the content.  The tracker
   address may be optional in the presence of a decentralized tracking
   mechanism.  The mechanisms for tracking peers are outside of the
   scope of this document.

   Peer A now registers with the tracker following the peer-to-peer
   streaming protocol tracker specification [PPSP-TP] and receives the
   IP address and port of peers already in the swarm, say, Peers B, C,
   and D.  At this point, the PPSPP starts operating.  Peer A now sends
   a datagram containing a PPSPP HANDSHAKE message to Peers B, C, and D.
   This message conveys protocol options.  In particular, Peer A
   includes the ID of the swarm (part of the swarm metadata) as a
   protocol option because the destination peers can listen for multiple
   swarms on the same transport address.

   Peers B and C respond with datagrams containing a PPSPP HANDSHAKE
   message and one or more HAVE messages.  A HAVE message conveys (part
   of) the chunk availability of a peer; thus, it contains a chunk
   specification that denotes what chunks of the content Peers B and C
   have, respectively.  Peer D sends a datagram with a HANDSHAKE and
   HAVE messages, but also with a CHOKE message.  The latter indicates
   that Peer D is not willing to upload chunks to Peer A at present.

Top      ToC       Page 10 
2.2.  Example: Exchanging Chunks

   In response to Peers B and C, Peer A sends new datagrams to Peers B
   and C containing REQUEST messages.  A REQUEST message indicates the
   chunks that a peer wants to download; thus, it contains a chunk
   specification.  The REQUEST messages to Peers B and C refer to
   disjoint sets of chunks.  Peers B and C respond with datagrams
   containing HAVE, DATA, and, in this example, INTEGRITY messages.  In
   the Merkle hash tree content protection scheme (see Section 5.1), the
   INTEGRITY messages contain all cryptographic hashes that Peer A needs
   to verify the integrity of the content chunk sent in the DATA
   message.  Using these hashes, Peer A verifies that the chunks
   received from Peers B and C are correct against the trusted swarm ID.
   Peer A also updates the chunk availability of Peers B and C using the
   information in the received HAVE messages.  In addition, it passes
   the chunks of video to the user's browser for rendering.

   After processing, Peer A sends a datagram containing HAVE messages
   for the chunks it just received to all its peers.  In the datagram to
   Peers B and C, it includes an ACK message acknowledging the receipt
   of the chunks and adds REQUEST messages for new chunks.  ACK messages
   are not used when a reliable transport protocol is used.  When, for
   example, Peer C finds that Peer A obtained a chunk (from Peer B) that
   Peer C did not yet have, Peer C's next datagram includes a REQUEST
   for that chunk.

   Peer D also sends HAVE messages to Peer A when it downloads chunks
   from other peers.  When Peer D is willing to accept REQUESTs from
   Peer A, Peer D sends a datagram with an UNCHOKE message to inform
   Peer A.  If Peer B or C decides to choke Peer A, they send a CHOKE
   message and Peer A should then re-request from other peers.  Peers B
   and C may continue to send HAVE, REQUEST, or periodic keep-alive
   messages such that Peer A keeps sending them HAVE messages.

   Once Peer A has received all content (video-on-demand use case), it
   stops sending messages to all other peers that have all content
   (a.k.a. seeders).  Peer A can also contact the tracker or another
   source again to obtain more peer addresses.

2.3.  Example: Leaving a Swarm

   To leave a swarm in a graceful way, Peer A sends a specific HANDSHAKE
   message to all its peers (see Section 8.4) and deregisters from the
   tracker following the tracker specification [PPSP-TP].  Peers
   receiving the datagram should remove Peer A from their current peer
   list.  If Peer A crashes ungracefully, peers should remove Peer A
   from their peer list when they detect it no longer sends messages
   (see Section 3.12).

Top      ToC       Page 11 
3.  Messages

   No error codes or responses are used in the protocol; absence of any
   response indicates an error.  Invalid messages are discarded, and
   further communication with the peer SHOULD be stopped.  The rationale
   is that it is sufficient to classify peers as either good or bad and
   only use the good ones.  A good peer is a peer that responds with
   chunks; a peer that does not respond, or does not respond in time is
   classified as bad.  The idea is that, in PPSPP, the content is
   available from multiple sources (unlike HTTP), so a peer should not
   invest too much effort in trying to obtain it from a particular
   source.  This classification in good or bad allows a peer to deal
   with slow, crashed, and (silent) malicious peers.

   Multiple messages MUST be multiplexed into a single datagram for
   transmission.  Messages in a single datagram MUST be processed in the
   strict order in which they appear in the datagram.  If an invalid
   message is found in a datagram, the remaining messages MUST be
   discarded.

   For the sake of simplicity, one swarm of peers deals with one content
   file or stream only.  There is a single division of the content into
   chunks that all peers in the swarm adhere to, determined by the
   content publisher.  Distribution of a collection of files can be done
   either by using multiple swarms or by using an external storage
   mapping from the linear byte space of a single swarm to different
   files, transparent to the protocol.  In other words, the audio/video
   container format used is outside the scope of this document.

3.1.  HANDSHAKE

   For Peer P to establish communication with Peer Q in Swarm S, the
   peers must first exchange HANDSHAKE messages by means of a handshake
   procedure.  The initiating Peer P needs to know the metadata of Swarm
   S, which consists of:

   (a)  the swarm ID of the content (see Sections 5.1 and 6),

   (b)  the chunk size used,

   (c)  the chunk addressing method used,

   (d)  the content integrity protection method used, and

   (e)  the Merkle hash tree function used (if applicable).

Top      ToC       Page 12 
   (f)  If automatic content size detection (see Section 5.6) is not
        used, the content length is also part of the metadata (for
        static content.)

   This document assumes the swarm metadata is obtained from a trusted
   source.  In addition, Peer P needs to know a transport address for
   Peer Q, obtained from a peer discovery/tracking protocol.

   The payload of the HANDSHAKE message contains a sequence of protocol
   options.  The protocol options encode the swarm metadata just
   described to enable an end-to-end check to see whether the peers are
   in the right swarm.  Additionally, the options encode a number of
   per-peer configuration parameters.  The complete set of protocol
   options are specified in Section 7.  The HANDSHAKE message also
   contains a channel ID for multiplexing communication and security
   (see Sections 3.11 and 12.1).  A HANDSHAKE message MUST always be the
   first message in a datagram.

3.1.1.  Handshake Procedure

   The handshake procedure for a peer, Peer P, to start communication
   with another peer, Peer Q, in Swarm S is now as follows.

   1.  The first datagram the initiating Peer P sends to Peer Q MUST
       start with a HANDSHAKE message.  This HANDSHAKE message MUST
       contain:

       *  A channel ID, chanP, randomly chosen as specified in
          Section 12.1.

       *  The metadata of Swarm S, encoded as protocol options, as
          specified in Section 7.  In particular, the initiating Peer P
          MUST include the swarm ID.

       *  The capabilities of Peer P, in particular, its supported
          protocol versions, "Live Discard Window" (in case of a live
          swarm) and "Supported Messages", encoded as protocol options.

       This first datagram MUST be prefixed with the (destination)
       channel ID 0; see Section 3.11.  Hence, the datagram contains two
       channel IDs: the destination channel ID prefixed to the datagram
       and the channel ID chanP included in the HANDSHAKE message inside
       the datagram.  This datagram MAY also contain some minor
       additional payload, e.g., HAVE messages to indicate Peer P's
       current progress, but it MUST NOT include any heavy payload
       (defined in Section 1.3), such as a DATA message.  Allowing minor

Top      ToC       Page 13 
       payload minimizes the number of initialization round trips, thus
       improving time-till-playback.  Forbidding heavy payload prevents
       an amplification attack (see Section 12.1).

   2.  The receiving Peer Q checks the HANDSHAKE message from Peer P.
       If any check by Peer Q fails, or if Peers P and Q are not in the
       same swarm, Peer Q MUST NOT send a HANDSHAKE (or any other)
       message back, as the message from Peer P may have been spoofed
       (see Section 12.1).  Otherwise, if Peer Q is interested in
       communicating with Peer P, Peer Q MUST send a datagram to Peer P
       that starts with a HANDSHAKE message.  This reply HANDSHAKE MUST
       contain:

       *  A channel ID, chanQ, randomly chosen as specified in
          Section 12.1.

       *  The metadata of Swarm S, encoded as protocol options, as
          specified in Section 7.  In particular, the responding Peer Q
          MAY include the swarm ID.

       *  The capabilities of Peer Q, in particular, its supported
          protocol versions, its "Live Discard Window" (in case of a
          live swarm) and "Supported Messages", encoded as protocol
          options.

       This reply datagram MUST be prefixed with the channel ID chanP
       sent by Peer P in the first HANDSHAKE message (see Section 3.11).
       This reply datagram MAY also contain some minor additional
       payload, e.g., HAVE messages to indicate Peer Q's current
       progress, or REQUEST messages (see Section 3.7), but it MUST NOT
       include any heavy payload.

   3.  The initiating Peer P checks the reply datagram from Peer Q.  If
       the reply datagram is not prefixed with (destination) channel ID
       chanP, Peer P MUST discard the datagram.  Peer P SHOULD continue
       to process datagrams from Peer Q that do meet this requirement.
       This check prevents interference by spoofing, see Section 12.1.
       If Peer P's channel ID is echoed correctly, the initiator Peer P
       knows that the addressed Peer Q really responds.

   4.  Next, Peer P checks the HANDSHAKE message in the datagram from
       Peer Q.  If any check by Peer P fails, or Peer P is no longer
       interested in communicating with Peer Q, Peer P MAY send a
       HANDSHAKE message to inform Peer Q it will cease communication.
       This closing HANDSHAKE message MUST contain an all zeros channel
       ID and a list of protocol options.  The list MUST either be empty
       or contain the maximum version number Peer P supports, following
       the min/max versioning scheme defined in [RFC6709], Section 4.1.

Top      ToC       Page 14 
       The datagram containing this closing HANDSHAKE message MUST be
       prefixed with the (destination) channel ID chanQ.  Peer P MAY
       also simply cease communication.

   5.  If the addressed peer, Peer Q, does not respond to initiating
       Peer P's first datagram, Peer P MAY resend that datagram until
       Peer Q is considered dead, according to the rules specified in
       Section 3.12.

   6.  If the reply datagram by Peer Q does pass the checks by Peer P,
       and Peer P wants to continue interacting with Peer Q, Peer P can
       now send REQUEST, PEX_REQ, and other messages to Peer Q.
       Datagrams carrying these messages MUST be prefixed with the
       channel ID chanQ sent by Peer Q.  More specifically, because Peer
       P knows that Peer Q really responds, Peer P MAY start sending
       Peer Q messages with heavy payload.  That means that Peer P MAY
       start responding to any REQUEST messages that Peer Q may have
       sent in this first reply datagram with DATA messages.  Hence,
       transfer of chunks can start soon in PPSPP.

   7.  If Peer Q receives any datagram (apparently) from Peer P that
       does not contain channel ID chanQ, Peer Q MUST discard the
       datagram but SHOULD continue to process datagrams from Peer P
       that do meet this requirement.  Once Peer Q receives a datagram
       from Peer P that does contain the channel ID chanQ, Peer Q knows
       that Peer P really received its reply datagram, and the three-way
       handshake and channel establishment is complete.  Peer Q MAY now
       also start sending messages with heavy payload to Peer P.

   8.  If Peer P decides it no longer wants to communicate with Peer Q,
       or vice versa, the peer SHOULD send a closing HANDSHAKE message
       to the other, as described above.

3.2.  HAVE

   The HAVE message is used to convey which chunks a peer has available
   for download.  The set of chunks it has available may be expressed
   using different chunk addressing and availability map compression
   schemes, described in Section 4.  HAVE messages can be used both for
   sending a complete overview of a peer's chunk availability as well as
   for updates to that set.

   In particular, whenever a receiving Peer P has successfully checked
   the integrity of a chunk, or interval of chunks, it MUST send a HAVE
   message to all peers Q1..Qn it wants to allow to download those
   chunks.  A policy in Peer P determines when the HAVE is sent.  Peer P
   may send it directly, or Peer P may wait either until it has other
   data to send to Peer Qi or until it has received and checked multiple

Top      ToC       Page 15 
   chunks.  The policy will depend on how urgent it is to distribute
   this information to the other peers.  This urgency is generally
   determined in turn by the chunk picking policy (see Section 9.1).  In
   general, the HAVE messages can be piggybacked onto other messages.
   Peers that do not receive HAVE messages are effectively prevented
   from downloading the newly available chunks; hence, the HAVE message
   can be used as a method of choking.

   The HAVE message MUST contain the chunk specification of the received
   and verified chunks.  A receiving peer MUST NOT send a HAVE message
   to peers for which the handshake procedure is still incomplete, see
   Section 12.1.  A peer SHOULD NOT send a HAVE message to peers that
   have the complete content already (e.g., in video-on-demand
   scenarios).

3.3.  DATA

   The DATA message is used to transfer chunks of content.  The DATA
   message MUST contain the chunk ID of the chunk and chunk itself.  A
   peer MAY send the DATA messages for multiple chunks in the same
   datagram.  The DATA message MAY contain additional information if
   needed by the specific congestion control mechanism used.  At
   present, PPSPP uses LEDBAT [RFC6817] for congestion control, which
   requires the current system time to be sent along with the DATA
   message, so the current system time MUST be included.

3.4.  ACK

   ACK messages MUST be sent to acknowledge received chunks if PPSPP is
   run over an unreliable transport protocol.  ACK messages MAY be sent
   if a reliable transport protocol is used.  In the former case, a
   receiving peer that has successfully checked the integrity of a
   chunk, or interval of chunks C, MUST send an ACK message containing a
   chunk specification for C.  As LEDBAT is used, an ACK message MUST
   contain the one-way delay, computed from the peer's current system
   time received in the DATA message.  A peer MAY delay sending ACK
   messages as defined in the LEDBAT specification [RFC6817].

3.5.  INTEGRITY

   The INTEGRITY message carries information required by the receiver to
   verify the integrity of a chunk.  Its payload depends on the content
   integrity protection scheme used.  When the Merkle Hash Tree scheme
   is used, an INTEGRITY message MUST contain a cryptographic hash of a
   subtree of the Merkle hash tree and the chunk specification that
   identifies the subtree.

Top      ToC       Page 16 
   As a typical example, when a peer wants to send a chunk and Merkle
   hash trees are used, it creates a datagram that consists of several
   INTEGRITY messages containing the hashes the receiver needs to verify
   the chunk and the actual chunk itself encoded in a DATA message.
   What are the necessary hashes and the exact rules for encoding them
   into datagrams is specified in Sections 5.3, and 5.4, respectively.

3.6.  SIGNED_INTEGRITY

   The SIGNED_INTEGRITY message carries digitally signed information
   required by the receiver to verify the integrity of a chunk in live
   streaming.  It logically contains a chunk specification, a timestamp,
   and a digital signature.  Its exact payload depends on the live
   content integrity protection scheme used, see Section 6.1.

3.7.  REQUEST

   While bulk download protocols normally do explicit requests for
   certain ranges of data (i.e., use a pull model, for example,
   BitTorrent [BITTORRENT]), live streaming protocols quite often use a
   push model without requests to save round trips.  PPSPP supports both
   models of operation.

   The REQUEST message is used to request one or more chunks from
   another peer.  A REQUEST message MUST contain the specification of
   the chunks the requester wants to download.  A peer receiving a
   REQUEST message MAY send out the requested chunks (by means of DATA
   messages).  When Peer Q receives multiple REQUESTs from the same Peer
   P, Peer Q SHOULD process the REQUESTs in the order received.
   Multiple REQUEST messages MAY be sent in one datagram, for example,
   when a peer wants to request several rare chunks at once.

   When live streaming via a push model, a peer receiving REQUESTs also
   MAY send some other chunks in case it runs out of requests or for
   some other reason.  In that case, the only purpose of REQUEST
   messages is to provide hints and coordinate peers to avoid
   unnecessary data retransmission.

3.8.  CANCEL

   When downloading on-demand or live streaming content, a peer can
   request urgent data from multiple peers to increase the probability
   of it being delivered on time.  In particular, when the specific
   chunk picking algorithm (see Section 9.1), detects that a request for
   urgent data might not be served on time, a request for the same data
   can be sent to a different peer.  When a Peer P decides to request
   urgent data from a Peer Q, Peer P SHOULD send a CANCEL message to all
   the peers to which the data has been previously requested.  The

Top      ToC       Page 17 
   CANCEL message contains the specification of the chunks Peer P no
   longer wants to request.  In addition, when Peer Q receives a HAVE
   message for the urgent data from Peer P, Peer Q MUST also cancel the
   previous REQUEST(s) from Peer P.  In other words, the HAVE message
   acts as an implicit CANCEL.

3.9.  CHOKE and UNCHOKE

   Peer A can send a CHOKE message to Peer B to signal it will no longer
   be responding to REQUEST messages from Peer B, for example, because
   Peer A's upload capacity is exhausted.  Peer A MAY send a subsequent
   UNCHOKE message to signal that it will respond to new REQUESTs from
   Peer B again (Peer A SHOULD discard old requests).  When Peer B
   receives a CHOKE message from Peer A, it MUST NOT send new REQUEST
   messages and it cannot expect answers to any outstanding ones, as the
   transfer of chunks is choked.  When Peer B is choked but receives a
   HAVE message from Peer A, it is not automatically unchoked and MUST
   NOT send any new REQUEST messages.  The CHOKE and UNCHOKE messages
   are informational as responding to REQUESTs is OPTIONAL, see
   Section 3.7.

3.10.  Peer Address Exchange

3.10.1.  PEX_REQ and PEX_RES Messages

   Peer Exchange (PEX) messages are common in many peer-to-peer
   protocols.  They allow peers to exchange the transport addresses of
   the peers they are currently interacting with, thereby reducing the
   need to contact a central tracker (or Distributed Hash Table) to
   discovery new peers.  The strength of this mechanism is therefore
   that it enables decentralized peer discovery: after an initial
   bootstrap, a central tracker is no longer needed.  Its weakness is
   that it enables a number of attacks, so it should not be used on the
   Internet unless extra security measures are in place.

   PPSPP supports peer-address exchange on the Internet and in benign
   private networks as an OPTIONAL feature (not mandatory to implement)
   under certain conditions.  The general mechanism works as follows.
   To obtain some peer addresses, a Peer A MAY send a PEX_REQ message to
   Peer B.  Peer B MAY respond with one or more PEX_REScert messages.
   Logically, a PEX_REScert reply message contains the address of a
   single peer Ci.  Peer B MUST have exchanged messages with Peer Ci in
   the last 60 seconds to guarantee liveliness.  Upon receipt, Peer A
   may contact any or none of the returned peers Ci.  Alternatively,
   peers MAY ignore PEX_REQ and PEX_REScert messages if uninterested in
   obtaining new peers or because of security considerations (rate
   limiting) or any other reason.  The PEX messages can be used to
   construct a dedicated tracker peer.

Top      ToC       Page 18 
   To use PEX in PPSPP on the Internet, two conditions must be met:

   1.  Peer transport addresses must be relatively stable.

   2.  A peer must not obtain all its peer addresses through PEX.

   The full security analysis for PEX messages can be found in
   Section 12.2.  Physically, a PEX_REScert message carries a swarm-
   membership certificate rather than an IP address and port.  A
   membership certificate for Peer C states that Peer C at address
   (ipC,portC) is part of Swarm S at Time T and is cryptographically
   signed by an issuer.  The receiver Peer A can check the certificate
   for a valid signature by a trusted issuer, the right swarm, and
   liveliness and only then consider contacting C.  These swarm-
   membership certificates correspond to signed node descriptors in
   secure decentralized peer sampling services [SPS].

   Several designs are possible for the security environment for these
   membership certificates.  That is, there are different designs
   possible for who signs the membership certificates and how public
   keys are distributed.  Section 12.2.2 describes an example where a
   central tracker acts as the Certification Authority.

   In a hostile environment, such as the Internet, peers must also
   ensure that they do not end up interacting only with malicious peers
   when using the peer-address exchange feature.  To this extent, peers
   MUST ensure that part of their connections are to peers whose
   addresses came from a trusted and secured tracker (see
   Section 12.2.3).

   In addition to the PEX_REScert, there are two other PEX reply
   messages.  The PEX_RESv4 message contains a single IPv4 address and
   port.  The PEX_RESv6 message contains a single IPv6 address and port.
   They MUST only be used in a benign environment, such as a private
   network, as they provide no guarantees that the host addressed
   actually participates in a PPSPP swarm.

   Once a PPSPP implementation has obtained a list of peers (either via
   PEX, from a central tracker, or via a Distributed Hash Table (DHT)),
   it has to determine which peers to actually contact.  In this
   process, a PPSPP implementation can benefit from information by
   network or content providers to help improve network usage and boost
   PPSPP performance.  How a peer-to-peer (P2P) system like PPSPP can
   perform these optimizations using the Application-Layer Traffic
   Optimization (ALTO) protocol is described in detail in [RFC7285],
   Section 7.

Top      ToC       Page 19 
3.11.  Channels

   It is increasingly complex for peers to enable communication between
   each other due to NATs and firewalls.  Therefore, PPSPP uses a
   multiplexing scheme, called channels, to allow multiple swarms to use
   the same transport address.  Channels loosely correspond to TCP
   connections and each channel belongs to a single swarm, as
   illustrated in Figure 1.  As with TCP connections, a channel is
   identified by a unique identifier local to the peer at each end of
   the connection (cf.  TCP port), which MUST be randomly chosen.  In
   other words, the two peers connected by a channel use different IDs
   to denote the same channel.  The IDs are different and random for
   security reasons, see Section 12.1.

   In the PPSP-over-UDP encapsulation (Section 8.3), when a Channel C
   has been established between Peer A and Peer B, the datagrams
   containing messages from Peer A to Peer B are prefixed with the four-
   byte channel ID allocated by Peer B, and vice versa for datagrams
   from Peer B to A.  The channel IDs used are exchanged as part of the
   handshake procedure, see Section 8.4.  In that procedure, the channel
   ID with value 0 is used for the datagram that initiates the
   handshake.  PPSPP can be used in combination with Session Traversal
   Utilities for NAT (STUN) [RFC5389].

Top      ToC       Page 20 
               _________    _________          _________
               |       |    |       |          |       |
               | Swarm |    | Swarm |          | Swarm |
               |  Mgr  |    |   A   |          |   B   |
               |_______|    |_______|          |_______|
                   |            |                /   \
                   |            |               /     \
               ____|____    ____|____    ______/__    _\_______
               |       |    |       |    |       |    |       |
               | Chan  |    | Chan  |    | Chan  |    | Chan  |
               |   0   |    |  481  |    |  836  |    |  372  |
               |_______|    |_______|    |_______|    |_______|
                   |            |            |            |
                   |            |            |            |
               ____|____________|____________|____________|____
               |                                              |
               |                      UDP                     |
               |                   port 6778                  |
               |______________________________________________|


   Network stack of a PPSPP peer that is reachable on UDP port 6778 and
   is connected via channel 481 to one peer in Swarm A and two peers in
     Swarm B via channels 836 and 372, respectively.  Channel ID 0 is
                   special and is used for handshaking.

                                 Figure 1

3.12.  Keep Alive Signaling

   A peer SHOULD send a "keep alive" message periodically to each peer
   it is interested in, but has no other messages to send to them at
   present.  The goal of the keep alives is to keep a signaling channel
   open to peers that are of interest.  Which peers those are is
   determined by a policy that decides which peers are of interest now
   and in the near future.  This document does not prescribe a policy,
   but examples of interesting peers are (a) peers that have chunks on
   offer that this client needs or (b) peers that currently do not have
   interesting chunks on offer (because they are still downloading
   themselves, or in live streaming) but gave good performance in the
   past.  When these peers have new chunks to offer, the peer that kept
   a signaling channel open can use them again.  Periodically sending
   "keep alive" messages prevents other peers declaring the peer dead.
   A guideline for declaring a peer dead when using UDP consists of a
   three minute delay since that last packet has been received from that
   peer and at least three datagrams having been sent to that peer
   during the same period.  When a peer is declared dead, the channel to
   it is closed, no more messages will be sent to that peer and the

Top      ToC       Page 21 
   local administration about the peer is discarded.  Busy servers can
   force idle clients to disconnect by not sending keep alives.  PPSPP
   does not define an explicit message type for "keep alive" messages.
   In the PPSP-over-UDP encapsulation they are implemented as simple
   datagrams consisting of a four-byte channel ID only, see Sections 8.3
   and 8.4.



(page 21 continued on part 2)

Next RFC Part