tech-invite   World Map     

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

RFC 7574

 
 
 

Peer-to-Peer Streaming Peer Protocol (PPSPP)

Part 3 of 4, p. 45 to 68
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 45 
8.  UDP Encapsulation

   PPSPP implementations MUST use UDP as transport protocol and MUST use
   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.  Future PPSPP versions can also run over other transport
   protocols or use different congestion control algorithms.

8.1.  Chunk Size

   In general, a UDP datagram containing PPSPP messages SHOULD fit
   inside a single IP packet, so its maximum size depends on the MTU of
   the network.  If the UDP datagram does not fit, its chance of getting
   lost in the network increases as the loss of a single fragment of the
   datagram causes the loss of the complete datagram.

   The largest message in a PPSPP datagram is the DATA message carrying
   a chunk of content.  So the (maximum) size of a chunk to choose for a
   particular swarm depends primarily on the expected MTU.  The chunk
   size should be chosen such that a chunk and its required INTEGRITY
   messages can generally be carried inside a single datagram, following
   the Atomic Datagram Principle (Section 5.3).  Other considerations
   are the hardware capabilities of the peers.  Having large chunks and
   therefore less chunks per megabyte of content reduces processing
   costs.  The chunk addressing schemes can all work with different
   chunk sizes, see Section 4.

   The RECOMMENDED approach is to use fixed-size chunks of 1024 bytes,
   as this size has a high likelihood of traveling end-to-end across the
   Internet without any fragmentation.  In particular, with this size, a
   UDP datagram with a DATA message can be transmitted as a single IP
   packet over an Ethernet network with 1500-byte frames.

   A PPSPP implementation MAY use a variant of the Packetization Layer
   Path MTU Discovery (PLPMTUD), described in [RFC4821], for discovering
   the optimal MTU between sender and destination.  As in PLPMTUD,
   progressively larger probing packets are used to detect the optimal
   MTU for a given path.  However, in PPSPP, probe packets SHOULD
   contain actual messages, in particular, multiple DATA messages.  By
   using actual DATA messages as probe packets, the returning ACK
   messages will confirm the probe delivery, effectively updating the
   MTU estimate on both ends of the link.  To be able to scale up probe
   packets with sensible increments, a minimum chunk size of 512 bytes
   SHOULD be used.  Smaller chunk sizes lead to an inefficient protocol.
   An implication is that PPSPP supports datagrams over IPv4 of 576
   bytes or more only.  This variant is not mandatory to implement.

Top      Up      ToC       Page 46 
   The chunk size used for a particular swarm, or the fact that it is
   variable, MUST be part of the swarm's metadata (which then minimally
   consists of the swarm ID and the chunk nature and size).

8.2.  Datagrams and Messages

   When using UDP, the abstract datagram described above corresponds
   directly to a UDP datagram.  Most messages within a datagram have a
   fixed length, which generally depends on the type of the message.
   The first byte of a message denotes its type.  The currently defined
   types are:

                      +----------+------------------+
                      | Msg Type | Description      |
                      +----------+------------------+
                      | 0        | HANDSHAKE        |
                      | 1        | DATA             |
                      | 2        | ACK              |
                      | 3        | HAVE             |
                      | 4        | INTEGRITY        |
                      | 5        | PEX_RESv4        |
                      | 6        | PEX_REQ          |
                      | 7        | SIGNED_INTEGRITY |
                      | 8        | REQUEST          |
                      | 9        | CANCEL           |
                      | 10       | CHOKE            |
                      | 11       | UNCHOKE          |
                      | 12       | PEX_RESv6        |
                      | 13       | PEX_REScert      |
                      | 14-254   | Unassigned       |
                      | 255      | Reserved         |
                      +----------+------------------+

                       Table 7: PPSPP Message Types

   Furthermore, integers are serialized in network (big-endian) byte
   order.  So, consider the example of a HAVE message (Section 3.2)
   using bin chunk addressing.  It has a message type of 0x03 and a
   payload of a bin number, a 4-byte integer (say, 1); hence, its on-
   the-wire representation for UDP can be written in hex as
   "0300000001".

   All messages are idempotent or recognizable as duplicates.
   Idempotent means that processing a message more than once does not
   lead to a different state from if it was processed just once.  In
   particular, a peer MAY resend DATA, ACK, HAVE, INTEGRITY, PEX_*,
   SIGNED_INTEGRITY, REQUEST, CANCEL, CHOKE, and UNCHOKE messages
   without problems when loss is suspected.  When a peer resends a

Top      Up      ToC       Page 47 
   HANDSHAKE message, it can be recognized as duplicate by the receiver,
   because it already recorded the first connection attempt, and be
   dealt with.

8.3.  Channels

   As described in Section 3.11, PPSPP uses a multiplexing scheme,
   called channels, to allow multiple swarms to use the same UDP port.
   In the UDP encapsulation, each datagram from Peer A to Peer B is
   prefixed with the channel ID allocated by Peer B.  The peers learn
   about each other's channel ID during the handshake as explained in
   Section 3.1.1.  A channel ID consists of 4 bytes and MUST be
   generated following the requirements in [RFC4960] (Section 5.1.3).

8.4.  HANDSHAKE

   A channel is established with a handshake.  To start a handshake, the
   initiating peer needs to know the swarm metadata, defined in
   Section 3.1 and the IP address and UDP port of a peer.  A datagram
   containing a HANDSHAKE message then looks as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Destination Channel ID (32)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0|            Source Channel ID (32)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                     Protocol Options                          ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

      Destination Channel ID:

         If the datagram is sent by the initiating peer, then it MUST be
         an all-zeros channel ID.

         If the datagram is sent by the responding peer, then it MUST
         consist of the Source Channel ID from the sender's HANDSHAKE
         message.

      The octet 0x00: The HANDSHAKE message type

Top      Up      ToC       Page 48 
      Source Channel ID: A locally unused channel ID

      Protocol Options: A list of protocol options encoding the swarm's
      metadata, as defined in Section 7.

   A peer SHOULD explicitly close a channel by sending a HANDSHAKE
   message that MUST contain an all zeros Source Channel ID and a list
   of protocol options.  The list MUST either be empty or contain the
   maximum version number the sender supports, following the min/max
   versioning scheme defined in [RFC6709], Section 4.1.

8.5.  HAVE

   A HAVE message (type 0x03) consists of a single chunk specification
   that states that the sending peer has those chunks and successfully
   checked their integrity.  The single chunk specification represents a
   consecutive range of verified chunks.  A bin consists of a single
   integer, and a chunk or byte range of two integers, of the width
   specified by the Chunk Addressing protocol options, encoded big-
   endian.

   A HAVE message using 32-bit chunk ranges as Chunk Addressing method:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 1 1|                 Start chunk (32)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |                  End chunk (32)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |
   +-+-+-+-+-+-+-+-+

   where the first octet is the HAVE message (0x03) followed by the
   start chunk and the end chunk describing the chunk range.  Note this
   diagram shows a message and not a datagram, so it is not prefixed by
   the destination Channel ID.  This holds for all subsequent message
   diagrams.

8.6.  DATA

   A DATA message (type 0x01) consists of a chunk specification, a
   timestamp, and the actual chunk.  In case a datagram contains one
   DATA message, a sender MUST always put the DATA message in the tail
   of the datagram.  A datagram MAY contain multiple DATA messages when
   the chunk size is fixed and when none of the DATA messages carry the
   last chunk, if that is smaller than the chunk size.  As LEDBAT
   congestion control is used, a sender MUST include a timestamp, in

Top      Up      ToC       Page 49 
   particular, a 64-bit integer representing the current system time
   with microsecond accuracy.  The timestamp MUST be included between
   chunk specification and the actual chunk.

   A DATA message using 32-bit chunk ranges as Chunk Addressing method:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 1|                 Start chunk (32)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |                  End chunk (32)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Timestamp (64)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                            Data                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where the first octet is the DATA message (0x01) followed by the
   start chunk and the end chunk describing the single chunk, the
   timestamp, and the actual data.

8.7.  ACK

   An ACK message (type 0x02) acknowledges data that was received from
   its addressee; to comply with the LEDBAT delay-based congestion
   control, an ACK message consists of a chunk specification and a
   timestamp representing a one-way delay sample.  The one-way delay
   sample is a 64-bit integer with microsecond accuracy, and it is
   computed from the timestamp received from the previous DATA message
   containing the chunk being acknowledged following the LEDBAT
   specification.

Top      Up      ToC       Page 50 
   An ACK message using 32-bit chunk ranges as Chunk Addressing method:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 1 0|                 Start chunk (32)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |                  End chunk (32)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  One-way delay sample (64)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |
   +-+-+-+-+-+-+-+-+

   where the first octet is the ACK message (0x02) followed by the start
   chunk and the end chunk describing the chunk range and the one-way
   delay sample.

8.8.  INTEGRITY

   An INTEGRITY message (type 0x04) consists of a chunk specification
   and the cryptographic hash for the specified chunk or node.  The type
   and format of the hash depends on the protocol options.

   An INTEGRITY message using 32-bit chunk ranges as Chunk Addressing
   method and a SHA-256 hash:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 1 0 0|                 Start chunk (32)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |                  End chunk (32)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                            Hash (256)                         ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |
   +-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 51 
   where the first octet is the INTEGRITY message (0x04) followed by the
   start chunk and the end chunk describing the chunk range and the
   hash.

8.9.  SIGNED_INTEGRITY

   A SIGNED_INTEGRITY message (type 0x07) consists of a chunk
   specification, a 64-bit timestamp in NTP Timestamp format [RFC5905]
   and a digital signature encoded as a Signature field would be in an
   RRSIG record in DNSSEC without the Base64 encoding [RFC4034].  The
   signature algorithm is defined by the Live Signature Algorithm
   protocol option, see Section 7.7.  The plaintext over which the
   signature is taken depends on the content integrity protection method
   used, see Section 6.1.

   A SIGNED_INTEGRITY message using 32-bit chunk ranges as Chunk
   Addressing method:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 1 1 1|                 Start chunk (32)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |                  End chunk (32)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Timestamp (64)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Signature                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where the first octet is the SIGNED_INTEGRITY message (0x07) followed
   by the start chunk and the end chunk describing the chunk range, the
   timestamp, and the Signature.

   The length of the digital signature can be derived from the Live
   Signature Algorithm protocol option and the swarm ID as follows.  The
   first mandatory algorithms are RSASHA1 and RSASHA256.  For those
   algorithms, the swarm ID consists of a 1-byte Algorithm field
   followed by an RSA public key stored as a tuple (exponent length,
   exponent, modulus) [RFC3110].  Given the exponent length and the
   length of the public key tuple in the swarm ID, the length of the
   modulus in bytes can be calculated.  This yields the length of the

Top      Up      ToC       Page 52 
   signature, as in RSA this is the length of the modulus [HAC01].  The
   other mandatory algorithms are ECDSAP256SHA256 and ECDSAP384SHA384
   [RFC6605].  For these algorithms, the length of the digital signature
   is 64 and 96 bytes, respectively.

8.10.  REQUEST

   A REQUEST message (type 0x08) consists of a chunk specification for
   the chunks the requester wants to download.

   A REQUEST message using 32-bit chunk ranges as Chunk Addressing
   method:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 1 0 0 0|                 Start chunk (32)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |                  End chunk (32)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |
   +-+-+-+-+-+-+-+-+

   where the first octet is the REQUEST message (0x08) followed by the
   start chunk and the end chunk describing the chunk range.

8.11.  CANCEL

   A CANCEL message (type 0x09) consists of a chunk specification for
   the chunks the requester no longer is interested in.

   A CANCEL message using 32-bit chunk ranges as Chunk Addressing
   method:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 1 0 0 1|                 Start chunk (32)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |                  End chunk (32)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |
   +-+-+-+-+-+-+-+-+

   where the first octet is the CANCEL message (0x09) followed by the
   start chunk and the end chunk describing the chunk range.

Top      Up      ToC       Page 53 
8.12.  CHOKE and UNCHOKE

   Both CHOKE and UNCHOKE messages (types 0x0a and 0x0b, respectively)
   carry no payload.

   A CHOKE message:

    0
    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |0 0 0 0 1 0 1 0|
   +-+-+-+-+-+-+-+-+

   where the first octet is the CHOKE message (0x0a).

   An UNCHOKE message:

    0
    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |0 0 0 0 1 0 1 1|
   +-+-+-+-+-+-+-+-+

   where the first octet is the UNCHOKE message (0x0b).

8.13.  PEX_REQ, PEX_RESv4, PEX_RESv6, and PEX_REScert

   A PEX_REQ (0x06) message has no payload.  A PEX_RESv4 (0x05) message
   consists of an IPv4 address in big-endian format followed by a UDP
   port number in big-endian format.  A PEX_RESv6 (0x0c) message
   contains a 128-bit IPv6 address instead of an IPv4 one.  If a PEX_REQ
   message does not originate from a private, unique-local, link-local,
   or multicast address [RFC1918] [RFC4193] [RFC4291], then the PEX_RES*
   messages sent in reply MUST NOT contain such addresses.  This is to
   prevent leaking of internal addresses to external peers.

   A PEX_REQ message:

    0
    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |0 0 0 0 0 1 1 0|
   +-+-+-+-+-+-+-+-+

   where the first octet is the PEX_REQ message (0x06).

Top      Up      ToC       Page 54 
   A PEX_RESv4 message:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 1 0 1|              IPv4 Address (32)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |             Port (16)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where the first octet is the PEX_RESv4 message (0x05) followed by the
   IPv4 address and the port number.

   A PEX_RESv6 message:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 1 1 0 0|                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   IPv6 Address (128)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |             Port (16)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where the first octet is the PEX_RESv6 message (0x0c), followed by
   the IPv6 address and the port number.

   A PEX_REScert (0x0d) message consists of a 16-bit integer in big-
   endian specifying the size of the membership certificate that
   follows, see Section 12.2.1.  This membership certificate states that
   Peer P at Time T is a member of Swarm S and is a X.509v3 certificate
   [RFC5280] that is encoded using the ASN.1 distinguished encoding
   rules (DER) [CCITT.X690.2002].  The certificate MUST contain a
   "Subject Alternative Name" extension, marked as critical, of type
   uniformResourceIdentifier.

Top      Up      ToC       Page 55 
   A PEX_REScert message:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 1 1 0 1|   Size of Memb. Cert. (16)    |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Membership Certificate                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where the first octet is the PEX_REScert message (0x0d) followed by
   the size of the membership certificate and the membership
   certificate.

   The URL contained in the name extension MUST follow the generic
   syntax for URLs [RFC3986], where its scheme component is "file", the
   host in the authority component is the DNS name or IP address of Peer
   P, the port in the authority component is the port of Peer P, and the
   path contains the swarm identifier for Swarm S, in hexadecimal form.
   In particular, the preferred form of the swarm identifier is
   xxyyzz..., where the 'x's, 'y's, and 'z's are 2 hexadecimal digits of
   the 8-bit pieces of the identifier.  The validity time of the
   certificate is set with notBefore UTCTime set to T and notAfter
   UTCTime set to T plus some expiry time defined by the issuer.  An
   example URL:

       file://192.0.2.0:6778/e5a12c7ad2d8fab33c699d1e198d66f79fa610c3

8.14.  KEEPALIVE

   Keep alives do not have a message type on UDP.  They are just simple
   datagrams consisting of the 4-byte channel ID of the destination
   only.

   A keep-alive datagram:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Channel ID (32)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 56 
8.15.  Flow and Congestion Control

   Explicit flow control is not required for PPSPP over UDP.  In the
   case of video on demand, the receiver explicitly requests the content
   from peers, and is therefore in control of how much data is coming
   towards it.  In the case of live streaming, where a push model may be
   used, the amount of data incoming is limited to the stream bitrate,
   which the receiver must be able to process for a continuous playback.
   Should, for any reason, the receiver get saturated with data, the
   congestion control at the sender side will detect the situation and
   adjust the sending rate accordingly.

   PPSPP over UDP can support different congestion control algorithms.
   At present, it uses the LEDBAT congestion control algorithm
   [RFC6817].  LEDBAT is a delay-based congestion control algorithm that
   is used every day by millions of users as part of the uTP
   transmission protocol of BitTorrent [LBT] [LCOMPL] and is suitable
   for P2P streaming [PPSPPERF].

   LEDBAT monitors the delay of the packets on the data path.  It uses
   the one-way delay variations to react early and limit the congestion
   that the stream may induce in the network [RFC6817].  Using LEDBAT
   enables PPSPP to serve the content to other interested peers after
   the playback has finished (seeding), without disrupting the user.
   After the playback, the user might move to different tasks that use
   its network link, which are prioritized over PPSPP traffic.  Hence,
   the user does not notice the background PPSPP traffic, which in turn
   increases the chances of seeding the content for a longer period of
   time.

   The property of reacting early is not a problem in a peer-to-peer
   system where multiple sources offer the content.  Considering the
   case of congestion near the sender, LEDBAT's early reaction impacts
   the transmission of chunks to the receiver.  However, for the
   receiver, it is actually beneficial to learn early that the
   transmission from a particular source is impacted.  The receiver can
   then choose to download time-critical chunks from other sources
   during its chunk picking phase.

   If the bottleneck is near the receiver, the receiver is indeed
   unlucky that transmissions from any source that runs through this
   bottleneck will back off quite fast due to LEDBAT.  However, for the
   rest of the network (and the network operator), this is beneficial as
   the video-streaming system will back off early enough and not
   contribute too much to the congestion.

Top      Up      ToC       Page 57 
   The power of LEDBAT is that its behavior can be configured.  In the
   case of live streaming, a PPSPP deployer may want a more aggressive
   behavior to ensure quality of service.  In that case, LEDBAT can be
   configured to be more aggressive.  In particular, LEDBAT's queuing
   target delay value (TARGET in [RFC6817]) and other parameters can be
   adjusted such that it acts as aggressive as TCP (or even more).
   Hence, LEDBAT is an algorithm that works for many scenarios in a
   peer-to-peer context.

8.16.  Example of Operation

   We present a small example of communication between a leecher and a
   seeder.  The example presents the transmission of the file "Hello
   World!", which fits within a 1024-byte chunk.  For an easy
   understanding, we use the message description names, as listed in
   Table 7, and the protocol option names as listed in Table 2, rather
   than the actual binary value.

   To do the handshake, the initiating peer sends a datagram that MUST
   start with an all-zeros channel ID (0x00000000); followed by a
   HANDSHAKE message, whose payload is a locally unused; a random
   channel ID (in this case 0x00000001); and a list of protocol options.
   Channel IDs MUST be randomly chosen, as described in Section 12.1.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   HANDSHAKE   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 1|    Version    |0 0 0 0 0 0 0 1|  Min Version  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 1|   Swarm ID    |0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 1 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 0 1 0 0 1 1 1 1 1 0 0 1 1 0|
   ~                             .....                             ~
   |1 0 0 0 0 1 1 0 1 0 1 0 1 0 1 0 1 0 1 1 0 0 0 0 0 0 1 1 1 0 1 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Cont. Int.  |0 0 0 0 0 0 0 1| Mer.H.Tree F. |0 0 0 0 0 0 1 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Chunk Add.  |0 0 0 0 0 0 1 0|   Chunk Size  |0 0 0 0 0 0 0 0~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0|      End      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 58 
   The protocol options are:

      Version: 1

      Minimum supported Version: 1

      Swarm Identifier: A 32-byte root hash (47a0...b03b) identifying
      the content

      Content Integrity Protection Method: Merkle Hash Tree

      Merkle Tree Hash Function: SHA-256

      Chunk Addressing Method: 32-bit chunk ranges

      Chunk Size: 1024

   The receiving peer MAY respond, in which case the returned datagram
   MUST consist of the channel ID from the sender's HANDSHAKE message
   (0x00000001); a HANDSHAKE message, whose payload is a locally unused;
   a random channel ID (0x00000008); and a list of protocol options;
   followed by any other messages it wants to send.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   HANDSHAKE   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 1 0 0 0|    Version    |0 0 0 0 0 0 0 1|   Cont. Int.  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 1| Mer.H.Tree F. |0 0 0 0 0 0 1 0|   Chunk Add.  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 1 0|  Chunk Size   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0|      End      |      HAVE     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   With the protocol options, the receiving peer agrees on speaking
   protocol version 1, on using the Merkle Hash Tree as the Content
   Integrity Protection Method, SHA-256 hash as the Merkle Tree Hash
   Function, 32-bit chunk ranges as the Chunk Addressing Method, and

Top      Up      ToC       Page 59 
   Chunk Size 1024.  Furthermore, it sends a HAVE message within the
   same datagram, announcing that it has locally available the first
   chunk of content.

   At this point, the initiator knows that the peer really responds; for
   that purpose, channel IDs MUST be random enough to prevent easy
   guessing.  So, the third datagram of a handshake MAY already contain
   some heavy payload.  To minimize the number of initialization round
   trips, the first two datagrams MAY also contain some minor payload,
   e.g., the HAVE message.

   The initiating peer MAY send a request for the chunks of content it
   wants to retrieve from the receiving peer, e.g., the first chunk
   announced during the handshake.  It always precedes the message with
   the channel ID of the peer it is communicating with (0x00000008 in
   our example), as described in Section 3.11.  Furthermore, it MAY add
   additional messages such as a PEX_REQ.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    REQUEST    |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0|    PEX_REQ    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   When receiving the third datagram, both peers have proof that they
   really talk to each other; the three-way handshake is complete.  The
   receiving peer responds to the request by sending a DATA message
   containing the requested content.

Top      Up      ToC       Page 60 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     DATA      |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 1 1 0 1 0 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 1 0 0 0 0 0 1 1 0 0 0 0 0 0 0 1 0 1 1 0 1 1 1 1 1 0 1 1 0 1 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 1 0 0 0 1 0 0|0 1 0 0 1 0 0 0 0 1 1 0 0 1 0 1 0 1 1 0 1 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                           .....                               ~
   |0 1 1 0 1 1 0 0 0 1 1 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 1 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The DATA message consists of:

      The 32-bit chunk range: 0,0 (the first chunk)

      The timestamp value: 0004e94180b7db44

      The data: 48656c6c6f20776f726c6421 (the "Hello world!" file)

   Note that the above datagram does not include the INTEGRITY message,
   as the entire content can fit into a single message; hence, the
   initiating peer is able to verify it against the root hash.  Also, in
   this example, the peer does not respond to the PEX_REQ as it does not
   know any third peer participating in the swarm.

   Upon receiving the requested data, the initiating peer responds with
   an ACK message for the first chunk, containing a one-way delay sample
   (100 ms).  Furthermore, it also adds a HAVE message for the chunk.

Top      Up      ToC       Page 61 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      ACK      |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 1 1 0 0 1 0 0|      HAVE     |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   At this point, the initiating peer has successfully retrieved the
   entire file.  Then, it explicitly closes the connection by sending a
   HANDSHAKE message that contains an all-zeros Source Channel ID.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   HANDSHAKE   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0|      End      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9.  Extensibility

9.1.  Chunk Picking Algorithms

   Chunk (or piece) picking entirely depends on the receiving peer.  The
   sending peer is made aware of preferred chunks by the means of
   REQUEST messages.  In some (live) scenarios, it may be beneficial to
   allow the sender to ignore those hints and send unrequested data.

   The chunk picking algorithm is external to the PPSPP and will
   generally be a pluggable policy that uses the mechanisms provided by
   PPSPP.  The algorithm will handle the choices made by the user

Top      Up      ToC       Page 62 
   consuming the content, such as seeking or switching audio tracks or
   subtitles.  Example policies for P2P streaming can be found in
   [BITOS], and [EPLIVEPERF].

9.2.  Reciprocity Algorithms

   The role of reciprocity algorithms in peer-to-peer systems is to
   promote client contribution and prevent freeriding.  A peer is said
   to be freeriding if it only downloads content but never uploads to
   others.  Examples of reciprocity algorithms are tit-for-tat as used
   in BitTorrent [TIT4TAT] and Give-to-Get [GIVE2GET].  In PPSPP,
   reciprocity enforcement is the sole responsibility of the sending
   peer.

10.  IANA Considerations

   IANA has created a new top-level registry called "Peer-to-Peer
   Streaming Peer Protocol (PPSPP)", which hosts the six new sub-
   registries defined below for the extensibility of the protocol.  For
   all registries, assignments consist of a name and its associated
   value.  Also, for all registries, the "Unassigned" ranges designated
   are governed by the policy "IETF Review" as described in [RFC5226].

10.1.  PPSPP Message Type Registry

   The registry name is "PPSPP Message Type Registry".  Values are
   integers in the range 0-255, with initial assignments and
   reservations given in Table 7.

10.2.  PPSPP Option Registry

   The registry name is "PPSPP Option Registry".  Values are integers in
   the range 0-255, with initial assignments and reservations given in
   Table 2.

10.3.  PPSPP Version Number Registry

   The registry name is "PPSPP Version Number Registry".  Values are
   integers in the range 0-255, with initial assignments and
   reservations given in Table 3.

10.4.  PPSPP Content Integrity Protection Method Registry

   The registry name is "PPSPP Content Integrity Protection Method
   Registry".  Values are integers in the range 0-255, with initial
   assignments and reservations given in Table 4.

Top      Up      ToC       Page 63 
10.5.  PPSPP Merkle Hash Tree Function Registry

   The registry name is "PPSPP Merkle Hash Tree Function Registry".
   Values are integers in the range 0-255, with initial assignments and
   reservations given in Table 5.

10.6.  PPSPP Chunk Addressing Method Registry

   The registry name is "PPSPP Chunk Addressing Method Registry".
   Values are integers in the range 0-255, with initial assignments and
   reservations given in Table 6.

11.  Manageability Considerations

   This section presents operations and management considerations
   following the checklist in [RFC5706], Appendix A.

   In this section, "PPSPP client" is defined as a PPSPP peer acting on
   behalf of an end user which may not yet have a copy of the content,
   and "PPSPP server" as a PPSPP peer that provides the initial copies
   of the content to the swarm on behalf of a content provider.

11.1.  Operations

11.1.1.  Installation and Initial Setup

   A content provider wishing to use PPSPP to distribute content should
   set up at least one PPSPP server.  PPSPP servers need to have access
   to either some static content or some live audio/video sources.  To
   provide flexibility for implementors, this configuration process is
   not standardized.  The output of this process will be a list of
   metadata records, one for each swarm.  A metadata record consists of
   the swarm ID, the chunk size used, the chunk addressing method used,
   the content integrity protection method used, and the Merkle hash
   tree function used (if applicable).  If automatic content size
   detection (see Section 5.6) is not used, the content length is also
   part of the metadata record for static content.  Note the swarm ID
   already contains the Live Signature Algorithm used, in case of a live
   stream.

   In addition, a content provider should set up a tracking facility for
   the content by configuring, for example, a peer-to-peer streaming
   protocol tracker [PPSP-TP] or a Distributed Hash Table.  The output
   of the latter process is a list of transport addresses for the
   tracking facility.

Top      Up      ToC       Page 64 
   The list of metadata records of available content, and transport
   address for the tracking facility, can be distributed to users in
   various ways.  Typically, they will be published on a website as
   links.  When a user clicks such a link, the PPSPP client is launched,
   either as a standalone application or by invoking the browser's
   internal PPSPP protocol handler, as exemplified in Section 2.  The
   clients use the tracking facility to obtain the transport address of
   the PPSPP server(s) and other peers from the swarm, executing the
   peer protocol to retrieve and redistribute the content.  The format
   of the PPSPP URLs should be defined in an extension document.  The
   default protocol options should be exploited to keep the URLs small.

   The minimal information a tracking facility must return when queried
   for a list of peers for a swarm is as follows.  Assuming the
   communication between tracking facility and requester is protected,
   the facility must at least return for each peer in the list its IP
   address, transport protocol identifier (i.e., UDP), and transport
   protocol port number.

11.1.2.  Migration Path

   This document does not detail a migration path since there is no
   previous standard protocol providing similar functionality.

11.1.3.  Requirements on Other Protocols and Functional Components

   When using the peer-to-peer streaming protocol tracker, PPSPP
   requires a specific behavior from this protocol for security reasons,
   as detailed in Section 12.2.

11.1.4.  Impact on Network Operation

   PPSPP is a peer-to-peer protocol that takes advantage of the fact
   that content is available from multiple sources to improve
   robustness, scalability, and performance.  At the same time, poor
   choices in determining which exact sources to use can lead to bad
   experience for the end user and high costs for network operators.
   Hence, PPSPP can benefit from the ALTO protocol to steer peer
   selection, as described in Section 3.10.1.

Top      Up      ToC       Page 65 
11.1.5.  Verifying Correct Operation

   PPSPP is operating correctly when all peers obtain the desired
   content on time.  Therefore, the PPSPP client is the ideal location
   to verify the protocol's correct operation.  However, it is not
   feasible to mandate logging the behavior of PPSPP peers in all
   implementations and deployments, for example, due to privacy reasons.
   There are two alternative options:

   o  Monitoring the PPSPP servers initially providing the content,
      using standard metrics such as bandwidth usage, peer connections,
      and activity, can help identify trouble, see next section and
      [RFC2564].

   o  The tracker protocol [PPSP-TP] may be used to gather information
      about all peers in a swarm, to obtain a global view of operation,
      according to PPSP.OAM.REQ-3 in [RFC6972].

   Basic operation of the protocol can be easily verified when a tracker
   and swarm metadata are known by starting a PPSPP download.  Deep
   packet inspection for DATA and ACK messages help to establish that
   actual content transfer is happening and that the chunk availability
   signaling and integrity checking are working.

11.1.6.  Configuration

   Table 8 shows the PPSPP parameters, their defaults, and where the
   parameter is defined.  For parameters that have no default, the table
   row contains the word "var" and refers to the section discussing the
   considerations to make when choosing a value.

Top      Up      ToC       Page 66 
   +-------------------------+-----------------------+-----------------+
   | Name                    | Default               | Definition      |
   +-------------------------+-----------------------+-----------------+
   | Chunk Size              | var, 1024 bytes       | Section 8.1     |
   |                         | recommended           |                 |
   |                         |                       |                 |
   | Static Content          | 1 (Merkle Hash Tree)  | Section 7.5     |
   | Integrity Protection    |                       |                 |
   | Method                  |                       |                 |
   |                         |                       |                 |
   | Live Content Integrity  | 3 (Unified Merkle     | Section 7.5     |
   | Protection Method       | Tree)                 |                 |
   |                         |                       |                 |
   | Merkle Hash Tree        | 2 (SHA-256)           | Section 7.6     |
   | Function                |                       |                 |
   |                         |                       |                 |
   | Live Signature          | 13 (ECDSAP256SHA256)  | Section 7.7     |
   | Algorithm               |                       |                 |
   |                         |                       |                 |
   | Chunk Addressing Method | 2 (32-bit chunk       | Section 7.8     |
   |                         | ranges)               |                 |
   |                         |                       |                 |
   | Live Discard Window     | var                   | Section 6.2,    |
   |                         |                       | Section 7.9     |
   |                         |                       |                 |
   | NCHUNKS_PER_SIG         | var                   | Section 6.1.2.1 |
   |                         |                       |                 |
   | Dead peer detection     | No reply in 3 minutes | Section 3.12    |
   |                         | + 3 datagrams         |                 |
   +-------------------------+-----------------------+-----------------+

                          Table 8: PPSPP Defaults

11.2.  Management Considerations

   The management considerations for PPSPP are very similar to other
   protocols that are used for large-scale content distribution, in
   particular HTTP.  How does one manage large numbers of servers?  How
   does one push new content out to a server farm and allows staged
   releases?  How are faults detected and how are servers and end-user
   performance measured?  As standard solutions to these challenges are
   still being developed, this section cannot provide a definitive
   recommendation on how PPSPP should be managed.  Hence, it describes
   the standard solutions available at this time and assumes a future
   extension document will provide more complete guidelines.

Top      Up      ToC       Page 67 
11.2.1.  Management Interoperability and Information

   As just stated, PPSPP servers providing initial copies of the content
   are akin to WWW and FTP servers.  They can also be deployed in large
   numbers and thus can benefit from standard management facilities.
   Therefore, PPSPP servers may implement an SNMP management interface
   based on the APPLICATION-MIB [RFC2564], where the file object can be
   used to report on swarms.

   What is missing is the ability to remove or rate limit specific PPSPP
   swarms on a server.  This corresponds to removing or limiting
   specific virtual servers on a web server.  In other words, as
   multiple pieces of content (swarms, virtual WWW servers) are
   multiplexed onto a single server process, more fine-grained
   management of that process is required.  This functionality is
   currently missing.

   Logging is an important functionality for PPSPP servers and,
   depending on the deployment, PPSPP clients.  Logging should be done
   via syslog [RFC5424].

11.2.2.  Fault Management

   The facilities for verifying correct operation and server management
   (just discussed) appear sufficient for PPSPP fault monitoring.  This
   can be supplemented with host resource [RFC2790] and UDP/IP network
   monitoring [RFC4113], as PPSPP server failures can generally be
   attributed directly to conditions on the host or network.

   Since PPSPP has been designed to work in a hostile environment, many
   benign faults will be handled by the mechanisms used for managing
   attacks.  For example, when a malfunctioning peer starts sending the
   wrong chunks, this is detected by the content integrity protection
   mechanism and another source is sought.

11.2.3.  Configuration Management

   Large-scale deployments may benefit from a standard way of
   replicating a new piece of content on a set of initial PPSPP servers.
   This functionality may need to include controlled releasing, such
   that content becomes available only at a specific point in time
   (e.g., the release of a movie trailer).  This functionality could be
   provided via NETCONF [RFC6241], to enable atomic configuration
   updates over a set of servers.  Uploading the new content could be
   one configuration change, making the content available for download
   by the public another.

Top      Up      ToC       Page 68 
11.2.4.  Accounting Management

   Content providers may offer PPSPP hosting for different customers and
   will want to bill these customers, for example, based on bandwidth
   usage.  This situation is a common accounting scenario, similar to
   billing per virtual server for web servers.  PPSPP can therefore
   benefit from general standardization efforts in this area [RFC2975]
   when they come to fruition.

11.2.5.  Performance Management

   Depending on the deployment scenarios, the application performance
   measurement facilities of [RFC3729] and associated [RFC4150] can be
   used with PPSPP.

   In addition, when the PPSPP tracker protocol is used, it provides a
   built-in, application-level, performance measurement infrastructure
   for different metrics.  See PPSP.OAM.REQ-3 in [RFC6972].

11.2.6.  Security Management

   Malicious peers should ideally be locked out long term.  This is
   primarily for performance reasons, as the protocol is robust against
   attacks (see next section).  Section 12.7 describes a procedure for
   long-term exclusion.



(page 68 continued on part 4)

Next RFC Part