idnits 2.17.1 

draft-ietf-ppsp-peer-protocol-09.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

  -- The document date (April 4, 2014) is 3675 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-4'

  -- Possible downref: Non-RFC (?) normative reference: ref.
     'IANADNSSECALGNUM'

  == Outdated reference: A later version (-12) exists of
     draft-ietf-ppsp-base-tracker-protocol-03

  -- Obsolete informational reference (is this intentional?): RFC 4960
     (Obsoleted by RFC 9260)

  -- Obsolete informational reference (is this intentional?): RFC 5226
     (Obsoleted by RFC 8126)

  -- Obsolete informational reference (is this intentional?): RFC 5389
     (Obsoleted by RFC 8489)

  -- Obsolete informational reference (is this intentional?): RFC 6347
     (Obsoleted by RFC 9147)


     Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.
--------------------------------------------------------------------------------


2	PPSP                                                           A. Bakker
3	Internet-Draft                              Vrije Universiteit Amsterdam
4	Intended status: Standards Track                             R. Petrocco
5	Expires: October 6, 2014                                  V. Grishchenko
6	                                           Technische Universiteit Delft
7	                                                           April 4, 2014

9	              Peer-to-Peer Streaming Peer Protocol (PPSPP)
10	                    draft-ietf-ppsp-peer-protocol-09

12	Abstract

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

32	Status of this Memo

34	   This Internet-Draft is submitted in full conformance with the
35	   provisions of BCP 78 and BCP 79.

37	   Internet-Drafts are working documents of the Internet Engineering
38	   Task Force (IETF).  Note that other groups may also distribute
39	   working documents as Internet-Drafts.  The list of current Internet-
40	   Drafts is at http://datatracker.ietf.org/drafts/current/.

42	   Internet-Drafts are draft documents valid for a maximum of six months
43	   and may be updated, replaced, or obsoleted by other documents at any
44	   time.  It is inappropriate to use Internet-Drafts as reference
45	   material or to cite them other than as "work in progress."

47	   This Internet-Draft will expire on October 6, 2014.

49	Copyright Notice

51	   Copyright (c) 2014 IETF Trust and the persons identified as the
52	   document authors.  All rights reserved.

54	   This document is subject to BCP 78 and the IETF Trust's Legal
55	   Provisions Relating to IETF Documents
56	   (http://trustee.ietf.org/license-info) in effect on the date of
57	   publication of this document.  Please review these documents
58	   carefully, as they describe your rights and restrictions with respect
59	   to this document.  Code Components extracted from this document must
60	   include Simplified BSD License text as described in Section 4.e of
61	   the Trust Legal Provisions and are provided without warranty as
62	   described in the Simplified BSD License.

64	Table of Contents

66	   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6
67	     1.1.  Purpose  . . . . . . . . . . . . . . . . . . . . . . . . .  6
68	     1.2.  Requirements Language  . . . . . . . . . . . . . . . . . .  7
69	     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  7
70	   2.  Overall Operation  . . . . . . . . . . . . . . . . . . . . . .  9
71	     2.1.  Example: Joining a Swarm . . . . . . . . . . . . . . . . .  9
72	     2.2.  Example: Exchanging Chunks . . . . . . . . . . . . . . . . 10
73	     2.3.  Example: Leaving a Swarm . . . . . . . . . . . . . . . . . 11
74	   3.  Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
75	     3.1.  HANDSHAKE  . . . . . . . . . . . . . . . . . . . . . . . . 11
76	     3.2.  HAVE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
77	     3.3.  DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
78	     3.4.  ACK  . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
79	     3.5.  INTEGRITY  . . . . . . . . . . . . . . . . . . . . . . . . 13
80	     3.6.  SIGNED_INTEGRITY . . . . . . . . . . . . . . . . . . . . . 13
81	     3.7.  REQUEST  . . . . . . . . . . . . . . . . . . . . . . . . . 13
82	     3.8.  CANCEL . . . . . . . . . . . . . . . . . . . . . . . . . . 14
83	     3.9.  CHOKE and UNCHOKE  . . . . . . . . . . . . . . . . . . . . 14
84	     3.10. Peer Address Exchange  . . . . . . . . . . . . . . . . . . 14
85	       3.10.1.  PEX_REQ and PEX_RES Messages  . . . . . . . . . . . . 14
86	     3.11. Channels . . . . . . . . . . . . . . . . . . . . . . . . . 16
87	     3.12. Keep Alive Signalling  . . . . . . . . . . . . . . . . . . 17
88	   4.  Chunk Addressing Schemes . . . . . . . . . . . . . . . . . . . 17
89	     4.1.  Start-End Ranges . . . . . . . . . . . . . . . . . . . . . 18
90	       4.1.1.   Chunk Ranges  . . . . . . . . . . . . . . . . . . . . 18
91	       4.1.2.   Byte Ranges . . . . . . . . . . . . . . . . . . . . . 18
92	     4.2.  Bin Numbers  . . . . . . . . . . . . . . . . . . . . . . . 18
93	     4.3.  In Messages  . . . . . . . . . . . . . . . . . . . . . . . 20
94	       4.3.1.   In HAVE Messages  . . . . . . . . . . . . . . . . . . 20
95	       4.3.2.   In ACK Messages . . . . . . . . . . . . . . . . . . . 20

97	   5.  Content Integrity Protection . . . . . . . . . . . . . . . . . 21
98	     5.1.  Merkle Hash Tree Scheme  . . . . . . . . . . . . . . . . . 21
99	     5.2.  Content Integrity Verification . . . . . . . . . . . . . . 22
100	     5.3.  The Atomic Datagram Principle  . . . . . . . . . . . . . . 23
101	     5.4.  INTEGRITY Messages . . . . . . . . . . . . . . . . . . . . 24
102	     5.5.  Discussion and Overhead  . . . . . . . . . . . . . . . . . 24
103	     5.6.  Automatic Detection of Content Size  . . . . . . . . . . . 25
104	       5.6.1.   Peak Hashes . . . . . . . . . . . . . . . . . . . . . 26
105	       5.6.2.   Procedure . . . . . . . . . . . . . . . . . . . . . . 28
106	   6.  Live Streaming . . . . . . . . . . . . . . . . . . . . . . . . 28
107	     6.1.  Content Authentication . . . . . . . . . . . . . . . . . . 28
108	       6.1.1.   Sign All  . . . . . . . . . . . . . . . . . . . . . . 29
109	       6.1.2.   Unified Merkle Tree . . . . . . . . . . . . . . . . . 30
110	         6.1.2.1.  Signed Munro Hashes  . . . . . . . . . . . . . . . 30
111	         6.1.2.2.  Munro Signature Calculation  . . . . . . . . . . . 33
112	         6.1.2.3.  Procedure  . . . . . . . . . . . . . . . . . . . . 33
113	         6.1.2.4.  Secure Tune In . . . . . . . . . . . . . . . . . . 33
114	     6.2.  Forgetting Chunks  . . . . . . . . . . . . . . . . . . . . 34
115	   7.  Protocol Options . . . . . . . . . . . . . . . . . . . . . . . 35
116	     7.1.  End Option . . . . . . . . . . . . . . . . . . . . . . . . 35
117	     7.2.  Version  . . . . . . . . . . . . . . . . . . . . . . . . . 35
118	     7.3.  Minimum Version  . . . . . . . . . . . . . . . . . . . . . 36
119	     7.4.  Swarm Identifier . . . . . . . . . . . . . . . . . . . . . 36
120	     7.5.  Content Integrity Protection Method  . . . . . . . . . . . 37
121	     7.6.  Merkle Tree Hash Function  . . . . . . . . . . . . . . . . 37
122	     7.7.  Live Signature Algorithm . . . . . . . . . . . . . . . . . 38
123	     7.8.  Chunk Addressing Method  . . . . . . . . . . . . . . . . . 38
124	     7.9.  Live Discard Window  . . . . . . . . . . . . . . . . . . . 39
125	     7.10. Supported Messages . . . . . . . . . . . . . . . . . . . . 40
126	   8.  UDP Encapsulation  . . . . . . . . . . . . . . . . . . . . . . 40
127	     8.1.  Chunk Size . . . . . . . . . . . . . . . . . . . . . . . . 40
128	     8.2.  Datagrams and Messages . . . . . . . . . . . . . . . . . . 41
129	     8.3.  Channels . . . . . . . . . . . . . . . . . . . . . . . . . 42
130	     8.4.  HANDSHAKE  . . . . . . . . . . . . . . . . . . . . . . . . 43
131	     8.5.  HAVE . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
132	     8.6.  DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
133	     8.7.  ACK  . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
134	     8.8.  INTEGRITY  . . . . . . . . . . . . . . . . . . . . . . . . 46
135	     8.9.  SIGNED_INTEGRITY . . . . . . . . . . . . . . . . . . . . . 47
136	     8.10. REQUEST  . . . . . . . . . . . . . . . . . . . . . . . . . 48
137	     8.11. CANCEL . . . . . . . . . . . . . . . . . . . . . . . . . . 48
138	     8.12. CHOKE and UNCHOKE  . . . . . . . . . . . . . . . . . . . . 49
139	     8.13. PEX_REQ, PEX_RESv4, PEX_RESv6 and PEX_REScert  . . . . . . 49
140	     8.14. KEEPALIVE  . . . . . . . . . . . . . . . . . . . . . . . . 51
141	     8.15. Detecting a Dead Peer  . . . . . . . . . . . . . . . . . . 51
142	     8.16. Flow and Congestion Control  . . . . . . . . . . . . . . . 52
143	     8.17. Example of Operation . . . . . . . . . . . . . . . . . . . 52
144	   9.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . . . 57
145	     9.1.  Chunk Picking Algorithms . . . . . . . . . . . . . . . . . 57
146	     9.2.  Reciprocity Algorithms . . . . . . . . . . . . . . . . . . 57
147	   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57
148	   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 58
149	     11.1. PPSP Peer Protocol Message Type Registry . . . . . . . . . 58
150	     11.2. PPSP Peer Protocol Option Registry . . . . . . . . . . . . 58
151	     11.3. PPSP Peer Protocol Version Number Registry . . . . . . . . 58
152	     11.4. PPSP Peer Protocol Content Integrity Protection Method
153	           Registry . . . . . . . . . . . . . . . . . . . . . . . . . 58
154	     11.5. PPSP Peer Protocol Merkle Hash Tree Function Registry  . . 58
155	     11.6. PPSP Peer Protocol Chunk Addressing Method Registry  . . . 58
156	   12. Manageability Considerations . . . . . . . . . . . . . . . . . 58
157	     12.1. Operations . . . . . . . . . . . . . . . . . . . . . . . . 59
158	       12.1.1.  Installation and Initial Setup  . . . . . . . . . . . 59
159	       12.1.2.  Requirements on Other Protocols and Functional
160	                Components  . . . . . . . . . . . . . . . . . . . . . 60
161	       12.1.3.  Migration Path  . . . . . . . . . . . . . . . . . . . 60
162	       12.1.4.  Impact on Network Operation . . . . . . . . . . . . . 60
163	       12.1.5.  Verifying Correct Operation . . . . . . . . . . . . . 60
164	       12.1.6.  Configuration . . . . . . . . . . . . . . . . . . . . 61
165	     12.2. Management Considerations  . . . . . . . . . . . . . . . . 61
166	       12.2.1.  Management Interoperability and Information . . . . . 62
167	       12.2.2.  Fault Management  . . . . . . . . . . . . . . . . . . 62
168	       12.2.3.  Configuration Management  . . . . . . . . . . . . . . 62
169	       12.2.4.  Accounting Management . . . . . . . . . . . . . . . . 63
170	       12.2.5.  Performance Management  . . . . . . . . . . . . . . . 63
171	       12.2.6.  Security Management . . . . . . . . . . . . . . . . . 63
172	   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 63
173	     13.1. Security of the Handshake Procedure  . . . . . . . . . . . 63
174	       13.1.1.  Protection Against Attack 1 . . . . . . . . . . . . . 64
175	       13.1.2.  Protection Against Attack 2 . . . . . . . . . . . . . 65
176	       13.1.3.  Protection Against Attack 3 . . . . . . . . . . . . . 65
177	     13.2. Secure Peer Address Exchange . . . . . . . . . . . . . . . 66
178	       13.2.1.  Protection against the Amplification Attack . . . . . 66
179	       13.2.2.  Example: Tracker as Certification Authority . . . . . 67
180	       13.2.3.  Protection Against Eclipse Attacks  . . . . . . . . . 68
181	     13.3. Support for Closed Swarms (PPSP.SEC.REQ-1) . . . . . . . . 68
182	     13.4. Confidentiality of Streamed Content (PPSP.SEC.REQ-2+3) . . 68
183	     13.5. Strength of the Hash Function for Merkle Hash Trees  . . . 69
184	     13.6. Limit Potential Damage and Resource Exhaustion by Bad
185	           or Broken Peers (PPSP.SEC.REQ-4+6) . . . . . . . . . . . . 69
186	       13.6.1.  HANDSHAKE . . . . . . . . . . . . . . . . . . . . . . 69
187	       13.6.2.  HAVE  . . . . . . . . . . . . . . . . . . . . . . . . 69
188	       13.6.3.  DATA  . . . . . . . . . . . . . . . . . . . . . . . . 70
189	       13.6.4.  ACK . . . . . . . . . . . . . . . . . . . . . . . . . 70
190	       13.6.5.  INTEGRITY and SIGNED_INTEGRITY  . . . . . . . . . . . 70
191	       13.6.6.  REQUEST . . . . . . . . . . . . . . . . . . . . . . . 71
192	       13.6.7.  CANCEL  . . . . . . . . . . . . . . . . . . . . . . . 71
193	       13.6.8.  CHOKE . . . . . . . . . . . . . . . . . . . . . . . . 71
194	       13.6.9.  UNCHOKE . . . . . . . . . . . . . . . . . . . . . . . 71
195	       13.6.10. PEX_RES . . . . . . . . . . . . . . . . . . . . . . . 72
196	       13.6.11. Unsolicited Messages in General . . . . . . . . . . . 72
197	     13.7. Exclude Bad or Broken Peers (PPSP.SEC.REQ-5) . . . . . . . 72
198	   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
199	     14.1. Normative References . . . . . . . . . . . . . . . . . . . 72
200	     14.2. Informative References . . . . . . . . . . . . . . . . . . 73
201	   Appendix A.  Revision History  . . . . . . . . . . . . . . . . . . 77
202	   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 95

204	1.  Introduction

206	1.1.  Purpose

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

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

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

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

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

254	1.2.  Requirements Language

256	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
257	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
258	   document are to be interpreted as described in RFC 2119 [RFC2119].

260	1.3.  Terminology

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

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

273	   content
274	       Either a live transmission, a pre-recorded multimedia asset, or a
275	       file.

277	   chunk
278	       The basic unit in which the content is divided.  E.g. a block of
279	       N kilobyte.

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

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

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

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

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

301	   content integrity protection scheme
302	       Scheme for protecting the integrity of the content while it is
303	       being distributed via the peer-to-peer network.  I.e. methods for
304	       receiving peers to detect whether a requested chunk has been
305	       maliciously modified by the sending peer.

307	   hash
308	       The result of applying a cryptographic hash function, more
309	       specifically a modification detection code (MDC) [HAC01], such as
310	       SHA-1 [FIPS180-4], to a piece of data.

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

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

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

326	   swarm ID
327	       Unique identifier for a swarm of peers, in PPSPP a sequence of
328	       bytes.  When Merkle hash trees are used for content integrity
329	       protection, the identifier is the so-called root hash of the
330	       content (video-on-demand).  For live streaming, the swarm ID is a
331	       public key.

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

338	   choking
339	       When a peer A is choking peer B it means that A is currently not
340	       willing to accept requests for content from B.

342	   seeding
343	       Peer A is said to be seeding when A has downloaded a static
344	       content asset completely and is now offering it for others to
345	       download.

347	   leeching
348	       Peer A is said to be leeching when A has not completely
349	       downloaded a static content asset yet or is not offering to
350	       upload it to others.

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

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

362	   In this document the prefixes kilo, mega, etc. denote base 1024.

364	2.  Overall Operation

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

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

378	2.1.  Example: Joining a Swarm

380	   Consider a user who wants to watch a video.  To play the video, the
381	   user clicks on the play button of a HTML5 <video> element shown in
382	   his PPSPP-enabled browser.  Imagine this element has a PPSPP URL (to
383	   be defined elsewhere) identifying the video as it source.  The
384	   browser passes this URL to its PPSP protocol handler.  Let's call
385	   this protocol handler peer A. Peer A parses the URL to retrieve the
386	   transport address of a PPSP tracker and swarm ID of the content.  The
387	   tracker address may be optional in the presence of a decentralized
388	   tracking mechanism.

390	   Peer A now registers with the tracker following the PPSP tracker
391	   protocol [I-D.ietf-ppsp-base-tracker-protocol] and receives the IP
392	   address and port of peers already in the swarm, say B, C, and D. Peer
393	   A now sends a datagram containing a HANDSHAKE message to B, C, and D.

395	   This message conveys protocol options, in particular, peer A includes
396	   the ID of the swarm as the destination peers can listen for multiple
397	   swarms on the same transport address.

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

407	2.2.  Example: Exchanging Chunks

409	   In response to B and C, A sends new datagrams to B and C containing
410	   REQUEST messages.  A REQUEST message indicates the chunks that a peer
411	   wants to download, and thus contains a chunk specification.  The
412	   REQUEST messages to B and C refer to disjunct sets of chunks.  B and
413	   C respond with datagrams containing HAVE, DATA and, in this example,
414	   INTEGRITY messages.  In the Merkle hash tree content protection
415	   scheme (see Section 5.1), the INTEGRITY messages contain all
416	   cryptographic hashes that peer A needs to verify the integrity of the
417	   content chunk sent in the DATA message.  Using these hashes peer A
418	   verifies that the chunks received from B and C are correct.  It also
419	   updates the chunk availability of B and C using the information in
420	   the received HAVE messages.  In addition, it passes the chunks of
421	   video to the user's browser for rendering.

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

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

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

444	2.3.  Example: Leaving a Swarm

446	   To leave a swarm in a graceful way, peer A sends a specific HANDSHAKE
447	   message to all its peers (see Section 8.4) and deregisters from the
448	   tracker following the (PPSP) tracker protocol.  Peers receiving the
449	   datagram should remove A from their current peer list.  If A crashes
450	   ungracefully, peers should remove A from their peer list when they
451	   detect it no longer sends messages (see Section 8.15).

453	3.  Messages

455	   In general, no error codes or responses are used in the protocol;
456	   absence of any response indicates an error.  Invalid messages are
457	   discarded, and further communication with the peer SHOULD be stopped.
458	   The rationale is that it is sufficient to classify peers as either
459	   good (i.e., responding with chunks) or bad and only use the good
460	   ones.  This behavior allows a peer to deal with slow, crashed and
461	   (silent) malicious peers.

463	   Multiple messages are multiplexed into a single datagram for
464	   transmission.  Messages in a single datagram MUST be processed in the
465	   strict order in which they appear in the datagram.

467	   For the sake of simplicity, one swarm of peers deals with one content
468	   asset (e.g. file) only.  Retrieval of a collections of files can be
469	   done either by using multiple swarms or by using an external storage
470	   mapping from the linear byte space of a single swarm to different
471	   files, transparent to the protocol.

473	3.1.  HANDSHAKE

475	   The initiating peer and the addressed peer MUST send a HANDSHAKE
476	   message as the first message in the first datagrams they exchange.
477	   The payload of the HANDSHAKE message is a channel ID (see
478	   Section 3.11) and a sequence of protocol options.  Example options
479	   are the content integrity protection scheme used and an option to
480	   specify the swarm identifier.  The complete set of protocol options
481	   are specified in Section 7.

483	   After the handshakes are exchanged, the initiator knows that the peer
484	   really responds.  Hence, the second datagram the initiator sends MAY
485	   already contain some heavy payload, e.g.  DATA messages.  To minimize
486	   the number of initialization round-trips, the first two datagrams
487	   exchanged MAY also contain some minor payload, e.g.  HAVE messages to
488	   indicate the current progress of a peer or a REQUEST (see
489	   Section 3.7), but MUST NOT include any DATA message.

491	3.2.  HAVE

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

500	   In particular, whenever a receiving peer P has successfully checked
501	   the integrity of a chunk, or interval of chunks, it SHOULD send a
502	   HAVE message to all peers Q1..Qn it wants to interact with in the
503	   near future.  A policy in peer P determines when the HAVE is sent.  P
504	   may sent it directly, or peer P may wait until either it has other
505	   data to sent to Qi, or until it has received and checked multiple
506	   chunks.  The policy will depend on how urgent it is to distribute
507	   this information to the other peers.  This urgency is generally
508	   determined in turn by the chunk picking policy (see Section 9.1).  In
509	   general, the HAVE messages can be piggybacked onto other messages.
510	   Peers that do not receive HAVE messages are effectively prevented
511	   from downloading the newly available chunks, hence the HAVE message
512	   can be used as a method of choking.

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

521	3.3.  DATA

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

532	3.4.  ACK

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

544	3.5.  INTEGRITY

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

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

561	3.6.  SIGNED_INTEGRITY

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

569	3.7.  REQUEST

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

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

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

592	3.8.  CANCEL

594	   When downloading on demand or live streaming content, a peer can
595	   request urgent data from multiple peers to increase the probability
596	   of it being delivered on time.  In particular, when the specific
597	   chunk picking algorithm (see Section 9.1), detects that a request for
598	   urgent data might not be served on time, a request for the same data
599	   can be sent to a different peer.  When a peer P decides to request
600	   urgent data from a peer Q, peer P SHOULD send a CANCEL message to all
601	   the peers to which the data has been previously requested.  The
602	   CANCEL message contains the specification of the chunks P no longer
603	   wants to request.  In addition, when peer Q receives a HAVE message
604	   for the urgent data from peer P, peer Q MUST also cancel the previous
605	   REQUEST(s) from P. In other words, the HAVE message acts as an
606	   implicit CANCEL.

608	3.9.  CHOKE and UNCHOKE

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

620	3.10.  Peer Address Exchange

622	3.10.1.  PEX_REQ and PEX_RES Messages

624	   Peer address exchange messages (or PEX messages for short) are common
625	   in many peer-to-peer protocols.  They allow peers to exchange the
626	   transport addresses of the peers they are currently interacting with,
627	   thereby reducing the need to contact a central tracker (or DHT) to
628	   discovery new peers.  The strength of this mechanism is therefore
629	   that it enables decentralized peer discovery: after an initial
630	   bootstrap no central tracker is needed anymore.  Its weakness is that
631	   it enables a number of attacks, so it should not be used outside a
632	   benign environment unless extra security measures are in place.

634	   PPSPP supports peer-address exchange in benign and potentially
635	   hostile environments, as an OPTIONAL feature (not mandatory to
636	   implement).  The general mechanism works as follows.  To obtain some
637	   peer addresses a peer A MAY send a PEX_REQ message to peer B. Peer B
638	   MAY respond with one or more PEX_RES messages.  PPSPP supports three
639	   types of PEX_RES reply messages, each containing the address of a
640	   single peer Ci.  The address in the PEX_RES message MUST be of a peer
641	   B has exchanged messages with in the last 60 seconds to guarantee
642	   liveliness.  Upon receipt, peer A may contact any or none of the
643	   returned peers Ci.  Alternatively, peers MAY ignore PEX_REQ and
644	   PEX_RES messages if uninterested in obtaining new peers or because of
645	   security considerations (rate limiting) or any other reason.  The PEX
646	   messages can be used to construct a dedicated tracker peer.

648	   As indicated, there are three types of PEX_RES messages: PEX_RESv4
649	   containing a single IPv4 address and port, PEX_RESv6 containing a
650	   single IPv6 address and port, and a PEX_REScert message.  The
651	   PEX_RESv4 and PEX_RESv6 MUST only be used in a benign environment, as
652	   they provide no guarantees that the host addressed actually
653	   participates in a PPSPP swarm.

655	   To use PEX in PPSPP in a potentially hostile environment, such as the
656	   Internet, three conditions must be met:

658	   1.  Peer transport addresses must be relatively stable.

660	   2.  PEX_REScert messages must be used instead of PEX_RESv4 and
661	       PEX_RESv6.

663	   3.  A peer must not obtain all its peer addresses through PEX.

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

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

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

688	   Once a PPSPP implementation has obtained a list of peers (either via
689	   PEX, from a central tracker or via a DHT), it has to determine which
690	   peers to actually contact.  In this process, a PPSPP implementation
691	   can benefit from information by network or content providers to help
692	   improve network usage and boost PPSPP performance.  How a P2P system
693	   like PPSPP can perform these optimizations using the ALTO protocol is
694	   described in detail in [I-D.ietf-alto-protocol], Section 7.

696	3.11.  Channels

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

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

719	               _________    _________          _________
720	               |       |    |       |          |       |
721	               | Swarm |    | Swarm |          | Swarm |
722	               |  Mgr  |    |   A   |          |   B   |
723	               |_______|    |_______|          |_______|
724	                   |            |                /   \
725	                   |            |               /     \
726	               ____|____    ____|____    ______/__    _\_______
727	               |       |    |       |    |       |    |       |
728	               | Chan  |    | Chan  |    | Chan  |    | Chan  |
729	               |   0   |    |  481  |    |  836  |    |  372  |
730	               |_______|    |_______|    |_______|    |_______|
731	                   |            |            |            |
732	                   |            |            |            |
733	               ____|____________|____________|____________|____
734	               |                                              |
735	               |                      UDP                     |
736	               |                   port 6778                  |
737	               |______________________________________________|

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

744	                                 Figure 1

746	3.12.  Keep Alive Signalling

748	   A peer SHOULD send a "keep alive" message periodically to each peer
749	   it wants to interact with in the future, but has no other messages to
750	   send them at present.  Periodically sending "keep alive" messages
751	   prevents other peers from closing the connection after a predefined
752	   time interval of 3 minutes, as described in Section 8.15.  PPSPP does
753	   not define an explicit message type for "keep alive" messages.  In
754	   the PPSP-over-UDP encapsulation they are implemented as simple
755	   datagrams consisting of a 4-byte channel ID only, see Section 8.3 and
756	   Section 8.4.

758	4.  Chunk Addressing Schemes

760	   PPSPP can use different methods of chunk addressing, that is, support
761	   different ways of identifying chunks and different ways of expressing
762	   the chunk availability map of a peer in a compact fashion.

764	   All peers in a swarm MUST use the same chunk addressing method.

766	4.1.  Start-End Ranges

768	   A chunk specification consists of a single (start specification,end
769	   specification) pair that identifies a range of chunks (end
770	   inclusive).  The start and end specifications can use one of multiple
771	   addressing schemes.  Two schemes are currently defined, chunk ranges
772	   and byte ranges.

774	4.1.1.  Chunk Ranges

776	   The start and end specification are both chunk identifiers.  Chunk
777	   identifiers are 32-bit or 64-bit unsigned integers.  A PPSPP peer
778	   MUST support this scheme.

780	    0                   1                   2                   3
781	    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
782	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
783	   ~                    Start chunk (32 or 64)                     ~
784	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
785	   ~                    End chunk (32 or 64)                       ~
786	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

788	4.1.2.  Byte Ranges

790	   The start and end specification are 64-bit byte offsets in the
791	   content.  The support for this scheme is OPTIONAL.

793	    0                   1                   2                   3
794	    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
795	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
796	   |                    Start byte offset (64)                     |
797	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
798	   |                                                               |
799	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
800	   |                    End byte offset (64)                       |
801	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
802	   |                                                               |
803	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

805	4.2.  Bin Numbers

807	   PPSPP introduces a novel method of addressing chunks of content
808	   called "bin numbers" (or "bins" for short).  Bin numbers allow the
809	   addressing of a binary interval of data using a single integer.  This
810	   reduces the amount of state that needs to be recorded per peer and
811	   the space needed to denote intervals on the wire, making the protocol
812	   light-weight.  In general, this numbering system allows PPSPP to work
813	   with simpler data structures, e.g. to use arrays instead of binary
814	   trees, thus reducing complexity.  The support for this scheme is
815	   OPTIONAL.

817	   In bin addressing, the smallest binary interval is a single chunk
818	   (e.g. a block of bytes which may be of variable size), the largest
819	   interval is a complete range of 2**63 chunks.  In a novel addition to
820	   the classical scheme, these intervals are numbered in a way which
821	   lays them out into a vector nicely, which is called bin numbering, as
822	   follows.  Consider an chunk interval of width W. To derive the bin
823	   numbers of the complete interval and the subintervals, a minimal
824	   balanced binary tree is built that is at least W chunks wide at the
825	   base.  The leaves from left-to-right correspond to the chunks 0..W-1
826	   in the interval, and have bin number I*2 where I is the index of the
827	   chunk (counting beyond W-1 to balance the tree).  The bin number of
828	   higher level nodes P in the tree is calculated as follows:

830	       binP = (binL + binR) / 2

832	   where binL is the bin of node P's left-hand child and binR is the bin
833	   of node P's right-hand child.  Given that each node in the tree
834	   represents a subinterval of the original interval, each such
835	   subinterval now is addressable by a bin number, a single integer.
836	   The bin number tree of an interval of width W=8 looks like this:

838	                                    7
839	                                   / \
840	                                 /     \
841	                               /         \
842	                             /             \
843	                            3                11
844	                           / \              / \
845	                          /   \            /   \
846	                         /     \          /     \
847	                        1       5        9       13
848	                       / \     / \      / \      / \
849	                      0   2   4   6    8   10  12   14

851	                      C0  C1  C2  C3   C4  C5  C6   C7

853	              The bin number tree of an interval of width W=8

855	                                 Figure 2

857	   So bin 7 represents the complete interval, bin 3 represents the
858	   interval of chunk 0..3, bin 1 represents the interval of chunks 0 and
859	   1, and bin 2 represents chunk C1.  The special numbers 0xFFFFFFFF
860	   (32-bit) or 0xFFFFFFFFFFFFFFFF (64-bit) stands for an empty interval,
861	   and 0x7FFF...FFF stands for "everything".

863	   When bin numbering is used, the ID of a chunk is its corresponding
864	   (leaf) bin number in the tree and the chunk specification in HAVE and
865	   ACK messages is equal to a single bin number (32-bit or 64-bit), as
866	   follows.

868	    0                   1                   2                   3
869	    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
870	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
871	   ~                    Bin number (32 or 64)                      ~
872	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

874	4.3.  In Messages

876	4.3.1.  In HAVE Messages

878	   When a receiving peer has successfully checked the integrity of a
879	   chunk or interval of chunks it MUST send a HAVE message to all peers
880	   it wants to interact with.  The latter allows the HAVE message to be
881	   used as a method of choking.  The HAVE message MUST contain the chunk
882	   specification of the biggest complete interval of all chunks the
883	   receiver has received and checked so far that fully includes the
884	   interval of chunks just received.  So the chunk specification MUST
885	   denote at least the interval received, but the receiver is supposed
886	   to aggregate and acknowledge bigger intervals, when possible.

888	   As a result, every single chunk is acknowledged a logarithmic number
889	   of times.  That provides some necessary redundancy of acknowledgments
890	   and sufficiently compensates for unreliable transport protocols.

892	   Implementation note:

894	       To record which chunks a peer has in the state that an
895	       implementation keeps for each peer, an implementation MAY use the
896	       efficient "binmap" data structure, which is a hybrid of a bitmap
897	       and a binary tree, discussed in detail in [BINMAP].

899	4.3.2.  In ACK Messages

901	   PPSPP peers MUST use ACK messages to acknowledge received chunks if
902	   an unreliable transport protocol is used.  When a receiving peer has
903	   successfully checked the integrity of a chunk or interval of chunks C
904	   it MUST send a ACK message containing the chunk specification of its
905	   biggest, complete interval covering C to the sending peer (see HAVE).

907	5.  Content Integrity Protection

909	   PPSPP can use different methods for protecting the integrity of the
910	   content while it is being distributed via the peer-to-peer network.
911	   More specifically, PPSPP can use different methods for receiving
912	   peers to detect whether a requested chunk has been maliciously
913	   modified by the sending peer.  In benign environments, content
914	   integrity protection can be disabled.

916	   For static content, PPSPP currently defines one method for protecting
917	   integrity, called the Merkle Hash Tree scheme.  If PPSPP operates
918	   over the Internet, this scheme MUST be used.  If PPSPP operates in a
919	   benign environment this scheme MAY be used.  So the scheme is
920	   mandatory-to-implement, to satisfy the requirement of strong security
921	   for an IETF protocol [RFC3365].  An extended version of the scheme is
922	   used to efficiently protect dynamically generated content (live
923	   streams), as explained below and in Section 6.1.

925	   The Merkle Hash Tree scheme can work with different chunk addressing
926	   schemes.  All it requires is the ability to address a range of
927	   chunks.  In the following description abstract node IDs are used to
928	   identify nodes in the tree.  On the wire these are translated to the
929	   corresponding range of chunks in the chosen chunk addressing scheme.

931	5.1.  Merkle Hash Tree Scheme

933	   PPSPP uses a method of naming content based on self-certification.
934	   In particular, content in PPSPP is identified by a single
935	   cryptographic hash that is the root hash in a Merkle hash tree
936	   calculated recursively from the content [ABMRKL].  This self-
937	   certifying hash tree allows every peer to directly detect when a
938	   malicious peer tries to distribute fake content.  It also ensures
939	   only a small the amount of information is needed to start a download
940	   (the root hash and some peer addresses).  For live streaming a
941	   dynamic tree and a public key are used, see below.

943	   The Merkle hash tree of a content asset that is divided into N chunks
944	   is constructed as follows.  Note the construction does not assume
945	   chunks of content to be fixed size.  Given a cryptographic hash
946	   function, more specifically a modification detection code (MDC)
947	   [HAC01] , such as SHA1, the hashes of all the chunks of the content
948	   are calculated.  Next, a binary tree of sufficient height is created.
949	   Sufficient height means that the lowest level in the tree has enough
950	   nodes to hold all chunk hashes in the set, as with bin numbering.
951	   The figure below shows the tree for a content asset consisting of 7
952	   chunks.  As before with the content addressing scheme, the leaves of
953	   the tree correspond to a chunk and in this case are assigned the hash
954	   of that chunk, starting at the left-most leaf.  As the base of the
955	   tree may be wider than the number of chunks, any remaining leaves in
956	   the tree are assigned an empty hash value of all zeros.  Finally, the
957	   hash values of the higher levels in the tree are calculated, by
958	   concatenating the hash values of the two children (again left to
959	   right) and computing the hash of that aggregate.  If the two children
960	   are empty hashes, the parent is an empty all zeros hash as well (to
961	   save computation).  This process ends in a hash value for the root
962	   node, which is called the "root hash".  Note the root hash only
963	   depends on the content and any modification of the content will
964	   result in a different root hash.

966	                               7 = root hash
967	                              / \
968	                            /     \
969	                          /         \
970	                        /             \
971	                      3*               11
972	                     / \              / \
973	                    /   \            /   \
974	                   /     \          /     \
975	                  1       5        9       13* = uncle hash
976	                 / \     / \      / \      / \
977	                0   2   4   6    8   10* 12   14

979	                C0  C1  C2  C3   C4  C5  C6   E
980	                =chunk index     ^^           = empty hash

982	             The Merkle hash tree of an interval of width W=8

984	                                 Figure 3

986	5.2.  Content Integrity Verification

988	   Assuming a peer receives the root hash of the content it wants to
989	   download from a trusted source, it can check the integrity of any
990	   chunk of that content it receives as follows.  It first calculates
991	   the hash of the chunk it received, for example chunk C4 in the
992	   previous figure.  Along with this chunk it MUST receive the hashes
993	   required to check the integrity of that chunk.  In principle, these
994	   are the hash of the chunk's sibling (C5) and that of its "uncles".  A
995	   chunk's uncles are the sibling Y of its parent X, and the uncle of
996	   that Y, recursively until the root is reached.  For chunk C4 its
997	   uncles are nodes 13 and 3, marked with * in the figure.  Using this
998	   information the peer recalculates the root hash of the tree, and
999	   compares it to the root hash it received from the trusted source.  If
1000	   they match the chunk of content has been positively verified to be
1001	   the requested part of the content.  Otherwise, the sending peer
1002	   either sent the wrong content or the wrong sibling or uncle hashes.
1003	   For simplicity, the set of sibling and uncles hashes is collectively
1004	   referred to as the "uncle hashes".

1006	   In the case of live streaming the tree of chunks grows dynamically
1007	   and the root hash is undefined or, more precisely, transient, as long
1008	   as new data is generated by the live source.  Section 6.1.2 defines a
1009	   method for content integrity verification for live streams that works
1010	   with such a dynamic tree.  Although the tree is dynamic, content
1011	   verification works the same for both live and predefined content,
1012	   resulting in a unified method for both types of streaming.

1014	5.3.  The Atomic Datagram Principle

1016	   As explained above, a datagram consists of a sequence of messages.
1017	   Ideally, every datagram sent must be independent of other datagrams,
1018	   so each datagram SHOULD be processed separately and a loss of one
1019	   datagram must not disrupt the flow of datagrams between two peers.
1020	   Thus, as a datagram carries zero or more messages, neither messages
1021	   nor message interdependencies SHOULD span over multiple datagrams.

1023	   This principle implies that as any chunk is verified using its uncle
1024	   hashes the necessary hashes SHOULD be put into the same datagram as
1025	   the chunk's data.  If this is not possible because of a limitation on
1026	   datagram size, the necessary hashes MUST be sent first in one or more
1027	   datagrams.  As a general rule, if some additional data is still
1028	   missing to process a message within a datagram, the message SHOULD be
1029	   dropped.

1031	   The hashes necessary to verify a chunk are in principle its sibling's
1032	   hash and all its uncle hashes, but the set of hashes to send can be
1033	   optimized.  Before sending a packet of data to the receiver, the
1034	   sender inspects the receiver's previous acknowledgments (HAVE or ACK)
1035	   to derive which hashes the receiver already has for sure.  Suppose,
1036	   the receiver had acknowledged chunks C0 and C1 (first two chunks of
1037	   the file), then it must already have uncle hashes 5, 11 and so on.
1038	   That is because those hashes are necessary to check C0 and C1 against
1039	   the root hash.  Then, hashes 3, 7 and so on must be also known as
1040	   they are calculated in the process of checking the uncle hash chain.
1041	   Hence, to send chunk C7, the sender needs to include just the hashes
1042	   for nodes 14 and 9, which let the data be checked against hash 11
1043	   which is already known to the receiver.

1045	   The sender MAY optimistically skip hashes which were sent out in
1046	   previous, still unacknowledged datagrams.  It is an optimization
1047	   trade-off between redundant hash transmission and possibility of
1048	   collateral data loss in the case some necessary hashes were lost in
1049	   the network so some delivered data cannot be verified and thus has to
1050	   be dropped.  In either case, the receiver builds the Merkle tree on-
1051	   demand, incrementally, starting from the root hash, and uses it for
1052	   data validation.

1054	   In short, the sender MUST put into the datagram the missing hashes
1055	   necessary for the receiver to verify the chunk.  The receiver MUST
1056	   remember all the hashes it needs to verify missing chunks that it
1057	   still wants to download.  Note that the latter implies that a
1058	   hardware-limited receiver MAY forget some hashes if it does not plan
1059	   to announce possession of these chunks to others (i.e., does not plan
1060	   to send HAVE messages.)

1062	5.4.  INTEGRITY Messages

1064	   Concretely, a peer that wants to send a chunk of content creates a
1065	   datagram that MUST consist of a list of INTEGRITY messages followed
1066	   by a DATA message.  If the INTEGRITY messages and DATA message cannot
1067	   be put into a single datagram because of a limitation on datagram
1068	   size, the INTEGRITY messages MUST be sent first in one or more
1069	   datagrams.  The list of INTEGRITY messages sent MUST contain a
1070	   INTEGRITY message for each hash the receiver misses for integrity
1071	   checking.  A INTEGRITY message for a hash MUST contain the chunk
1072	   specification corresponding to the node ID of the hash and the hash
1073	   data itself.  The chunk specification corresponding to a node ID is
1074	   defined as the range of chunks formed by the leaves of the subtree
1075	   rooted at the node.  For example, node 3 in Figure 3 denotes chunks
1076	   0,2,4,6, so the chunk specification should denote that interval.  The
1077	   list of INTEGRITY messages MUST be sorted in order of the tree height
1078	   of the nodes, descending.  The DATA message MUST contain the chunk
1079	   specification of the chunk and chunk itself.  A peer MAY send the
1080	   required messages for multiple chunks in the same datagram, depending
1081	   on the encapsulation.

1083	5.5.  Discussion and Overhead

1085	   The current method for protecting content integrity in BitTorrent
1086	   [BITTORRENT] is not suited for streaming.  It involves providing
1087	   clients with the hashes of the content's chunks before the download
1088	   commences by means of metadata files (called .torrent files in
1089	   BitTorrent.)  However, when chunks are small as in the current UDP
1090	   encapsulation of PPSPP this implies having to download a large number
1091	   of hashes before content download can begin.  This, in turn,
1092	   increases time-till-playback for end users, making this method
1093	   unsuited for streaming.

1095	   The overhead of using Merkle hash trees is limited.  The size of the
1096	   hash tree expressed as the total number of nodes depends on the
1097	   number of chunks the content is divided (and hence the size of
1098	   chunks) following this formula:

1100	       nnodes = math.pow(2,math.log(nchunks,2)+1)

1102	   In principle, the hash values of all these nodes will have to be sent
1103	   to a peer once for it to verify all chunks.  Hence the maximum on-
1104	   the-wire overhead is hashsize * nnodes.  However, the actual number
1105	   of hashes transmitted can be optimized as described in Section 5.3.
1106	   To see a peer can verify all chunks whilst receiving not all hashes,
1107	   consider the example tree in Section 5.1.

1109	   In case of a simple progressive download, of chunks 0,2,4,6, etc. the
1110	   sending peer will send the following hashes:

1112	          +-------+---------------------------------------------+
1113	          | Chunk | Node IDs of hashes sent                     |
1114	          +-------+---------------------------------------------+
1115	          |   0   | 2,5,11                                      |
1116	          |   2   | - (receiver already knows all)              |
1117	          |   4   | 6                                           |
1118	          |   6   | -                                           |
1119	          |   8   | 10,13 (hash 3 can be calculated from 0,2,5) |
1120	          |   10  | -                                           |
1121	          |   12  | 14                                          |
1122	          |   14  | -                                           |
1123	          | Total | # hashes 7                                  |
1124	          +-------+---------------------------------------------+

1126	                  Table 1: Overhead for the example tree

1128	   So the number of hashes sent in total (7) is less than the total
1129	   number of hashes in the tree (16), as a peer does not need to send
1130	   hashes that are calculated and verified as part of earlier chunks.

1132	5.6.  Automatic Detection of Content Size

1134	   In PPSPP, the root hash of a static content asset, such as a video
1135	   file, along with some peer addresses is sufficient to start a
1136	   download.  In addition, PPSPP can reliably and automatically derive
1137	   the size of such content from information received from the network
1138	   when fixed sized chunks are used.  As a result, it is not necessary
1139	   to include the size of the content asset as the metadata of the
1140	   content, in addition to the root hash.  Implementations of PPSPP MAY
1141	   use this automatic detection feature.  Note this feature is the only
1142	   feature of PPSPP that requires that a fixed-sized chunk is used.

1144	5.6.1.  Peak Hashes

1146	   The ability for a newcomer peer to detect the size of the content
1147	   depends heavily on the concept of peak hashes.  Peak hashes, in
1148	   general, enable two cornerstone features of PPSPP: reliable file size
1149	   detection and download/live streaming unification (see Section 6).
1150	   The concept of peak hashes depends on the concepts of filled and
1151	   incomplete nodes.  Recall that when constructing the binary trees for
1152	   content verification and addressing the base of the tree may have
1153	   more leaves than the number of chunks in the content.  In the Merkle
1154	   hash tree these leaves were assigned empty all-zero hashes to be able
1155	   to calculate the higher level hashes.  A filled node is now defined
1156	   as a node that corresponds to an interval of leaves that consists
1157	   only of hashes of content chunks, not empty hashes.  Reversely, an
1158	   incomplete (not filled) node corresponds to an interval that contains
1159	   also empty hashes, typically an interval that extends past the end of
1160	   the file.  In the following figure nodes 7, 11, 13 and 14 are
1161	   incomplete the rest is filled.

1163	   Formally, a peak hash is the hash of a filled node in the Merkle
1164	   tree, whose sibling is an incomplete node.  Practically, suppose a
1165	   file is 7162 bytes long and a chunk is 1 kilobyte.  That file fits
1166	   into 7 chunks, the tail chunk being 1018 bytes long.  The Merkle tree
1167	   for that file is shown in Figure 4.  Following the definition the
1168	   peak hashes of this file are in nodes 3, 9 and 12, denoted with a *.
1169	   E denotes an empty hash.

1171	                                  7
1172	                                 / \
1173	                               /     \
1174	                             /         \
1175	                           /             \
1176	                         3*               11
1177	                        / \              / \
1178	                       /   \            /   \
1179	                      /     \          /     \
1180	                     1       5        9*      13
1181	                    / \     / \      / \      / \
1182	                   0   2   4   6    8   10  12*  14

1184	                   C0  C1  C2  C3   C4  C5  C6   E
1185	                                            = 1018 bytes

1187	                    Peak hashes in a Merkle hash tree.

1189	                                 Figure 4

1191	   Peak hashes can be explained by the binary representation of the
1192	   number of chunks the file occupies.  The binary representation for 7
1193	   is 111.  Every "1" in binary representation of the file's packet
1194	   length corresponds to a peak hash.  For this particular file there
1195	   are indeed three peaks, nodes 3, 9, 12.  The number of peak hashes
1196	   for a file is therefore also at most logarithmic with its size.

1198	   A peer knowing which nodes contain the peak hashes for the file can
1199	   therefore calculate the number of chunks it consists of, and thus get
1200	   an estimate of the file size (given all chunks but the last are fixed
1201	   size).  Which nodes are the peaks can be securely communicated from
1202	   one (untrusted) peer A to another B by letting A send the peak hashes
1203	   and their node IDs to B. It can be shown that the root hash that B
1204	   obtained from a trusted source is sufficient to verify that these are
1205	   indeed the right peak hashes, as follows.

1207	   Lemma: Peak hashes can be checked against the root hash.

1209	   Proof: (a) Any peak hash is always the left sibling.  Otherwise, be
1210	   it the right sibling, its left neighbor/sibling must also be a filled
1211	   node, because of the way chunks are laid out in the leaves,
1212	   contradiction. (b) For the rightmost peak hash, its right sibling is
1213	   zero. (c) For any peak hash, its right sibling might be calculated
1214	   using peak hashes to the left and zeros for empty nodes. (d) Once the
1215	   right sibling of the leftmost peak hash is calculated, its parent
1216	   might be calculated. (e) Once that parent is calculated, we might
1217	   trivially get to the root hash by concatenating the hash with zeros
1218	   and hashing it repeatedly.

1220	   Informally, the Lemma might be expressed as follows: peak hashes
1221	   cover all data, so the remaining hashes are either trivial (zeros) or
1222	   might be calculated from peak hashes and zero hashes.

1224	   Finally, once peer B has obtained the number of chunks in the content
1225	   it can determine the exact file size as follows.  Given that all
1226	   chunks except the last are fixed size B just needs to know the size
1227	   of the last chunk.  Knowing the number of chunks B can calculate the
1228	   node ID of the last chunk and download it.  As always B verifies the
1229	   integrity of this chunk against the trusted root hash.  As there is
1230	   only one chunk of data that leads to a successful verification the
1231	   size of this chunk must be correct.  B can then determine the exact
1232	   file size as

1234	       (number of chunks -1) * fixed chunk size + size of last chunk

1236	5.6.2.  Procedure

1238	   A PPSPP implementation that wants to use automatic size detection
1239	   MUST operate as follows.  When a peer A sends a DATA message for the
1240	   first time to a peer B, A MUST first send all the peak hashes for the
1241	   content, unless B has already signalled earlier in the exchange that
1242	   it knows the peak hashes by having acknowledged any chunk.  If they
1243	   are needed, the peak hashes MUST be sent as an extra list of uncle
1244	   hashes for the chunk, before the list of actual uncle hashes of the
1245	   chunk as described in Section 5.3.  The receiver B MUST check the
1246	   peak hashes against the root hash to determine the approximate
1247	   content size.  To obtain the definite content size peer B MUST
1248	   download the last chunk of the content from any peer that offers it.

1250	   As an example, let's consider a 7162 bytes long file, which fits in 7
1251	   chunks of 1 kilobyte, distributed by a peer A. Figure 4 shows the
1252	   relevant Merkle hash tree.  A peer B which only knows the root hash
1253	   of the file, after successfully connecting to A, requests the first
1254	   chunk of data, C0 in Figure 4.  Peer A replies to B by including in
1255	   the datagram the following messages in this specific order.  First
1256	   the three peak hashes of this particular file, the hashes of nodes 3,
1257	   9 and 12.  Second, the uncle hashes of C0, followed by the DATA
1258	   message containing the actual content of C0.  Upon receiving the peak
1259	   hashes, peer B checks them against the root hash determining that the
1260	   file is 7 chunks long.  To establish the exact size of the file, peer
1261	   B needs to request and retrieve the last chunk containing data, C6 in
1262	   Figure 4.  Once the last chunk has been retrieved and verified, peer
1263	   B concludes that it is 1018 bytes long, hence determining that the
1264	   file is exactly 7162 bytes long.

1266	6.  Live Streaming

1268	   The set of messages defined above can be used for live streaming as
1269	   well.  In a pull-based model, a live streaming injector can announce
1270	   the chunks it generates via HAVE messages, and peers can retrieve
1271	   them via REQUEST messages.  Areas that need special attention are
1272	   content authentication and chunk addressing (to achieve an infinite
1273	   stream of chunks).

1275	6.1.  Content Authentication

1277	   For live streaming, PPSPP supports two methods for a peer to
1278	   authenticate the content it receives from another peer, called "Sign
1279	   All" and "Unified Merkle Tree".

1281	   In the "Sign All" method, the live injector signs each chunk of
1282	   content using a private key and peers, upon receiving the chunk,
1283	   check the signature using the corresponding public key obtained from
1284	   a trusted source.  Support for this method is OPTIONAL.

1286	   In the "Unified Merkle Tree" method, PPSPP combines the Merkle Hash
1287	   Tree scheme for static content with signatures to unify the video-on-
1288	   demand and live streaming scenarios.  The use of Merkle hash trees
1289	   reduces the number of signing and verification operations, hence
1290	   providing a similar signature amortization to the approach described
1291	   in [SIGMCAST].  If PPSPP operates over the Internet, the "Unified
1292	   Merkle Tree" method MUST be used.  If the protocol operates in a
1293	   benign environment the method MAY be used.  So this method is
1294	   mandatory-to-implement.

1296	   In both methods the swarm ID consists of a public key encoded as in a
1297	   DNSSEC DNSKEY resource record without BASE-64 encoding [RFC4034].  In
1298	   particular, the swarm ID consists of a 1 byte Algorithm field that
1299	   identifies the public key's cryptographic algorithm and determines
1300	   the format of the Public Key field that follows.  The value of this
1301	   Algorithm field is one of the Domain Name System Security (DNSSEC)
1302	   Algorithm Numbers [IANADNSSECALGNUM].  The RSASHA1 [RFC4034],
1303	   ECDSAP256SHA256 and ECDSAP384SHA384 [RFC6605] algorithms are
1304	   MANDATORY to implement.

1306	    0                   1                   2                   3
1307	    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
1308	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1309	   | Algo Number(8)|                                               ~
1310	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1311	   ~                DNSSEC Public Key (variable)                   ~
1312	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1314	6.1.1.  Sign All

1316	   In the "Sign All" method, the live injector signs each chunk of
1317	   content using a private key and peers, upon receiving the chunk,
1318	   check the signature using the corresponding public key obtained from
1319	   a trusted source.  In particular, in PPSPP, the swarm ID of the live
1320	   stream is that public key.

1322	   A peer that wants to send a chunk of content creates a datagram that
1323	   MUST contain a SIGNED_INTEGRITY message with the chunk's signature,
1324	   followed by a DATA message with the actual chunk.  If the
1325	   SIGNED_INTEGRITY message and DATA message cannot be contained into a
1326	   single datagram, because of a limitation on datagram size, the
1327	   SIGNED_INTEGRITY message MUST be sent first in a separate datagram.
1328	   The SIGNED_INTEGRITY message consists of the chunk specification, the
1329	   timestamp, and the digital signature.

1331	   The digital signature algorithm which is used, is determined by the
1332	   Live Signature Algorithm protocol option, see Section 7.7.  The
1333	   signature is computed over a concatenation of the on-the-wire
1334	   representation of the chunk specification, a 64-bit NTP timestamp
1335	   [RFC5905], and the chunk, in that order.  The timestamp is the time
1336	   signature that was made at the injector in UTC.

1338	6.1.2.  Unified Merkle Tree

1340	   In this method, the chunks of content are used as the basis for a
1341	   Merkle hash tree as for static content.  However, because chunks are
1342	   continuously generated, this tree is not static, but dynamic.  As a
1343	   result, the tree does not have a root hash, or more precisely has a
1344	   transient root hash.  A public key therefore serves as swarm ID of
1345	   the content.  It is used to digitally sign updates to the tree,
1346	   allowing peers to expand it based on trusted information using the
1347	   following process.

1349	6.1.2.1.  Signed Munro Hashes

1351	   The live injector generates a number of chunks, denoted
1352	   NCHUNKS_PER_SIG, corresponding to fixed power of 2
1353	   (NCHUNKS_PER_SIG>=2), which are added as new leaves to the existing
1354	   hash tree.  As a result of this expansion the hash tree contains a
1355	   new subtree, that is NCHUNKS_PER_SIG chunks wide at the base.  The
1356	   root of this new subtree is referred to as the munro of that subtree,
1357	   and its hash as the munro hash of the subtree, illustrated in
1358	   Figure 5.  In this figure, node 5 is the new munro, labeled with a $
1359	   sign.

1361	                                     3
1362	                                    / \
1363	                                   /   \
1364	                                  /     \
1365	                                 1       5$
1366	                                / \     / \
1367	                               0   2   4   6

1369	   Expanded live tree.  With NCHUNKS_PER_SIG=2, node 5 is the munro for
1370	      the new subtree spanning 4 and 6.  Node 1 is the munro for the
1371	    subtree spanning chunks 0 and 2, created in the previous iteration.

1373	                                 Figure 5

1375	   Informally, the process now proceeds as follows.  The injector now
1376	   signs only the munro hash of the new subtree using its private key.

1378	   Next, the injector announces the existence of the new subtree to its
1379	   peers using HAVE messages.  When a peer, in response to the HAVE
1380	   messages, requests a chunk from the new subtree, the injector first
1381	   sends the signed munro hash corresponding to the requested chunk.
1382	   Afterwards, similar to static content, the injector sends the uncle
1383	   hashes necessary to verify that chunk, as in Section 5.1.  In
1384	   particular, the injector sends the uncle hashes necessary to verify
1385	   the requested chunk against the munro hash.  This differs from static
1386	   content, where the verification takes places against the root hash.
1387	   Finally, the injector sends the actual chunk.

1389	   The receiving peer verifies the signature on the signed munro using
1390	   the swarm ID (a public key), and updates its hash tree.  As the peer
1391	   now knows the munro hash is trusted, it can verify all chunks in the
1392	   subtree against this munro hash, using the accompanying uncle hashes
1393	   as in Section 5.1.

1395	   To illustrate this procedure, lets consider the next iteration in the
1396	   process.  The injector has generated the current tree shown in
1397	   Figure 5 and it is connected to several peers that currently have the
1398	   same tree and all posses chunks 0, 2, 4 and 6.  When the injector
1399	   generates two new chunks, NCHUNKS_PER_SIG=2, the hash tree expands as
1400	   shown in Figure 6.  The two new chunks, 8 and 10, extend the tree on
1401	   the right side, and to accommodate them a new root is created, node
1402	   7.  As this tree is wider at the base than the actual number of
1403	   chunks, there are currently two empty leaves.  The munro node for the
1404	   new subtree is 9, labeled with a $ sign.

1406	                                     7
1407	                                    / \
1408	                                  /     \
1409	                                /         \
1410	                              /             \
1411	                            3               11
1412	                           / \              / \
1413	                          /   \            /   \
1414	                         /     \          /     \
1415	                        1       5        9$      13
1416	                       / \     / \      / \      / \
1417	                      0   2   4   6    8   10   E   E

1419	    Expanded live tree.  With NCHUNKS_PER_SIG=2, node 9 is the munro of
1420	             the newly added subtree spanning chunks 8 and 10.

1422	                                 Figure 6

1424	   The injector now needs to inform its peers of the updated tree,
1425	   communicating the addition of the new munro hash 9.  Hence, it sends
1426	   a HAVE message with a chunk specification for nodes 8+10 to its
1427	   peers.  As a response, a peer P requests the newly created chunk,
1428	   e.g. chunk 8, from the injector by sending a REQUEST message.  In
1429	   reply, the injector sends the signed munro hash of node 9 as an
1430	   INTEGRITY message with the hash of node 9, and a SIGNED_INTEGRITY
1431	   message with the signature of the hash of node 9.  These messages are
1432	   followed by an INTEGRITY message with the hash of node 10, and a DATA
1433	   message with chunk 8.

1435	   Upon receipt, peer P verifies the signature of the munro and expands
1436	   its view of the tree.  Next, the peer computes the hash of chunk 8
1437	   and combines it with the received hash of node 10, computing the
1438	   expected hash of node 9.  He can then verify the content of chunk 8
1439	   by computing the computed hash of node 9 with the munro hash of the
1440	   same node he just received, hence P has successfully verified the
1441	   integrity of chunk 8.

1443	   This procedure requires just one signing operation for every
1444	   NCHUNKS_PER_SIG chunks created, and one verification operation for
1445	   every NCHUNKS_PER_SIG received, making it much cheaper than "Sign
1446	   All".  A receiving peer does additionally need to check one or more
1447	   hashes per chunk via the Merkle Tree scheme, but this has less
1448	   hardware requirements than a signature verification for every chunk.
1449	   This approach is similar to signature amortization via Merkle Tree
1450	   Chaining [SIGMCAST].  The downside of scheme is in an increased
1451	   latency.  A peer cannot download the new chunks until the injector
1452	   has computed the signature and announced the subtree.  A peer MUST
1453	   check the signature before forwarding the chunks to other peers
1454	   [POLLIVE].

1456	   The number of chunks per signature NCHUNKS_PER_SIG MUST be a fixed
1457	   power of 2 for simplicity.  NCHUNKS_PER_SIG MUST be larger than 1 for
1458	   performance reasons.  There are two related factors to consider when
1459	   choosing a value for NCHUNKS_PER_SIG.  First, the allowed CPU load on
1460	   clients due to signature verifications, given the expected bitrate of
1461	   the stream.  To achieve a low CPU load in a high bitrate stream,
1462	   NCHUNKS_PER_SIG should be high.  Second, the effect on latency, which
1463	   increases when NCHUNKS_PER_SIG gets higher, as just discussed.  Note
1464	   how the procedure does not preclude the use of variable-sized chunks.

1466	   This method of integrity verification provides an additional benefit.
1467	   If the system includes some peers that saved the complete broadcast,
1468	   as soon as the broadcast ends, the content is available as a video-
1469	   on-demand download using the now stabilized tree and the final root
1470	   hash as swarm identifier.  Peers which saved all the chunks, can now
1471	   announce the root hash to the tracking infrastructure and instantly
1472	   seed the content.

1474	6.1.2.2.  Munro Signature Calculation

1476	   The digital signature algorithm used is determined by the Live
1477	   Signature Algorithm protocol option, see Section 7.7.  The signature
1478	   is computed over a concatenation of the on-the-wire representation of
1479	   the chunk specification of the munro, a 64-bit NTP timestamp
1480	   [RFC5905], and the munro hash, in that order.  The timestamp is the
1481	   time signature that was made at the injector in UTC.

1483	6.1.2.3.  Procedure

1485	   Formally, the injector MUST NOT send a HAVE message for chunks in the
1486	   new subtree until it has computed the signed munro hash for that
1487	   subtree.

1489	   When peer B requests a chunk C from peer A (either the injector or
1490	   another peer), and peer A decides to reply, it must do so as follows.
1491	   First, peer A MUST send an INTEGRITY message with the chunk
1492	   specification for the munro of chunk C and the munro's hash, followed
1493	   by a SIGNED_INTEGRITY message with the chunk specification for the
1494	   munro, timestamp and its signature, in a single datagram, unless B
1495	   indicated earlier in the exchange that it already possess a chunk
1496	   with the same corresponding munro (by means of HAVE or ACK messages).
1497	   Following these two messages (if any), peer A MUST send the necessary
1498	   missing uncles hashes needed for verifying the chunk against its
1499	   munro hash, and the chunk itself, as described in Section 5.4,
1500	   sharing datagrams if possible.

1502	6.1.2.4.  Secure Tune In

1504	   When a peer tunes into a live stream it has to determine what is the
1505	   last chunk the injector has generated.  To facilitate this process in
1506	   the Unified Merkle Tree scheme, each peer shares its knowledge about
1507	   the injector's chunks with the others by exchanging their latest
1508	   signed munro hashes, as follows.

1510	   Recall that in PPSPP, when peer A initiates a channel with peer B,
1511	   peer A sends a first datagram with a HANDSHAKE message, and B
1512	   responds with a second datagram also containing a HANDSHAKE message
1513	   (see Section 3.1).  When A sends a third datagram to B, and it is
1514	   received by B both peers know that the other is listening on its
1515	   stated transport address.  B is then allowed to send heavy payload
1516	   like DATA messages in the fourth datagram.  Peer A can already safely
1517	   do that in the third datagram.

1519	   In the Unified Merkle Tree scheme, peer A MUST send its right-most
1520	   signed munro hash to B in the third datagram, and in any subsequent
1521	   datagrams to B, until B indicates that it possess a chunk with the
1522	   same corresponding munro or a more recent munro (by means of a HAVE
1523	   or ACK message).  B may already have indicated this fact by means of
1524	   HAVE messages in the second datagram.  Conversely, when B sends the
1525	   fourth datagram or any subsequent datagram to A, B MUST send its
1526	   right-most signed munro hash, unless A indicated knowledge of it or
1527	   more recent munros.  The right-most signed munro hash of a peer is
1528	   defined as the munro hash signed by the injector of the right-most
1529	   subtree of width NCHUNKS_PER_SIG chunks in the peer's Merkle hash
1530	   tree.  Peer A and B MUST NOT send the signed munro hash in the first,
1531	   respectively, second datagram as it is considered heavy payload.

1533	   When a peer receives a SIGNED_INTEGRITY message with a signed munro
1534	   hash but the timestamp is too old, the peer MUST discard the message.
1535	   Otherwise it SHOULD use the signed munro to update its hash tree and
1536	   pick a tune-in point in the live stream.  A peer may use the
1537	   information from multiple peers to pick the tune-in point.

1539	6.2.  Forgetting Chunks

1541	   As a live broadcast progresses a peer may want to discard the chunks
1542	   that it already played out.  Ideally, other peers should be aware of
1543	   this fact such that they will not try to request these chunks from
1544	   this peer.  This could happen in scenarios where live streams may be
1545	   paused by viewers, or viewers are allowed to start late in a live
1546	   broadcast (e.g., start watching a broadcast at 20:35 whereas it began
1547	   at 20:30).

1549	   PPSPP provides a simple solution for peers to stay up-to-date with
1550	   the chunk availability of a discarding peer.  A discarding peer in a
1551	   live stream MUST enable the Live Discard Window protocol option,
1552	   specifying how many chunks/bytes it caches before the last chunk/byte
1553	   it advertised as being available (see Section 7.9).  Its peers SHOULD
1554	   apply this number as a sliding window filter over the peer's chunk
1555	   availability as conveyed via its HAVE messages.

1557	   Three factors are important when deciding for an appropriate value
1558	   for this option: the desired amount of playback buffer for peers, the
1559	   bitrate of the stream and the available resources of the peer.
1560	   Consider the case of a fresh peer joining the stream.  The size of
1561	   the discard window of the peers it connects to influences how much
1562	   data it can directly download to establish its prebuffer.  If the
1563	   window is smaller than the desired buffer, the fresh peer has to wait
1564	   until the peers downloaded more of the stream before it can start
1565	   playback.  As media buffers are generally specified in terms of a
1566	   number of seconds, the size of the discard window also related to the
1567	   (average) bitrate of the stream.  Finally, if a peer has little
1568	   resources to store chunks and metadata it should chose a small
1569	   discard window.

1571	7.  Protocol Options

1573	   The HANDSHAKE message in PPSPP can contain the following protocol
1574	   options.  Unless stated otherwise, a protocol option consists of an
1575	   8-bit code followed by an 8-bit value.  Larger values are all encoded
1576	   big-endian.  Each protocol option is explained in the following
1577	   subsections.

1579	              +-------+-------------------------------------+
1580	              | Code  | Description                         |
1581	              +-------+-------------------------------------+
1582	              | 0     | Version                             |
1583	              | 1     | Minimum Version                     |
1584	              | 2     | Swarm Identifier                    |
1585	              | 3     | Content Integrity Protection Method |
1586	              | 4     | Merkle Hash Tree Function           |
1587	              | 5     | Live Signature Algorithm            |
1588	              | 6     | Chunk Addressing Method             |
1589	              | 7     | Live Discard Window                 |
1590	              | 8     | Supported Messages                  |
1591	              | 9-254 | Unassigned                          |
1592	              | 255   | End Option                          |
1593	              +-------+-------------------------------------+

1595	                    Table 2: PPSP Peer Protocol Options

1597	7.1.  End Option

1599	   A peer MUST conclude the list of protocol options with the end
1600	   option.  Subsequent octets should be considered protocol messages.
1601	   The code for the end option is 255, and unlike others it has no value
1602	   octet, so the option's length is 1 octet.

1604	    0 1 2 3 4 5 6 7
1605	   +-+-+-+-+-+-+-+-+
1606	   |1 1 1 1 1 1 1 1|
1607	   +-+-+-+-+-+-+-+-+

1609	7.2.  Version

1611	   A peer MUST include the maximum version of the PPSPP protocol it
1612	   supports as the first protocol option in the list.  The code for this
1613	   option is 0.  Defined values are listed in Table 3.

1615	           +---------+----------------------------------------+
1616	           | Version | Description                            |
1617	           +---------+----------------------------------------+
1618	           | 1       | Protocol as described in this document |
1619	           | 2-255   | Unassigned                             |
1620	           +---------+----------------------------------------+

1622	                Table 3: PPSP Peer Protocol Version Numbers

1624	    0                   1
1625	    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1626	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1627	   |0 0 0 0 0 0 0 0|  Version (8)  |
1628	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1630	7.3.  Minimum Version

1632	   When a peer initiates the handshake it MUST include the minimum
1633	   version of the PPSPP protocol it supports in the list of protocol
1634	   options, following the Min/max versioning scheme defined in
1635	   [RFC6709], Section 4.1, strategy 5.  The code for this option is 1.
1636	   Defined values are listed in Table 3.

1638	    0                   1
1639	    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1640	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1641	   |0 0 0 0 0 0 0 1| Min. Ver. (8) |
1642	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1644	7.4.  Swarm Identifier

1646	   When a peer initiates the handshake it MUST include a single swarm
1647	   identifier option.  In other cases a peer MAY include a swarm
1648	   identifier option, as an end-to-end check.  This option has the
1649	   following structure:

1651	    0                   1                   2                   3
1652	    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
1653	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1654	   |0 0 0 0 0 0 1 0|     Swarm ID Length (16)      |               ~
1655	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1656	   ~                       Swarm Identifier (variable)             ~
1657	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1659	   The Swarm ID Length field contains the length of the single Swarm
1660	   Identifier that follows in bytes.  The Length field is 16 bits wide
1661	   to allow for large public keys as identifiers in live streaming.

1663	   Each PPSPP peer knows the IDs of the swarms it joins so this
1664	   information can be immediately verified upon receipt.

1666	7.5.  Content Integrity Protection Method

1668	   A peer MUST include the content integrity method used by a swarm.
1669	   The code for this option is 3.  Defined values are listed in Table 4.

1671	                   +--------+-------------------------+
1672	                   | Method | Description             |
1673	                   +--------+-------------------------+
1674	                   | 0      | No integrity protection |
1675	                   | 1      | Merkle Hash Tree        |
1676	                   | 2      | Sign All                |
1677	                   | 3      | Unified Merkle Tree     |
1678	                   | 4-255  | Unassigned              |
1679	                   +--------+-------------------------+

1681	          Table 4: PPSP Peer Content Integrity Protection Methods

1683	   The "Merkle Hash Tree" method is the default for static content, see
1684	   Section 5.1.  "Sign All", and "Unified Merkle Tree" are for live
1685	   content, see Section 6.1, with "Unified Merkle Tree" being the
1686	   default.

1688	    0                   1
1689	    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1690	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1691	   |0 0 0 0 0 0 1 1|   CIPM (8)    |
1692	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1694	7.6.  Merkle Tree Hash Function

1696	   When the content integrity protection method is "Merkle Hash Tree"
1697	   this option defining which hash function is used for the tree MUST be
1698	   included.  The code for this option is 4.  Defined values are listed
1699	   in Table 5 (see [FIPS180-4] for the function semantics).

1701	                        +----------+-------------+
1702	                        | Function | Description |
1703	                        +----------+-------------+
1704	                        | 0        | SHA1        |
1705	                        | 1        | SHA-224     |
1706	                        | 2        | SHA-256     |
1707	                        | 3        | SHA-384     |
1708	                        | 4        | SHA-512     |
1709	                        | 5-255    | Unassigned  |
1710	                        +----------+-------------+

1712	             Table 5: PPSP Peer Protocol Merkle Hash Functions

1714	   Implementations MUST support SHA1, see Section 13.5, which is also
1715	   the default.

1717	    0                   1
1718	    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1719	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1720	   |0 0 0 0 0 1 0 0|    MHF (8)    |
1721	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1723	7.7.  Live Signature Algorithm

1725	   When the content integrity protection method is "Sign All" or
1726	   "Unified Merkle Tree" this option MUST be defined.  The code for this
1727	   option is 5.  The 8-bit value of this option is one of the Domain
1728	   Name System Security (DNSSEC) Algorithm Numbers [IANADNSSECALGNUM].
1729	   The RSASHA1 [RFC4034], ECDSAP256SHA256 and ECDSAP384SHA384 [RFC6605]
1730	   algorithms are MANDATORY to implement.  Default is ECDSAP256SHA256.

1732	    0                   1
1733	    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1734	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1735	   |0 0 0 0 0 1 0 1|    LSA (8)    |
1736	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1738	7.8.  Chunk Addressing Method

1740	   A peer MUST include the chunk addressing method it uses.  The code
1741	   for this option is 6.  Defined values are listed in Table 6.

1743	                     +--------+---------------------+
1744	                     | Method | Description         |
1745	                     +--------+---------------------+
1746	                     | 0      | 32-bit bins         |
1747	                     | 1      | 64-bit byte ranges  |
1748	                     | 2      | 32-bit chunk ranges |
1749	                     | 3      | 64-bit bins         |
1750	                     | 4      | 64-bit chunk ranges |
1751	                     | 5-255  | Unassigned          |
1752	                     +--------+---------------------+

1754	                Table 6: PPSP Peer Chunk Addressing Methods

1756	   Implementations MUST support "32-bit chunk ranges" and "64-bit chunk
1757	   ranges".  Default is "32-bit chunk ranges".

1759	    0                   1
1760	    0 1 2 3 4 5 6 7 8 9 0 1 2
1761	   +-+-+-+-+-+-+-+-+-+-+-+-+-+
1762	   |0 0 0 0 0 1 1 0| CAM (8) |
1763	   +-+-+-+-+-+-+-+-+-+-+-+-+-+

1765	7.9.  Live Discard Window

1767	   A peer in a live swarm MUST include the discard window it uses.  The
1768	   code for this option is 7.  The unit of the discard window depends on
1769	   the chunk addressing method used.  For bins and chunk ranges it is a
1770	   number of chunks, for byte ranges it is a number of bytes.  Its data
1771	   type is the same as for a bin, or one value in a range specification.
1772	   In other words, its value is a 32-bit or 64-bit integer in big endian
1773	   format.  If this option is used, the Chunk Addressing Method MUST
1774	   appear before it in the list.  This option has the following
1775	   structure:

1777	    0                   1                   2                   3
1778	    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
1779	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1780	   |0 0 0 0 0 1 1 1|       Live Discard Window (32 or 64)          ~
1781	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1782	   ~                                                               ~
1783	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1785	   A peer that does not, under normal circumstances, discard chunks MUST
1786	   set this option to the special value 0xFFFFFFFF (32-bit) or
1787	   0xFFFFFFFFFFFFFFFF (64-bit).  For example, peers that record a
1788	   complete broadcast to offer it directly as a static asset after the
1789	   broadcast ends use these values (see Section 6.1.2).  Section 6.2
1790	   explains how to determine a value for this option.

1792	7.10.  Supported Messages

1794	   Peers may support just a subset of the PPSPP messages.  For example,
1795	   peers running over TCP may not accept ACK messages, or peers used
1796	   with a centralized tracking infrastructure may not accept PEX
1797	   messages.  For these reasons, peers who support only a proper subset
1798	   of the PPSPP messages MUST signal which subset they support by means
1799	   of this protocol option.  The code for this option is 8.  The value
1800	   of this option is a length octet (SupMsgLen) indicating the length in
1801	   bytes of the compressed bitmap that follows.

1803	   The set of messages supported can be derived from the compressed
1804	   bitmap by padding it with bytes of value 0 until it is 256 bits in
1805	   length.  Then a 1 bit in the resulting bitmap at position X
1806	   (numbering left to right) corresponds to support for message type X,
1807	   see Table 7.  In other words, to construct the compressed bitmap,
1808	   create a bitmap with a 1 for each message type supported and a 0 for
1809	   a message type that is not, store it as an array of bytes and
1810	   truncate it to the last non-zero byte.

1812	    0                   1                   2                   3
1813	    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
1814	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1815	   |0 0 0 0 0 0 1 0| SupMsgLen (8) |                               ~
1816	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1817	   ~            Supported Messages Bitmap (variable, max 256)      ~
1818	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1820	8.  UDP Encapsulation

1822	   PPSPP implementations MUST use UDP as transport protocol and MUST use
1823	   LEDBAT for congestion control [RFC6817].  Using LEDBAT enables PPSPP
1824	   to serve the content after playback (seeding) without disrupting the
1825	   user who may have moved to different tasks that use its network
1826	   connection.  Future PPSPP versions can also run over other transport
1827	   protocols, or use different congestion control algorithms.

1829	8.1.  Chunk Size

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

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

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

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

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

1872	8.2.  Datagrams and Messages

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

1880	                      +----------+------------------+
1881	                      | Msg Type | Description      |
1882	                      +----------+------------------+
1883	                      | 0        | HANDSHAKE        |
1884	                      | 1        | DATA             |
1885	                      | 2        | ACK              |
1886	                      | 3        | HAVE             |
1887	                      | 4        | INTEGRITY        |
1888	                      | 5        | PEX_RESv4        |
1889	                      | 6        | PEX_REQ          |
1890	                      | 7        | SIGNED_INTEGRITY |
1891	                      | 8        | REQUEST          |
1892	                      | 9        | CANCEL           |
1893	                      | 10       | CHOKE            |
1894	                      | 11       | UNCHOKE          |
1895	                      | 12       | PEX_RESv6        |
1896	                      | 13       | PEX_REScert      |
1897	                      | 14-254   | Unassigned       |
1898	                      | 255      | Reserved         |
1899	                      +----------+------------------+

1901	                 Table 7: PPSP Peer Protocol Message Types

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

1909	   All messages are idempotent or recognizable as duplicates.
1910	   Idempotent means that processing a message more than once does not
1911	   lead to a different state from if it was processed just once.  In
1912	   particular, a peer MAY resend DATA, ACK, HAVE, INTEGRITY, PEX_*,
1913	   SIGNED_INTEGRITY, REQUEST, CANCEL, CHOKE and UNCHOKE messages without
1914	   problems when loss is suspected.  When a peer resends a HANDSHAKE
1915	   message it can be recognized as duplicate by the receiver, because it
1916	   already recorded the first connection attempt, and be dealt with.

1918	8.3.  Channels

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

1928	8.4.  HANDSHAKE

1930	   A channel is established with a handshake.  To start a handshake, the
1931	   initiating peer needs to know:

1933	   1.  the IP address of a peer

1935	   2.  peer's UDP port and

1937	   3.  the swarm's metadata record which consists of:

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

1941	       (b)  the chunk size used,

1943	       (c)  the chunk addressing method used,

1945	       (d)  the content integrity protection method used, and

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

1949	       (f)  If automatic content size detection (see Section 5.6) is not
1950	            used, the content length is also part of the metadata record
1951	            for static content.

1953	   A datagram containing a HANDSHAKE message:

1955	    0                   1                   2                   3
1956	    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
1957	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1958	   |                  Destination Channel ID (32)                  |
1959	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1960	   |0 0 0 0 0 0 0 0|            Source Channel ID (32)             |
1961	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1962	   |               |                                               ~
1963	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1964	   |                                                               |
1965	   ~                     Protocol Options                          ~
1966	   |                                                               |
1967	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1969	   where:

1971	      Destination Channel ID:

1973	         If the message is sent by the initiating peer than it MUST be
1974	         an all 0-zeros channel ID.

1976	         If the message sent by the receiving peer than it MUST consist
1977	         of the Source Channel ID from the sender's HANDSHAKE message

1979	      The octect 0x00: The HANDSHAKE message: 0x00

1981	      The Source Channel ID: A locally unused channel ID

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

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

1992	8.5.  HAVE

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

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

2004	    0                   1                   2                   3
2005	    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
2006	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2007	   |0 0 0 0 0 0 1 1|                 Start chunk (32)              |
2008	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2009	   |               |                  End chunk (32)               |
2010	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2011	   |               |
2012	   +-+-+-+-+-+-+-+-+

2014	   where the first octet is the HAVE message (0x03), followed by the
2015	   start chunk and the end chunk describing the chunk range.

2017	   (received and checked first four kilobytes of a file/stream)

2019	8.6.  DATA

2021	   A DATA message (type 0x01) consists of a chunk specification, a
2022	   timestamp and the actual chunk.  In case a datagram contains one DATA
2023	   message, a sender MUST always put the DATA message in the tail of the
2024	   datagram.  A datagram MAY contain multiple DATA messages when the
2025	   chunk size is fixed and when none of DATA messages carry the last
2026	   chunk if that is smaller than the chunk size.  As the LEDBAT
2027	   congestion control is used, a sender MUST include a timestamp, in
2028	   particular, a 64-bit integer representing the current system time
2029	   with microsecond accuracy.  The timestamp MUST be included between
2030	   chunk specification and the actual chunk.

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

2034	    0                   1                   2                   3
2035	    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
2036	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2037	   |0 0 0 0 0 0 0 1|                 Start chunk (32)              |
2038	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2039	   |               |                  End chunk (32)               |
2040	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2041	   |               |                                               |
2042	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2043	   |                       Timestamp (64)                          |
2044	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2045	   |               |                                               |
2046	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2047	   |                                                               |
2048	   ~                            Data                               ~
2049	   |                                                               |
2050	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

2056	8.7.  ACK

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

2066	   An ACK message using 32-bit chunk ranges as Chunk Addressing method:

2068	    0                   1                   2                   3
2069	    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
2070	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2071	   |0 0 0 0 0 0 1 0|                 Start chunk (32)              |
2072	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2073	   |               |                  End chunk (32)               |
2074	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2075	   |               |                                               |
2076	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2077	   |                  One-way delay sample (64)                    |
2078	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2079	   |               |
2080	   +-+-+-+-+-+-+-+-+

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

2086	8.8.  INTEGRITY

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

2092	   An INTEGRITY message using 32-bit chunk ranges as Chunk Addressing
2093	   method and SHA1 hash:

2095	    0                   1                   2                   3
2096	    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
2097	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2098	   |0 0 0 0 0 1 0 0|                 Start chunk (32)              |
2099	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2100	   |               |                  End chunk (32)               |
2101	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2102	   |               |                                               |
2103	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2104	   |                                                               |
2105	   ~                            Hash (160)                         ~
2106	   |                                                               |
2107	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2108	   |               |
2109	   +-+-+-+-+-+-+-+-+
2110	   where the first octet is the ACK message (0x02), followed by the
2111	   start chunk and the end chunk describing the chunk range, and the
2112	   one-way delay sample.

2114	8.9.  SIGNED_INTEGRITY

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

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

2127	    0                   1                   2                   3
2128	    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
2129	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2130	   |0 0 0 0 0 1 1 1|                 Start chunk (32)              |
2131	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2132	   |               |                  End chunk (32)               |
2133	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2134	   |               |                                               |
2135	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2136	   |                       Timestamp (64)                          |
2137	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2138	   |               |                                               |
2139	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2140	   |                                                               |
2141	   ~                       Signature                               ~
2142	   |                                                               |
2143	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

2149	   The length of the digital signature can be derived from the Live
2150	   Signature Algorithm protocol option and the swarm ID as follows.  The
2151	   first MANDATORY algorithm is RSASHA1.  In that case, the swarm ID
2152	   consists of a 1-byte Algorithm field followed by a RSA public key
2153	   stored as a tuple (exponent length,exponent,modulus) [RFC3110].
2154	   Given the exponent length and the length of the public key tuple in
2155	   the swarm ID, the length of the modulus in bytes can be calculated.
2156	   This yields the length of the signature as in RSA this is the length
2157	   of the modulus [HAC01].  The other MANDATORY algorithms are
2158	   ECDSAP256SHA256 and ECDSAP384SHA384 [RFC6605].  For these algorithms
2159	   the length of the digital signature is 64 and 96 bytes, respectively.

2161	8.10.  REQUEST

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

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

2169	    0                   1                   2                   3
2170	    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
2171	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2172	   |0 0 0 0 1 0 0 0|                 Start chunk (32)              |
2173	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2174	   |               |                  End chunk (32)               |
2175	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2176	   |               |
2177	   +-+-+-+-+-+-+-+-+

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

2182	8.11.  CANCEL

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

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

2190	    0                   1                   2                   3
2191	    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
2192	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2193	   |0 0 0 0 1 0 0 1|                 Start chunk (32)              |
2194	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2195	   |               |                  End chunk (32)               |
2196	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2197	   |               |
2198	   +-+-+-+-+-+-+-+-+

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

2203	8.12.  CHOKE and UNCHOKE

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

2208	   A CHOKE message:

2210	    0
2211	    0 1 2 3 4 5 6 7
2212	   +-+-+-+-+-+-+-+-+
2213	   |0 0 0 0 1 0 1 0|
2214	   +-+-+-+-+-+-+-+-+

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

2218	   An UNCHOKE message:

2220	    0
2221	    0 1 2 3 4 5 6 7
2222	   +-+-+-+-+-+-+-+-+
2223	   |0 0 0 0 1 0 1 1|
2224	   +-+-+-+-+-+-+-+-+

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

2228	8.13.  PEX_REQ, PEX_RESv4, PEX_RESv6 and PEX_REScert

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

2239	   A PEX_REQ message:

2241	    0
2242	    0 1 2 3 4 5 6 7
2243	   +-+-+-+-+-+-+-+-+
2244	   |0 0 0 0 0 1 1 0|
2245	   +-+-+-+-+-+-+-+-+

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

2249	   A PEX_RES message:

2251	    0                   1                   2                   3
2252	    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
2253	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2254	   |0 0 0 0 0 1 0 1|              IPv4 Address (32)                |
2255	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2256	   |               |             Port (16)         |
2257	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2259	   where the first octet is the PEX_RES message (0x05), followed by the
2260	   IPv4 address and the port number.

2262	   A PEX_RESv6 message:

2264	    0                   1                   2                   3
2265	    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
2266	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2267	   |0 0 0 0 1 1 0 0|                                               |
2268	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2269	   |                                                               |
2270	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2271	   |                   IPv6 Address (128)                          |
2272	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2273	   |                                                               |
2274	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2275	   |               |             Port (16)         |
2276	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

2281	   A PEX_REScert (0x0d) message consists of a 16-bit integer in big
2282	   endian specifying the size of the membership certificate that
2283	   follows, see Section 13.2.1.  This membership certificate states that
2284	   peer P at time T is a member of swarm S and is a X.509v3 certificate
2285	   [RFC5280] that is encoded using the ASN.1 distinguished encoding
2286	   rules (DER) [CCITT.X208.1988].  The certificate MUST contain a
2287	   "Subject Alternative Name" extension, marked as critical, of type
2288	   uniformResourceIdentifier.

2290	   A PEX_REScert message:

2292	    0                   1                   2                   3
2293	    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
2294	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2295	   |0 0 0 0 1 1 0 1|   Size of Memb. Cert. (16)    |               |
2296	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2297	   |                                                               |
2298	   ~                    Membership Certificate                     ~
2299	   |                                                               |
2300	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

2318	       ppsp://192.0.2.0:6778/e5a12c7ad2d8fab33c699d1e198d66f79fa610c3

2320	8.14.  KEEPALIVE

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

2326	   A keepalive datagram:

2328	    0                   1                   2                   3
2329	    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
2330	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2331	   |                       Channel ID (32)                         |
2332	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2334	8.15.  Detecting a Dead Peer

2336	   A guideline for declaring a peer dead consist of a 3 minute delay
2337	   since that last packet has been received from that peer, and at least
2338	   3 datagrams were sent to that peer during the same period.

2340	8.16.  Flow and Congestion Control

2342	   Explicit flow control is not necessary in PPSPP-over-UDP.  In the
2343	   case of video-on-demand the receiver will request data explicitly
2344	   from peers and is therefore in control of how much data is coming
2345	   towards it.  In the case of live streaming, where a push-model may be
2346	   used, the amount of data incoming is limited to the bitrate, which
2347	   the receiver must be able to process otherwise it cannot play the
2348	   stream.  Should, for any reason, the receiver get saturated with data
2349	   that situation is perfectly detected by the congestion control.

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

2358	8.17.  Example of Operation

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

2367	   To do the handshake the initiating peer sends a datagram that MUST
2368	   start with an all 0-zeros channel ID (0x00000000), followed by a
2369	   HANDSHAKE message, whose payload is a locally unused channel ID
2370	   (0x00000001) and a list of protocol options.

2372	    0                   1                   2                   3
2373	    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
2374	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2375	   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
2376	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2377	   |   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|
2378	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2379	   |0 0 0 0 0 0 0 1|    Version    |0 0 0 0 0 0 0 1|  Min Version  |
2380	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2381	   |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|
2382	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2383	   |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|
2384	   ~                             .....                             ~
2385	   |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|
2386	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2387	   |   Cont. Int.  |0 0 0 0 0 0 0 1| Mer.H.Tree F. |0 0 0 0 0 0 0 0|
2388	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2389	   |   Chunk Add.  |0 0 0 0 0 0 1 0|      End      |
2390	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2392	   The protocol options are:

2394	      Version: 1

2396	      Minimum supported Version: 1

2398	      Swarm Identifier: A 20 bytes root hash (47a0...b03b) identifying
2399	      the content.

2401	      Content Integrity Protection Method: Merkle Hash Tree.

2403	      Merkle Tree Hash Function: SHA1.

2405	      Chunk Addressing Method: 32-bit chunk ranges.

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

2413	    0                   1                   2                   3
2414	    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
2415	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2416	   |0 0 0 0 0 0 0 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|
2417	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2418	   |   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|
2419	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2420	   |0 0 0 0 1 0 0 0|    Version    |0 0 0 0 0 0 0 1|   Cont. Int.  |
2421	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2422	   |0 0 0 0 0 0 0 1| Mer.H.Tree F. |0 0 0 0 0 0 0 0|   Chunk Add.  |
2423	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2424	   |0 0 0 0 0 0 1 0|      End      |      HAVE     |0 0 0 0 0 0 0 0|
2425	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2426	   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
2427	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2428	   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
2429	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2431	   With the protocol options the receiving peer agrees on speaking
2432	   protocol version 1, on using the Merkle Hash Tree as Content
2433	   Integrity Protection Method, SHA1 hash as Merkle Tree Hash Function,
2434	   and 32-bit chunk ranges as Chunk Addressing Method.  Furthermore, it
2435	   sends a HAVE message within the same datagram, announcing that it has
2436	   locally available the first chunk of content.

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

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

2452	    0                   1                   2                   3
2453	    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
2454	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2455	   |0 0 0 0 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|
2456	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2457	   |    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|
2458	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2459	   |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
2460	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2461	   |0 0 0 0 0 0 0 0|    PEX_REQ    |
2462	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

2469	    0                   1                   2                   3
2470	    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
2471	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2472	   |0 0 0 0 0 0 0 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|
2473	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2474	   |     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|
2475	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2476	   |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
2477	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2478	   |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|
2479	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2480	   |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|
2481	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2482	   |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|
2483	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2484	   ~                           .....                               ~
2485	   |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|
2486	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2488	   The DATA message consists of:

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

2492	      The timestamp value: 0004e94180b7db44

2494	      The Data message: 48656c6c6f20776f726c6421 (the "Hello world!"
2495	      file)

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

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

2508	    0                   1                   2                   3
2509	    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
2510	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2511	   |0 0 0 0 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|
2512	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2513	   |      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|
2514	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2515	   |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
2516	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2517	   |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
2518	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2519	   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
2520	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2521	   |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|
2522	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2523	   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
2524	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2525	   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
2526	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2528	   At this point the initiating peer has successfully retrieved the
2529	   entire file.  It then explicitly closes the connection by sending a
2530	   HANDSHAKE message that contains an all 0-zeros channel ID.

2532	    0                   1                   2                   3
2533	    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
2534	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2535	   |0 0 0 0 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|
2536	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2537	   |   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|
2538	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2539	   |0 0 0 0 0 0 0 0|      End      |
2540	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2542	9.  Extensibility

2544	9.1.  Chunk Picking Algorithms

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

2551	   The chunk picking algorithm is external to the PPSPP protocol and
2552	   will generally be a pluggable policy that uses the mechanisms
2553	   provided by PPSPP.  The algorithm will handle the choices made by the
2554	   user consuming the content, such as seeking, switching audio tracks
2555	   or subtitles.  Example policies for P2P streaming can be found in
2556	   [BITOS], and [EPLIVEPERF].

2558	9.2.  Reciprocity Algorithms

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

2568	10.  Acknowledgements

2570	   Arno Bakker, Riccardo Petrocco and Victor Grishchenko are partially
2571	   supported by the P2P-Next project (http://www.p2p-next.org/), a
2572	   research project supported by the European Community under its 7th
2573	   Framework Programme (grant agreement no. 216217).  The views and
2574	   conclusions contained herein are those of the authors and should not
2575	   be interpreted as necessarily representing the official policies or
2576	   endorsements, either expressed or implied, of the P2P-Next project or
2577	   the European Commission.

2579	   The PPSPP protocol was designed by Victor Grishchenko at Technische
2580	   Universiteit Delft.  The authors would like to thank the following
2581	   people for their contributions to this draft: the chairs (Martin
2582	   Stiemerling, Yunfei Zhang, Stefano Previdi, Ning Zong) and members of
2583	   the IETF PPSP working group, and Mihai Capota, Raul Jimenez, Flutra
2584	   Osmani, Johan Pouwelse, and Raynor Vliegendhart.

2586	11.  IANA Considerations

2588	   IANA is to create the new registries defined below for the
2589	   extensibility of the protocol.  For all registries, assignments
2590	   consist of a name and its associated value.  Also for all registries,
2591	   the "Unassigned" ranges designated are governed by the policy 'IETF
2592	   Review' as described in [RFC5226].

2594	11.1.  PPSP Peer Protocol Message Type Registry

2596	   Registry name is "PPSP Peer Protocol Message Type Registry".  Values
2597	   are integers in the range 0-255, with initial assignments and
2598	   reservations given in Table 7.

2600	11.2.  PPSP Peer Protocol Option Registry

2602	   Registry name is "PPSP Peer Protocol Option Registry".  Values are
2603	   integers in the range 0-255, with initial assignments and
2604	   reservations given in Table 2.

2606	11.3.  PPSP Peer Protocol Version Number Registry

2608	   Registry name is "PPSP Peer Protocol Version Number Registry".
2609	   Values are integers in the range 0-255, with initial assignments and
2610	   reservations given in Table 3.

2612	11.4.  PPSP Peer Protocol Content Integrity Protection Method Registry

2614	   Registry name is "PPSP Peer Protocol Content Integrity Protection
2615	   Method Registry".  Values are integers in the range 0-255, with
2616	   initial assignments and reservations given in Table 4.

2618	11.5.  PPSP Peer Protocol Merkle Hash Tree Function Registry

2620	   Registry name is "PPSP Peer Protocol Merkle Hash Tree Function
2621	   Registry".  Values are integers in the range 0-255, with initial
2622	   assignments and reservations given in Table 5.

2624	11.6.  PPSP Peer Protocol Chunk Addressing Method Registry

2626	   Registry name is "PPSP Peer Protocol Chunk Addressing Method
2627	   Registry".  Values are integers in the range 0-255, with initial
2628	   assignments and reservations given in Table 6.

2630	12.  Manageability Considerations

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

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

2640	12.1.  Operations

2642	12.1.1.  Installation and Initial Setup

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

2658	   In addition, a content provider should setup a tracking facility for
2659	   the content by configuring, for example, a PPSP tracker
2660	   [I-D.ietf-ppsp-base-tracker-protocol] or a Distributed Hash Table.
2661	   The output of the latter process is a list of transport addresses for
2662	   the tracking facility.

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

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

2683	12.1.2.  Requirements on Other Protocols and Functional Components

2685	   When using the PPSP tracker protocol, PPSPP requires a specific
2686	   behavior from this protocol for security reasons, as detailed in
2687	   Section 13.2.

2689	12.1.3.  Migration Path

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

2694	12.1.4.  Impact on Network Operation

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

2704	12.1.5.  Verifying Correct Operation

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

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

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

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

2728	12.1.6.  Configuration

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

2735	   +-------------------------+-----------------------+-----------------+
2736	   | Name                    | Default               | Definition      |
2737	   +-------------------------+-----------------------+-----------------+
2738	   | Chunk Size              | var, 1024 bytes       | Section 8.1     |
2739	   |                         | recommended           |                 |
2740	   | Static Content          | 1 (Merkle Hash Tree)  | Section 7.5     |
2741	   | Integrity Protection    |                       |                 |
2742	   | Method                  |                       |                 |
2743	   | Live Content Integrity  | 3 (Unified Merkle     | Section 7.5     |
2744	   | Protection Method       | Tree)                 |                 |
2745	   | Merkle Hash Tree        | 0 (SHA1)              | Section 7.6     |
2746	   | Function                |                       |                 |
2747	   | Live Signature          | 13 (ECDSAP256SHA256)  | Section 7.7     |
2748	   | Algorithm               |                       |                 |
2749	   | Chunk Addressing Method | 2 (32-bit chunk       | Section 7.8     |
2750	   |                         | ranges)               |                 |
2751	   | Live Discard Window     | var                   | Section 6.2,    |
2752	   |                         |                       | Section 7.9     |
2753	   | NCHUNKS_PER_SIG         | var                   | Section 6.1.2.1 |
2754	   | Dead peer detection     | No reply in 3 minutes | Section 8.15    |
2755	   |                         | + 3 datagrams         |                 |
2756	   +-------------------------+-----------------------+-----------------+

2758	                          Table 8: PPSPP Defaults

2760	12.2.  Management Considerations

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

2773	12.2.1.  Management Interoperability and Information

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

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

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

2793	12.2.2.  Fault Management

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

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

2807	12.2.3.  Configuration Management

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

2819	12.2.4.  Accounting Management

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

2828	12.2.5.  Performance Management

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

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

2838	12.2.6.  Security Management

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

2845	13.  Security Considerations

2847	   As any other network protocol, the PPSPP faces a common set of
2848	   security challenges.  An implementation must consider the possibility
2849	   of buffer overruns, DoS attacks and manipulation (i.e. reflection
2850	   attacks).  Any guarantee of privacy seems unlikely, as the user is
2851	   exposing its IP address to the peers.  A probable exception is the
2852	   case of the user being hidden behind a public NAT or proxy.  This
2853	   section discusses the protocol's security considerations in detail.

2855	13.1.  Security of the Handshake Procedure

2857	   Borrowing from the analysis in [RFC5971], the PPSP peer protocol may
2858	   be attacked with 3 types of denial-of-service attacks:

2860	   1.  DOS amplification attack: attackers try to use a PPSPP peer to
2861	       generate more traffic to a victim.

2863	   2.  DOS flood attack: attackers try to deny service to other peers by
2864	       allocating lots of state at a PPSPP peer.

2866	   3.  Disrupt service to an individual peer: attackers send bogus e.g.
2867	       REQUEST and HAVE messages appearing to come from victim peer A to
2868	       the peers B1..Bn serving that peer.  This causes A to receive
2869	       chunks it did not request or to not receive the chunks it
2870	       requested.

2872	   The basic scheme to protect against these attacks is the use of a
2873	   secure handshake procedure.  In the UDP encapsulation the handshake
2874	   procedure is secured by the use of randomly chosen channel IDs as
2875	   follows.  The channel IDs must be generated following the
2876	   requirements in [RFC4960] (Sec. 5.1.3).

2878	   When UDP is used, all datagrams carrying PPSPP messages are prefixed
2879	   with a 4-byte channel ID.  These channel IDs are random numbers,
2880	   established during the handshake phase as follows.  Peer A initiates
2881	   an exchange with peer B by sending a datagram containing a HANDSHAKE
2882	   message prefixed with the channel ID consisting of all 0s.  Peer A's
2883	   HANDSHAKE contains a randomly chosen channel ID, chanA:

2885	   A->B: chan0 + HANDSHAKE(chanA) + ...

2887	   When peer B receives this datagram, it creates some state for peer A,
2888	   that at least contains the channel ID chanA.  Next, peer B sends a
2889	   response to A, consisting of a datagram containing a HANDSHAKE
2890	   message prefixed with the chanA channel ID.  Peer B's HANDSHAKE
2891	   contains a randomly chosen channel ID, chanB.

2893	   B->A: chanA + HANDSHAKE(chanB) + ...

2895	   Peer A now knows that peer B really responds, as it echoed chanA.  So
2896	   the next datagram that A sends may already contain heavy payload,
2897	   i.e., a chunk.  This next datagram to B will be prefixed with the
2898	   chanB channel ID.  When B receives this datagram, both peers have the
2899	   proof they are really talking to each other, the three-way handshake
2900	   is complete.  In other words, the randomly chosen channel IDs act as
2901	   tags (cf. [RFC4960] (Sec. 5.1)).

2903	   A->B: chanB + HAVE + DATA + ...

2905	13.1.1.  Protection Against Attack 1

2907	   In short, PPSPP does a so-called return routability check before
2908	   heavy payload is sent.  This means that attack 1 is fended off: PPSPP
2909	   does not send back much more data than it received, unless it knows
2910	   it is talking to a live peer.  Attackers sending a spoofed HANDSHAKE
2911	   to B pretending to be A now need to intercept the message from B to A
2912	   to get B to send heavy payload, and ensure that that heavy payload
2913	   goes to the victim, something assumed too hard to be a practical
2914	   attack.

2916	   Note the rule is that no heavy payload may be sent until the third
2917	   datagram.  This has implications for PPSPP implementations that use
2918	   chunk addressing schemes that are verbose.  If a PPSPP implementation
2919	   uses large bitmaps to convey chunk availability these may not be sent
2920	   by peer B in the second datagram.

2922	13.1.2.  Protection Against Attack 2

2924	   On receiving the first datagram peer B will record some state about
2925	   peer A. At present this state consists of the chanA channel ID, and
2926	   the results of processing the other messages in the first datagram.
2927	   In particular, if A included some HAVE messages, B may add a chunk
2928	   availability map to A's state.  In addition, B may request some
2929	   chunks from A in the second datagram, and B will maintain state about
2930	   these outgoing requests.

2932	   So presently, PPSPP is somewhat vulnerable to attack 2.  An attacker
2933	   could send many datagrams with HANDSHAKEs and HAVEs and thus allocate
2934	   state at the PPSPP peer.  Therefore peer A MUST respond immediately
2935	   to the second datagram, if it is still interested in peer B.

2937	   The reason for using this slightly vulnerable three-way handshake
2938	   instead of the safer handshake procedure of SCTP [RFC4960] (Sec. 5.1)
2939	   is quicker response time for the user.  In the SCTP procedure, peer A
2940	   and B cannot request chunks until datagrams 3 and 4 respectively, as
2941	   opposed to 2 and 1 in the proposed procedure.  This means that the
2942	   user has to wait shorter in PPSPP between starting the video stream
2943	   and seeing the first images.

2945	13.1.3.  Protection Against Attack 3

2947	   In general, channel IDs serve to authenticate a peer.  Hence, to
2948	   attack, a malicious peer T would need to be able to eavesdrop on
2949	   conversations between victim A and a benign peer B to obtain the
2950	   channel ID B assigned to A, chanB.  Furthermore, attacker T would
2951	   need to be able to spoof e.g.  REQUEST and HAVE messages from A to
2952	   cause B to send heavy DATA messages to A, or prevent B from sending
2953	   them, respectively.

2955	   The capability to eavesdrop is not common, so the protection afforded
2956	   by channel IDs will be sufficient in most cases.  If not, point-to-
2957	   point encryption of traffic should be used, see below.

2959	13.2.  Secure Peer Address Exchange

2961	   As described in Section 3.10, a peer A can send Peer-Exchange
2962	   messages PEX_RES to a peer B, which contain the IP address and port
2963	   of other peers that are supposedly also in the current swarm.  The
2964	   strength of this mechanism is that it allows decentralized tracking:
2965	   after an initial bootstrap no central tracker is needed anymore.  The
2966	   vulnerability of this mechanism (and DHTs) is that malicious peers
2967	   can use it for an Amplification attack.

2969	   In particular, a malicious peer T could send PEX_RES messages to
2970	   well-behaved peer A with addresses of peers B1,B2,...,BN and on
2971	   receipt, peer A could send a HANDSHAKE to all these peers.  So in the
2972	   worst case, a single datagram results in N datagrams.  The actual
2973	   damage depends on A's behavior.  E.g. when A already has sufficient
2974	   connections it may not connect to the offered ones at all, but if it
2975	   is a fresh peer it may connect to all directly.

2977	   In addition, PEX can be used in Eclipse attacks [ECLIPSE] where
2978	   malicious peers try to isolate a particular peer such that it only
2979	   interacts with malicious peers.  Let us distinguish two specific
2980	   attacks:

2982	      E1.  Malicious peers try to eclipse the single injector in live
2983	      streaming.

2985	      E2.  Malicious peers try to eclipse a specific consumer peer.

2987	   Attack E1 has the most impact on the system as it would disrupt all
2988	   peers.

2990	13.2.1.  Protection against the Amplification Attack

2992	   If peer addresses are relatively stable, strong protection against
2993	   the attack can be provided by using public key cryptography and
2994	   certification.  In particular, a PEX_REScert message will carry
2995	   swarm-membership certificates rather than IP address and port.  A
2996	   membership certificate for peer B states that peer B at address
2997	   (ipB,portB) is part of swarm S at time T and is cryptographically
2998	   signed.  The receiver A can check the cert for a valid signature, the
2999	   right swarm and liveliness and only then consider contacting B. These
3000	   swarm-membership certificates correspond to signed node descriptors
3001	   in secure decentralized peer sampling services [SPS].

3003	   Several designs are possible for the security environment for these
3004	   membership certificates.  That is, there are different designs
3005	   possible for who signs the membership certificates and how public
3006	   keys are distributed.  As an example, we describe a design where the
3007	   PPSP tracker acts as certification authority.

3009	13.2.2.  Example: Tracker as Certification Authority

3011	   A peer A wanting to join swarm S sends a certificate request message
3012	   to a tracker X for that swarm.  Upon receipt, the tracker creates a
3013	   membership certificate from the request with swarm ID S, a timestamp
3014	   T and the external IP and port it received the message from, signed
3015	   with the tracker's private key.  This certificate is returned to A.

3017	   Peer A then includes this certificate when it sends a PEX_REScert to
3018	   peer B. Receiver B verifies it against the tracker public key.  This
3019	   tracker public key should be part of the swarm's metadata, which B
3020	   received from a trusted source.  Subsequently, peer B can send the
3021	   member certificate of A to other peers in PEX_REScert messages.

3023	   Peer A can send the certification request when it first contacts the
3024	   tracker, or at a later time.  Furthermore, the responses the tracker
3025	   sends could contain membership certificates instead of plain
3026	   addresses, such that they can be gossiped securely as well.

3028	   We assume the tracker is protected against attacks and does a return
3029	   routability check.  The latter ensures that malicious peers cannot
3030	   obtain a certificate for a random host, just for hosts where they can
3031	   eavesdrop on incoming traffic.

3033	   The load generated on the tracker depends on churn and the lifetime
3034	   of a certificate.  Certificates can be fairly long lived, given that
3035	   the main goal of the membership certificates is to prevent that
3036	   malicious peer T can cause good peer A to contact *random* hosts.
3037	   The freshness of the timestamp just adds extra protection in addition
3038	   to achieving that goal.  It protects against malicious hosts causing
3039	   a good peer A to contact hosts that previously participated in the
3040	   swarm.

3042	   The membership certificate mechanism itself can be used for a kind of
3043	   amplification attack against good peers.  Malicious peer T can cause
3044	   peer A to spend some CPU to verify the signatures on the membership
3045	   certificates that T sends.  To counter this, A SHOULD check a few of
3046	   the certificates sent and discard the rest if they are defective.

3048	   The same membership certificates described above can be registered in
3049	   a Distributed Hash Table that has been secured against the well-known
3050	   DHT specific attacks [SECDHTS].

3052	   Note that this scheme does not work for peers behind a symmetric
3053	   Network Address Translator, but neither does normal tracker
3054	   registration.

3056	13.2.3.  Protection Against Eclipse Attacks

3058	   Before we can discuss Eclipse attacks we first need to establish the
3059	   security properties of the central tracker.  A tracker is vulnerable
3060	   to Amplification attacks too.  A malicious peer T could register a
3061	   victim B with the tracker, and many peers joining the swarm will
3062	   contact B. Trackers can also be used in Eclipse attacks.  If many
3063	   malicious peers register themselves at the tracker, the percentage of
3064	   bad peers in the returned address list may become high.  Leaving the
3065	   protection of the tracker to the PPSP tracker protocol specification,
3066	   we assume for the following discussion that it returns a true random
3067	   sample of the actual swarm membership (achieved via Sybil attack
3068	   protection).  This means that if 50% of the peers is bad, you'll
3069	   still get 50% good addresses from the tracker.

3071	   Attack E1 on PEX can be fended off by letting live injectors disable
3072	   PEX.  Or at least, let live injectors ensure that part of their
3073	   connections are to peers whose addresses came from the trusted
3074	   tracker.

3076	   The same measures defend against attack E2 on PEX.  They can also be
3077	   employed dynamically.  When the current set of peers B that peer A is
3078	   connected to doesn't provide good quality of service, A can contact
3079	   the tracker to find new candidates.

3081	13.3.  Support for Closed Swarms (PPSP.SEC.REQ-1)

3083	   The Closed Swarms [CLOSED] and Enhanced Closed Swarms [ECS]
3084	   mechanisms provide swarm-level access control.  The basic idea is
3085	   that a peer cannot download from another peer unless it shows a
3086	   Proof-of-Access.  Enhanced Closed Swarms improve on the original
3087	   Closed Swarms by adding on-the-wire encryption against man-in-the-
3088	   middle attacks and more flexible access control rules.

3090	   The exact mapping of ECS to PPSPP is defined in
3091	   [I-D.gabrijelcic-ppsp-ecs].

3093	13.4.  Confidentiality of Streamed Content (PPSP.SEC.REQ-2+3)

3095	   No extra mechanism is needed to support confidentiality in PPSPP.  A
3096	   content publisher wishing confidentiality should just distribute
3097	   content in cyphertext / DRM-ed format.  In that case it is assumed a
3098	   higher layer handles key management out-of-band.  Alternatively, pure
3099	   point-to-point encryption of content and traffic can be provided by
3100	   the proposed Closed Swarms access control mechanism, or by DTLS
3101	   [RFC6347] or IPsec [RFC4301].

3103	13.5.  Strength of the Hash Function for Merkle Hash Trees

3105	   Implementations MUST support SHA1 as the hash function for content
3106	   integrity protection via Merkle Hash trees.  SHA1 is preferred over
3107	   stronger hash functions for two reasons.  First, it reduces on-the-
3108	   wire overhead.  Second, few implementations need the extra strength
3109	   of other functions because the function is used in a hash tree.  In
3110	   particular, if attackers manage to find a collision for a hash it can
3111	   replace just one chunk, so the impact is limited.  If fixed sized
3112	   chunks are used, the collision has to be of the same size as the
3113	   original chunk.  For hashes higher up in the hash tree, a collision
3114	   must be a concatenation of two hashes.  In sum, finding collisions
3115	   that fit with the hash tree are generally harder to find than regular
3116	   SHA1 collisions, which are, at the time of writing, still hard to
3117	   find.

3119	13.6.  Limit Potential Damage and Resource Exhaustion by Bad or Broken
3120	       Peers (PPSP.SEC.REQ-4+6)

3122	   In this section an analysis is given of the potential damage a
3123	   malicious peer can do with each message in the protocol, and how it
3124	   is prevented by the protocol (implementation).

3126	13.6.1.  HANDSHAKE

3128	   o  Secured against DoS amplification attacks as described in
3129	      Section 13.1.

3131	   o  Threat HS.1: An Eclipse attack where peers T1..Tn fill all
3132	      connection slots of A by initiating the connection to A.

3134	      Solution: Peer A must not let other peers fill all its available
3135	      connection slots, i.e., A must initiate connections itself too, to
3136	      prevent isolation.

3138	13.6.2.  HAVE

3140	   o  Threat HAVE.1: Malicious peer T can claim to have content which it
3141	      hasn't.  Subsequently T won't respond to requests.

3143	      Solution: peer A will consider T to be a slow peer and not ask it
3144	      again.

3146	   o  Threat HAVE.2: Malicious peer T can claim not to have content.
3147	      Hence it won't contribute.

3149	      Solution: Peer and chunk selection algorithms external to the
3150	      protocol will implement fairness and provide sharing incentives.

3152	13.6.3.  DATA

3154	   o  Threat DATA.1: peer T sending bogus chunks.

3156	      Solution: The content integrity protection schemes defend against
3157	      this.

3159	   o  Threat DATA.2: peer T sends peer A unrequested chunks.

3161	      To protect against this threat we need network-level DoS
3162	      prevention.

3164	13.6.4.  ACK

3166	   o  Threat ACK.1: peer T acknowledges wrong chunks.

3168	      Solution: peer A will detect inconsistencies with the data it sent
3169	      to T.

3171	   o  Threat ACK.2: peer T modifies timestamp in ACK to peer A used for
3172	      time-based congestion control.

3174	      Solution: In theory, by decreasing the timestamp peer T could fake
3175	      there is no congestion when in fact there is, causing A to send
3176	      more data than it should.  [RFC6817] does not list this as a
3177	      security consideration.  Possibly this attack can be detected by
3178	      the large resulting asymmetry between round-trip time and measured
3179	      one-way delay.

3181	13.6.5.  INTEGRITY and SIGNED_INTEGRITY

3183	   o  Threat INTEGRITY.1: An amplification attack where peer T sends
3184	      bogus INTEGRITY or SIGNED_INTEGRITY messages, causing peer A to
3185	      checks hashes or signatures, thus spending CPU unnecessarily.

3187	      Solution: If the hashes/signatures don't check out A will stop
3188	      asking T because of the atomic datagram principle and the content
3189	      integrity protection.  Subsequent unsolicited traffic from T will
3190	      be ignored.

3192	   o  Threat INTEGRITY.2: An attack where peer T sends old
3193	      SIGNED_INTEGRITY messages in the Unified Merkle Tree scheme,
3194	      trying to make peer A tune in at a past point in the live stream.

3196	      Solution: The timestamp in the SIGNED_INTEGRITY message protects
3197	      against such replays.  Subsequent traffic from T will be ignored.

3199	13.6.6.  REQUEST

3201	   o  Threat REQUEST.1: peer T could request lots from A, leaving A
3202	      without resources for others.

3204	      Solution: A limit is imposed on the upload capacity a single peer
3205	      can consume, for example, by using an upload bandwidth scheduler
3206	      that takes into account the need of multiple peers.  A natural
3207	      upper limit of this upload quotum is the bitrate of the content,
3208	      taking into account that this may be variable.

3210	13.6.7.  CANCEL

3212	   o  Threat CANCEL.1: peer T sends CANCEL messages for content it never
3213	      requested to peer A.

3215	      Solution: peer A will detect the inconsistency of the messages and
3216	      ignore them.  Note that CANCEL messages may be received
3217	      unexpectedly when a transport is used where REQUEST messages may
3218	      be lost or reordered with respect to the subsequent CANCELs.

3220	13.6.8.  CHOKE

3222	   o  Threat CHOKE.1: peer T sends REQUEST messages after peer A sent B
3223	      a CHOKE message.

3225	      Solution: peer A will just discard the unwanted REQUESTs and
3226	      resend the CHOKE, assuming it got lost.

3228	13.6.9.  UNCHOKE

3230	   o  Threat UNCHOKE.1: peer T sends an UNCHOKE message to peer A
3231	      without having sent a CHOKE message before.

3233	      Solution: peer A can easily detect this violation of protocol
3234	      state, and ignore it.  Note this can also happen due to loss of a
3235	      CHOKE message sent by a benign peer.

3237	   o  Threat UNCHOKE.2: peer T sends an UNCHOKE message to peer A, but
3238	      subsequently does not respond to its REQUESTs.

3240	      Solution: peer A will consider T to be a slow peer and not ask it
3241	      again.

3243	13.6.10.  PEX_RES

3245	   o  Secured against amplification and Eclipse attacks as described in
3246	      Section 13.2.

3248	13.6.11.  Unsolicited Messages in General

3250	   o  Threat: peer T could send a spoofed PEX_REQ or REQUEST from peer B
3251	      to peer A, causing A to send a PEX_RES/DATA to B.

3253	      Solution: the message from peer T won't be accepted unless T does
3254	      a handshake first, in which case the reply goes to T, not victim
3255	      B.

3257	13.7.  Exclude Bad or Broken Peers (PPSP.SEC.REQ-5)

3259	   A receiving peer can detect malicious or faulty senders as just
3260	   described, which it can then subsequently ignore.  However, excluding
3261	   such a bad peer from the system completely is complex.  Random
3262	   monitoring by trusted peers that would blacklist bad peers as
3263	   described in [DETMAL] is one option.  This mechanism does require
3264	   extra capacity to run such trusted peers, which must be
3265	   indistinguishable from regular peers, and requires a solution for the
3266	   timely distribution of this blacklist to peers in a scalable manner.

3268	14.  References

3270	14.1.  Normative References

3272	   [CCITT.X208.1988]
3273	              International International Telephone and Telegraph
3274	              Consultative Committee, "Specification of Abstract Syntax
3275	              Notation One (ASN.1)", CCITT Recommendation X.208,
3276	              November 1988.

3278	   [FIPS180-4]
3279	              Information Technology Laboratory,  National Institute of
3280	              Standards and Technology, "Federal Information Processing
3281	              Standards: Secure Hash Standard (SHS)", Publication 180-4,
3282	              Mar 2012.

3284	   [IANADNSSECALGNUM]
3285	              IANA, "Domain Name System Security (DNSSEC) Algorithm
3286	              Numbers",
3287	              <http://www.iana.org/assignments/dns-sec-alg-numbers>.

3289	   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
3290	              E. Lear, "Address Allocation for Private Internets",
3291	              BCP 5, RFC 1918, February 1996.

3293	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
3294	              Requirement Levels", BCP 14, RFC 2119, March 1997.

3296	   [RFC3110]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
3297	              Name System (DNS)", RFC 3110, May 2001.

3299	   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
3300	              Resource Identifier (URI): Generic Syntax", STD 66,
3301	              RFC 3986, January 2005.

3303	   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
3304	              Rose, "Resource Records for the DNS Security Extensions",
3305	              RFC 4034, March 2005.

3307	   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
3308	              Architecture", RFC 4291, February 2006.

3310	   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
3311	              Housley, R., and W. Polk, "Internet X.509 Public Key
3312	              Infrastructure Certificate and Certificate Revocation List
3313	              (CRL) Profile", RFC 5280, May 2008.

3315	   [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
3316	              Time Protocol Version 4: Protocol and Algorithms
3317	              Specification", RFC 5905, June 2010.

3319	   [RFC6605]  Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital
3320	              Signature Algorithm (DSA) for DNSSEC", RFC 6605,
3321	              April 2012.

3323	14.2.  Informative References

3325	   [ABMRKL]   Bakker, A., "Merkle hash torrent extension", BitTorrent
3326	              Enhancement Proposal 30, Mar 2009,
3327	              <http://bittorrent.org/beps/bep_0030.html>.

3329	   [BINMAP]   Grishchenko, V. and J. Pouwelse, "Binmaps: hybridizing
3330	              bitmaps and binary trees", Technical Report PDS-2011-005,
3331	              Parallel and  Distributed Systems Group, Fac. of
3332	              Electrical Engineering,  Mathematics, and Computer
3333	              Science, Delft University of Technology,  The Netherlands,
3334	              Apr 2009.

3336	   [BITOS]    Vlavianos, A., Iliofotou, M., Mathieu, F., and M.
3337	              Faloutsos, "BiToS: Enhancing BitTorrent for Supporting
3338	              Streaming Applications", IEEE INFOCOM Global Internet
3339	              Symposium Barcelona, Spain, Apr 2006.

3341	   [BITTORRENT]
3342	              Cohen, B., "The BitTorrent Protocol Specification",
3343	              BitTorrent Enhancement Proposal 3, Feb 2008,
3344	              <http://bittorrent.org/beps/bep_0003.html>.

3346	   [CLOSED]   Borch, N., Mitchell, K., Arntzen, I., and D. Gabrijelcic,
3347	              "Access Control to BitTorrent Swarms Using Closed Swarms",
3348	              ACM workshop on Advanced Video Streaming Techniques for
3349	              Peer-to-Peer Networks and Social Networking (AVSTP2P '10),
3350	              Florence, Italy, Oct 2010,
3351	              <http://doi.acm.org/10.1145/1877891.1877898>.

3353	   [DETMAL]   Shetty, S., Galdames, P., Tavanapong, W., and Ying. Cai,
3354	              "Detecting Malicious Peers in Overlay Multicast
3355	              Streaming", IEEE Conference on Local Computer
3356	              Networks (LCN'06). Tampa, FL, USA, Nov 2006.

3358	   [ECLIPSE]  Sit, E. and R. Morris, "Security Considerations for Peer-
3359	              to-Peer Distributed Hash Tables", IPTPS '01: Revised
3360	              Papers from the First International Workshop on Peer-to-
3361	              Peer Systems pp. 261-269, Springer-Verlag, 2002.

3363	   [ECS]      Jovanovikj, V., Gabrijelcic, D., and T. Klobucar, "Access
3364	              Control in BitTorrent P2P Networks Using the Enhanced
3365	              Closed Swarms Protocol", International Conference on
3366	              Emerging Security  Information, Systems and
3367	              Technologies (SECURWARE 2011), pp. 97-102, Nice, France,
3368	              Aug 2011.

3370	   [EPLIVEPERF]
3371	              Bonald, T., Massoulie, L., Mathieu, F., Perino, D., and A.
3372	              Twigg, "Epidemic Live Streaming: Optimal Performance
3373	              Trade-offs", Proceedings of the 2008 ACM SIGMETRICS
3374	              International  Conference on Measurement and Modeling of
3375	              Computer Systems Annapolis, MD, USA, Jun 2008.

3377	   [GIVE2GET]
3378	              Mol, J., Pouwelse, J., Meulpolder, M., Epema, D., and H.
3379	              Sips, "Give-to-Get: Free-riding Resilient Video-on-demand
3380	              in P2P Systems", Proceedings Multimedia Computing and
3381	              Networking conference (Proceedings of SPIE Vol. 6818) San
3382	              Jose, California, USA, Jan 2008.

3384	   [HAC01]    Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook
3385	              of Applied Cryptography", CRC Press, (Fifth Printing,
3386	              August 2001), Oct 1996.

3388	   [I-D.gabrijelcic-ppsp-ecs]
3389	              Gabrijelcic, D., "Enhanced Closed Swarm protocol",
3390	              draft-ppsp-gabrijelcic-ecs (work in progress),
3391	              November 2012.

3393	   [I-D.ietf-alto-protocol]
3394	              Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
3395	              draft-ietf-alto-protocol-27 (work in progress),
3396	              March 2014.

3398	   [I-D.ietf-ppsp-base-tracker-protocol]
3399	              Cruz, R., Nunes, M., Yingjie, G., Xia, J., Taveira, J.,
3400	              and D. Lingli, "PPSP Tracker Protocol-Base Protocol (PPSP-
3401	              TP/1.0)", draft-ietf-ppsp-base-tracker-protocol-03 (work
3402	              in progress), December 2013.

3404	   [JIM11]    Jimenez, R., Osmani, F., and B. Knutsson, "Sub-Second
3405	              Lookups on a Large-Scale Kademlia-Based Overlay", IEEE
3406	              International Conference on Peer-to-Peer
3407	              Computing (P2P'11), Kyoto, Japan, Aug 2011.

3409	   [LBT]      Rossi, D., Testa, C., Valenti, S., and L. Muscariello,
3410	              "LEDBAT: the new BitTorrent congestion control protocol",
3411	              Computer Communications and Networks (ICCCN), Zurich,
3412	              Switzerland, Aug 2010.

3414	   [LCOMPL]   Testa, C. and D. Rossi, "On the impact of uTP on
3415	              BitTorrent completion time", IEEE International Conference
3416	              on Peer-to-Peer Computing (P2P'11), Kyoto, Japan,
3417	              Aug 2011.

3419	   [MERKLE]   Merkle, R., "Secrecy, Authentication, and Public Key
3420	              Systems", Ph.D. thesis Dept. of Electrical Engineering,
3421	              Stanford University, CA, USA, pp 40-45, 1979.

3423	   [POLLIVE]  Dhungel, P., Hei, Xiaojun., Ross, K., and N. Saxena,
3424	              "Pollution in P2P Live Video Streaming", International
3425	              Journal of Computer Networks & Communications
3426	              (IJCNC) Vol.1, No.2, Jul 2009.

3428	   [PPSPPERF]
3429	              Petrocco, R., Pouwelse, J., and D. Epema, "Performance
3430	              analysis of the Libswift P2P streaming protocol", IEEE
3431	              International Conference on Peer-to-Peer
3432	              Computing (P2P'12), Tarragona, Spain, Sept 2012.

3434	   [RFC2564]  Kalbfleisch, C., Krupczak, C., Presuhn, R., and J.
3435	              Saperia, "Application Management MIB", RFC 2564, May 1999.

3437	   [RFC2790]  Waldbusser, S. and P. Grillo, "Host Resources MIB",
3438	              RFC 2790, March 2000.

3440	   [RFC2975]  Aboba, B., Arkko, J., and D. Harrington, "Introduction to
3441	              Accounting Management", RFC 2975, October 2000.

3443	   [RFC3365]  Schiller, J., "Strong Security Requirements for Internet
3444	              Engineering Task Force Standard Protocols", BCP 61,
3445	              RFC 3365, August 2002.

3447	   [RFC3729]  Waldbusser, S., "Application Performance Measurement MIB",
3448	              RFC 3729, March 2004.

3450	   [RFC4113]  Fenner, B. and J. Flick, "Management Information Base for
3451	              the User Datagram Protocol (UDP)", RFC 4113, June 2005.

3453	   [RFC4150]  Dietz, R. and R. Cole, "Transport Performance Metrics
3454	              MIB", RFC 4150, August 2005.

3456	   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
3457	              Internet Protocol", RFC 4301, December 2005.

3459	   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
3460	              Discovery", RFC 4821, March 2007.

3462	   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
3463	              RFC 4960, September 2007.

3465	   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
3466	              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
3467	              May 2008.

3469	   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
3470	              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
3471	              October 2008.

3473	   [RFC5424]  Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.

3475	   [RFC5706]  Harrington, D., "Guidelines for Considering Operations and
3476	              Management of New Protocols and Protocol Extensions",
3477	              RFC 5706, November 2009.

3479	   [RFC5971]  Schulzrinne, H. and R. Hancock, "GIST: General Internet
3480	              Signalling Transport", RFC 5971, October 2010.

3482	   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
3483	              Bierman, "Network Configuration Protocol (NETCONF)",
3484	              RFC 6241, June 2011.

3486	   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
3487	              Security Version 1.2", RFC 6347, January 2012.

3489	   [RFC6709]  Carpenter, B., Aboba, B., and S. Cheshire, "Design
3490	              Considerations for Protocol Extensions", RFC 6709,
3491	              September 2012.

3493	   [RFC6817]  Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
3494	              "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
3495	              December 2012.

3497	   [RFC6972]  Zhang, Y. and N. Zong, "Problem Statement and Requirements
3498	              of the Peer-to-Peer Streaming Protocol (PPSP)", RFC 6972,
3499	              July 2013.

3501	   [SECDHTS]  Urdaneta, G., Pierre, G., and M. van Steen, "A Survey of
3502	              DHT Security Techniques", ACM Computing Surveys vol.
3503	              43(2), Jun 2011.

3505	   [SIGMCAST]
3506	              Wong, C. and S. Lam, "Digital Signatures for Flows and
3507	              Multicasts", IEEE/ACM Transactions on Networking 7(4), pp.
3508	              502-513, 1999.

3510	   [SPS]      Jesi, G., Montresor, A., and M. van Steen, "Secure Peer
3511	              Sampling", Computer Networks vol. 54(12), pp. 2086-2098,
3512	              Elsevier, Aug 2010.

3514	   [SWIFTIMPL]
3515	              Grishchenko, V., Paananen, J., Pronchenkov, A., Bakker,
3516	              A., and R. Petrocco, "Swift reference implementation",
3517	              2014, <https://github.com/libswift/libswift>.

3519	   [TIT4TAT]  Cohen, B., "Incentives Build Robustness in BitTorrent",
3520	              1st Workshop on Economics of Peer-to-Peer
3521	              Systems, Berkeley, CA, USA, Jun 2003.

3523	Appendix A.  Revision History
3524	   -00        2011-12-19 Initial version.

3526	   -01        2012-01-30 Minor text revision:

3528	       *   Changed heading to "A. Bakker"

3530	       *   Changed title to *Peer* Protocol, and abbreviation PPSPP.

3532	       *   Replaced swift with PPSPP.

3534	       *   Removed Sec. 6.4.  "HTTP (as PPSP)".

3536	       *   Renamed Sec. 8.4. to "Chunk Picking Algorithms".

3538	       *   Resolved Ticket #3: Removed sentence about random set of
3539	           peers.

3541	       *   Resolved Ticket #6: Added clarification to "Chunk Picking
3542	           Algorithms" section.

3544	       *   Resolved Ticket #11: Added Sec. 3.12 on Storage Independence

3546	       *   Resolved Ticket #14: Added clarification to "Automatic Size
3547	           Detection" section.

3549	       *   Resolved Ticket #15: Operation section now states it shows
3550	           example behaviour for a specific set of policies and schemes.

3552	       *   Resolved Ticket #30: Explained why multiple REQUESTs in one
3553	           datagram.

3555	       *   Resolved Ticket #31: Renamed PEX_ADD message to PEX_RES.

3557	       *   Resolved Ticket #32: Renamed Sec 3.8. to "Keep Alive
3558	           Signaling", and updated explanation.

3560	       *   Resolved Ticket #33: Explained NAT hole punching via only
3561	           PPSPP messages.

3563	       *   Resolved Ticket #34: Added section about limited overhead of
3564	           the Merkle hash tree scheme.

3566	   -02        2012-04-17 Major revision

3568	       *   Allow different chunk addressing and content integrity
3569	           protection schemes (ticket #13):

3571	       *   Added chunk ID, chunk specification, chunk addressing scheme,
3572	           etc. to terminology.

3574	       *   Created new Sections 4 and 5 discussing chunk addressing and
3575	           content integrity protection schemes, respectively and moved
3576	           relevant sections on bin numbering and Merkle hash trees
3577	           there.

3579	       *   Renamed Section 4 to "Merkle Hash Trees and The Automatic
3580	           Detection of Content Size".

3582	       *   Reformulated automatic size detection in terms of nodes, not
3583	           bins.

3585	       *   Extended HANDSHAKE message to carry protocol options and
3586	           created Section 8 on Protocol options.  VERSION and
3587	           MSGTYPE_RCVD messages replaced with protocol options.

3589	       *   Renamed HASH message to INTEGRITY.

3591	       *   Renamed HINT to REQUEST.

3593	       *   Added description of chunk addressing via (start,end) ranges.

3595	       *   Resolved Ticket #26: Extended "Security Considerations" with
3596	           section on the handshake procedure.

3598	       *   Resolved Ticket #17: Defined recently as "in last 60 seconds"
3599	           in PEX.

3601	       *   Resolved Ticket #20: Extended "Security Considerations" with
3602	           design to make Peer Address Exchange more secure.

3604	       *   Resolved Ticket #38+39 / PPSP.SEC.REQ-2+3: Extended "Security
3605	           Considerations" with a section on confidentiality of content.

3607	       *   Resolved Ticket #40+42 / PPSP.SEC.REQ-4+6: Extended "Security
3608	           Considerations" with a per-message analysis of threats and
3609	           how PPSPP is protected from them.

3611	       *   Progressed Ticket #41 / PPSP.SEC.REQ-5: Extended "Security
3612	           Considerations" with a section on possible ways of excluding
3613	           bad or broken peers from the system.

3615	       *   Moved Rationale to Appendix.

3617	       *   Resolved Ticket #43: Updated Live Streaming section to
3618	           include "Sign All" content authentication, and reference to

3620	           [SIGMCAST] following discussion with Fabio Picconi.

3622	       *   Resolved Ticket #12: Added a CANCEL message to cancel
3623	           REQUESTs for the same data that were sent to multiple peers
3624	           at the same time in time-critical situations.

3626	   -03        2012-10-22 Major revision

3628	       *   Updated Abstract and Introduction, removing download case.

3630	       *   Resolved Ticket #4: Added explicit CHOKE/UNCHOKE messages.

3632	       *   Removed directory lists unused in streaming.

3634	       *   Resolved Ticket #22, #23, #28: Failure behaviour, error codes
3635	           and dealing with peer crashes.

3637	       *   Resolved Ticket #13: Chunk ranges are the default chunk
3638	           addressing scheme that all peers MUST support.

3640	       *   Added a section on compatibility between chunk addressing
3641	           schemes.

3643	       *   Expanded the explanation of Unified Merkle Trees as a method
3644	           for content integrity protection for live streams.

3646	       *   Added a section on forgetting chunks in live streaming.

3648	       *   Added "End" option to protocol options and corrected bugs in
3649	           UDP encapsulation, following Karl Knutsson's comments.

3651	       *   Added SHA-2 support for Merkle Hash functions.

3653	       *   Added content integrity protection methods for live streaming
3654	           to the relevant protocol option.

3656	       *   Added a Live Signature Algorithm protocol option.

3658	       *   Resolved Ticket #24+27: The choice for UDP + LEDBAT as
3659	           transport has now been reflected in the draft.  TCP and RTP
3660	           encapsulations have been removed.

3662	       *   Superfluous parts of Section 10 on extensibility have been
3663	           removed.

3665	       *   Removed appendix with Rationale.

3667	       *   Resolved Ticket #21+25: PPSPP currently uses LEDBAT and the
3668	           DATA and ACK messages now contain the time fields it
3669	           requires.  Should other congestion control algorithms be
3670	           supported in the future, a protocol option will be added.

3672	   -04        2012-11-07 Minor revision

3674	       *   Corrected typos.

3676	       *   Added empty protocol option list when HANDSHAKE is used for
3677	           explicitly closing a channel in the UDP encapsulation.

3679	       *   Corrected definition of a range chunk specification to be a
3680	           single (start,end) pair.  To send multiple disjunct ranges
3681	           multiple messages should be used.

3683	       *   Clarified that in a range chunk specification the end is
3684	           inclusive.  I.e., [start,end] not [start,end)

3686	       *   Added PEX_REScert message to carry a membership certificate.
3687	           Renamed PEX_RES to PEX_RESv4.

3689	       *   Added a guideline about private and link-local addresses in
3690	           PEX_RES messages.

3692	       *   Defined the format of the public key that is used as swarm ID
3693	           in live streaming.

3695	       *   Clarified that a HANDSHAKE message must be the first message
3696	           in a datagram.

3698	       *   Clarified sending INTEGRITY messages ahead in a separate
3699	           datagram if not all necessary hashes that still need to be
3700	           sent and the chunk fit into a single datagram.  Defined an
3701	           order for the INTEGRITY messages.

3703	       *   Clarified rare case of sending multiple DATA messages in one
3704	           datagram.

3706	       *   Clarified UDP datagrams carrying PPSPP should adhere to the
3707	           network's MTU to avoid IP fragmentation.

3709	       *   Defined value for version protocol option.

3711	       *   Added small clarifications and corrected typos.

3713	       *   Extended versioning scheme to Min/max versioning scheme
3714	           defined in [RFC6709], Section 4.1, following Riccardo
3715	           Bernardini's suggestion.

3717	       *   Processed comments on unclear phrasing from Riccardo
3718	           Bernardini.

3720	       *   Added a guideline on when to declare a peer dead.

3722	       *   Made sure all essential references are listed as Normative
3723	           references following RFC3967.

3725	   -05        2013-01-23 Minor revision

3727	       *   Corrected category to Standards Track.

3729	       *   Clarified that swarm identifier is a required protocol option
3730	           in an initiating HANDSHAKE in the UDP encapsulation.

3732	       *   Added IANA considerations and tablised name spaces for
3733	           registry definition.

3735	   -06        2013-02-11 Minor revision

3737	       *   Updated "Overall Operation" to have more context (HTML5
3738	           video).

3740	       *   Clarified wording on PEX_REQ.

3742	       *   Clarified wording on SIGNED_INTEGRITY.

3744	       *   Added a reference on how ALTO can be used with PPSPP.

3746	       *   Added Manageability Consideration section following RFC5706.

3748	       *   Clarified that implementations SHOULD implement the "Unified
3749	           Merkle Tree" content integrity protection method for live,
3750	           and MAY implement "Sign All".

3752	       *   Made SHA1 hash function mandatory-to-implement as Merkle Tree
3753	           Hash function and explained the security considerations.

3755	       *   Made RSA/SHA1 mandatory-to-implement as Live Signature
3756	           Algorithm for integrity protection while live streaming.

3758	       *   Clarified that implementations MUST implement addressing via
3759	           32-bit chunk ranges.

3761	       *   Made LEDBAT an Informational reference to prevent a so-called
3762	           "down ref".

3764	       *   Updated reference to PPSP problem statement and requirements
3765	           document.

3767	       *   Used kibibyte unit in formal sections.

3769	   -07        2013-06-19 Revision following AD Review

3771	           Quoting the AD review by Martin Stiemerling: ***High-level
3772	           issues:

3774	           1) Merkle Hash Trees I have found the document very confusing
3775	           on whether Merkle Hash Trees (MHTs) and the for the MHT
3776	           required bin numbering scheme are now optional or mandatory.
3777	           Parts of the draft make the impression that either of them or
3778	           both or optional (mainly in the beginning of the document),
3779	           while Section 5 and later Sections are relying heavily on
3780	           MHTs.  My naive reading of the current draft is that you
3781	           could rely on start-end ranges for chunk addressing and MHTs
3782	           for content protection.  However, I do know that this
3783	           combination is not working.  If MHTs are really optional,
3784	           including the bin numbering, the document should really state
3785	           this and make clear what the operations of the protocol are
3786	           with the mandatory to implement (MTI) mechanisms.  The MHT,
3787	           bins, and all the protocol handling should go in an appendix.
3788	           There is a call to make for the WG: I do know that MHTs were
3789	           considered by some as burden and they have called for a
3790	           leaner way, i.e., the start-end ranges.  The call for the
3791	           leaner way has been implemented in the document but not
3792	           fully.

3794	           +   The text now states that MHTs SHOULD be used unless in
3795	               benign environments and are mandatory-to-implement.  It
3796	               also states that only start-end chunk range is mandatory-
3797	               to-implement, and bins are optional.

3799	           2) LEDBAT as congestion control vs. PPSPP The PPSP peer
3800	           protocol is intended for the Standards Track and relies in a
3801	           normative manner on LEDBAT (RFC 6817).  LEDBAT as such is an
3802	           **experimental** delay-based congestion control algorithm.  A
3803	           Standards Track protocol cannot normatively rely on an
3804	           Experimental congestion control mechanism (or RFC in
3805	           general).  There are ways out of this situation: i) Do not
3806	           use ledbat: this would call for another congestion control
3807	           mechanism to be described in the PPSPP draft. ii) Work on an
3808	           'upgrade' of the LEDBAT specification to Standards Track:
3809	           Possible, but a very long way. iii) Agree on having PPSPP
3810	           also as Experimental protocol.  I'm currently leaning towards
3811	           option iii), but this is my pure personal opinion as an
3812	           individual in the IETF.

3814	           +   A new paragraph has been added to Section 8.16 describing
3815	               the widespread use of LEDBAT in current P2P systems.
3816	               Hence, aim is a DOWNREF procedure.

3818	           3) No formal protocol message definition Section 7 and more
3819	           specific Section 8 describe the protocol syntax of the
3820	           protocol options and the messages, though Section 8 is
3821	           talking about UDP encapsulation.  Section 7 is hard to digest
3822	           if someone should implement the options, see also later, but
3823	           Section 8 is almost impossible to understand by somebody who
3824	           has not been involved in the PPSP working group.  See also
3825	           further down for a more detailed review of the sections.  To
3826	           give an example out of Section 8.4: This section describes
3827	           the HANDSHAKE message and gives examples how such a HANDSHAKE
3828	           message could look like.  But no formal definition of the
3829	           message is given leaving a number of thins unclear, such as
3830	           what the local channel number and what's the remote channel
3831	           number is.  This is implicitly defined, but that is not a
3832	           good way of writing Standards Track drafts.

3834	           +   We added the usual bit-based ASCII art representations.

3836	           4) Implicit use of default values There are a number of
3837	           places all over the draft where default values are defined.
3838	           Many of those default values are used when there are no
3839	           values explicitly signaled, e.g., the default chunk size of 1
3840	           Kbyte in Section 8.4 or Section Section 7.5. with the default
3841	           for the Content Integrity Protection Method.  I have the
3842	           feeling that the protocol and the surroundings (e.g., what
3843	           comes in via the 'tracker') are over-optimized, e.g., always
3844	           providing the Content Integrity Protection Method as part of
3845	           the Protocol options will not waste more than 2 bytes in a
3846	           HANDSHAKE message.  Further, I do not see the need to define
3847	           a default chunk size in the base protocol specification, as
3848	           this default can look very different, depending on who is
3849	           deploying the protocol and in what context.  This calls for a
3850	           more dynamic way of handling the system chunk size, either as
3851	           part of an external mechanisms (e.g. via the tracker) or in
3852	           the HANDSHAKE message.

3854	           +   Removed implicit defaults from protocol options.  Chunk
3855	               size is part of the content's metadata and thus
3856	               configurable.  The default 1KiB has been turned into a
3857	               recommendation.

3859	           5) Concept of channels The concept of channels is good but it
3860	           is introduced too late in the draft, namely in Section 8.3,
3861	           and it is introduced with very few words.  Why isn't this
3862	           introduced as part of Section 2 or Section 3, also in the
3863	           relationship to the used transport protocol?  I.e., the
3864	           intention is to keep only one transport 'connection' between
3865	           two distinct peers and to allow to run multiple swarm
3866	           instances at the same time over the same transport.  And how
3867	           do swarms and channels correlate?

3869	           +   Concept now introduced in Section 3 with a figure.

3871	           ***Technicals:

3873	           - Section 2.1, 2nd paragraph, about the tracker: I haven't
3874	           seen a single place where the interaction with a tracker is
3875	           discussed or where the tracker less operation is discussed in
3876	           contrast.  It is further unclear what type of information is
3877	           really required from a tracker.  A tracker (or a resource
3878	           directory) would need to provide more then IP address & port,
3879	           e.g., the used transport protocol for the protocol exchange
3880	           (given that other transports are allowed), used chunk size,
3881	           chunk addressing scheme, etc

3883	           +   Interaction with tracking facilities in general is
3884	               discussed in the Operations and Management section,
3885	               Section 12.1.1.  This also discusses swarm metadata and
3886	               information required from tracking facility.
3887	               Decentralized tracking in PPSPP is discussed in
3888	               Section 3.10.1.

3890	           - Section 2.3, the 1st paragraph, 'close-channel': This has
3891	           been the first time where I stumbled over the channel without
3892	           knowing the concept.

3894	           +   Rephrased.

3896	           - Section 3.1: ordering of messages The 1st sentence implies
3897	           that ordering of messages in a datagram matters a lot.  This
3898	           is outlined later in the document, but I would add this as
3899	           part of 3., i.e., the messages are processed in the strict
3900	           order or something along this line.

3902	           +   Phrase added.

3904	           - Section 3.1, 1st paragraph, options to include I would not
3905	           say anything about 'SHOULD include options' here, as this is
3906	           anyhow described in Section 8.

3908	           +   Phrase removed.

3910	           - Section 3.1, 2nd paragraph: "Datagrams exchanged MAY also
3911	           contain some minor payload, e.g.  HAVE messages to indicate
3912	           the current progress of a peer or a REQUEST (see Section
3913	           3.7)." to be added, just to make it clear IMHO: ", but MUST
3914	           NOT include any DATA message".

3916	           +   Added.

3918	           - Section 3.2, 2nd paragraph: "In particular, whenever a
3919	           receiving peer has successfully checked the integrity of a
3920	           chunk or interval of chunks it MUST send a HAVE message to
3921	           all peers it wants to interact with in the near future."
3922	           This looks like a place where a lot of traffic can be send
3923	           out of a peer, i.e., whenever a chunk arrives a HAVE message
3924	           must be sent.  I don't believe that this should be mandated
3925	           by the protocol specification, but there should guidance on
3926	           when to send this, e.g., peers might be also able to wait for
3927	           a short period of time to gather more chunks to be reported
3928	           in HAVE.  Or should in this case a single UDP datagram
3929	           contain multiple HAVEs?

3931	           +   Clarified that this is indeed controlled by a policy
3932	               outside the peer protocol that can decide to piggyback
3933	               onto other traffic or wait till multile chunks are
3934	               verified.

3936	           - Section 3.4 on ACKs This section looks pretty weak, as ACKs
3937	           may be sent but on the other hand MUST be sent if ledbat is
3938	           used.  I would simply say: - ACK MUST be sent if an
3939	           unreliable transport protocol is used - ACK MAY be sent if a
3940	           reliable transport protocol is used - keep clarification
3941	           about ledbat.

3943	           +   DONE.

3945	           - Section 3.5: Give text where INTEGERITY is described at
3946	           least for the MTI scheme.

3948	           +   DONE.

3950	           - Section 3.7, 2nd paragraph - all 'MAY' are actually not
3951	           right here.  Please remove or replace them with lower letters
3952	           if appropriate. - It is not clear what the 'sequentially'
3953	           means exactly.  Is it in the received order?
3954	           +   Rephrased MAYs.  "Sequentially" replaced with "received
3955	               order".

3957	           - Section 3.8: Please replace 'MAY' by can, as those are not
3958	           normative behaviors but more the fact that peers can, for
3959	           instance, request urgent data.

3961	           +   DONE.

3963	           - Section 3.9 Same comment as for the Section 3.8 just above
3964	           this comment.

3966	           +   DONE.

3968	           - Section 3.9 waiting for responses OLD " When peer B
3969	           receives a CHOKE message from A it MUST NOT send new REQUEST
3970	           messages and SHOULD NOT expect answers to any outstanding
3971	           ones."  NEW " When peer B receives a CHOKE message from A it
3972	           MUST NOT send new REQUEST messages and it cannot expect
3973	           answers to any outstanding ones, as the transfer of chunks is
3974	           choked."

3976	           +   DONE.

3978	           - Section 3.10.2 This whole section about PEX hole punching
3979	           reads very, very experimental.  The STUN method is ok, but
3980	           PEX isn't.  First of all, the safe behavior for a peer when
3981	           it receives unsolicited PEX messages, is to discard those
3982	           messages.  Second, this unsolicited PEX messages trigger some
3983	           behavior which may open an attack vector.  The best way, but
3984	           this needs more discussion, is to include to some token in
3985	           the messages that are exchanged in order to make avoid any
3986	           blind attacks here.  However, this will need more and
3987	           detailed discussions of the purpose of this.

3989	           +   We moved parts of the security analysis of PEX up, such
3990	               that all mechanisms are explained in the main text, and
3991	               the analysis of what attacks there are and how these
3992	               mechanisms prevent them is in the Sec. Considerations
3993	               section.

3995	           +   The section about hole punching was removed, lacking a
3996	               reference to the experiments we conducted with this exact
3997	               variant of the mechanism.

3999	           - Section 3.11 I don't see the 'MUST send keep-alive' as a
4000	           mandatory requirement, as peers might have good reasons not
4001	           to send any keep alive.  Why not saying 'A peer can send a
4002	           keep-alive' and it 'MUST use the simple datagram...' as
4003	           already described.  Though there is also no really need to
4004	           say MUST.

4006	           +   Now Section 3.12.  Rephrased and clarified the reason and
4007	               consequences of sending keep-alive msgs.

4009	           - Section 4 The syntax definition for each of the chunk
4010	           addressing schemes is missing.  This is not suitable for any
4011	           specification that aims at interoperable implementations.

4013	           +   We added the usual bit-based ASCII art representations.

4015	           - Section 4.3.2 PPSPP peers MUST use the ACK message if an
4016	           unreliable transport protocol is used.

4018	           +   DONE.

4020	           - Section 4.4 Has been tested in an implementation?  I would
4021	           like to understand the need for such a section, as in my
4022	           understanding a peer implementation should chose one scheme
4023	           and support this and there shouldn't be the need to convert
4024	           between the different schemes.

4026	           +   Yes, the reference implementation translates from chunk
4027	               ranges on the wire to bins internally.  However, for
4028	               simplicity we now state that all peers in a swarm MUST
4029	               use the same method and the compatibility section has
4030	               been removed.

4032	           - Section 5 This reads that MHTs are mandatory to implement
4033	           while the document makes the impression that MHTs are
4034	           optional.

4036	           +   Rephrased, see High-level issues.

4038	           - Section 5.3 " so each datagram SHOULD be processed
4039	           separately and a loss of one datagram MUST NOT disrupt the
4040	           flow" The MUST NOT is not a protocol specification
4041	           requirement, but more an informative part saying that a lost
4042	           message shouldn't impact the protocol machinery, but it can
4043	           impact the overall operation.  What is the flow here in that
4044	           sentence?

4046	           +   Rephrased.

4048	           - Section 5.6.2.  An illustrative example explaining how the
4049	           automatic size detection works is required here.

4051	           +   Added a paragraph with an example that follows the figure
4052	               used during the explanation.  A state diagram could also
4053	               be added, but might be a bit redundant.

4055	           - Section 6.1, 4th paragraph: Where do I find the 1 byte
4056	           algorithm field in the swarm ID?  The swarm ID is not really
4057	           defined in a single place.

4059	           +   Expanded.  Added a formal definition.

4061	           - Section 7.3 The described min/max versioning relies on the
4062	           fact that there are major and minor version numbers.  I
4063	           cannot find any major and minor version number scheme in the
4064	           draft.

4066	           +   Actually, it does not.  There is a single unstructured
4067	               version number.

4069	           - Section 7.4, Length field It is not clear what the 'Length'
4070	           field is referring to.  Further, it is not clear of the swam
4071	           IDs are concatenated in one swarm ID option, of each swarm ID
4072	           must be placed in a separate swam ID option.

4074	           +   Clarified.

4076	           - Section 7.6 MHTs are mandatory to support though MHTs are
4077	           optional?

4079	           +   Clarified.

4081	           - Section 7.7 'key size ... derived from the swarm ID'.  This
4082	           relates to my high level comment no 4. on the use of implicit
4083	           information.  Either it is clearly specified how this
4084	           information is derived or there is a protocol field/
4085	           information about the size.

4087	           +   Key size derivation procedure added to description of
4088	               SIGNED_INTEGRITY in UDP encapsulation.

4090	           - Section 7.8 I would recommend to say that the default MUST
4091	           be supported, but the peer must always signal what method it
4092	           is supporting or at least using.

4094	           +   Corrected, see High-level issues 4.)
4095	           - Section 7.10 I have not understood how the 'Lenght' field
4096	           relates to the message bitmap and how long the message bitmap
4097	           can grow.  The figure looks like a maximum of 16 bits?

4099	           +   Clarified.

4101	           - Section 8 I do not see the value of the text in the preface
4102	           of Section 8.  I would say that this text should say what is
4103	           mandatory and what's not, i.e., MUST use UDP and MUST use
4104	           LEDBAT.  Potentially saying that future protocol versions can
4105	           also run over other transport protocols.

4107	           +   Adjusted.

4109	           - Section 8.1 about Maximum Transfer Unit (MTU) The text is
4110	           discussing that a Ethernet can carry 1500 bytes.  This is
4111	           true, but the Ethernet payload is not the normative MTU
4112	           across all of the Internet.  For IPv6 the min MTU is 1280
4113	           bytes and for IPv4 it is 576 bytes, though for IPv4 it can be
4114	           theoretically much lower at 64 bytes.  It would move the
4115	           definition of the default chunk size to a recommendation with
4116	           text saying that this size has a high likelihood to travel
4117	           end-to-end in the Internet without any fragmentation.
4118	           Fragmentation might increase the loss of complete chunks, as
4119	           one lost fragment will cause the loss of a complete chunk.
4120	           One way of getting an informed decision on whether chunks can
4121	           travel in their size is to use the Don't Fragment (DF) bit in
4122	           IPv4 and also to watch for ICMP error messages.  However,
4123	           ICMP error messages are not a reliable indication, but they
4124	           can be some indication.

4126	           +   1 KiB chunk size has been made a recommendation.

4128	           +   Added a small paragraph discussing the optional
4129	               integration of MTU path discovery.

4131	           - Section 8.1 Definition of the default chunk size There is
4132	           no need to define a default chunk size, if the chunk size
4133	           would be always signaled per swarm.  This is another default/
4134	           implicit value places that is unnecessary.

4136	           +   The chunk size is always part of the content's metadata.

4138	           - Section 8.3: see also my comment no 3.  The concept of
4139	           channels is introduced very late and with few words.  A
4140	           figure to explain the concept will help a lot and also more
4141	           formal text on what a channel is and how they are identified.
4142	           Also what the init channel is.

4144	           +   Concept now introduced in Section 3.11.

4146	           - Section 8 in general: There is no formal definition of the
4147	           messages, just bit pattern examples.

4149	           +   We added the usual bit-based ASCII art representations.

4151	           - Section 8.4 (as example for the other Sections in 8.x): i)
4152	           What is the '(CHANNEL' paramter?  Is it actually a parameter?
4153	           ii) it is implicit that the first channel no (0000000) is the
4154	           remote peer's channel and that the second channel no
4155	           (00000011) is the local peer's channel, right?  This isn't
4156	           clear from the text, but my guess.

4158	           +   We added the usual bit-based ASCII art representations.

4160	           - Section 8.5 Can HAVE messages multiple bin specs in one
4161	           message or do I have to make a HAVE message for each bin?

4163	           +   Clarified.

4165	           - Section 8.6 What is the formal defintion of a DATA message?
4166	           That's completely missing or I have not understood it.

4168	           +   We added the usual bit-based ASCII art representations.

4170	           - Section 8.7 looks just underspecified, especially as this
4171	           is the link to LEDBAT.

4173	           +   Implementors will unfortunately need to read the full
4174	               LEDBAT specification.

4176	           - Section 8.11 How are the chunks specified here?  The formal
4177	           syntax definition or reference to one is missing.

4179	               We added the usual bit-based ASCII art representations.

4181	           - Section 8.13 I'm lost on this section, as I haven't fully
4182	           understood the concept of the PEX in this document.
4183	           Especially not why there is the PEX_REScert.

4185	           +   We moved parts of the security analysis of PEX up into
4186	               3.10, such that all mechanisms are explained in the main
4187	               text, and the analysis of what attacks there are and how
4188	               these mechanisms prevent them is in the Sec.
4189	               Considerations section.

4191	           - Section 11 The RFC required for protocol extensions of a
4192	           standards track protocol looks odd.  This must be at least
4193	           IETF Review or Standards Action.

4195	           +   Policy changed to "IETF Review" and the section was
4196	               extended with information about data types and required
4197	               information.

4199	           ***Editorials:

4201	           - Abstract (and probably also other places), 1st sentence of,
4202	           PPSPP is not a transport protocol, just a protocol

4204	           +   DONE.

4206	           - Section 1.1, 4th paragraph: I would remove the reference to
4207	           rmcat, as it is not yet clear what the outcome of the rmcat
4208	           wg will be

4210	           +   DONE.

4212	           - Section 1.3, on page 8, about seeding/leeching: I would
4213	           break it in to sub-bullets.

4215	           +   DONE.

4217	           - Section 2.1 and following: These are examples, isn'it?  If
4218	           so, this should be mentioned or clarified.

4220	           +   DONE.  All subsections now labeled "Example:".

4222	           - Section 2.1: What is the PPSP Url?

4224	           +   Reformulated in terms of "Imagine there is a PPSP URL".

4226	           - Section 2.3, the 1st paragraph, detection of dead peers: It
4227	           would be good to say where this detection is described in the
4228	           remainder of the draft.  Just for completeness.

4230	           +   DONE.  Dead peer detection is now a separate section and
4231	               referenced here.

4233	           - Section 2.2, the very last paragraph, 'Peer A MAY also':
4234	           This 'MAY' is not useful here.  I would just write 'Peer A
4235	           can also', as there is nothing normative described here.

4237	           +   DONE.

4239	           - Section 3.2, last paragraph: What is the latter
4240	           confinement?  This is not clear to me.

4242	           +   Rephrased.

4244	           - Section 3.9, last sentence I am not sure to what the
4245	           reference to Section 3.7 is pointing in this respect.

4247	           +   Rephrased.

4249	           - Section 3.10.1 about PEX messages The text says 'PPSPP
4250	           optionally features...'.  I have not understood if this
4251	           optionally refers to mandatory to implement but optionally to
4252	           use, or if the PEX messages are optionally to implement.

4254	           +   Made it clear that is OPTIONAL and not mandatory-to-
4255	               implement.

4257	           - Section 3.12 I'm not sure what this section is telling
4258	           exactly.  Isn't just saying that PPSPP as such does not care
4259	           how chunks are stored locally, as this is implementation
4260	           dependent?

4262	           +   Yes. Removed.

4264	           - Section 4.2, page 15, 1st paragraph: OLD 'A PPSPP peer MAY
4265	           support' NEW 'The support for this scheme is OPTIONAL'

4267	           +   DONE, for byte ranges as well.

4269	           - Section 6.1.1 This section is not describing sign-all, but
4270	           rather a justification why it may still work.  This doesn't
4271	           help at all.

4273	           - Section 7, 1st paragraph Why is there a reference to RFC
4274	           2132?

4276	           +   Removed, just similarity in format.

4278	           - Section 7 in general i) It is common to give bit positions
4279	           in the figures where the syntax of options is described.
4280	           This allows to count how many bits are used for a protocol
4281	           field more easily and also way more reliable. ii) Please add
4282	           also Figure labels to the syntax definitions of the options.
4283	           This makes it easier to reference them later on if needed.

4285	           - Section 8.1 1 kibibyte is 1 kbyte?
4286	           +   Mentioned base 1024 in Terminology.  Changed to 1024
4287	               bytes where appropriate.

4289	           - Section 8.2, last paragraph i ) "All messages are
4290	           idempotent" in what respect? ii) "or recognizable as
4291	           duplicates" but how are the recognized as duplicates?

4293	           +   Idempotent means that processing a message twice does not
4294	               lead to a different state than processing them once.
4295	               Resent handshakes can be recognized as duplicates because
4296	               a peer already recorded the first connection attempt in
4297	               its state.  Updated text.

4299	           - Section 8.5, last sentence in brackets: What is this last
4300	           sentence about?

4302	           +   Was explanation of the on-the-wire bytes shown.

4304	           - Section 8.13 " If sender of the PEX_REQ message does not
4305	           have a private or link-local address, then the PEX_RES*
4306	           messages MUST NOT contain such addresses [RFC1918][RFC4291]."
4307	           What is this text saying?  Do not include what you do not
4308	           have anyway?

4310	           +   Rephrased.  It tries to say that internal addresses must
4311	               not be leaked to external peers.

4313	           - Section 8.14 There is no single place where all the
4314	           constants are collected and also documented what the default
4315	           values or the recommended values.  For instance in this
4316	           Section 8.14 where the dead peer time out is set to 3 minutes
4317	           and also the number of datagrams that should have sent.  I
4318	           would make a section or subsection to discuss dead peers and
4319	           how they are detected and just link to the keep-alive
4320	           mechanism in Section 8.14.

4322	           +   The Section 12.1.6 section was rewritten for this in the
4323	               Ops & Mgmt part.

4325	           - Section 11 This section needs to be overhauled once the
4326	           document is ready for the IESG.  The section is not wrong but
4327	           can be improved to help IANA.

4329	           +   The section was extended with information about data
4330	               types and required information.

4332	   -08        2013-08-8 Continued Revision following AD Review

4334	           Please see the -07 entry for our responses to the comments.

4336	           Added ECDSAP256SHA256 and ECDSAP384SHA384 as mandatory-to-
4337	           implement live signature algorithms, as they provide small
4338	           swarm IDs.

4340	           Added line that a peer SHOULD NOT send HAVEs to peers that
4341	           already have the complete content (e.g. in video-on-demand
4342	           scenarios).

4344	           In response to a remark at WG meeting at IETF 87 we added a
4345	           paragraph on OPTIONAL MTU discovery using PPSPP messages to
4346	           Section 8.1.

4348	Authors' Addresses

4350	   Arno Bakker
4351	   Vrije Universiteit Amsterdam
4352	   De Boelelaan 1081
4353	   Amsterdam,   1081HV
4354	   The Netherlands

4356	   Phone:
4357	   Email: arno@cs.vu.nl

4359	   Riccardo Petrocco
4360	   Technische Universiteit Delft
4361	   Mekelweg 4
4362	   Delft,   2628CD
4363	   The Netherlands

4365	   Phone:
4366	   Email: r.petrocco@gmail.com

4368	   Victor Grishchenko
4369	   Technische Universiteit Delft
4370	   Mekelweg 4
4371	   Delft,   2628CD
4372	   The Netherlands

4374	   Phone:
4375	   Email: victor.grishchenko@gmail.com