RFC 7574

Peer-to-Peer Streaming Peer Protocol (PPSPP)

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.

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

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

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

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

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.

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.

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.

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.

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.

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.

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.